MITRE ATT&CK® Credential Access (TA0006) - Detect, Investigate, and Respond

What is credential access in MITRE ATT&CK?

Credential access is a tactic in the MITRE ATT&CK framework (TA0006) that describes the techniques adversaries use to steal account credentials such as passwords, password hashes, authentication tokens, and Kerberos tickets. Stolen credentials let attackers impersonate legitimate users, escalate privileges, and traverse the network without triggering the kind of alerts that malware execution or exploit-based lateral movement would. This is why credential access is arguably the most dangerous post-compromise tactic in the entire ATT&CK matrix.

The 2025 Verizon Data Breach Investigations Report found that stolen credentials were involved in 44.7% of all confirmed breaches, more than any other attack action. IBM's 2024 Cost of a Data Breach Report reported that breaches caused by stolen or compromised credentials took an average of 292 days to identify and contain, the longest lifecycle of any initial attack vector. The reason is simple: when attackers use valid credentials, they look like authorized users, and traditional perimeter-based defenses cannot distinguish them from legitimate activity.

Credential access is the bridge between initial access (TA0001) and the attacker's ultimate objectives. An adversary who gains a single low-privilege foothold can dump credentials from memory, crack password hashes offline, forge Kerberos tickets, or relay NTLM authentication to escalate to domain administrator privileges (TA0004), often within hours. Groups like FIN7, APT29 (Cozy Bear), and Scattered Spider routinely chain credential access techniques to achieve full Active Directory compromise before the security team detects the initial breach.

This guide covers the credential access techniques that matter most for detection: OS Credential Dumping, Brute Force, Steal or Forge Kerberos Tickets, and Adversary-in-the-Middle, maps each to specific SIEM detection rules, walks through real-world attack scenarios from 2024-2025 incidents, and shows how to build a comprehensive detection and response strategy using ManageEngine Log360 and its 219 prebuilt detection rules for credential access.

Why credential access is critical to detect early

Credential access sits at a pivotal point in the attack lifecycle. Before credential access, the attacker may only control a single compromised endpoint with limited privileges. After successful credential access, the attacker can:

• Move laterally across the entire network: Stolen domain credentials grant access to file servers, databases, other workstations, and domain controllers. This enables lateral movement (TA0008) at scale without exploiting any vulnerability.
• Escalate to domain administrator: Techniques like DCSync and Kerberoasting can extract domain admin credentials or forge tickets that grant domain admin access, achieving privilege escalation (TA0004).
• Persist indefinitely: Golden Tickets forged with the KRBTGT hash grant access for as long as the ticket is valid (default 10 hours, but attackers set them for years). Even a full password reset across the organization won't revoke a Golden Ticket. Only a KRBTGT password rotation will.
• Exfiltrate data silently: With legitimate credentials, attackers can access sensitive data, databases, and cloud services as if they were authorized, making exfiltration indistinguishable from normal business activity.

The credential access attack chain

Understanding how credential access fits within a broader attack is essential for building detection depth. Here is the typical progression:

CrowdStrike's 2025 Global Threat Report noted that the average breakout time, from initial compromise to lateral movement, is now 62 minutes. Credential access is almost always the enabler of this rapid progression. Attack groups like Scattered Spider have achieved full Active Directory takeover in under 4 hours using credential access techniques alone, without deploying any traditional malware.

Credential access techniques in MITRE ATT&CK

MITRE ATT&CK catalogs 17 techniques under credential access. Four of these account for the vast majority of real-world credential theft incidents and represent the strongest detection opportunities for SIEM-based monitoring. Log360 provides 30 targeted detection rules across these four high-impact techniques, plus 189 additional rules for broader credential anomaly detection.

Understanding the credential landscape

To detect credential access effectively, security teams need to understand what attackers are targeting and where credentials live in the environment:

---

How credential access attacks work: Real-world scenarios

These scenarios are drawn from publicly reported incidents in 2024-2025. Each illustrates how credential access techniques chain together in real attacks, and exactly where Log360's detection rules trigger to break the chain.

Scenario 1 - Mimikatz to Domain Admin in 3 hours (T1003)

