How do you investigate security incidents in Active Directory? Is the investigation only at the Active Directory level? or may it include the endpoint? Is it through an interface or CLI? Adversaries love Active Directory, and as we can see, many APT groups adopt Active Directory as part of the attack chain. Their other platforms that need to be part of the investigation? Such as mail, applications, data, and others.

This post focuses on Active Directory Kill-Chain, the attack surface with Microsoft Defender for Identity, and the investigation approach, including many valuable queries. This post is an introduction to the investigation post.

Active Directory Kill-Chain

We can’t talk about AD Security without Kill-Chain, because we must attach the attack chain and surface to Active Directory and connect it to Defender for Identity, the investigation approach, and the options we’ve got. So, let’s start with the little things.

Active Directory Domain Services (ADDS) is the backbone of identities for many environments worldwide. It’s often not managed well, which opens the doors for adversaries to compromise it – Sometimes in a concise time. Active Directory Domain Services is full of delegated rights and permissions that grant privileges to security principals. Some permissions with these objects are more sensitive than others and should be kept only for privileged accounts.

Recent cyber-attacks target the vulnerable Active Directory used in enterprise networks where the organization handles thousands of objects in a single point – one of the primarily targeted services by the APT groups. Though manipulating the Active directory is challenging, It’s sure to activate the directory exploitation cheat sheet, which contains attack methods, including the several following phases to simplify it.

Active Directory Kill Chain is separated into many topics. Here are the main ones.

• Recon & Enum
• Privilege Escalation
• Admin Privileges
• Data Exfil
• Lateral Movement

Today, many organizations connect and sync Active Directory Domain Services to the cloud with Azure AD and, by default, expand the risks, gaps, and security issues. The fact that Active Directory Domain Services is hackable is known to everyone and especially to the attackers. In Hebrew, a situation for hybrid Identity is called “to mix joy with other joy.”

The following AD KillChain provides the known cycle that can lead to persistence.

Attack Surface

Reducing the attack surface on Active Directory deployment isn’t an easy task. It requires careful planning, implementation, and control validation in some scenarios. It can take a lot of time and effort. Based on my experience with the pre-breach phase and post-breach remediation, an incremental approach focused on immediate, tactical, and strategic measures is most effective. The Active Directory Domain Services (ADDS) attack surface is vast, and every environment is exposed to many attack= scenarios! One of the known attacks that utilize Active Directory Domain Services is Ransomware.

Rather than the lack of distinction, automated attacks historically associated with Ransomware, modern attackers carry out human-operated ransomware campaigns that utilize tools like BloodHound, Mimikatz, and PowerSploit to gather helpful information about the Active Directory environment, steal credentials, and move deeper into the network.

Suppose we take, for example, the Ryuk ransomware, which the security community has linked to multiple attack campaigns in recent years. In many of these targeted environments, Ryuk was the final payload, but the attack began with TrickBot or Emotet. That malware would, in turn, download tools like Cobalt Strike or PowerShell. The threat actors would then conduct recon and steal creds.

More about the Weaponization of Active Directory: An Inside Look at Ransomware Attacks Ryuk, Maze, and SaveTheQueen by Semperis

This type of attack isn’t unique to Ryuk. Adversaries using the other Ransomware follow a similar pattern by deploying the ransomware post-compromise and perpetrating data theft. Recently, the Ransomware was linked to an attack on Virginia’s Fairfax County public school system. In an analysis of Maze from May 2020, researchers at FireEye noted that malicious emails and RDP were observed among the initial methods of compromise, and the attackers sought to gain access to multiple domains and local system accounts.

In another Active Directory attack, security researchers spotlighted a tension of Ransomware dubbed SaveTheQueen that has been observed using the SYSVOL share on Active Directory to propagate throughout the environment. Accessing the SYSVOL share – used to deliver policy and logon scripts to domain members – typically requires elevated privileges and indicates a severe Active Directory compromise.

