- Unit 42 reports an Iranian state-aligned actor used a fake Dubai Airports coding test, in a March 2026 campaign against Iraqi critical infrastructure.
- The project was built to run malware the moment it opened in Visual Studio, before any code was compiled, and it used GitHub's API for control traffic.
- Leaders should treat opening an outside project as running a program, and ask whether developer machines are isolated and monitored.
A coding test feels like a safe task. You open the project, find the bug and send it back. A report from Palo Alto Networks Unit 42 shows how that routine can become the attack itself. The lesson here is simple: for a developer, opening a project is the same as running a program.
What Unit 42 found
Unit 42 reports that an Iranian state-aligned actor posed as the Dubai Airports IT department. It sent coding tests with malware hidden inside to valuable targets.
The researchers label the cluster CL-STA-1178. They name its March 2026 campaign against Iraqi critical infrastructure Blinder Tunnel. They link the activity to Iran with high confidence.
The approach began in late March 2026. A fake recruiter offered one person a software development job. Unit 42 describes the target as likely a software engineer.
The trail began with files uploaded to VirusTotal by a user based in Iraq.
Dubai Airports is not accused of anything. Unit 42 knows of no breach or weakness in its systems. The airport's name was only a mask.
A recruitment process built to lower guard
The lure had two stages. In the first, the target was told to install a file called Dubai Airport Careers. It set up an offline site that looked like a career portal. After login, it showed a 10-question HR questionnaire.
Unit 42 found the questionnaire harmless. It sent no data and ran no malicious code. The researchers conclude it was a decoy to build trust.
In April 2026, the same submitter uploaded the second stage. It was a Visual Studio project archive posing as a coding test. A personalized Readme file told the target to find and fix a bug. The planted bug was a loop that skips the last item. An experienced engineer could fix it easily.
How the trick works
The danger was not in the bug. It sat in the project's .csproj file. That file tells Visual Studio how to build the software.
Opening a project makes Visual Studio quietly run a preparatory build behind the scenes. That build sets up editor features and checks dependencies. One step in it is called GetFrameworkPaths.
The attackers wrote their own step with that exact name. It replaced Microsoft's safe default. Unit 42 says this ran the payload as soon as the project loaded, before any compile.
The script made a folder called RuntimeBrokers in the user's local app data. It copied hidden files there and launched RuntimeBroker.exe. That file was a renamed, signed Microsoft hosting process.
A small configuration file then swapped the program's startup manager for the attackers' own. This is called AppDomainManager hijacking.
The same file also switched off Event Tracing for Windows. Security tools use it to spot threats running in memory. Unit 42 says this could weaken detection.
The last step was DLL sideloading. A trusted program loads a malicious library. That library was custom malware Unit 42 calls ShelbyLoader V2.
Unit 42 stresses that this misuses a legitimate product. It does not mean the product is flawed.
Control traffic that looks like ordinary work
Unit 42 says the malware used GitHub's API for command and control. The method is called living off the cloud. The malware registered the machine in a repository, then checked a file for new instructions.
The repository also held a wrapper for Chisel, an open-source tunneling tool. The attackers used it as a bridge into compromised networks.
The malware also tried to dodge analysis. It checked for virtual machines and hardware limits. It ran only if started by explorer.exe. GitHub has taken down the infrastructure Unit 42 identified.
Who carries the risk
Many security programs focus on the finished product. This attack went after the person who builds it. A developer's machine often holds source code, credentials and network access. It also runs trusted tools all day, so odd activity can blend in.
The report describes one visible target in this campaign. It does not count how many others were approached.
Still, this is not presented as a one-off. Unit 42 ties it to a wider cluster of activity. It says the actor targets telecoms, aviation and other critical entities across Iraq, Israel and the UAE. Its recruitment lures were aimed at Iraqi software developers and engineers more broadly.
Unit 42 also calls AppDomainManager hijacking an emerging technique that attackers are increasingly adopting. It names other Iranian groups, such as Screening Serpens, as users of it.
In this case, Unit 42 says its Cortex XDR product flagged and blocked the activity. It advises monitoring for programs that load unknown or non-standard DLLs from outside system folders.
Questions to put to your team
Where do developers open projects from outside the company? Think of coding tests, samples and recruiter files. Is that done on an isolated machine or virtual environment?
Would your monitoring flag a Microsoft-signed program running under a new name from a user's app data folder? Would it flag a change that turns off Windows event tracing?
Is outbound traffic to GitHub's API from developer machines understood and baselined? And do staff know how real recruiters contact them, so a fake one stands out?
A coding test is code from a stranger. Run it like any other.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Palo Alto Networks Unit 42.
