Analysis of OPSEC, MDI, and Active Directory operations

What differentiates CTF players, to real-world penetration testers, red-teamers and likes

What differentiates CTF players from real-world penetration testers, red-teamers, and the like?

1. EXECUTIVE SUMMARY

2. ABOUT MDI

3. RECONNAISANCE PHASE

4. CREDENTIAL ACCESS PHASE

5. LATERAL MOVEMENT PHASE

6. DOMAIN DOMINANCE PHASE

7. AD CS & HYBRID IDENTITY

8. ABUSE RESPONSE ACTION (SKIP IT IF YOU WANT)

9. CONCLUSION

10. A TABLE SUMMARISING THE ENTIRE ARTICLE

11. REFERENCES

EXECUTIVE SUMMARY

The adversarial dynamics within the Windows Active Directory environments have shifted from a contest of exploitation and taking over to more of a behaviour mimicry. Microsoft Defender for Identity (MDI) (formerly known as Azure Advanced Threat protection aka ATP), is the current APEX of Microsoft's on-premises identity security stack.

It leverages advanced techniques like Deep Packet Inspection(DPI), Event Tracing for Windows (ETW), and proprietary user profiling algorithms. MDI aims to detect advanced threats across the Cyber Kill Chain (Recon > Initial access phase > Lateral Movement phase > Domain dominance phase > Exfiltration phase ) by identifying anomalies in user behaviour and protocol usage. HOWEVER there are some structural limitations in MDI's detection logic. These are not like bugs in code or glitches, but the byproducts of MDI's sensor-based architetural model a system that relies heavily on "normality" and specific interaction patterns with the Domain Controller (DC)

So this blog is about MDI's architecture, detection capabilitiesm and specific tradecraft employed to bypass these controls. **The core aim of this blog is not be a careless attacker **.

In very short, know your tools, don't use off-the-shelf tools and techniques, do not disregard Operational Security (OpSec), and read about TTPs used by sophisticated actors. AND BE PATIENT

---

1. Identity-Centric Detection: Architectural Foundations of MDI

FOUNDATIONS OF MDI

To understand how to bypass MDI, we'll first understand what it sees, detects, analyse and more importantly, what it ignores. As I said,d and this is a very important point to keep in mind, nd MDI operates on a sensor-based paradigm, moving the point of detection from the endpoint (the land of EDR), to the source of identity, i.e., the Domain Controller.

1.1 SENSOR-CLOUD HYBRID MODEL

The MDI sensor is installed directly on Domain Controllers, Active Directory Federation Services (AD FS), Active Directory Certificate Services (AD CS) servers, and Microsoft Entra Connect servers. The sensor is responsible for capturing two primary types of info-

1. Network traffic - parses traffic from specific ports, including Kerberos, NTLM, RPC, SMB, LDAP, and DNS.

2. Windows Events - The sensors ingest specific windows events logs (like - 4769, 4624, etc check MDI documentations for more) to correlate network traffic with authentication events. The data is PARSED > ENCRYPTED > TRANSMITTED TO THE Microsoft Defender Cloud service (Azure), in the cloud where the profiling engine builds a dynamic behavioral profile for entities (users and computers) in the network. It establishes a baseline of "normal" behaviour, like typical login hours, source workstations, resource access patterns, etc.

1.2 THE DC-CENTRIC BLIND SPOT

The fundamental limitation of MDI is that it is too DC-Centric. MDI generally only sees the traffic that hits the Domain Controller. If an attacker can perform an action that does not require interaction with the DC (like a silver ticket attack against a file server), the MDI is blind to it. MDI also assumes that DC is a "heavily-monitored" entity and relies on the assumption that attackers must intact with the DC to enumerate or move further in the Cyber Kill Chain.

1.3 "CARELESS" ATTACKERS

MDI's detection logic often relies on high thresholds or specific noisy indicators. So, a careless attacker is someone who

• Uses a default/off-the-shelf tool that doesn't respect OpSec and generates massive LDAP queries

• Violate the domain's kKerberospolicy (like forging a ticket with infinite lifetimes)

• Rush the process, and don't pay attention to details like using RC4 in modern environments (which triggers "Encryption Downgrade" alerts).

• Leave obvious event log signatures by creating new services for lateral movement, et.c

• "Hacker Tools" (BloodHound, SharpHound) is dangerous not because of what they do, but how they do it (unoptimized queries, unique binary signatures).

Evasion is not about finding zero-day vulnerabilities in MDI, or anything too complicated, but rather about being patient, careful, and adhering to strict OpSec.

