Phishing gets a lot of airtime in security awareness training, and almost none of it covers what happens after the click. The focus is almost always on prevention: recognize the email, don’t click the link, report it to IT. That framing treats the click as the end of the story. It isn’t. It’s the beginning.

This post walks through the full post-phishing kill chain. The technical mechanisms behind credential theft, in-memory execution, C2 establishment, lateral movement, privilege escalation, and persistence. At each stage I’ll cover the tools attackers are using, the detection opportunities defenders have, and the mitigations that matter. This is the attack as it looks from the inside.

The Lure Has Changed

Before getting into the kill chain, it’s worth addressing something: the mental model most people carry about phishing is wrong.

Modern spearphishing campaigns are researched. Attackers scrape LinkedIn for org charts, harvest email formats from breach databases, and reference real internal projects they’ve found in job postings or GitHub repos. AI tooling has made it trivially cheap to generate grammatically perfect, contextually plausible emails at scale. The volume-quality tradeoff that made bulk phishing easy to filter is largely gone.

The practical implication: your detection surface has moved upstream. By the time a user is evaluating a well-crafted spearphishing email, you’re already relying on judgment under pressure. Your controls need to assume some percentage of those clicks will land.

The Click: Three Technical Vectors

When a phishing payload delivers, it typically lands in one of three buckets.

1. AiTM Credential Theft

Adversary-in-the-Middle (AiTM) phishing uses a reverse proxy (Evilginx2, Modlishka, or Muraena are the most common open-source options) to sit between the victim and the legitimate identity provider. The victim browses to a lookalike URL, the proxy fetches the real login page and renders it transparently, and the victim authenticates normally, including completing their MFA challenge.

The critical detail: the proxy captures the post-authentication session cookie, the token issued by the IdP after MFA succeeds. That cookie is then replayed from the attacker’s machine. Microsoft 365, Google Workspace, Okta, all of them are vulnerable to session cookie replay. MFA has already been satisfied. There’s nothing left to challenge.

This is why MFA alone isn’t sufficient against targeted phishing. The fix is phishing-resistant MFA: FIDO2 hardware tokens (YubiKey, Titan) or device-bound passkeys. These use a cryptographic handshake that binds authentication to the legitimate origin domain. A proxy can’t intercept or replay it because the real domain isn’t present.

Detection opportunities: Impossible travel alerts (token replay from a different geographic IP immediately after legitimate auth), sign-in from new ASN post-MFA, Conditional Access policy triggers for unrecognized device or non-compliant state.

2. Malware Dropper: Fileless Execution

The second vector delivers an initial stager, typically via an / bundle, a macro-enabled Office document, or an HTML smuggling payload. The stager’s job is minimal: download and execute the next stage in memory.

Modern droppers almost universally avoid writing to disk. The execution chain looks roughly like this:

  • A shortcut or HTML smuggled payload executes an encoded PowerShell command
  • The stager bypasses AMSI (Windows Antimalware Scan Interface) using one of several well-documented in-memory patches that zero out the AmsiScanBuffer function before scanning occurs
  • A reflective DLL is loaded into the memory space of a trusted host process (explorer.exe, svchost.exe, a browser process) via reflective DLL injection or process hollowing
  • No file touches disk. AV has nothing to scan.

The result is a C2 agent running inside a legitimate, signed process with no on-disk artifacts.

Detection opportunities: AMSI bypass attempts generate ETW (Event Tracing for Windows) telemetry that EDR products can catch. PowerShell Scriptblock logging (Event ID 4104) captures the encoded commands. Process injection is detectable via memory scanning and behavioral analysis. Look for unsigned code executing in signed process memory, or processes making network connections they don’t normally make (e.g., explorer.exe beaconing to an external IP).

3. Session Hijacking via Reverse Proxy

This is architecturally similar to AiTM but worth distinguishing. Rather than harvesting credentials for replay, the attacker maintains a live proxied session. The victim’s authenticated session is continuously relayed through the attacker’s infrastructure in real time. Evilginx handles this natively; the attacker’s console shows a live terminal into the victim’s authenticated web session.

Remediation here requires cookie invalidation, not just a password reset. Force sign-out all sessions from the IdP admin console, then investigate from there.

The Kill Chain: From C2 Callback to Domain Admin

Once a C2 agent is running, the clock starts.

Phase 1: Initial Recon (0-15 minutes)

The implant phones home. Cobalt Strike, Sliver, or Brute Ratel are the dominant frameworks right now, beaconing over HTTPS/443 on a jitter interval (typically 60 +/- 30 seconds) to blend into normal web traffic. From the attacker’s console, they have an interactive shell on the victim machine.

Initial enumeration is fast and systematic:

Simultaneously, BloodHound (via the SharpHound ingestor) ingests Active Directory LDAP data and builds a graph database of every user, group, GPO, ACL, and trust relationship in the domain. It calculates the shortest attack path from the current user context to Domain Admin. This takes minutes. The output tells the attacker exactly which accounts to compromise next and in what order.

