Full Report
Learn how SentinelOne's Static AI blocked APT29's CaptiveCrunch campaign on the endpoint, stopping local DNS poisoning and captive portal network lures.
Analysis Summary
# Incident Report: APT29 CaptiveCrunch Campaign Blocked at the Endpoint
## Executive Summary
APT29 (Midnight Blizzard, Cozy Bear) ran the CaptiveCrunch campaign, which used local network spoofing and fake captive-portal sign-in prompts to deliver the CornFlake remote access trojan and the ChocoShell infostealer. SentinelOne telemetry showed the adversary answering name-resolution requests from inside victims' own network segments, not through compromised public infrastructure. SentinelOne's Static AI blocked the campaign on the endpoint across multiple environments in three regions, stopping both the local DNS poisoning and the captive-portal lures.
## Incident Details
- **Discovery Date:** Microsoft publicly disclosed the campaign in July 2026. SentinelOne's exact endpoint detection dates are not stated in the excerpt.
- **Incident Date:** Not specified. The article describes the activity as occurring after the July 2026 disclosure, but gives no precise dates.
- **Affected Organization:** Not disclosed. The article refers only to "multiple environments we protect," which are SentinelOne customers.
- **Sector:** Not specified. The campaign's targets are described generically (travelers and users on public Wi-Fi).
- **Geography:** Three unnamed regions. Public captive portals (hotels, airports, conference centres) are the initial lure location.
## Timeline of Events
### Initial Access
- **Date/Time:** Not specified. The campaign was disclosed by Microsoft in July 2026.
- **Vector:** Local network spoofing. A Responder-style spoofer on the victim's layer-2 segment answered LLMNR queries (UDP/5355) with the adversary's address. Public accounts also describe compromised captive-portal gateways (T1584.008), though SentinelOne's telemetry pointed to on-segment spoofing instead.
- **Details:**
- The DnsPoison indicator recorded forged LLMNR responses on roughly one-third of affected hosts. The queries used randomised canary hostnames.
- The spoofer replayed the genuine CNAME chain and rewrote only the terminal A record.
- Success rates varied from 5.6% to 84% by network, with clean and poisoned answers interleaving.
- Windows' connectivity check, a plain HTTP fetch of a known file, was intercepted. The forged reply made Windows open the default browser to the adversary's sign-in page.
- The lure delivered a browser updater matched to the victim's browser, with fake updates served as content injection (T1659).
### Lateral Movement
- Not described in the excerpt. The article focuses on the initial access and payload stages.
### Data Exfiltration/Impact
- **Payload: CornFlake** (Go-based RAT). Capabilities include:
- Raw-input keylogging, clipboard monitoring, on-demand screenshots, microphone and webcam capture, and USB monitoring.
- **Secondary payload: ChocoShell** (in-memory PowerShell infostealer), deployed by CornFlake.
- Data theft and exfiltration details are not included in the excerpt.
### Detection & Response
- **Detection:** SentinelOne's Static AI blocked the campaign on the endpoint. The article notes that the payload's dangerous behaviour occurs after process creation, and that the preceding steps (name resolution, OS connectivity checks, browser launch) are normal OS or network behaviour that detection engines typically don't flag.
- **Response actions:** The excerpt does not describe post-block containment or investigation steps. It notes that no ClickFix-style lures were seen on SentinelOne-protected endpoints. Downloading and launching the file was manual every time.
## Attack Methodology
- **Initial Access:** LLMNR poisoning and adversary-in-the-middle on the local segment (T1557.001, T1557), with a captive-portal lure and browser redirection.
- **Persistence:** CornFlake uses service registration, Run keys, and scheduled tasks, plus a watchdog that restores these if removed.
- **Privilege Escalation:** Not described in the excerpt.
- **Defense Evasion:** The chain uses no email, link, attachment, or scripting host. ChocoShell runs in memory. Most steps use legitimate OS and network behaviour.
- **Credential Access:** Not described in the excerpt. CornFlake's keylogging and clipboard capture are collection techniques that can also expose credentials.
- **Discovery:** Not described in the excerpt.
- **Lateral Movement:** Not described in the excerpt.
- **Collection:** Keylogging, clipboard monitoring, screenshots, microphone and webcam capture, USB monitoring.
- **Exfiltration:** Not described in the excerpt.
- **Impact:** Surveillance and infostealing on compromised hosts.
## Impact Assessment
- **Financial:** Not disclosed.
- **Data Breach:** Potential exposure of keystrokes, clipboard contents, screen and audio/video capture, and credentials. Actual volume is not reported, and the article indicates these attacks were blocked.
- **Operational:** No disruption reported for SentinelOne customers, since the campaign was blocked.
- **Reputational:** Not applicable to a specific victim. The campaign is attributed to APT29, a Russian state-sponsored group.
## Indicators of Compromise
- **Network indicators:**
- Forged LLMNR responses on UDP/5355 from on-segment hosts (the spoofer's address was not included in the excerpt)
- Randomised canary hostnames in LLMNR queries
- Rewritten terminal A records following legitimate CNAME chains
- Tampered responses to Windows plain-HTTP connectivity checks
- **File indicators:**
- CornFlake (Go RAT)
- ChocoShell (PowerShell infostealer)
- Browser updater payload with fake update content
- **Behavioural indicators:**
- Windows opening the default browser to an unexpected captive-portal page
- Services, Run keys, or scheduled tasks created by CornFlake
- Watchdog processes restoring removed components
- Keylogging, clipboard, screenshot, and webcam/microphone access by unknown processes
## Response Actions
- **Containment:** Endpoint blocking by SentinelOne Static AI, which stopped the local DNS poisoning and captive-portal lures.
- **Eradication:** Not described in the excerpt.
- **Recovery:** Not described in the excerpt.
## Lessons Learned
- **Key takeaways:**
- Network-level controls, DNS filtering, and trusted resolvers do not protect against on-segment spoofing that wins the race on the wire.
- Attacks that rely on OS-native behaviour (connectivity checks, browser launch, LLMNR fallback) generate little for behavioural detection to flag until a payload runs.
- Endpoint controls are necessary when the network segment itself is untrusted.
- **What could have been done better:**
- LLMNR was enabled on hosts that did not need it. Disabling it removes the protocol being abused.
- The article suggests the lure relied on an unexpected captive-portal prompt. Users who sign in without reading were the path in.
## Recommendations
- **Disable LLMNR** on managed endpoints through Group Policy, since it is rarely needed in managed environments. Consider also disabling NBT-NS, which is a similar name-resolution fallback that the article does not discuss.
- **Enforce endpoint-level protection** (such as Static AI) that can block payloads regardless of how they were delivered.
- **Restrict untrusted network exposure:** Use client isolation or 802.1X-based network access controls where possible, and advise staff to avoid using public Wi-Fi for corporate work.
- **Train users** to treat unexpected captive-portal prompts and browser-launched update requests with suspicion, and to avoid running commands or downloads they were not expecting.
- **Monitor for the indicators above**, especially LLMNR traffic on UDP/5355 and unexpected services or scheduled tasks created by unknown binaries.
*Note: This report is based on a truncated article excerpt. Sections on post-detection response, lateral movement, exfiltration, and specific IOCs are incomplete in the source material. Recommendations beyond the article's own guidance are general good practice and should be validated against your environment.*