Vibe Coded Extortion: Avalon’s Path from Legal Lure to CrownX Ransom Capabilities

Key Takeaways 

• Blackpoint’s Adversary Pursuit Group (APG) identified and analyzed a previously undocumented malware framework, now tracked as Avalon, delivered through a multi-stage phishing chain designed to evade conventional security controls.  

• The attack began with a spoofed legal document email directing recipients to a password protected archive on Proton Drive. Malicious content was embedded inside an ISO image rather than attached directly, reducing the likelihood of detection at the email layer.  

• The intrusion demonstrated how a single compromised endpoint could become the starting point for wider operational impact, as Avalon combined credential collection, remote access, recovery disruption, and destructive capabilities that could affect adjacent systems and shared infrastructure. 

• Avalon is operationally significant because it consolidates credential theft, persistence, and ransom functionality under one recovered payload rather than distributing them across discrete malware families. The ransomware component carries the internal label of CrownX. 

• Avalon shows strong indicators of AI assisted development. A multi-function framework that would previously have required significant expertise to build can now be produced rapidly, lowering the bar for threat actors to field sophisticated tooling.  

Executive Summary 

Blackpoint’s Adversary Pursuit Group (APG) recently analyzed a phishing delivery chain in which the threat actor used a spoofed legal document email to initiate the intrusion. The lure directed recipients to a password protected archive hosted on Proton Drive, which contained an ISO image presented as a secure document package. Interacting with a document themed shortcut inside the mounted image transferred execution into a staged malware chain without requiring a conventional executable attachment in the original email, an intentional strategy designed to reduce friction against email-based security controls. 

Analysis of the recovered final payload surfaced the name Avalon as a developer assigned framework label, identified through embedded strings and corroborating forensic artifacts. Avalon operated as a modular framework with distinct capabilities spanning credential theft, lateral movement, recovery disruption, anti-forensic cleanup, and ransomware execution. The ransom capability was internally branded as CrownX, with that designation appearing across embedded branding, ransom note templates, file encryption logic, decryption mode arguments, and recovery workflow strings, suggesting an intentional effort to maintain a separable, externally presentable ransom identity within the broader framework. 

The kill chain illustrates how a familiar business lure can progress into a reusable, multi-capability framework designed to harvest credentials, retrieve subsequent payloads entirely in memory, and stage multiple follow-on actions from a single compromised endpoint. Avalon is operationally significant because it consolidates credential theft, persistence, and ransom functionality under one recovered payload rather than distributing them across discrete malware families. That consolidation shifts the defensive priority toward early disruption of the delivery chain itself, before any single capability executes, rather than waiting for a recognizable family name or final stage outcome to drive the response. 

What makes Avalon particularly notable in the current threat landscape is what its construction reflects about how adversaries are building tools today. The framework bears the hallmarks of AI assisted development, assembled rapidly from functional components with little regard for tradecraft refinement or operational security, the kind of capability that previously required sustained development effort but can now be produced in a fraction of the time. That accessibility is the threat. The barrier to fielding a multi-stage framework with credential theft, lateral movement, and ransomware functionality has dropped substantially, and Avalon is an example of what that looks like in practice. A polished, modular implant recovered from an endpoint may reflect an afternoon of iteration rather than a seasoned development team, and the operational impact is identical either way. The rarity of a capability is no longer a reliable signal of the sophistication or resources behind it. 

Technical Analysis 

Signed, Zipped, and Delivered 

The intrusion began with a phishing email that masqueraded as a legal document notification and directed the recipient to Proton Drive (Figure 1). Using a legitimate file sharing service gave the lure the appearance of an ordinary business workflow while keeping the malicious archive outside the email itself. The password protected ZIP also limited the ability of email and web controls to examine its contents before the archive reached the endpoint. 

Figure 1: Staging archive hosted on Proton Drive 

Inside the archive was an ISO image named Secure_Document_CA-283505_pdf.iso. Mounting the image exposed a shortcut named Secure Document CA-283505.pdf.lnk alongside a folder named Mimecast Secure File Logs (Figure 2). The shortcut paired a document themed filename with a Microsoft Edge icon, presenting the user with what appeared to be a secure PDF rather than an object capable of launching commands. That presentation kept the actual staging file outside the user’s direct path and allowed the shortcut to handle the transition from the mounted image into execution.  