Detection: SharpHound generates significant LDAP query volume against the domain controller. Look for anomalous LDAP enumeration from workstation accounts, particularly (objectClass=computer), (objectClass=group), and msDS-AllowedToDelegateTo queries. BloodHound’s query patterns are well-documented and signaturable.

Phase 2: Credential Harvesting

With a foothold on the endpoint, credential harvesting is the priority. Three primary techniques:

LSASS Dumping via Mimikatz

lsass.exe holds credential material for currently authenticated users in memory: NTLM hashes, Kerberos tickets, and (in some configurations) cleartext credentials. Mimikatz’s sekurlsa::logonpasswords module reads this memory directly. On modern systems with Credential Guard enabled, cleartext extraction is blocked, but NTLM hashes are still recoverable and usable for Pass-the-Hash.

Attackers increasingly use indirect LSASS dump techniques to avoid direct Mimikatz execution. Creating a minidump via comsvcs.dll  or using ProcDump with the -ma flag are common alternatives:

The dump is exfiltrated and parsed offline.

LaZagne

LaZagne harvests stored credentials from 60+ applications: browsers (Chrome, Firefox, Edge), email clients, SSH agents, database tools, FTP clients, and more. Runs in seconds. Browser credential stores are a particularly high-yield target because users routinely store things there that they don’t think of as “passwords”: API keys, admin console logins, cloud provider credentials.

Kerberoasting

Any authenticated domain user can request a Kerberos service ticket (TGS) for any service account registered in AD via an SPN. The ticket is encrypted with the service account’s NTLM hash. Attackers extract the ticket and crack it offline using Hashcat or John the Ripper.

Service accounts are disproportionately vulnerable because they’re often created once, given broad permissions, and never have their passwords rotated. A 14-character password cracked in hours on a GPU rig is not unusual.

AS-REP Roasting targets accounts with Kerberos pre-authentication disabled, a misconfiguration that allows requesting authentication data without presenting any credentials. The returned AS-REP blob is crackable offline using the same method.

Detection: LSASS access from non-system processes (Event ID 10 in Sysmon, with lsass.exe as the target), unusual volume of TGS requests from a single account in a short window (Event ID 4769 with RC4 encryption; modern environments should be using AES, so RC4 TGS requests are a strong Kerberoasting signal), credential access from accounts that don’t normally access those resources.

Phase 3: Lateral Movement

The initial foothold is rarely on an interesting machine. Lateral movement is how attackers get from a marketing laptop to a server that matters.

Pass-the-Hash (PtH)

NTLM hashes don’t need to be cracked to be useful. They can be used directly to authenticate against any service that accepts NTLM: SMB shares, WMI, RDP (with restricted admin mode), LDAP. Mimikatz’s sekurlsa::pth spawns a new process with injected credentials:

Password expiration doesn’t help here. The hash is the credential. The fix is disabling NTLM where possible (enforce Kerberos), implementing tiered admin models, and deploying Protected Users security group membership for privileged accounts.

LOLBins-Based Remote Execution

Once PtH or valid credentials are in hand, remote execution via built-in Windows tooling is preferred over dropping additional malware:

  • PSExec  / PsExec-equivalent via Impacket: service installation + remote execution over SMB
  • WMIexec: remote command execution via WMI, no service installation required, lower noise
  • Evil-WinRM: PowerShell remoting over WinRM using stolen credentials
  • dcomexec: lateral movement via DCOM, even lower detection footprint than WMI

These all use legitimate Windows protocols and generate log entries that are indistinguishable from routine IT operations unless behavioral baselines are in place.

Detection: SMB-based PsExec creates a service on the remote host (Event ID 7045 on the target). WMI execution generates Event ID 4688 (process creation) with WmiPrvSE.exe as the parent. PowerShell remoting leaves Event ID 4688 entries on both source and target. Correlating authentication events (4624, 4648) with process creation on the target, particularly for accounts that don’t normally perform remote administration, is the core detection logic.

Phase 4: Privilege Escalation

From a standard user account, the path to Domain Admin runs through privilege escalation. Common techniques in order of frequency:

Misconfigured ACLs and Delegations

BloodHound surfaces these automatically. Common escalation paths include:

  • GenericWrite or WriteDACL on a user or group object, which allows password reset or group membership modification
  • Kerberos constrained/unconstrained delegation, where service accounts with delegation enabled can impersonate any user to any service
  • DCSync rights granted to non-DC accounts, sometimes created by misconfigured third-party tools

Unquoted Service Paths

If a Windows service binary path contains spaces and isn’t quoted, Windows searches for executables in each path component. An attacker with write access to an intermediate directory can place a malicious executable that runs as SYSTEM when the service starts.

DCSync