---

2. RECONNAISSANCE: THE ART OF SCOUTING SILENTLY

Reconnaissance is the phase where the attackers map the terrain. In an MDI-protected environment, active and rushed scanning is the quickest way to burn an operation. MDI monitors for 3 primary recon vectors-

1. LDAP enumeration

2. SAMR queries

3. SMB session mapping

2.1 LDAP RECON

One of the most sensitive detectors in MDI is the one for LDAP queries;t he detection is designed to catch attackers looking for specific toxic attributes in making an LDAP query, which differs from the everyday usage (and rightly so)

THE TRIGGER MECHANISM

1. Enumeration patterns: High-Volume queries dumping large datasets (eg, objectclass=* )

2. Attribute Targeting: Queries targeting specific attributes known for further attacks (eg. admincount=1, servicePrincipalName=*, userPassword, and more)

3. Honeytoken Activity: MDI allows the configuration of honeytoken accounts, fake entities that look valuable, but should never used. LDAP Queries targeting a simple honeytoken account (even a simple lookup) triggers high-severity alert.

4. Source Anomaly: MDI correlates the LDAP query with the source IP and computer account, the patterns learnt initially in the learning phase set the baseline for the behavior patterns,(eg.,workstations that perform only basic user auth suddenly execute a complex LDAP query)

5. Process Context: MDI monitors which processes initiate the network traffic. Unusual processes making network calls can trigger alerts even if the query is valid. (tThisis for when MDE is also installed in the endpoint devices, and the two are linked in the XDR portal)

EVASION METHODS

The attempts to evade detection focuses the speed, behaviour, and the source of the traffic.

1. Rate Limiting: Be Low & Slow, M,DI and even other UEBA systems do not rely solely on short-term thresholds. They maintain long-term statistical profiles. Even if the enumeration is slow, but originates from a user account that has never queried those before objects before, or deviates from the baseline personality that the system has created, such activity remains suspicious.

2. Blending In: If a user in "marketing" group executes a PowerShell script that queries servicePrincipalName, or any other suspicious attribute, MDI will flag is because it conflicts with the user's peer group profile.

3. Efficient queries: Malicious enumeration tools, like bloodhound ingestors often ignores OpSec entirely and queries about everything (*). Legit applications are usually coded to ask only what is needed, i.e very specific queres like -(|(mail=*)(telephoneNumber=*)).

4. Filter offline: Even if you do request for broad set of objects, parse the data to your machine and filter the data offline.

5. Sensor disruption: In advanced scenarios, techniques like DNS redirection to block sensor telemetry transmission to the cloud without alerting the sensor itself, or patching event logging providers to suppress LDAP-related ETW traces. This requires domain controller access and carries high risk of detection by other defenses .This one is just so you know, dont do this in production environments, matter of fact don't do anything like this, which might affect the business servers.

2.2 SAMR (User & Group membership recon)

SAMR (Security Account Manager Remote) protocol is a legacy method for querying local users and groups on a remote machine.

THE TRIGGER MECHANISM

1. Noisy tool: Built-in windows net.exe utility uses SAMR, and MDI has high-fidelity signatures for the traffic patterns generated by it.

2. lazy with commands: if you don't be careful with the usage of commands like SamrGetMembersInDomain, SamrGetMembersInAlias, SamrGetAliasMembership, etc. it will generate suspicious patterns and will get flagged by MDI.

3. High Volume/sensitivity: The queries target high-value groups (Administrators), or attempt to enumerate the entire directory structure (as we discussed in point 2)

EVASION METHODS

1. avoid the noisy tools: Tools like net.exe, or samrdump.py are easily detected. Infact evasion is not just about changing the tools but the behavior(throttling the requests, asking for one specific user rather than the whole domain list).

2. Leverage alternative Protocols: Focus on using alternative protocols like LDAP for recon.

3. Query Non-DC machines: Perform SAMR enumeration against non-Domain Controller machines first. (Tho this only gives local users and groups, not Domain wide recon)

2.3 SMB SESSION ENUMERATION

Attackers often use NetSessionEnum against the DC to identify which IP addresses users are logged into (which is a critical step for planning lateral movement).

THE TRIGGER MECHANISM

1. Behaviour & Specific API calls: Again suspicious behaviour like repeated NetSessionEnum againt the DC are a strong indicator of "User and IP address reconnaissance".

2. The Protocol: This traffic occurs over DCE/RPC, usually pipes (specifically the srvsvc pipe), MDI parses this traffic to see the specific opnum corresponding to NetSessionEnum.