Attack workflow

The attack

A threat actor gained initial access to a healthcare organization through a phishing email that delivered a malicious macro. Once the macro executed a PowerShell download cradle, the attacker established a Cobalt Strike beacon on the compromised workstation. Within 20 minutes, they executed Mimikatz with sekurlsa::logonpasswords to dump all credentials from LSASS memory, harvesting the NTLM hashes and plaintext passwords of three recently logged-in users, including an IT administrator.

Using the IT admin's NTLM hash in a pass-the-hash attack, the attacker moved laterally to a domain controller. There, they executed DCSync, a Mimikatz feature that mimics domain controller replication traffic to request the password hash for any domain account, including the KRBTGT service account. With the KRBTGT hash, the attacker could forge Golden Tickets granting unlimited domain access.

What it looks like in logs

• Windows Event ID 4688: Process creation showing mimikatz.exe (or renamed binary with known command-line arguments like sekurlsa, lsadump, kerberos::golden).
• Windows Event ID 4656/4663: Object access audit showing a non-LSASS process requesting read access to lsass.exe, the signature of credential dumping.
• Windows Event ID 4624 (Type 9): NewCredentials logon type, created when pass-the-hash is used. The logon ID will differ from the user's interactive session.
• AD Replication Event (Event ID 4662): DCSync generates AD replication requests from a non-domain-controller machine account, specifically requesting the DS-Replication-Get-Changes-All extended right.

How Log360 detects this

Log360 provides multi-layer detection for this scenario:

1. Mimikatz Detection (Critical): Catches known Mimikatz process names and command-line patterns at the moment of execution.
2. LSASS Dump Keyword In CommandLine (Trouble): Detects obfuscated or renamed Mimikatz variants that still reference LSASS in their arguments.
3. Active Directory Replication from Non Machine Account (Critical): Fires when a DCSync request originates from a non-domain-controller source, catching the credential harvesting at the AD level.
4. Mimikatz DC Sync (Trouble): Specifically targets the DCSync technique using Mimikatz's lsadump::dcsync command pattern.

Even if the attacker renames Mimikatz and obfuscates command-line arguments, Log360's UEBA module detects the behavioral anomaly: a workstation initiating AD replication traffic is never normal behavior, regardless of the tool used.

Scenario 2 - Kerberoasting a Service Account (T1558)

Attack workflow

The attack