Figure 2: Contents within the malicious ISO 

The ISO contained four relevant artifacts:  

• Secure Document CA-283505.pdf.lnk  

• Mimecast Secure File Logs\zfighv.tmp  

• Mimecast Secure File Logs\verification.txt  

• Mimecast Secure File Logs\manifest.xml 
   

The text and XML files reinforced the secure document theme. verification.txt claimed that integrity checks had passed, while manifest.xml described the package as a document. Neither file contributed to execution, but both helped make the directory structure appear consistent with a protected delivery workflow. The functional payload was zfighv.tmp. Despite its extension, the file was not temporary data. It was a complete MSBuild project that contained inline C# and the encrypted managed stage that continued the intrusion. 

Opening the shortcut launched cmd.exe with delayed environment variable expansion enabled (Figure 3). The shortcut metadata pointed to the Windows command shell while still displaying an icon associated with Microsoft Edge. Its arguments split important command components across several small environment variables, preventing values such as the MSBuild path and execution flags from appearing as one contiguous string inside the .lnk file.  

Figure 3: Raw Contents of Secure Document CA-283505.pdf.lnk 

The command then searched for a hard coded list of drive letters for either \Mimecast Secure File Logs\zfighv.tmp or \zfighv.tmp (Figure 4). This allowed the shortcut to locate the project regardless of which drive letter Windows assigned to the mounted ISO. Once found, the project was copied to %TEMP%\ngen0cc9.dat, executed with the 64-bit .NET Framework build of MSBuild.exe, and deleted after execution. 

Figure 4: Cleaned up logic of the malicious .lnk file 

Analysis of the MSBuild project explained why the shortcut never launched a conventional executable. MSBuild supported inline C# through CodeTaskFactory, which allowed an XML project to compile and execute managed code inside a Microsoft signed development utility. In this case, the project defined a custom task named _cyrbusnAC63Do, referenced $(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll, and embedded the C# source directly inside the XML.  

That inline task reconstructed strings at runtime, decoded a large Base64 blob, decrypted the resulting byte array, and loaded the recovered assembly through System.Reflection.Assembly.Load. Reflection invoked _GnJwIhfBM._kP0LMYpk49P::_wBuO3mVJ directly from the in memory assembly, transferring execution from the MSBuild wrapper to the embedded .NET payload without writing it to disk or launching a separate process (Figure 5). 

Figure 5: Primary logic of the inline task 

Opaque arithmetic conditions, changing state values, randomized identifiers, and indirect string recovery surrounded this core logic. Those layers complicated static review without altering the main execution path. The project therefore functioned as a reconstruction wrapper rather than the final payload, giving MSBuild enough information to recover the managed downloader in memory and invoke it without writing the assembly as a normal DLL or executable. Static inspection of zfighv.tmp exposed the wrapper and encrypted content, but not the full behavior of the stage it loaded. 

The recovered assembly was a PE32 .NET DLL built for the .NET Framework 4 runtime. Its decoded strings and native API resolution logic exposed routines associated with Event Tracing for Windows (ETW), the Antimalware Scan Interface (AMSI), exception handling, and thread context manipulation (Figure 6). Referenced functions included: 

• EtwEventWrite 

• EtwEventWriteEx 

• EtwEventWriteFull 

• EtwEventWriteTransfer 

• EtwEventWriteString 

• EtwNotificationRegister 

• NtTraceEvent 

• AmsiScanBuffer 

• AddVectoredExceptionHandler 

• GetThreadContext 

• SetThreadContext 

ETW provides a native event pipeline used by Windows components and security products to record system and application activity, while AMSI allows supported applications to submit scripts and memory content for antimalware inspection. The loader resolved several ETW entry points and prepared short return stubs consistent with forcing those functions to report success without emitting their original events. Separate vectored exception and thread context logic surrounded AmsiScanBuffer, providing another path for redirecting inspection related execution. 

Figure 6: Simplified representation of the ETW logic 