Active Directory Vulnerabilities – Over the lengthy lifespan of Windows Server and Active Directory, numerous vulnerabilities have been identified with low to critical scores on the CVSS scale. Security analysts track these vulnerabilities for disclosures, testing, and fix validations. However, the issue is that deploying a patch and ensuring that the Active Directory infrastructure is always on the latest release is a non-trivial task for any enterprise and leaves the infrastructure vulnerable to attacks.

MIcrosoft XDR 4 Investigation

Now that we have freshened our memory with some Active Directory attacks and the Kill-Chain we can move forward to the Microsoft Defender for Identity and Defender for Endpoint and the advantage as part of the Microsoft XDR.

As a DFIR guy, the investigation and response are crucial for many reasons. The Microsoft Defender, or may I call it the Microsoft XDR, provides the power to investigate and respond with various tools, such as Identity, endpoint, applications, data, and much more. Suppose we focus on the incident part with Microsoft Defenders. In that case, we should say that it is a collection of correlated incidents, alerts, and associated data that make up the story of an attack.

Microsoft 365 Defender services and apps create alerts when they detect a suspicious or malicious event or activity. Individual alerts provide valuable clues about a completed or ongoing attack. However, attacks typically employ various techniques against different entities, such as devices, users, and mailboxes.

The result is multiple alerts for multiple entities in your tenant. Because piecing the individual alerts together to gain insight into an attack can be challenging and time-consuming, Microsoft 365 Defender automatically aggregates the alerts and their associated information into an incident.

Grouping related alerts into an incident give you a comprehensive view of an attack. For example, you can see the following:

• Where did the attack start?
• What tactics were used?
• How far has the attack gone into your tenant?
• The scope of the attack, such as how many devices, users, and mailboxes were impacted.
• All of the data is associated with the attack.

The primary artifacts of an incident are:

Image source: MDI playbook from Microsoft DOCS

• Alerts & incidents – All the alerts & incidents related to the incident and their information.
• Devices – All the devices that have been identified to be part of or related to the incident.
• Users – All the users that have been identified to be part of or related to the incident.
• Investigations – Alerts in the incident trigger all the automated investigations.
• Evidence and Response – All the supported events and suspicious entities in the incident alerts.

Investigation Workflow

Here’s a specific example workflow for responding to incidents with the Microsoft 365 Defender and the for each stage.

Learn Days by MDI

Typically, cyberattacks are launched against any available or exposed object, such as a low-privileged user or SPN, and then find a way to move laterally until they gain access to valuable assets. A valuable asset can be sensitive accounts, domain administrators, etc.

Microsoft Defender for Identity can identify these advanced threats at the source throughout the entire attack kill chain and classifies them into the following phases:

1. Reconnaissance
2. Compromised credentials
3. Lateral Movements
4. Domain dominance
5. Exfiltration

You must know the scope of the breach for each phase and the suggested remediation and steps for prevention. On top of that, you need to add your experience and the big picture of the attacked environment. First, keep in mind that MDI works on the following attack phases:

Then be aware that MDI needs machine learning before generating alerts/incidents and the evidence. For example, the following alerts require a learning period for each phase.

MDI Learn Days – Alerts Timeline

To allow Defender for Identity to profiling and learn legitimate objects, no alerts are triggered in the first days following the deployment phase. Once the initial learning phase is completed and even part of it. The alerts are generated on entities that perform suspicious actions, such as LDAP enumeration queries or actions targeted to sensitive groups.

Reconnaissance  

• Security principal reconnaissance (LDAP) – 15 days
• User and group membership reconnaissance (SAMR) – 4 weeks
• Network mapping reconnaissance (DNS) – 8 days 

Compromised Credential  

• Suspected brute force attack (Kerberos, NTLM) – 1 week
• Suspicious VPN connection – 30 days

Domain Dominance

• Suspected Golden Ticket usage (encryption downgrade) – 5 days
• Suspicious additions to sensitive groups – 4 weeks
• Suspected skeleton key attack (encryption downgrade) – After the first usage

Note: Lateral Movement and Exfiltration – No Machine Learning for all alerts – Per October 2022.