Once Domain Admin equivalent rights are obtained, DCSync is the final move. It exploits the MS-DRSR replication protocol to request password hashes for any or all accounts directly from the Domain Controller, without logging into the DC and without touching ntds.dit on disk:

The krbtgt hash enables Golden Ticket creation: forged Kerberos TGTs for any account, with any group memberships, valid for any duration. A Golden Ticket persists even through domain admin password resets. The krbtgt account password must be rotated twice (due to Kerberos history) to invalidate existing tickets.

Detection: DCSync from non-DC machine accounts generates Event ID 4662 (object access) on the DC with specific access rights (Replicating Directory Changes, Replicating Directory Changes All). This is one of the highest-fidelity detections available for late-stage intrusion. If you have nothing else, alert on this.

Phase 5: Persistence

Before cashing out, mature threat actors establish redundant persistence. A single password reset should not evict a threat actor who has been in your environment for more than a few hours.

Common mechanisms:

  • Registry Run keys: HKLM\Software\Microsoft\Windows\CurrentVersion\Run executes on login and is trivial to create silently
  • Scheduled tasks via schtasks /create: flexible triggers, command-line creation, survives reboots
  • WMI event subscriptions: EventFilter  + EventConsumer + FilterToConsumerBinding executes on system events, highly persistent, and poorly monitored in most environments
  • DLL hijacking in trusted application paths: malicious DLL placed in a search path before the legitimate one, inheriting the host application’s signing and trust context
  • Golden Ticket: a domain-wide persistence mechanism that survives targeted account remediation

Detection: WMI subscriptions are logged via WMI-Activity/Operational event logs and Sysmon Event ID 19/20/21. Scheduled task creation generates Event ID 4698. New Run key entries are detectable via registry auditing (Event ID 4657) or EDR telemetry. None of these are noisy. Alerts on these events should be treated as high priority.

Cash-Out: Ransomware and Double Extortion

The end of the kill chain is increasingly double extortion: exfiltrate first, encrypt second.

Data staging and exfiltration typically use cloud storage (Mega, Dropbox, rclone to attacker-controlled S3) over HTTPS to blend into normal traffic. File shares, email archives, databases, and document management systems are prioritized. Sensitive file discovery is automated, with filenames matching account password, account password credential, vpn, .env, financial terms, and customer data patterns.

Ransomware deployment is staged across all reachable hosts simultaneously, often via GPO or PsExec, to maximize impact and minimize the response window. Modern ransomware families use hybrid encryption (AES per-file, RSA-wrapped key) that makes decryption without the private key computationally infeasible.

The double extortion pressure point: even organizations with clean backups face the threat of public data disclosure. Paying doesn’t guarantee recovery, doesn’t guarantee data deletion, and directly funds the next campaign.

Defensive Priorities

If you’re using this post to inform a security program, here’s what moves the needle:

Phishing-resistant MFA everywhere. FIDO2 hardware tokens or platform passkeys for all privileged accounts and any account with access to sensitive data. OTP-based MFA is better than nothing but it’s vulnerable to AiTM.

EDR with behavioral detection, actively monitored. Signature-based AV misses fileless execution. You need an EDR that does memory scanning, process injection detection, and behavioral analysis, and someone must be watching it. That’s the minimum viable detection stack for modern threats.

Privileged Access Workstations and tiered admin model. Lateral movement is dramatically harder when admin credentials are never exposed on standard workstations. Tier 0 (DC/AD), Tier 1 (servers), Tier 2 (workstations), with dedicated admin accounts for each tier that are never used interactively on lower tiers.

Credential Guard and Protected Users. Credential Guard prevents LSASS from caching credential material in a form Mimikatz can extract. Protected Users security group disables NTLM, DES, and RC4 authentication for member accounts, which eliminates several lateral movement techniques outright.

Patch management with urgency on internet-facing services. The non-phishing attack surface, exposed services and unpatched vulnerabilities, is where zero-click attacks originate. CVSS score alone is a poor prioritization signal. Exploit availability and exposure context matter more.

Assume breach. Test the assumption. The most reliable way to know how far an attacker can get in your environment is to have someone try. Red team exercises, purple team assessments, and adversary simulation against real-world TTPs tell you whether your detections fire and how far a post-exploitation chain can run before something stops it.

One More Thing

The 21-day average dwell time in the IBM Cost of a Data Breach report isn’t a worst-case outlier. It’s the mean. Three weeks of an attacker with Domain Admin quietly staging data, establishing persistence, and learning your environment before you know they’re there.

The kill chain above isn’t theoretical. It’s what our team runs against real environments during red team engagements, and it’s what real threat actors are running against organizations right now. The tools are open source. The techniques are documented. The only variable is whether your defenses are ready to catch them.

Sprocket Security provides hybrid continuous penetration testing. If you want to know how far an attacker can get in your environment before they do, we can help.

Questions or feedback? tlyons@sprocketsecurity.com