The byte sequence 31 C0 C3 translated to xor eax, eax; ret, causing a patched function to return zero immediately rather than follow its normal implementation. By placing this activity before remote payload retrieval, the loader attempted to reduce the telemetry available as the next stage entered memory. 

With that groundwork in place, the downloader used System.Net.WebClient to retrieve the next stage over HTTPS. It also installed a custom certificate validation callback that approved every certificate presented by the server, bypassing the normal checks for trust, expiration, hostname matching, and certificate chain validity. This allowed the downloader to complete the connection even if the server used an invalid or untrusted certificate. The request then used a browser-like User-Agent and a custom X-Edge-Cache header (Figure 7). 

Figure 7: The staging request sent by the downloader 

The custom header acted as a campaign specific request value, giving the server a property it could use to distinguish expected clients from ordinary web traffic. The browser-like User-Agent made the request resemble normal web activity, while the path placed the object beneath a directory structure associated with static content. Although the domain was no longer usable during later retrieval attempts, the response format and decryption logic were recoverable directly from the downloader. A separately captured copy of the returned object then completed analysis of the Avalon stage. 

The remote response consisted of an encrypted body followed by a 32-byte HMAC-SHA256 tag: adbc18f15019ef2ba6890b7996445c14350d57ba772eb33182889bc14ac47085. Rather than using a standard stream cipher, the loader generated a 32-byte keystream block by calculating HMAC-SHA256 over the current byte offset (Figure 8). The inputs progressed as 0x00, 0x20, 0x40, 0x60, and so on, with each value encoded as a little-endian 64-bit integer before being passed to HMAC-SHA256.  

Figure 8: Simplified decryption routine 

This authentication step ensured that only a response produced with the embedded key reached the manual loader. A truncated, modified, or unrelated object would have failed validation before its contents were interpreted as executable code. The same construction also protected the server delivered PE from passive inspection, since recovering the payload from captured traffic required the encrypted response, the embedded key, and the exact offset based keystream calculation used by the downloader. 

Once the response passed validation, the managed stage manually mapped the decrypted PE into the current process instead of writing it to disk and launching a new executable. A normal Windows image load relies on the operating system to allocate the image, copy its sections, resolve imported functions, apply relocations, configure memory protections, register exception metadata, and transfer control to the entry point. The managed loader reproduced those operations itself. 

The loader first inspected the decrypted PE to confirm that it was a valid Windows executable and determine how it should be placed in memory. It parsed the DOS header, followed e_lfanew to locate the NT headers, validated the PE\0\0 signature, and extracted key values such as the preferred image base, SizeOfImage, SizeOfHeaders, the number of sections, and the entry point address (Figure 9). These fields told the loader how much memory to reserve, where each section belonged, and where execution should begin once the image was fully prepared. 

Figure 9: High level breakdown of the loader’s mapping sequence  

After allocating memory, the loader copied the PE headers and sections into their expected locations, then corrected any addresses that depended on the image loading at its preferred base by applying IMAGE_REL_BASED_DIR64 relocations. It walked the import table to identify required Windows libraries, loaded missing modules with LoadLibraryW, and resolved imported functions through GetModuleHandleA and GetProcAddress before writing those addresses into the import address table. The loader then applied the appropriate memory protections, registered x64 exception and unwind metadata through RtlAddFunctionTable, and called SetProcessValidCallTargets to register valid indirect branch destinations for Control Flow Guard. These steps reproduced much of the work normally performed by the Windows loader, allowing the executable to run directly from memory without being launched as a conventional file-backed process. 

Execution favored the Windows thread pool APIs TpAllocWork, TpPostWork, and TpWaitForWork. If that pathway failed, the loader fell back to CreateThread, WaitForSingleObject, and CloseHandle. The final entry point therefore ran inside the process context already established by MSBuild.exe and the managed downloader. No separate payload process was required, and the recovered PE did not need to be written to disk. 

Welcome to Avalon 

The carved final stage was a native x64 Windows GUI executable that introduced the primary post exploitation framework onto the endpoint. Its version resources attempted to blend into Windows by presenting the executable as the Windows Management Instrumentation Provider Host, using values including Microsoft Corporation, Windows Management Instrumentation, WmiPrvSE, and WmiPrvSE.exe (Figure 10). 

