PLAYBOOKS NET HOST ATTRIB DETECT
← all playbooks
INCIDENT TRIAGE · TIER 1
Compromised Credentials
Valid credentials in use, no malware anywhere. 82% of 2025 detections were malware-free (CrowdStrike). The attacker looks exactly like a legitimate user. The playbook is: which accounts, where did they go, what did they touch.
reactive · identity-based · 30% of intrusions · often malware-free
The hardest triage. There is no implant to find, no malware to hash, no C2 to block. The attacker IS a valid user as far as every log is concerned. Detection relies entirely on behavioral anomalies: wrong time, wrong source, wrong access pattern, wrong geography.
Phase 1: Determine scope of compromise (first hours)
  1. 1. Identify which accounts are compromised How did you find out? Dark web monitoring alert, impossible travel detection, suspicious mailbox rule, MFA fatigue reports, help desk social engineering attempt, or infostealer log found. The source determines which accounts to investigate first.
  2. 2. Pull the authentication timeline For each suspected account: every logon event (EID 4624), every failed attempt (EID 4625), every Kerberos ticket (EID 4768/4769), every VPN connection, every cloud/SaaS authentication. Map the IPs, geolocations, timestamps, and user agents. Look for: logins from IPs that aren't the user's normal locations, logins outside normal working hours, multiple accounts authenticating from the same unusual IP. Security EID 4624/4625/4768/4769 · VPN logs · Azure AD/Entra ID sign-in logs
  3. 3. Check for MFA bypass indicators Was MFA present? If yes, how was it bypassed? Common methods: adversary-in-the-middle proxy (Evilginx, Modlishka) capturing session tokens, MFA fatigue/push bombing (repeated push notifications until the user approves), SIM swap, or a compromised MFA device. Check for: multiple MFA denials followed by an approval, session token reuse from a different IP than the MFA approval. Azure AD: Sign-in logs with MFA result · Conditional Access audit logs
  4. 4. Determine the credential source Where did the attacker get the credentials? The source determines whether this is isolated or part of a wider campaign. Common sources in order of 2025-2026 prevalence: infostealer on a personal/BYOD device (check dark web monitoring feeds), vishing/help desk social engineering (+442% in 2025, now the #2 initial access vector per Mandiant M-Trends 2026), ClickFix/fake CAPTCHA lures (+563% in 2025, copies malicious PowerShell to clipboard), phishing email with credential harvesting link or AiTM proxy (Evilginx, Tycoon 2FA), device code phishing (victim enters a code at Microsoft's real login page, granting the attacker a valid token), and credential stuffing from a previous breach (password reuse).
Phase 2: Trace attacker activity (hours 2-8)
  1. 5. Map what the compromised account accessed File shares accessed (EID 5140/5145), mailboxes read (Exchange/M365 audit), SharePoint/OneDrive activity, internal applications authenticated to. The attacker has the user's access. Everything the user can reach, the attacker can reach. Focus on: sensitive file shares, email (especially executive mailboxes), financial systems, HR/payroll systems. Security EID 5140/5145 · M365 Unified Audit Log · Application access logs
  2. 6. Check for mailbox rule manipulation Inbox rules forwarding to external addresses, rules deleting messages matching specific subjects (hiding their tracks), or rules moving messages to RSS/hidden folders. This is the #1 BEC indicator. A forwarding rule to an external address is active exfiltration. Exchange: Get-InboxRule · M365: Search-UnifiedAuditLog -Operations "New-InboxRule"
  3. 7. Check for OAuth/app consent grants Did the attacker grant consent to a malicious OAuth application? Illicit consent grants give the attacker persistent access to the user's data (mail, files, calendar) even after the password is reset. Check Azure AD/Entra ID for new application consents during the compromise window. Azure AD: Enterprise applications · Application consent audit logs
  4. 8. Look for privilege escalation Did the attacker use the compromised account to escalate? Adding themselves to groups, requesting role assignments, modifying permissions. If the compromised account is an IT admin, check for: new admin accounts created, password resets on other accounts, group membership changes, conditional access policy modifications. HOST: Privilege Escalation · Azure AD: Directory audit logs
  5. 9. Check for lateral movement Did they use the compromised credentials to access other systems? RDP (EID 4624 type 10), SMB (type 3), WinRM, SSH. The attacker authenticates as the user, so the lateral movement looks legitimate in isolation. The anomaly is: this user doesn't normally RDP to the domain controller. HOST: Lateral Movement · EID 4624 from unusual source IPs
  6. 10. Check for credential harvesting from accessed hosts If they landed on any host (RDP, SSH), did they dump credentials there? LSASS access, SAM hive exports, shadow credential harvesting. One compromised account that lands on a host with cached Domain Admin credentials becomes a domain compromise. HOST: Credential Access (all techniques)
Phase 3: Containment and reset
  1. 11. Reset credentials and revoke sessions Password reset is not enough. You must also: revoke all active sessions and refresh tokens (Azure AD: Revoke-AzureADUserAllRefreshToken), disable the account temporarily if investigation is ongoing, remove OAuth app consents, delete malicious mailbox rules, and review conditional access policy exceptions. Session tokens can survive password resets.
  2. 12. Check for credential reuse across accounts If the compromised password was reused on other accounts (common with personal passwords), those accounts are also compromised. Cross-reference the user's other accounts: VPN, email, cloud services, internal applications, service accounts they manage.
  3. 13. Assess whether this is part of a broader campaign One compromised account might be part of a wider credential stuffing attack, a targeted phishing campaign hitting multiple employees, or an infostealer infection that harvested credentials from many users. Check: did other users receive the same phishing email? Are other accounts authenticating from the same attacker infrastructure?
Credential compromise is the new initial access. The industry shifted from "find the malware" to "find the anomalous authentication." Your SIEM baselines for user behavior (normal login times, normal source IPs, normal access patterns) are the primary detection. Without those baselines, compromised credential use is essentially invisible.
Actors who use stolen credentials

APT29 specializes in cloud-focused credential abuse, particularly targeting Microsoft 365 environments via OAuth abuse and token theft. Their operations are almost entirely malware-free post-initial-access. Scattered Spider (UNC3944) uses help desk social engineering and MFA fatigue to compromise identities, then lives entirely in cloud/SaaS. Volt Typhoon uses valid credentials with no malware at all, making credential-based detection the only viable approach.