Blinder Tunnel Campaign Targets Iraqi Infrastructure

What it is

Unit 42's technical report on CL-STA-1178's "Blinder Tunnel" campaign details a specific three-stage execution chain and gives exact code-level mechanics the existing summary only names in passing.

How it works

Stage one abuses the .csproj MSBuild target GetFrameworkPaths — Visual Studio runs this during its background "design-time build" the moment a project is opened, before any compile step. The attackers override this target to copy hidden binaries from the project's Resources folder into %LOCALAPPDATA%\Microsoft\RuntimeBrokers and launch RuntimeBroker.exe — all while the victim is still reading the decoy Readme.md.

Stage two: the launched process (a renamed vshost.exe) loads a modified RuntimeBroker.exe.config, hijacking the AppDomainManager and inserting <etwEnable enabled="false"/> to blind ETW before the malware body runs.

Stage three: RuntimeBroker.exe is vulnerable to DLL search-order hijacking, letting the actor sideload RuntimeBroker.dll (ShelbyLoader V2).

ShelbyLoader V2 then runs two timers: persistence check every 120s (writes MicrosoftRuntime under HKCU...\Run) and a 63s beacon that authenticates to GitHub with a hardcoded PAT, uploads a Base64 machine fingerprint to peakyblinders-tm/myLic as /{machineId}/Lic.txt, and polls /{machineId}/Inf.txt for Base64-encoded tasking. On HTTP 403 it sleeps one hour. If the token is revoked (401), it falls back to searching GitHub Issues by date (yyyymmdd) for AES-256-CBC ciphertext hidden inside HTML comment markers, keyed by MD5(date+machineId) iterated five times.

The final RAT, RuntimeBrokerApi.dll (ShelbyC2 V2), is decrypted using SHA-256 of a license string fetched live from the GitHub repo, then reflectively loaded in memory — no disk artifact. PsProxy.dll executes PowerShell by hooking System.Management.Automation.dll directly, avoiding powershell.exe entirely. Blackwood (tunneling loader) decrypts an embedded 8.4MB resource (Blackwood.Cheese.xml) via SHA-256 of a hardcoded passphrase to reveal a Go-compiled Chisel DLL, then reads its config (Blackwood.dll.conf) via RC4 with hardcoded key "My name is Blackwood !" — but only decrypts correctly if the loader file still has a .dll extension, an anti-tamper check.

Preconditions / Affected

Victim must open the malicious .csproj in Visual Studio (triggers the design-time build automatically — no explicit build/run needed). Relies on a Microsoft-signed vshost.exe/vshost32.exe being present and susceptible to DLL search-order hijacking in its working directory.

What to do

• Monitor for unexpected child processes or file writes from msbuild.exe/Visual Studio design-time builds, particularly into %LOCALAPPDATA%\Microsoft\RuntimeBrokers.
• Alert on RuntimeBroker.exe.config (or any .exe.config) being created/modified outside of normal app installation, especially containing etwEnable enabled="false".
• Flag binaries loading DLLs from non-standard/non-system directories (DLL sideloading indicator).
• Watch for the registry value HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\MicrosoftRuntime.
• Block/alert on outbound traffic to github[.]com/peakyblinders-tm and github[.]com/GreenBeret0.
• Cortex XDR in the reported incident flagged the root .slnx file that triggers DLL sideloading as high-severity and blocked it pre-execution — the page cites this as the actual point of detection.

Caveats

Attribution of specific TTP overlaps (AppDomainManager/ETW disabling resembling Screening Serpens; in-memory PowerShell wrappers resembling Agent Serpens) is explicitly stated as low-confidence overlap, not group attribution — Unit 42 attributes only to a general Iranian-nexus actor with high confidence, not to either named group.