Figure 10: Metadata of the Avalon implant showcases its attempt in masquerading as WmiPrvSe.exe 

Further analysis showed that the executable functioned as a central orchestration layer rather than as a single purpose payload. Strings tied to its coordination logic referenced registration, credential harvesting, shadow copy handling, lateral movement, and status reporting. Embedded development labels and related artifacts identified this framework as Avalon, which prepared the host, reduced visibility, collected credentials, established communications, and supported access to additional systems. 

Avalon also contained a broad defense evasion subsystem that extended the visibility reduction already performed by the managed downloader. Analysis identified functionality intended to interfere with AMSI and ETW. It also contained hardware breakpoint handling, clean copy mapping of ntdll.dll, and HalosGate and TartarusGate style syscall resolution, which allowed the framework to avoid calling Windows APIs through potentially monitored or hooked paths. 

Additional functionality existed to conceal execution after the payload entered memory. This included return address and stack spoofing, thread manipulation during sleep periods, awareness of Control Flow Enforcement Technology, and product specific handling for Microsoft Defender, SentinelOne, CrowdStrike, Sophos, Elastic Endpoint, FortiEDR, ESET, McAfee, Bitdefender, and other security tools. These capabilities give the framework a multitude of ways to reduce telemetry, bypass user mode monitoring, and adjust its execution depending on the defensive controls present on the host. 

Credential and data harvesting were integrated into the same framework. The harvesting cluster referenced Chromium based browsers and Firefox, along with browser databases and artifacts such as Login Data, Cookies, History, Bookmarks, and Network\Cookies. Avalon copied selected databases into temporary files including tmp_login.db and tmp_cookies.db, then referenced CryptUnprotectData as part of the process used to recover DPAPI protected material from the local profile. Output structures in the same area tracked logins, encrypted usernames, encrypted passwords, cookies, Windows credentials, bookmarks, browsing history, RDP data, and Wi-Fi material. 

The collection scope extended beyond browser profiles. Avalon also referenced MetaMask, Phantom, Coinbase Wallet, Exodus, Electrum, Atomic Wallet, Ledger Live, and Bitcoin Core paths, along with Discord, Discord Canary, Slack, Teams, OpenVPN, WireGuard, SSH known hosts, saved RDP connections, Windows Credential Manager, Wi-Fi profiles, and Group Policy Preferences cpassword artifacts (Figure 11). This collection gave the framework access to far more than files stored on the original endpoint. Browser sessions, messaging tokens, wallet data, VPN profiles, SSH material, and remote administration history could preserve access to other systems and services after the initial host was contained. 

Figure 11: Simplified harvesting workflow  

A separate local credential validation component turned harvested and guessed passwords into potential authentication material. The executable referenced LogonUserW, local SAM account enumeration, and status messages that tracked the number of users identified, passwords tested, and credentials successfully validated. It contained a built-in password list including common and seasonal patterns such as Password1, Password123, P@ssw0rd, Admin123, Welcome1, Changeme1, Summer2024, Winter2024, Spring2024, Qwerty123, Company123, Temp1234, Admin@123, and Server2024. Testing these values against local accounts allowed Avalon to convert weak credentials into reusable access for propagation and remote execution. 

Avalon’s C2 and exfiltration logic used the native WinHTTP stack, including WinHttpOpen, WinHttpConnect, WinHttpOpenRequest, WinHttpSendRequest, WinHttpReceiveResponse, WinHttpReadData, and WinHttpSetOption. The request templates used POST requests with application/x-www-form-urlencoded content, browser style client hints, and form fields tied to harvested data, general exfiltration, LSASS material, SAM data, and host registration. These markers showed that the framework separated different categories of collected data while maintaining a common transport layer for reporting and operator tasking (Figure 12). 

Figure 12: POST request from infected host to C2 regarding tasking 

