Avalon and CrownX: the ransomware built to blind every EDR you own
Blackpoint Cyber found Avalon, an AI-assisted modular framework that hides from nine EDR products, then wipes recovery and runs CrownX ransomware. Why the wire still sees what the endpoint can't.
On July 3, Blackpoint Cyber published research on a previously undocumented modular malware framework it named Avalon — a single toolkit that harvests credentials, moves laterally, opens remote access, systematically destroys recovery, and finishes with a ransomware payload internally labeled CrownX. What makes it worth stopping for is not any one of those functions. It is the design premise: Avalon assumes the target is running an endpoint detection product, names nine of them explicitly, and builds its whole execution flow around going dark on the sensor before it does anything loud. When the endpoint is the thing being deceived, the detection question moves somewhere the malware cannot reach — the network.
Anatomy of the Avalon infection chain
The intrusion starts the way most do now: a spoofed legal-document email. The lure does not carry the payload. It points to a password-protected archive on Proton Drive, and inside the archive is an ISO image. That container choice is deliberate — mounting an ISO sidesteps the Mark-of-the-Web tagging that Windows applies to downloaded files, so the SmartScreen and macro warnings a user would normally see never fire.
Inside the ISO is a Windows shortcut (.lnk) themed to look like the promised document. Opening it does not run an executable an EDR would flag. It launches MSBuild, the legitimate Microsoft .NET build tool, pointed at a project file that compiles and loads an embedded .NET assembly in memory. From there the loader reaches out over HTTPS for the next stage. Every early step rides on a signed, trusted Microsoft binary — MSBuild.exe, csc.exe, InstallUtil.exe — which is the whole point. There is no novel dropper for a signature engine to catch, only Windows' own developer tooling doing exactly what it is designed to do, for the wrong reason.
The chain, stage by stage:
- Delivery — spoofed legal email → Proton Drive → password-protected archive → ISO image (Mark-of-the-Web bypass).
- Execution — document-themed
.lnk→ MSBuild compiles/loads an in-memory .NET assembly. - Staging — HTTPS pull of the next stage; framework modules loaded reflectively.
- Command and control — WinHTTP
POSTrequests to/api/v2/taskingonhelloxcherry[.]com, with form fields that separate LSASS dumps, SAM material, and general exfiltration.
CrownX ransomware and the art of blinding the EDR
Before CrownX encrypts anything, Avalon spends its effort making the room dark. Blackpoint's writeup, echoed in the Rescana and CyberPress analyses, lists an evasion subsystem built to conceal execution from a specific roster: Microsoft Defender, SentinelOne, CrowdStrike, Sophos, Elastic Endpoint, FortiEDR, ESET, McAfee, and Bitdefender. Alongside product-specific concealment, the framework tampers with ETW (Event Tracing for Windows) and manipulates AMSI — the two telemetry pipes most EDRs and most PowerShell/script defenses lean on. Blind those, and a large fraction of endpoint visibility simply stops producing events. Not alerts that get triaged and dismissed — events that never exist.
This is the uncomfortable core of the story. The endpoint-centric security model rests on an assumption: that the sensor on the host will observe malicious behaviour and emit a signal. Avalon is engineered against that assumption directly. It does not try to look benign to a working EDR; it works to stop the EDR from watching at all. When that succeeds, the SOC's richest data source goes quiet, and quiet reads as safe.
"The endpoint told us nothing was wrong. It told us that because the thing it was supposed to watch had already switched it off."
But there is a layer Avalon cannot switch off, because it does not run there. The credential exfiltration to helloxcherry[.]com is HTTPS traffic to a domain the environment has never talked to before. The lateral movement — pushing .NET components to remote hosts over administrative shares and launching them via scheduled tasks and remote services — is SMB and RPC on the wire. The eventual encryption phase is a burst of file-write operations across shares. None of that is visible to a sensor that has been told to look away, and all of it is visible to anything watching the network segment those hosts sit on.
The recovery-destruction stage
CrownX treats your backups as the primary target, not an afterthought. Per the reporting, the framework "stopped VSS, deleted shadow copies via COM, modified registry recovery settings, and targeted WinRE images and restore configuration." It goes further than the usual vssadmin delete shadows most ransomware families run: it carries a direct physical-drive write capability able to corrupt partition and boot structures, pushing impact past encryption into disk-level destruction. The encryption itself uses BCrypt with AES-GCM and appends the extension .8hn2yc.
The sequencing matters for defenders. Recovery destruction happens before the loud encryption pass — the operators want your restore path gone while the endpoint is still blinded and before anyone is looking. By the time files start locking and someone notices, shadow copies, WinRE, and in the worst case the boot record are already gone. A response plan that assumes "we'll just restore from local snapshots" is planning around a capability CrownX specifically removes.
AI-assisted malware and the collapsing skill floor
Blackpoint's researchers, Nevan Beal and Sam Decker, flagged something about how Avalon was built. The framework shows signs of AI-assisted development — components assembled together with, in their assessment, "scant regard for sophisticated tradecraft or operational security." Read that carefully. It is not that AI produced elite malware. It is that AI let someone who is not elite assemble a modular framework with credential theft, lateral movement, EDR evasion, recovery destruction, and ransomware, and field it — work that used to require a team and months. The opsec sloppiness (a reused staging domain, a single hardcoded Bitcoin address) is the tell of a low-skill operator holding a high-capability toolset.
For defenders this shifts the base rate. When the floor to produce a functional, EDR-aware, multi-stage framework drops, the volume of these campaigns rises and each one looks a little different — a per-target rewrite, a slightly reshuffled loader, a new staging domain. Signature and reputation defenses degrade fastest exactly here, because there is no stable artifact to sign. What stays stable is the behaviour on the network: something has to beacon out, something has to fan out laterally, something has to move data to an external endpoint.
Remediation
Avalon is not a CVE you patch — it is an intrusion you hunt. Treat any suspected Avalon/CrownX activity as a live incident and work these steps in order.
Am I affected? — first-pass triage. Hunt for the execution fingerprint rather than a file hash (the payload is per-intrusion). On endpoints and in EDR/SIEM telemetry, look for:
MSBuild.exe,csc.exe, orInstallUtil.exeexecuting with a parent ofexplorer.exeor a mounted ISO/removable volume, or building a project from a user-writable path (Downloads, Temp,%APPDATA%). Legitimate MSBuild almost never launches from a double-clicked shortcut.- Recently mounted
.isoimages containing a.lnk, and.lnkfiles whose target ismsbuild/cmd/powershell. - Outbound HTTPS to
helloxcherry[.]com, or WinHTTPPOSTto a/api/v2/taskingpath on any never-before-seen domain. - Files renamed with the
.8hn2ycextension; the CrownX ransom note.
Compensating controls (deploy now, before you finish hunting).
- Block execution of MSBuild/csc/InstallUtil for standard users via WDAC or AppLocker; these LOLBins have no place on a normal workstation.
- Enforce Mark-of-the-Web and block or restrict mounting of ISO/IMG files delivered by mail/web (Attack Surface Reduction rule "Block executable content from email client and webmail", plus Group Policy to prevent
.isoauto-mount). - Sinkhole/block
helloxcherry[.]comat the resolver and egress proxy. - Turn on Defender tamper protection and ASR rule "Block abuse of exploited vulnerable signed drivers"; put ETW/AMSI-tamper detections into alerting, not just logging.
Hunt for compromise — detection signals mapped to MITRE ATT&CK.
| Behaviour | IOC / telemetry | ATT&CK |
|---|---|---|
| ISO/LNK delivery | mounted .iso + document-themed .lnk |
T1553.005, T1204.002 |
| MSBuild proxy execution | MSBuild.exe compiling from user path |
T1127.001 |
| C2 tasking | WinHTTP POST /api/v2/tasking → helloxcherry[.]com |
T1071.001 |
| Credential theft | LSASS/SAM dumps, browser/VPN/SSH creds | T1003.001, T1003.002, T1555 |
| Lateral movement | .NET pushed over admin shares + scheduled tasks | T1021.002, T1053.005 |
| Telemetry blinding | ETW/AMSI tamper, EDR concealment | T1562.001, T1562.006 |
| Recovery destruction | VSS stop, shadow delete via COM, WinRE tamper | T1490 |
| Disk destruction | direct physical-drive writes to boot/partition | T1561.002 |
| Impact | AES-GCM encryption, .8hn2yc |
T1486 |
Eradicate and verify. Isolate affected hosts at the switch, not just the EDR (the sensor may be compromised). Assume every credential touched by an affected host is burned — rotate LSASS-resident and Credential-Manager secrets, browser/VPN/SSH keys, and any service account that authenticated to a compromised machine. Because CrownX targets local recovery, restore only from offline or immutable backups verified clean, and rebuild rather than restore any host where boot/partition tampering is suspected. Confirm the clean state after eradication with a fresh, out-of-band scan — do not trust the on-host agent that may have been blinded.
The network is the sensor CrownX cannot disable
Every step of Avalon's design is an argument for watching the wire. It blinds the endpoint on purpose, so the endpoint's silence is not evidence of safety. It rides trusted Microsoft binaries, so there is no malicious file to fingerprint. It is AI-assembled and likely per-target, so signatures and reputation lists lag. What it cannot do is move credentials to helloxcherry[.]com, fan out across administrative shares, and encrypt file servers without generating traffic — and traffic is the one surface it never gets to switch off.
This is the exact scenario Zero Hunt's AI Traffic Analysis was built for. Our proprietary deep-learning model runs on the appliance GPU with four parallel inference heads — suspicious-traffic detection, malware classification, attack-type identification, and application fingerprinting — trained on billions of PCAP sequences, at a 2.7+ Gbit/s baseline, entirely on-prem. It reads behaviour on the wire, not signatures, so an unseen C2 domain receiving structured POST tasking, a workstation that historically only ingests suddenly staging outbound to a never-seen ASN, or the SMB write-fan-out of a lateral push all surface while they happen — independent of whether the host's EDR was tricked into looking away. Because the appliance is fully on-prem with no cloud callbacks, there is no external telemetry path for an intruder to sever either. When the attacker's entire plan is to turn off the sensor on the box, the detection has to live where they cannot reach — on the network, at wire speed, in the moment the credentials leave.
If your incident-response playbook still assumes the EDR will be the thing that tells you, Avalon is the case study for why that assumption needs a second, independent layer. Talk to us about putting the network back in the loop.