3. Behavioral Context: Just like with SAMR, MDI applies behavioral profiling:

   1. If a specific management server performs this actin daily, MDI learns that it is normal.

   2. But, suddenly is a workstation that typically only accesses the file shares queries DC for a list of all active sessions, MDI will flag this as recon alert.

---

3. CREDENTIAL ACCESS

Once the target is identified, the attacker moves to credential access. MDI focuses heavily on detection of "Roasting" attacks like Kerberoasting, As-Rep roasting, and the use of Honeytokens

3.1 HONEYTOKEN AVOIDANCE

Honeytokens are decoy accounts created specifically to be monitored. They act as tripwires; any authentication or query targeting them triggers a high-severity alert.

TRIGGER MECHANISM

1. MDI allows administrators to tag specific accounts as honeytokens. The sensor then watches these SIDs with extreme sensitivity.

2. DCSync: attempting to replicate credentials for a honeytoken.

3. LDAP Lookup: Explicitly querying the honeytoken's attributes.

4. Kerberoasting: Requesting a TGS ticket for Honeytoken service account

EVASION METHODS

1. if you have access to logs, avoid interaction with accounts that have not been observed performing legitimate traffic

2. If an account has LogonCount=0 or a PwdLastSet date from 5 years ago, but the account is enabled, this is a red flag, and it should be treated as a high-risk object (potentially honeytoken).

3.2 KERBEROATING: FROM SPRAY TO SNIPE

Kerberoasting involves requesting a Service Ticket for a service account. The ticket is encrypted with the service account's NTLM hash.

THE VOLUMETRIC TRIGGER

1. The default behaviour of tools like Rubeus kerberoast (without arguments) is to request a TGS for every account in the domain that has a Service Principal Name (SPN).

2. This generates a massive spike in TGS-REQ traffic (Event ID 4769) from a single source IP in a matter of seconds. MDI’s anomaly detection engine easily flags this as "Suspected Kerberos SPN Exposure".

THE BYPASS: TARGETED EXTRACTION

1. while enumeration either use the offline filtering technique, or enumerate for specific accounts with very low number of requests.

2. Choose only high-probability targets, and request for a single ticket at a time.

3. Use the /rc4opsec flag in Rubeus but only for accounts with no AES.

3.3 AS-REP ROASTING