The carved executable did not expose its Command and Control (C2) host as a simple plaintext configuration value, but dynamic analysis confirmed that it communicated with helloxcherry[.]com through the /api/v2/tasking endpoint. The implant issued HTTP POST requests using application/x-www-form-urlencoded content, a Chrome-like User-Agent, and a persistent connection, so that its traffic to resembled ordinary browser communications while it registered the victim, uploaded collected data, and requested additional tasking. 

The lateral movement subsystem prioritized systems that could increase the operational impact of the intrusion. It contained host discovery logic to classify domain controllers, infrastructure systems, servers, backup platforms, and other endpoints, then search for names associated with Veeam, Acronis, NetApp, Synology, Exchange, Citrix, Hyper-V, and vCenter. These targets represented systems capable of extending access, centralizing administrative control, hosting business critical workloads, or supporting recovery. 

The malware staged follow-on payloads through remote administrative shares and commonly writable paths, including C$\Windows\Temp, C$\ProgramData, C$\Users\Public, and ADMIN$\Temp. Authentication logic distinguished between access obtained through stolen tokens and access obtained through credentials, while status strings tracked token failures, blocked authentication attempts, and exhausted credential spray candidates. This allowed Avalon to select the strongest available access method before attempting remote execution. 

Execution options included delayed scheduled tasks through DCOM, immediate scheduled tasks under the current identity, scheduled tasks created with a stolen token, and remote service execution described as PsExec style. Avalon also prepared several .NET based components that could support execution on additional systems. The files dmrc.csproj, dmrc_iu.cs, and dmrc_iu.dll represented different stages of that process: the .csproj file defined how the project should be built, the .cs file contained the underlying C# source code, and the .dll file represented the compiled component that Windows could load and execute. 

To work with these files, the framework relied on trusted Microsoft utilities already present on many Windows systems. MSBuild.exe could process the project file and compile or run embedded code, csc.exe served as the Microsoft C# compiler, and InstallUtil.exe could load specially prepared .NET assemblies through the installation framework. References to both 32-bit and 64-bit .NET Framework directories showed that Avalon was designed to select the appropriate toolset for the system it reached. 

Heavy is the Crown 

Beyond its credential theft, C2, and lateral movement functions, Avalon contained a dedicated ransomware and extortion function known as CrownX. This component handled the file encryption workflow, ransom note delivery, payment instructions, and the local recovery process within the broader Avalon framework.  

The encryption subsystem relied on Windows Cryptography Next Generation, a built-in Windows framework exposed through bcrypt.dll. CrownX used APIs such as BCryptGenRandom to create cryptographically strong random values, BCryptOpenAlgorithmProvider to select the required encryption algorithm, and BCryptSetProperty to configure how that algorithm operated. It then used BCryptGenerateSymmetricKey to create the working encryption key and BCryptEncrypt or BCryptDecrypt to process file data. Related hashing functions supported integrity checks and key handling operations around that workflow.  

The code specifically configured ChainingModeGCM, indicating that CrownX used AES in Galois/Counter Mode. AES-GCM both encrypted the file contents and generated an authentication tag that could later be used to confirm that the encrypted data had not been altered. This showed that CrownX implemented a structured and reversible encryption process with dedicated key, nonce, and integrity handling, rather than simply overwriting or corrupting files. 

The file processing logic combined CrownX’s encryption routines with Windows features designed for efficient access to large files. APIs such as CreateFileMappingW and MapViewOfFile allowed the ransomware to map portions of a file directly into memory, where the data could be encrypted without repeatedly reading and writing small blocks through standard file operations. FlushViewOfFile then committed the modified data back to disk, while SetEndOfFile allowed the ransomware to adjust the final file size after appending or removing metadata. 

CrownX also referenced transaction aware APIs such as CreateFileTransactedW and MoveFileTransactedW, which allowed changes to file contents and names to be handled as coordinated operations. This gave the ransomware tighter control over when encrypted data and updated filenames became visible on disk and provided a cleaner way to recover from failed operations. Thread pool work submission supported parallel processing, allowing CrownX to distribute encryption tasks across worker threads without launching a separate process for every file. This made the operation more efficient and reduced the amount of process creation visible to defenders (Figure 13). 

Figure 13: Simplified recovery logic associated with the CrownX encryption 

