Palo Alto Networks Unit 42 documented a campaign called Blinder Tunnel that targeted Iraq’s critical infrastructure sector through a fake Dubai Airports recruitment process. The attack delivered a trojanized Microsoft Visual Studio project that executed malware when opened—before the victim compiled or ran any code.
The campaign is a clear example of how trusted developer tools can become delivery mechanisms. The victim wasn’t asked to run an obviously suspicious executable. They were asked to open a C# project, build it, and fix a coding error—activities that look identical to a legitimate technical screening.
The Attack Wrote Files to Disk Before Anything Ran
Unit 42 identified three execution stages, but all of them depended on one thing: writing malicious files to the Windows file system.
When the victim opened the project in Visual Studio, the IDE performed design-time evaluation to resolve dependencies. The malicious project overrode a standard XML target called GetFrameworkPaths. This caused Visual Studio to create a directory at %LOCALAPPDATA%\Microsoft\RuntimeBrokers, copy hidden binaries from the project’s Resources folder, and launch RuntimeBroker.exe.
That’s three file operations: create directory, write RuntimeBroker.exe, write RuntimeBroker.dll. All performed by a legitimate Microsoft process—devenv.exe or MSBuild.exe—acting on instructions from a malicious project file.
Once those files landed, the rest of the attack chain followed: AppDomainManager hijacking, DLL sideloading, ShelbyLoader V2 establishing GitHub-based C2, ShelbyC2 V2 running PowerShell commands in memory, and Blackwood tunneling traffic to 91.107.156[.]29.
But none of that happens if the payload never lands on disk.
FileSure Blocks the Payload at the File System Layer
FileSure Defend operates at the Windows kernel level via a filter driver. It intercepts file operations—open, read, write, create, delete, rename—before they complete. It sees which process is making the request, what type of file is being written, and where it’s going.
A rule configuration that would have stopped this attack:
File name filter: *.exe;*.dll;*.bat;*.ps1
Program name filter: \devenv.exe;\MSBuild.exe;\VSIISExeLauncher.exe
Operations: Write, Create
Drive type: Hard drives
Action: Deny
This rule blocks executable file writes from Visual Studio processes. When the malicious project attempted to write RuntimeBroker.exe and RuntimeBroker.dll to %LOCALAPPDATA%, FileSure would have intercepted the operation and denied it at the kernel level. The files never land. ShelbyLoader never runs. The C2 channel never opens. The attack stops at stage zero.
The important point is that this rule doesn’t depend on signatures, threat intelligence, or knowing what Blinder Tunnel is. It enforces a simple principle: development tools should not write executable files to arbitrary user directories during normal project operations. When that happens, it’s worth blocking and investigating.
Organizations that employ developers, engineers, or contractors should consider this attack vector carefully. The victim in this case was doing exactly what a legitimate recruiter might ask: opening a project and fixing a bug. The malicious behavior was hidden inside the project’s design-time evaluation, not in an obvious executable.
FileSure gives you visibility and control at the file system layer. Every blocked operation is logged with full context: which user, which machine, which program, which file, exact timestamp. If a developer legitimately needs to build a project that writes files during evaluation, you’ll see the block, investigate, and create an exception. If it’s an attack, you stopped it before any malware ran.
Start a free 21-day trial at bystorm.com and see what’s actually happening on your file systems.
Source: Blinder Tunnel: GitHub C2 Targets Iraqi Infrastructure
Category: Threat Intelligence
Tags: blinder tunnel, github c2, visual studio exploit, appdomain hijacking, dll sideloading, kernel filter driver, file system security, iranian threat actor