This attack targets users with "Do not require Kerberos preauthentication" enabled. It allows an attacker to request an AS-REP (containing an encrypted chunk of the user's password) without knowing the password first.

TRIGGER MECHANISM

1. Similar to kerberoasting, high volume of AS-REQ messages for preauth-desabled users.

THE BYPASS

1. Same as Kerberoasting, use targetted low volume request instead of trying to get AS-REP for every roastable account

---

4. LATERAL MOVEMENT: Living Off The Land

The Lateral Movement phase is where MDI attempts to detect the attacker moving in different machines and accounts. Alerts here focus on "Remote Code Execution" and credential reuse ("Pass-the-Ticket").

4.1 SCSHELL AND SERVICE MANIPULATION

One of the most common ways to execute code on a remote machine is via the Service Control Manager (SCM). Tools like PsExec work by creating a new service, starting it, and deleting it.

THE ALERT

• "Remote code execution attempt." MDI (and Defender for Endpoint) monitors for the creation of new services, especially those that look ephemeral or use random names.

THE BYPASS

• SCSHELL: SCShell does not create a new service. Instead, it leverages the ChangeServiceConfigA API to modify the binary path (binPath) of an existing, stopped service (e.g., XblAuthManager - Xbox Live Auth Manager, which is often present but unused on servers).

EXECUTION FLOW

1. Open handle to target service (RPC over SMB).

2. Change binPath to a malicious command (e.g., cmd /c powershell...).

3. Start the Service. (Payload executes).

4. Stop the Service.

5. Revert binPath to original.

DETECTION GAP

While this generates Event ID 7040 (Service Configuration Change), it evades the specific heuristic MDI uses for "Service Creation" (Event ID 7045). It mimics an administrative update to a service rather than the deployment of a new malware capability.

4.2 PASS-THE-HASH VS OVERPASS-THE-HASH

The detection mechanism for PTH is Behavioral Anomalies, while for OPTH it is protocol anomalies

1. Pass-The-Hash (PTH) The attacker uses the NTLM hash to authenticate directly to a service (SMB, RPC, etc.) without ever interacting with the KDC (Key Distribution Center). This is a purely NTLM flow.

   1. DETECTION MECHANISM MDI monitors the NTLM traffic (via Network parsing) and Logon Events (Event ID 4776 on the DC).

2. Overpass-The-Hash (OPTH) The attacker uses the to request a Kerberos Ticket Granting Ticket (TGT) from the DC. This effectively "upgrades" a hash into a fully valid Kerberos ticket.

   1. DETECTION MECHANISM

      • Many older OPTH tools use the NTLM hash to sign request which forces the encryption type to RC4, this generates an encryption downgrade alert, which is even more severe than the PTH

      • Synthetic Packet anomalies: Tools like Rubeus or mimikatz sometimes construct the AS-REQ packet slightly differently than the native Windows API (LSA).

      • MDI looks for missing fields or specific flag combinations (e.g., Forwardable, Renewable) that do not match the standard Windows client behavior. in short, if you use AES256 keys in OPTH, it will be more stealthy than PTH, but if you use NTLM hash in OPTH, in that case it would be noisier

FEATURE	PASS-THE-HASH	OVERPASS-THE-HASH
Protocol	NTLM (Port 445/135 etc.)	Kerberos (Port 88)
MDI Focus	Who & Where (Behavioral)	How (Encryption & Syntax)
Primary Trigger	Unusual Source Workstation(behavior)	RC4 Encryption in AS-REQ (0x17)
Noise Level	High (Harder to detect in legacy orgs)	Low (Very accurate in AES environments)
Red Team fix	Use a "clean" source machine.	Use AES Keys instead of NTLM hash.

---

5. DOMAIN DOMINANCE

Domain Dominance is about the persistance. This phase is characterized by attacks against the central trust mechanisms of AD: Replication (DCSync) and Ticket Granting (Golden/Diamond Tickets).

5.1 SUSPECTED DCSYNC ATTACK

DCSync simulates the behavior of a Domain Controller to request the replication of password data (hashes) via the Directory Replication Service (DRS) Remote Protocol.

TRIGGER

1. MDI monitors for DRSGetNCChanges requests. It maintains an "Allow List" of legitimate Domain Controllers. If a request originates from an IP or SID that is not on this list, it triggers a "Suspected DCSync attack" alert.

BYPASS TECHNIQUES

1. COMPROMISE A DC FIRST. If the attacker has code execution on a DC, performing DCSync from that DC is invisible, as it appears as normal inter-DC replication.

2. Replication Rights: Instead of pretending to be a DC, attackers target non-DC accounts that legitimately possess "Replicating Directory Changes" permissions. For eg, Azure AD Connect accounts sync hashes regularly. Using these credentials to sync hashes can blend the attack with legitimate synchronization traffic, provided the source IP matches the expected pattern.

5.2 THE ART OF TICKET FORGERY: GOLDEN VS DIAMOND

A Golden Ticket is a TGT forged entirely offline using the krbtgt account's NTLM or AES hash.

1. MDI Detection MDI detects Golden Tickets not by checking the signature (which is valid), but by analyzing the metadata and lifecycle of the ticket.

   • Time Anomaly: A ticket valid for 10 years when the domain policy is 10 hours.

   • Encryption Downgrade: A ticket signed with RC4 (NTLM) in an AES domain.

   • Made out of thin air: No prior AS-REQ or AS-REP, but still a golden ticket in use.

2. Golden Ticket Bypas.s Thadvicese is to create tickets that strictly comply with the domain's Kerberos Policy (eg, 10-hour lifetime) and use the krbtgt AES256 key.

5.2.1 THE DIAMOND TICKET

The diamond ticket represents a significant improvement over the golden ticket in terms of evasion.

• The flaw in golden ticket is that, they are made form thin air. There is no corresponding AS-REQ (request) or AS-REP (response) logged on the DC. MDI can infer a Golden Ticket by seeing a TGT being used (TGS-REQ) that it never saw issued. WHAT DIAMOND TICKET DOES:

1. The attacker requests a legitimate TGT for a low-privilege user (generating valid AS-REQ & AS-REP logs).

2. The attacker decrypts the TGT using the KRBTGT hash.

3. The attacker modifies the PAC (Privilege Attribute Certificate) inside the ticket to include the "Domain Admins" group SID.

4. The attacker re-encrypts the ticket using the krbtgt key. RESULT? A TGT that is mathematically valid, grants Admin rights, AND has a corresponding, valid creation log on the DC. This effectively blinds MDI's "TGT without request" anomaly logic

5.3 SILVER TICKETS

A Silver Ticket is a forged Service Ticket (TGS) for a specific service, signed with that service account's hash. The Blind Spot: Because the ticket is presented directly to the target server, and validation is local, no traffic is sent to the Domain Controller. Since the MDI sensors, on DC cannot see this attack vector, it is not detected. CAVEAT: Advanced configurations like PAC validation, might force the server to check the ticket with the DC, but this is rare and introduces latency as well. In standard environments, Silver Tickets remain a massive blind spot for DC-centric security tools.

---

6. AD CS & HYBRID IDENTITY

We'll touch lightly on the topics of AD CS (Active Directory Certificate Services), and the interactions between on-premises MDI and the cloud-based defender portal.

6.1 AD CS & PKINIT Abuse

AD CS allows for authentication via certificates (PKINIT). Attacks like ESC1 allow attackers to request certificates for arbitrary users.

• Detection: MDI has added alerts for Suspected rogue Kerberos certificate usage flagging certificates used on machines for the first time.

• BYPASS STATUS: Synacktiv indicates that tools like Rubeus were flagged based on their request syntax (eg. how they construct the ASN.1 structure in the PKINIT request) rather than the certificates usage itself. Customizing the tool or using Windows APIs directly can bypass these signatures.

---

7. ABUSING RESPONSE ACTIONS

There are also dangerous resorts that you should not take during a professional engagement

• MDI and the Defender XDR portal provide "Response Actions" allowing administrators to isolate machines or disable accounts.

• If an attacker compromises an account with "Security Administrator" rights in the Azure portal, they can use MDI to reset the password of a high-value on-premises user.

CRITICAL RULE OF ENGAGEMENT: Using administrative response actions to disable live accounts or reset passwords carries a high risk of Denial of Service (DoS) for the business. In a professional engagement, never execute these actions. Proof of access (e.g., screenshots of the active button) is sufficient to demonstrate the risk without causing operational downtime, legal liability, or reputational damage.

---

CONCLUSION

The analysis of Microsoft Defender for Identity reveals a security paradox: the more an attacker behaves like a compliant, bureaucratic administrator, the less visible they become. MDI's strength lies in detecting anomalies, deviations from the norm, protocol errors, and statistical spikes. Its weakness, therefore, is the "normal."

---

NOW JUST SOME LAST THINGS, AND THEN REFERENCES WHICH YOU CAN READ TO KNOW MORE

Alert Category	Specific Alert	Trigger Mechanism	Evasion/Bypass Technique
Reconnaissance	LDAP attributes recon	Querying sensitive OIDs (RBCD, NoPreAuth).	Offline Filtering: Request * (all properties) via ADModule, filter locally.
	SAMR recon	Usage of net.exe commands.	Use LDAP-based tools (PowerView, ADModule) exclusively.
	SMB session enum	NetSessionEnum against DC.	Avoid DC interaction; infer sessions via File Servers or TGS analysis.
Credential Access	Honeytoken Activity	Interaction with decoy accounts.	Avoid Dead Accounts: Check pwdLastSet (replicated)
	Kerberoasting	High-volume TGS-REQ (Spray).	Targeted Snipe: Enumerate SPNs offline, request single ticket. Use /rc4op
	AS-REP Roasting	High-volume AS-REQ (Spray)	Targeted Snipe: Enumerate NoPreAuth users offline, request single AS-REP.
Lateral Movement	RCE/Service Creation	SC create (Event ID 7045).	SCShell: Modify binPath of existing stopped service (ChangeServiceCo nfigA).
	Overpass-The-Hash	Encryption Downgrade (RC4 usage).	Use AES256 keys for the ticket request to match domain policy.
Domain Dominance	DCSync	Replication from non-DC IP.	Use AD Connect credentials or compromise a DC and route traffic through it.
	Golden Ticket	Time/Crypto anomalies in TGT.	Use AES256; match ticket lifetime to Kerberos Policy (e.g., 10 hours).
	Diamond ticket		Modify a valid TGT (obtained via AS-REQ) to create a perfect audit trail.
	Silver ticket	Service Ticket Forgery.	Traffic targets end-server, avoiding DC sensor entirely

SOME REFERENCES

1. https://learn.microsoft.com/en-us/defender-for-identity/

2. https://medium.com/@cyberengage.org/tracking-lateral-movement-named-pipes-scheduler-services-registry-and-dcom-event-ids-4f4670e70172

3. https://github.com/Mr-Un1k0d3r/SCShell

---

THIS BECAME A LIL TOO LONG, BUT YEA I WANTED TO BE DETAILED.