A member of the FIN7 threat group, having compromised a financial services organization, used Rubeus (a C# Kerberos abuse toolkit) to perform a Kerberoasting attack. The attacker first enumerated all accounts with Service Principal Names (SPNs) using setspn -T domain -Q */*, identifying 23 service accounts, including one used by a SQL Server instance running with domain admin privileges.

The attacker then requested Kerberos TGS (Ticket Granting Service) tickets for each SPN-enabled account. Because Kerberos TGS tickets are encrypted with the target service account's password hash, the attacker exported these tickets and cracked them offline using Hashcat with a GPU cluster. The SQL Server service account, which had a 12-character password that hadn't been rotated in 3 years, was cracked in under 8 hours.

What it looks like in logs

• Windows Event ID 4688: setspn.exe executed with enumeration parameters, followed by Rubeus execution.
• Windows Event ID 4769: A burst of Kerberos TGS requests from a single workstation for multiple different service accounts, especially with RC4 encryption (0x17), a strong Kerberoasting indicator since modern environments should use AES.
• Windows Event ID 4688 (on attacker's system): Hashcat execution with Kerberos cracking modules.

How Log360 detects this

1. Potential SPN Enumeration Via Setspn.EXE (Trouble): Catches the reconnaissance phase when the attacker inventories service accounts.
2. Kerberoasting Activity. Initial Query (Trouble): Detects the characteristic pattern of rapid TGS requests for multiple services, especially with RC4 encryption downgrade.
3. Rubeus detection (Critical): Identifies Rubeus execution by process name and command-line signatures.
4. Hashcat detection (Critical): Catches the offline cracking phase if the attacker runs Hashcat within the environment.

Scenario 3 - PetitPotam NTLM Relay to AD CS (T1557)

Attack workflow

The attack

An attacker exploited the PetitPotam vulnerability to coerce a domain controller into authenticating to a machine under the attacker's control via NTLM. The attacker relayed this NTLM authentication to the organization's Active Directory Certificate Services (AD CS) enrollment endpoint, requesting a certificate on behalf of the domain controller. With this certificate, the attacker could impersonate the domain controller to request a TGT for any account, achieving full domain compromise without ever cracking a password. This attack chain, first disclosed by security researcher Gilles Lionel (topotam), remains one of the most potent Active Directory attack paths.

What it looks like in logs

• Windows Event ID 4688: Execution of PetitPotam exploit tool or equivalent EfsRpcOpenFileRaw calls.
• Windows Event (Printer Spooler): Suspicious NTLM authentication requests originating from or targeting the print spooler service on domain controllers.
• AD CS Audit Logs: Certificate enrollment requests from unexpected sources, a domain controller requesting a certificate via a non-standard enrollment agent.

How Log360 detects this

1. Petitpotam detection (Critical): Catches PetitPotam exploit execution based on process behavior and known tool signatures.
2. Suspicious NTLM Authentication on the Printer Spooler Service (Trouble): Detects the NTLM coercion pattern targeting the print spooler, which is the classic PetitPotam relay path.
3. HackTool. ADCSPwn Execution (Trouble): Specifically catches the AD CS exploitation phase where the relayed authentication is used to request a certificate.

Detecting credential access by log source

Credential access attacks primarily target Windows endpoints and Active Directory infrastructure. Unlike initial access, which spans cloud and network logs, credential access detection concentrates on four key log sources, each requiring specific audit policies to be effective.

Essential Windows audit policies for credential access detection

Out-of-the-box Windows audit configurations are insufficient for credential access detection. You need to enable advanced audit policies. Here are the critical settings:

How to detect and investigate credential access with Log360

Log360's credential access detection operates at three levels: tool-signature rules that catch known attack tools, behavioral rules that detect credential theft techniques regardless of tooling, and UEBA anomaly detection that surfaces novel credential abuse patterns. Together, these create a layered detection architecture that catches credential theft even when attackers use custom or obfuscated tools.

Detecting OS credential dumping (T1003)

OS credential dumping is the most dangerous credential access technique because a single successful execution yields credentials for multiple accounts, often including privileged accounts. Log360 provides 16 dedicated rules covering every major credential dumping vector.

Key detection rules

Investigation workflow for credential dumping alerts

1. Confirm the process chain: When a Mimikatz or credential dumping alert fires, examine the full parent-child process tree. Legitimate security tools occasionally trigger false positives, but Mimikatz command-line arguments like sekurlsa::logonpasswords, lsadump::dcsync, or kerberos::golden are definitive indicators.
2. Identify exposed credentials: Determine which accounts were logged in to the compromised host at the time of the dump. Check Windows Event ID 4624 logs for all active sessions, every one of those accounts must be treated as compromised.
3. Check for lateral movement: After credential dumping, attackers immediately use stolen credentials. Search for Event ID 4624 (Type 3 or Type 9) logons from the compromised host to other systems. These pass-the-hash or pass-the-ticket events indicate the attacker is already moving laterally.
4. Assess domain-level impact: If Active Directory Replication from Non Machine Account or Mimikatz DC Sync fired, the attacker may have the KRBTGT hash. This means Golden Ticket forgery is possible, and the entire domain must be considered compromised until the KRBTGT password is rotated twice.

Detecting brute-force attacks (T1110)

Brute-force attacks generate the highest volume of credential access alerts but require careful tuning to separate real attacks from user mistakes. Log360's five brute-force rules combine tool-signature detection with pattern-based analysis.

Key detection rules

Investigation workflow for brute-force alerts

1. Analyze the pattern: Brute-force attacks have distinct patterns. Password guessing (T1110.001) targets a single account with many passwords. Password spraying (T1110.003) targets many accounts with one password. Check Windows Event ID 4625 (failed logon) to determine which pattern is occurring.
2. Check source IP reputation: If the brute-force attack originates from external IPs, check against threat intelligence feeds integrated in Log360. Internal brute-force activity (from a compromised host) is more concerning, it indicates the attacker is already inside.
3. Determine if any account was compromised: Look for a sequence of Event ID 4625 (failures) followed by Event ID 4624 (success) from the same source. This "fail-then-succeed" pattern confirms the brute force was successful.
4. Assess the blast radius: For password spraying, the attacker likely had a username list. Check if any accounts in the targeted list have elevated privileges, domain admins, service accounts, or admin-tier users.

Detecting Kerberos ticket attacks (T1558)

Kerberos-based credential access is particularly dangerous because it exploits protocol design, not vulnerabilities. Any domain user can request TGS tickets for any SPN-enabled service, which means Kerberoasting requires no elevated privileges at all. Detection relies on identifying abnormal Kerberos request patterns.

Key detection rules

Investigation workflow for Kerberos attacks

1. Identify targeted service accounts: When Kerberoasting is detected, determine which SPNs were requested. Check the SPN-enabled accounts for weak passwords, excessive privileges, and password age. Service accounts running as domain admin with old passwords are the highest-risk targets.
2. Check for encryption downgrades: Review Event ID 4769 for the encryption type. Requests using RC4 (0x17) in an environment that supports AES are a strong Kerberoasting indicator. Modern environments should enforce AES-256 (0x12) for all Kerberos operations.
3. Assess offline cracking risk: Even if you detect the Kerberoasting, the attacker may have already exported the tickets. The passwords of all requested service accounts should be rotated immediately, even if you catch the attack in progress.
4. Look for subsequent credential use: If any service account passwords were cracked, search for new logon events using those service accounts from unexpected sources. This indicates the attacker is leveraging the cracked credentials.

---

Proactive threat hunting for credential access

Rule-based detection catches known credential theft tools and patterns. But sophisticated attackers customize tools, use living-off-the-land binaries (LOLBins), and develop novel techniques that bypass signatures. Proactive threat hunting closes this gap. Here are four hunting hypotheses focused on credential access.

Hunt 1 - Undetected LSASS Access

Search for any process accessing LSASS memory that isn't a known legitimate accessor.

• What to search: Event ID 4656/4663 where the object is lsass.exe and the requesting process is NOT svchost.exe, csrss.exe, MsMpEng.exe (Defender), or your endpoint security agent. Any other process touching LSASS is suspicious.
• Why it works: Even when attackers use custom tools or reflective DLL injection, the LSASS access event is still generated. This hunt catches credential dumping regardless of the tool used.
• Where to search in Log360: Use Log360's log search to query Windows Security logs for Event IDs 4656/4663 with target process name containing "lsass".

Hunt 2 - Shadow Copy and NTDS.dit Extraction

Attackers who can't (or won't) use DCSync often resort to extracting the NTDS.dit database via volume shadow copies.

• What to search: Execution of vssadmin.exe, wmic shadowcopy, or diskshadow.exe on domain controllers, followed by file copy operations targeting ntds.dit, SYSTEM, or SECURITY registry hive files.
• Why it works: There are very few legitimate reasons to create shadow copies on domain controllers outside of backup windows. This hunt has a very low false-positive rate.
• Log360 rules that support this hunt: Shadow Copies Creation Using OS Utilities (Trouble) and Ntdsutil Abuse (Trouble) catch the most common extraction methods. Hunt for variants that bypass these rules.

Hunt 3 - Kerberos Anomalies Beyond Kerberoasting

Advanced attackers forge Kerberos tickets rather than cracking them. This requires detecting anomalies in Kerberos behavior.

• What to search: Kerberos TGT requests (Event ID 4768) where the encryption type is RC4 when the account supports AES. Golden Ticket usage where the ticket lifetime exceeds the domain's MaxTicketAge policy. Silver Ticket indicators where a TGS is presented without a preceding TGT request.
• Why it works: Forged tickets often have non-standard attributes, unusual lifetimes, mismatched encryption types, or missing parent requests. These statistical anomalies are difficult for attackers to eliminate.
• Where to search in Log360: Query Kerberos events and correlate with Log360's UEBA module, which builds baselines for normal Kerberos patterns per user and entity.

Hunt 4 - Credential Exposure in Cloud Environments

Cloud credential theft leaves different traces than on-premises attacks.

• What to search: OAuth token grant events from unusual applications. Service principal creation events followed by immediate resource access. API key usage from IP addresses that have never been seen before for that user.
• Why it works: Attackers who steal cloud tokens or API keys often use them from their own infrastructure. The IP-to-identity mismatch is a strong hunting signal.
• Where to search in Log360: Use Log360's cloud security monitoring to review M365 and AWS authentication patterns for anomalies.

How to respond to and remediate credential access attacks

When a credential access alert is confirmed as a true positive, the response urgency depends on what was stolen. A single user's password being brute-forced requires account-level remediation. A Mimikatz execution followed by DCSync requires domain-level incident response. Here are graduated response procedures for each scenario.

Immediate containment (first 30 minutes)

1. Isolate the compromised host: The machine where credential theft occurred is the priority containment target. Log360's automated response can trigger network isolation via integration with ManageEngine Endpoint Central, executing containment scripts within seconds of a Critical alert.
2. Disable compromised accounts: Every account that was active on the compromised system at the time of the credential dump must be disabled immediately. Log360's SOAR workflow can automate account disabling in Active Directory when Mimikatz or credential dumping rules fire.
3. Block attacker network indicators: If the credential theft involved network communication (C2 beacons, NTLM relay), block the identified IPs and domains at the firewall and proxy.

Technique-specific remediation

Log360 automated response capabilities

Log360 can execute critical response actions automatically when credential access rules fire, reducing mean time to respond from hours to seconds:

Other credential access techniques to monitor

Beyond the four core techniques, MITRE ATT&CK TA0006 includes additional credential access methods. While these have fewer prebuilt rules, they represent emerging attack vectors, particularly in cloud and hybrid environments. Log360's custom correlation rule builder and UEBA behavioral analytics can extend detection to these techniques.

Building a credential access detection strategy

Effective credential access detection is not about deploying rules and hoping for the best. It requires a deliberate strategy that covers multiple detection layers, accounts for attacker evasion, and aligns tool deployment with your environment's specific risk profile.

Step 1 - Map Your Credential Attack Surface

Before configuring detection rules, understand where credentials live in your environment and which are most valuable to attackers:

• Inventory privileged accounts: Domain admins, service accounts with SPN, accounts with DCSync rights, Microsoft Entra ID Global Admins, AWS IAM users with console access. These are the attackers' primary targets.
• Identify credential stores: LSASS on domain-joined workstations, NTDS.dit on domain controllers, Microsoft Entra ID token cache, AWS secrets in environment variables, SQL Server sa accounts. Each requires specific detection rules.
• Assess credential hygiene: Service accounts with passwords older than 90 days are prime Kerberoasting targets. Local admin passwords reused across workstations enable credential reuse. These hygiene issues directly inform which detection rules to prioritize.

Step 2 - Deploy Layered Detection

No single detection layer catches everything. Build defense in depth:

Step 3 - Tune and Validate

Credential access detection generates false positives from legitimate IT activities, backup agents accessing LSASS, IT staff using lsadump tools for AD recovery, service accounts with legitimate SPN enumeration. Effective tuning:

• Allowlist known legitimate processes: Identify your backup agent, EDR agent, and AD management tools. Create exclusions for processes from specific paths with specific parent processes only, never blanket-exclude a process name.
• Validate with purple team exercises: Run controlled credential access attacks using the same tools (Mimikatz, Rubeus, Kerbrute) in a test environment to confirm Log360's rules fire as expected. Validate that renamed or obfuscated variants are still detected.
• Review alert fidelity monthly: Check the true-positive rate for each credential access rule. Rules below 80% true-positive rate need tuning. Rules that never fire may indicate a log collection gap.

Need to explore ManageEngine Log360? Schedule a personalized demo

Frequently asked questions