CrownX targeted a broad range of file types associated with business operations, software development, engineering, data storage, and virtual infrastructure. Engineering and design formats included Blender, SolidWorks, and CATIA files such as .blend, .sldprt, .sldasm, .slddrw, .catproduct, and .catpart. Business and creative targets included Adobe InDesign and Premiere projects, OneNote notebooks, and Visio diagrams through formats such as .indd, .prproj, .onetoc2, and .vsdx. 

The target list also covered source code, configuration files, databases, and virtual machine storage. Developer focused extensions included .java, .swift, .ipynb, .proto, .graphql, .json, .yaml, .toml, .conf, .tfstate, .dockerfile, and .psm1, while database and storage targets included .sqlite, .accdb, .fmp12, .pgdata, and .oraenv. Virtual machine formats such as .vmxf, .vmem, .vmsn, .avhdx, .vmdk, .vhdx, and .qcow2 were also included. This scope showed that CrownX was designed to affect more than ordinary user documents, extending potential disruption into development environments, engineering workflows, databases, and hosted workloads. 

To support recovery of these varied file types, CrownX appended structured metadata to each encrypted file. This metadata recorded the information needed to reconstruct the encryption state, allowing the ransomware to reverse its own file transformations when supplied with the correct key. The stored nonce, authentication tag, and segment details tied the restore process directly to the original encryption workflow. 

This relationship connected CrownX’s local encryption workflow to Avalon’s communications layer. Avalon generated or handled the session material, delivered the key through its C2 logic, and retained a local restore path that depended on the corresponding 32-byte value.  

The ransom note subsystem completed the extortion workflow by generating both HTML and plaintext instructions. CrownX attempted to place the note on the desktop, use it as part of the wallpaper workflow, register file association and Run key display paths, and open it.  

CrownX used several built-in Windows programs to display the ransom note, increasing the chance that the instructions would open successfully on different systems. One method launched the note through cmd.exe /c start “CrownX” “%s”, which asked Windows to open the file with its default associated application. Other methods used mshta.exe or iexplore.exe for HTML content, rundll32.exe url.dll,FileProtocolHandler to open the note through Windows file handling logic, and notepad.exe or write.exe for plaintext instructions. 

Using multiple launch methods gave the ransomware fallback options if one program was unavailable, restricted, or failed to display the note. Rather than relying on a single application, CrownX could attempt several common Windows utilities until the payment instructions were shown to the user (Figure 14). 

Figure 14: Structure of the CrownX ransom note delivery logic 

The code also accounted for execution under SYSTEM and for hosts without an active interactive session. Status messages indicated that the ransom instructions could remain staged until the next user logon if no desktop session was available when CrownX completed its work. That fallback increased the likelihood that the victim would eventually see the payment instructions even when the ransomware ran outside a normal user context. 

The HTML ransom note template was more than a static payment message. It included placeholders that CrownX could populate with details from the affected system, including the number of files encrypted, the total volume of data processed, and the hostname of the compromised device. Presenting those values made the note appear specific to the victim and confirmed that the ransomware had completed meaningful activity on that host. 

The template also included deadline timers tied to the payment schedule. These counters showed how much time remained before the ransom increased from the initial demand to the higher amount. By combining victim-specific system details with visible countdowns, the note connected the user facing extortion message to the framework’s internal tracking of encryption progress, host identity, and payment deadlines (Figure 15). 

Figure 15: The reconstructed CrownX HTML template 

Avalon also contained functionality for terminating the Volume Shadow Copy Service, deleting shadow copies through COM, disabling VSS through registry changes, corrupting VSS metadata, removing related scheduled tasks, and querying Win32_ShadowCopy.ID through WMI. These capabilities targeted both the service responsible for creating and managing shadow copies and the system records Windows used to identify and expose available restore points. 

This matters because VSS often preserved previous versions of files and supported local recovery after accidental deletion, corruption, or ransomware activity. By stopping the service, deleting existing snapshots, and damaging the configuration and metadata behind them, Avalon reduced the likelihood that administrators could recover affected data without relying on separate backups. Removing VSS related tasks also interfered with the creation of new restore points, extending the impact beyond the shadow copies that already existed. 

