A coding test posing as a Dubai Airports hiring exercise carried malware in a Visual Studio project. Opening the project could start the infection before the developer built or ran the C# application. Palo Alto Networks Unit 42’s investigation traces the lure to an Iranian state-aligned activity cluster it calls CL-STA-1178, including a campaign against Iraqi critical infrastructure that began in March 2026. The immediate exposure question is whether a developer received and opened that test archive.
The attackers hid a project target behind an ordinary-looking assignment to fix a bug in a flight-management application. The earlier career-portal installer showed a questionnaire; according to Unit 42, submitting it caused no remote communication or malicious execution. The later coding challenge was the trap. Unit 42 found the archive in an April submission from the same source that submitted the portal. Dubai Airports was impersonated; Unit 42 says it knows of no compromise or vulnerability in the company’s systems.
Opening the project starts execution
Inside DubaiAirport_Carrers_IT_Test.zip, the Readme.md addressed the recipient by name and directed them to open the project. The typo in Carrers is part of the observed filename. The project file FlightManager.csproj supplied its own GetFrameworkPaths target. During a design-time build, Visual Studio evaluates project configuration to populate the editor. Unit 42 says the malicious target ran “the moment the project was loaded into the IDE,” ahead of an explicit compile.
That target copied hidden binaries from the project’s Resources folder into %LOCALAPPDATA%\Microsoft\RuntimeBrokers and launched RuntimeBroker.exe there. This copy is the first host artifact to look for. The attack then used a renamed Microsoft Visual Studio host binary and its adjacent RuntimeBroker.exe.config to hijack .NET’s AppDomainManager startup, followed by DLL sideloading of RuntimeBroker.dll. The configuration included an etwEnable setting that could impair Event Tracing for Windows visibility. A developer reading the instructions could already have a running loader.
Unit 42 calls the loaded DLL ShelbyLoader V2. It used a MicrosoftRuntime value under HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run to persist and polled GitHub for tasking. After receiving key material, it decrypted the RuntimeBrokerApi.dll RAT, ShelbyC2 V2, in memory. Its PsProxy.dll module ran PowerShell inside the host process rather than spawning PowerShell.exe; a hunt confined to that process name would miss those commands. Unit 42 also recovered Blackwood, a wrapper for the Chisel tunneling tool that could provide a reverse SOCKS bridge into a network. Blackwood is a capability of the recovered tool set; investigate host execution before attributing tunnel activity to any particular developer machine.
GitHub carried more than code
The loader registered a machine fingerprint in the attackers’ GitHub repository and checked for instructions. It could also read encrypted routing data embedded in GitHub issue comments if its primary token or channel failed. Ordinary access to api.github.com may therefore accompany the malware’s command traffic. Unit 42 reports that GitHub removed the malicious infrastructure it identified; the shared GitHub API itself is a legitimate service.
The music theme in the attackers’ public repositories gave investigators another link. An uploaded “Peaky Blinders” theme-song file retained MusicDel.ir metadata, which Unit 42 used alongside infrastructure ownership and targeting to assess an Iranian nexus with high confidence. It assigns only low confidence to overlaps with specific named Iranian groups. Elastic Security Labs’ earlier investigation documented Shelby malware using GitHub for command traffic in an Iraqi telecom phishing operation in 2025. That earlier case involved an attached installer, rather than this design-time Visual Studio project trigger; Elastic described airport-themed infrastructure as a probable target.
Find the project and host trail
Start with development workstations that received a Dubai Airports-branded coding challenge. Search retained archives for DubaiAirport_Carrers_IT_Test.zip, FlightManager.csproj, and an overriding GetFrameworkPaths target. Unit 42 publishes SHA-256 hashes for the archive (6e7d9b33f1e72ea1ede71373a604ecdb060dab7d42055179c1eede9ecd1fd239), project file (f5b12772db6817f7a765a6fe7565fd3d4f87edc28e42fe3ec0244a372a410fc9), loader (53f35e49eb9b271fd8cbcd3daacb525328dbf159a03dbd1c7adebe0363daa402) and proxy DLL (3fd810a3aa0039993393741b32287c367a9a5037a41e826906440887cdd3ed13). Match the file bytes where available; a renamed archive or project can still carry the same content.
On a host that opened the project, examine %LOCALAPPDATA%\Microsoft\RuntimeBrokers for RuntimeBroker.exe, its .config, RuntimeBroker.dll and RuntimeBrokerApi.dll. Correlate their file creation and process launches with msbuild.exe activity and the MicrosoftRuntime Run value. Unit 42’s tunnel configuration pointed to 91[.]107[.]156[.]29; investigate a host connecting there together with these local artifacts. The renamed RuntimeBroker.exe under a user’s app-data directory is more specific than the legitimate Windows process name by itself. Unit 42 says Cortex XDR blocked the chain in an observed detection example; it sells the products it describes in its protection section.
Keep untrusted projects off workstations
Open received project files only after inspecting them in an isolated development environment. In particular, review custom MSBuild targets before letting Visual Studio evaluate an outside coding challenge on a workstation with access to company systems. Restrict developer workstations’ access to sensitive internal services so a compromised endpoint has fewer paths to reach them. For an exposed host with the staging files, isolate it, preserve its process, file and network records, and investigate the Run value and GitHub API traffic before returning it to development use.
On machines that already opened the project, search host records for the design-time trigger and staged files. A practical verification check for a received project is to inspect its target definitions before opening it and confirm that GetFrameworkPaths has not been overridden by untrusted instructions. On any host already used for the test, use the staged files, process history and persistence value to decide whether to begin incident response. The first ordinary build command is too late to serve as the exposure boundary.