For the MDI alerts that require the learn days, you must wait 30 days after your complete MDI installation before starting a playbook, red-team operation, or pentesting. If you perform all your tests from the same machine or account, MDI won’t probably generate all new alerts triggered by this security context because of machine learning.

Remove learning period

Some of the Microsoft Defender for Identity alerts rely on learning periods to build a profile of patterns and then distinguish between legitimate and suspicious activities. This setting allows you to control whether to see alerts during the learning period before the profile has been built. Changing this setting will increase the number of alerts, some of which are legitimate traffic and activities.

The alerts generated by Defender for Identity are based on various factors such as profiling, deterministic detection, machine learning, and behavioral algorithms that it has learned about your network. The entire learning process for Defender for Identity can take up to 30 days per domain controller. However, there may be instances where you would like to receive alerts even before the full learning process has been completed.

The Power of Investigation

Now that we are more familiar with the AD Kill-Chain, the attack surface, we can go to the next level and hunt for attacks or investigate a security incident.

Microsoft Defender for Identity provides findings, artifacts, and evidence when users or devices have performed suspicious activities and show signs of being compromised. This investigation shows the security alerts and detections. The following example can give recommendations and help you determine the risks and how to investigate them.

In this investigation, I ran the actions below:

Hunting Tables

Defender for Identity provides a few tables in the advanced hunting schema containing information about queries performed against Active Directory objects. The tables are:

The IdentityLogonEvents table in the advanced hunting schema contains information about authentication activities made through your on-premises Active Directory captured by Microsoft Defender for Identity and authentication activities related to Microsoft online services captured by Microsoft Defender for Cloud Apps. It covers Azure AD logon activities tracked by Defender for Cloud Apps, specifically interactive sign-ins and authentication activities using ActiveSync and other legacy protocols.

The IdentityDirectoryEvents table in the advanced hunting schema contains events involving an on-premises domain controller running Active Directory. This table captures various identity-related events, like password changes, expiration, and UPN changes. It also captures system events on the Domain Controller, like the scheduling of tasks and PowerShell activity.

The IdentityInfo table in the advanced hunting schema contains information about user accounts obtained from various services, including Azure Active Directory.

The IdentityQueryEvents table in the advanced hunting schema contains information about queries performed against Active Directory objects, such as users, groups, devices, and domains.

Remember that other tables, such as AlertInfo, and AlertEvidence, can be part of the investigation. Each table depends on the investigation type and the information within.

I know what you did last SAMR 🤔

Now that we have recon information on the Defender for Identity, I can hunt for Account enumeration reconnaissance. The Investigation via KQL can be with Advanced Hunting or Microsoft Sentinel. The first action can be the search for the alert or incident. The hunting can be based on the Specific table or vis search command.

Once we get the incident and the information, we can move forward.

The Alert and Evidence tables provide a lot of information and even evidence. For example, the AdditionalFields or All Details can start the story about the incident:

• EdgeRole
• MDIOriginalEntity
• EvidenceRole
• EvidenceDirection
• Category

Those are the artifacts we have got. We must note them as part of the story. As mentioned, the simulation was to discover and Recon, so we received this information from the AlertInfo table.

Now that we know what we are looking for, we can go to the next step and search for tactics, the action itself, and other information on the alert. Let’s search for the actions themselves. In this situation, we search for the IdentityQueryEvents table, which contains information about queries performed against Active Directory objects.

The query must search for malicious actions and part of the enum and discover actions. We can check for known actions or search for any query type for any protocol with the following query Search-Recon-Enum-AD.

From this query, we have a lot of findings that can be part of the story:

Those actions and searching for evidence and malicious actions are at a high level. You can dig into the investigation with the Microsoft XDR console to get more evidence and artifacts that can lead to the patient zero.

Hunting 4 MDI

Below are a few queries that can help you on a day to day. Open your Advanced Hunting console and start hunting.

IdentityLogonEvents
| where ActionType == “LogonFailed”
| where Application == “Active Directory”
| where Protocol == “Kerberos”
| summarize count() by FailureReason

For more queries, visit MDI Hunting on GitHub

References

Active Directory Kill Chain Attack and Defense

Reconnaissance playbook with MDI