The recovery targeting logic also extended into Windows Recovery Environment and System Restore. Referenced paths and registry locations included: 

• C:\Recovery\WindowsRE\Winre.wim 

• C:\Recovery\ReAgent.xml 

• C:\Windows\System32\Recovery\Winre.wim 

• SOFTWARE\Microsoft\Windows\CurrentVersion\ReAgent 

• SOFTWARE\Policies\Microsoft\Windows NT\SystemRestore 

These actions supported CrownX by narrowing the recovery options available after encryption. Local shadow copies, recovery environment files, and restore configuration could no longer be assumed to remain available simply because the underlying backup or recovery feature had existed before the incident. 

Avalon contained an anti-forensic cleanup subsystem designed to remove the Windows artifacts investigators would normally use to reconstruct the intrusion. It targeted Prefetch and AmCache records, which could show that specific programs had executed; SRUM, BAM, and DAM data, which could help establish when applications ran and how they interacted with the system; and ShimCache entries, which could preserve evidence that executable files had existed or been launched. The framework also removed recent file records and Jump Lists, which could reveal which documents, tools, or network locations a user or process had accessed. 

The cleanup also extended into activity and usage history. PowerShell history could preserve commands entered during the intrusion, while thumbnail caches and Timeline databases could retain evidence of files viewed or applications used. RDP caches could help identify remote desktop activity, and Windows Error Reporting files could capture crash data, process names, and memory related details. Avalon also targeted registry transaction logs and the NTFS USN journal, both of which could help investigators recover evidence of registry changes, file creation, renaming, deletion, and movement even after the original artifacts were removed. By clearing these sources, the framework attempted to make it harder to determine what executed, which files were touched, how the attacker moved through the system, and when each stage of the incident occurred. 

These targets covered several of the primary sources investigators would use to reconstruct process execution, file activity, user interaction, persistence, and lateral movement. Their removal extended the impact beyond encryption by making it harder to determine which systems had been reached, which credentials had been used, and which recovery artifacts remained trustworthy. 

Avalon contained a direct disk destruction capability tied to \\.\PhysicalDrive%d, a Windows device path used to access physical drives rather than individual files. This capability could bypass normal file level operations and interact with disk structures directly, giving the framework a way to damage partition information, boot records, or other critical areas of the drive. 

This expanded the potential impact beyond file encryption and artifact cleanup. Instead of only making data inaccessible, direct writes to a physical drive could prevent the operating system from booting, disrupt recovery efforts, and leave the affected system unusable until the disk was repaired or rebuilt. 

CrownX represented the final extortion stage, but the damage extended well beyond the encryption itself. By the time the ransom note appeared, the broader framework had already collected credentials, established C2 communications, prepared multiple paths for lateral movement, and weakened local recovery options. What began as a single phishing event therefore developed into a coordinated intrusion capable of spreading across systems, disrupting restoration efforts, and increasing both the technical and business impact of the incident. 

Conclusion 

Blackpoint’s APG identified a new strain of malware in which Avalon operated as the framework coordinating the intrusion and CrownX served as the ransomware and extortion component delivered through that broader architecture. The final executable supported far more than file encryption, combining defense evasion, credential and token harvesting, local credential validation, persistence, lateral movement, C2 communications, recovery inhibition, and anti-forensic cleanup within a single operational framework. This breadth increased the risk well before encryption began, as the same implant could expand access, weaken recovery options, and prepare additional systems for disruption. 

Avalon’s post exploitation activity reinforced the value of detecting these shared behaviors. Credential access, token theft, validation of local accounts, administrative share usage, remote task and service creation, recovery sabotage, and forensic cleanup reflected the capabilities required to turn one compromised endpoint into a broader operational event. These actions are more difficult to replace than filenames, infrastructure, ransom note language, or payload branding because they are tied to the framework’s need to authenticate, propagate, impair recovery, and maintain control. 

For organizations responsible for multiple connected environments, Avalon and CrownX represented a broader destructive intrusion rather than a conventional file encryption event. The framework combined credential theft, remote access, lateral movement, recovery disruption, and destructive capabilities in a way that could allow a single compromised endpoint to affect users, infrastructure, backups, and adjacent systems. 

