Persistence (Part 1)

By Ashwin Venugopal -

 






Overview

Deploying persistence by a penetration tester is important during penetration testing assessment. Hence, implementing persistence throughout the AD compromise process, the tester can ensure that his access cannot easily be revoked by the blue team. 

Credentials

It is one of the most common but least reliable persistence techniques. DC sync is a process in which AD DC exchange updates and replicate data with each other. Each DC runs a Knowledge Consistency Checker (KCC) that generates a replication topology for the AD forest. Also, it automatically connects to other domain controllers via Remote Procedure Calls (RPC) to synchronize information. It contains updated information like the user's new password and new objects such as when a new user is created. DC sync attack is very popular. If the penetration tester has access to an account that has domain replication permissions, he can stage a DC Sync attack to harvest credentials from a DC.

Tickets

Golden Ticket

AD environments are the target of golden ticket attacks, a subset of advanced persistent threat (APT) attacks. By generating a fake Kerberos ticket, a penetration tester can utilize them to enter a domain without authorization and stay active on the network. A ticket for Kerberos is a digital token that a DC issues to a user or service account so they can use it to log in and access domain resources. Golden tickets are used to authenticate users in an AD environment by taking advantage of the way Kerberos tickets are issued.

After obtaining the golden ticket, the penetration tester can use it to authenticate as any user inside the domain and gain access to all resources, including private information and vital systems, that the account is permitted to access. This can allow the attacker to remain undetected while moving laterally around the network, exfiltrating data or delivering malicious payloads. Since golden tickets look just like real Kerberos tickets, they can be challenging to identify.

Silver Ticket

Similar to golden tickets, silver tickets are a kind of APT assault. A penetration tester can generate a fake Kerberos service ticket called a "silver ticket" by utilizing the encryption key, service account name, and Service Principal Name (SPN) from a compromised service account. Using this knowledge, the penetration tester can fabricate a new service ticket with fictitious data that appears just like a genuine service ticket.
 
After obtaining the silver ticket, the penetration tester can use it to access any resources that the service account is permitted to access and authenticate to a particular service, such as a file server, web server, or terminal server. This will allow him to navigate the network laterally while staying undetected. Silver tickets are also hard to identify.

Certificates

The penetration tester requires a valid certificate for client authentication. It will allow him to use the certificate to request a TGT. This way he can continue to order TGTs irrespective of the number of rotations they do on the account being attacked. He can only be kicked out if he himself revoke the certificate he generated or it expires. This means, he will have persistent access for roughly next 5 years, by default.

Stealing the private key of the root CA's certificate is another way to generate certificates on demand. Since these certificates are not issued by the CA, the blue team cannot revoke them. This will mean the rotation of CA, i.e., all the issued certificates should be revoked to kick the penetration tester out. 

These techniques are incredibly invasive and hard to remove. Even the penetration tester has to signoff on his red team exercise to perform these techniques. Mostly, the red team exercise will be dechained instead of using them. Hence, most likely these persistence techniques are not to be performed but rather simulated. 

Conclusion

This part talks about the various persistence techniques and usages. 



















































Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Project Resourcing (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here Engineering - SIEM The SIEM engineers configures Microsoft Sentinel, including Log Analytics, Logic Apps, workbooks, and playbooks. They are also responsible for the following high-level tasks: Initial configuration of Azure tenant, including provisioning required resources, assigning access roles, and configuring workspace parameters like log retention, resource tagging, and blueprints.  Deployment and configuration of syslog/CEF log collection agents in appropriate locations to collect logs from on-premises devices. Generally, it will be joint effort of both system engineer and SIEM engineer, involving configuration and potential troubleshooting.  Working with system owners to enable log forwarding and configuring any required parsing of log data in Log Analytics.  Working with security operations to create and deploy KQL analytic rules to offer detections for SOC/Computer Security Incident Response Team (CSRIT) use. Tuning...
Read more