Trusted Intel tool turned against banks

A legitimate Intel storage utility has been repurposed in a highly targeted malware campaign that uses a little-known. NET mechanism to run hostile code inside a signed executable, giving attackers a quieter path into corporate networks and making detection far harder for many security products. The operation, identified as PhantomCLR, has been observed against financial institutions and other organisations across the Middle East and the wider EMEA region.

At the centre of the intrusion is IAStorHelp. exe, a genuine Intel Rapid Storage Technology component. Rather than tampering with the binary itself, the attackers package it with a malicious configuration file and supporting payloads. When the file set is opened, the trusted Intel program launches as expected, but the. NET runtime reads the rogue configuration alongside it and hands control to attacker-defined code before the application’s normal logic fully takes hold. Microsoft’s documentation shows that AppDomainManager can customise a domain before other managed code runs, which helps explain why the technique is so effective inside a legitimate process.

The delivery method appears built for deception rather than scale. The malware is typically wrapped inside a ZIP archive containing the signed Intel executable, a poisoned IAStorHelp. exe. config file, an obfuscated loader, an encrypted payload, a shortcut disguised as a PDF and a decoy document crafted to look official. One lure analysed by researchers used a “Work From Home Policy Updates” theme with Saudi government-style branding, indicating an effort to align the bait with regional political and workplace conditions. That suggests the operators are not casting a wide net but choosing victims carefully and shaping the social engineering to local expectations.

What makes the campaign notable is not only the use of a signed binary but the depth of the follow-on evasion. Researchers say the framework avoids altering the original Intel file, preserving its digital trust, and then relies on computation-heavy delays rather than ordinary sleep calls to frustrate sandboxes. One stage reportedly uses a 60-second prime-number routine, followed by an 892,007-iteration key-derivation process to unlock an encrypted payload. By the time the main malware becomes visible, automated tools may already have timed out or logged only what appears to be resource-heavy but harmless activity.

The malware also avoids some of the behaviours that security teams have spent years tuning their tools to catch. Instead of leaning on well-watched APIs such as VirtualAlloc or WriteProcessMemory, the attackers use a just-in-time compilation route to obtain executable memory and then pivot into shellcode from there. CYFIRMA’s analysis says the framework further uses direct system calls, reflective loading and API resolution methods designed to reduce obvious forensic artefacts. It also includes memory cleanup routines intended to erase traces after execution, raising the cost of incident response and post-breach analysis.

The network side of the campaign is built with similar care. Command-and-control traffic is said to pass through Amazon CloudFront infrastructure, masking the destination behind a cloud service that many enterprises already trust. That does not make the traffic invisible, but it does complicate simple blocking strategies that depend on crude domain or IP reputation lists. For banks, insurers and regional conglomerates that already rely on cloud-heavy business traffic, the overlap with normal network patterns may narrow the window for analysts to distinguish legitimate communications from malicious beaconing.

The technique itself is part of a broader shift in enterprise intrusion tradecraft. Security researchers have warned this year that AppDomainManager injection allows attackers to run code inside trusted. NET applications without exploiting a software flaw in the traditional sense. That makes the abuse attractive because it borrows the reputation of genuine software and turns ordinary configuration behaviour into an execution trigger. The PhantomCLR case shows how that concept can be operationalised in a more mature post-exploitation framework aimed at sectors where stealth, dwell time and credential access matter more than noisy disruption.