The research also showed how the operation depended on reusable post compromise capabilities that remained valuable even if the final ransomware component changed. Stolen credentials, established access, and damaged recovery mechanisms could continue to drive impact after the original host was contained, making the intrusion a broader operational threat rather than a single host encryption event. 

Recommendations 

• Restrict or inspect password protected archives and disk image files delivered through external email or public file sharing services. Platforms like Proton Drive are legitimate but increasingly abused as delivery channels in phishing chains impersonating legal or financial workflows. 

• Strengthen email and web controls around externally hosted files, especially when users are directed to download password protected archives or disk images. Pair preventive controls with user awareness focused on legal, financial, and document-sharing lures. 

• Block or alert on shortcut files from mounted images that launch command interpreters, particularly when those commands copy hidden content into temporary directories and invoke a trusted system utility. 

• Monitor for MSBuild executing project files from user writable or temporary paths and correlate those events with child processes, outbound HTTPS connections, and short lived project files that disappear after execution. 

• Monitor for memory only PE loading behavior from unusual parent processes, including allocation of executable memory, import resolution, section protection changes, threadpool work execution, and CreateThread fallback activity after MSBuild or managed loader execution. 

• Build ransomware readiness detections around recovery sabotage and administrative spread, including VSS and WinRE tampering, suspicious writes to admin shares, remote task or service creation, CrownX ransom note artifacts, and creation of files ending in .8hn2yc. 

• Maintain tested offline backups and regularly validate recovery procedures across critical systems. Recovery planning should assume that attackers may target local restore points, backup infrastructure, and administrative tools before launching disruptive activity. 

Indicators of Compromise (IoCs) 

Type	Indicator	Context
ISO image	Secure_Document_CA-283505_pdf.iso	Mounted image containing the fake PDF shortcut and MSBuild project.
Shortcut	Secure Document CA-283505.pdf.lnk	Fake PDF shortcut launched cmd.exe and used a Microsoft Edge icon.
MSBuild project	Mimecast Secure File Logs\zfighv.tmp	Malicious MSBuild XML project copied from the ISO.
Decoy file	Mimecast Secure File Logs\verification.txt	Decoy text file in the ISO.
Decoy file	Mimecast Secure File Logs\manifest.xml	Decoy XML file in the ISO.
Temporary project path	%TEMP%\ngen0cc9.dat	Temporary copy of the MSBuild project executed by MSBuild.exe.
Staging domain	helloxcherry[.]com	Remote staging domain contacted by the managed loader.
Staging URL	hxxps://helloxcherry[.]com/cdn/static/c3587edc48c37656b29bcd3da9458eea/update	Encrypted remote object retrieved by the managed loader. URL was unavailable during later sandbox testing.
HTTP header	X-Edge-Cache: e3ec5926a167d6e3359f98cdfb7ac3b2cce97652843056505d02e6d2898573c6	Custom header sent by the managed loader during remote stage retrieval.
User agent	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36	User agent sent by the managed loader.
Encrypted file extension	.8hn2yc	Extension associated with CrownX encrypted files.
Cryptocurrency address	bc1qq9tx6p99jpqcj9p6nr3mwc3f9q3sxmj45l4anz	Bitcoin address embedded in the ransom note.

Artifact	SHA-256
Secure_Document_CA-283505_pdf.iso	b7d50d0406afcd2efd87bf3bf8c4211719ba9817dd2e0ad62af10c933e765e28
Secure Document CA-283505.pdf.lnk	607cb58b8a592885eef5cfbe35ddce962741b0775c575f58cb3a96ca0ee893a6
Mimecast Secure File Logs\zfighv.tmp	59a260716d05c20229c6a46fe0a2fb5b80fa30c9c73a850222d9d3454426a60a
Decrypted managed loader	4b7301f02b8312ae6de614981f325dbbabee32166630618fdff74615d9a487ba
Final Avalon payload with CrownX capability	c725815cbb07ab5be8903e74ef8aea46ef9c25e4a3bc626ae94bfc1ae21df6e3