Blinder Tunnel: Fake Dubai Airports Job Test Runs Malware on Project Open

A fake Dubai Airports recruitment process turned a routine coding assessment into a malware launch: the trap could fire when the candidate opened the Visual Studio project, before compiling it. Unit 42’s October 6 report reconstructs the Blinder Tunnel campaign against a person in Iraq’s critical-infrastructure sector, likely a software engineer. The operation began in March 2026, with preparation visible from November 2025. This is a newly published investigation of earlier activity, not a claim that the attack started today.

The airport brand was the disguise. Unit 42 says it is not aware of a breach or vulnerability in Dubai Airports’ systems. The useful warning for developers is more specific than “do not run unknown programs”: an unfamiliar project can execute build-related instructions while an IDE is loading it.

The harmless first test made the dangerous second one credible

The purported recruiters first supplied an installer for an offline careers portal. Candidates logged in with credentials provided by the “recruiters” and completed a ten-question HR questionnaire. In the researchers’ analysis, submitting those answers did not exfiltrate data, contact a backend or launch malicious code. That quiet first stage helped the later request look like another ordinary step in the same hiring process.

In April, the same Iraq-based VirusTotal submitter uploaded the next stage: a Visual Studio project archive for a flight-management coding exercise. Its README addressed the intended recipient by name and presented a short home assessment. A deliberately flawed loop skipped the final element, giving the developer a plausible reason to build and run the project.

The personalized name and small debugging task were credibility cues, not proof of a legitimate employer. The screenshot above, published with the target’s identity redacted, shows how the instructions framed the project as a normal skills test.

Opening the project crossed the execution boundary

The malicious instruction was in the .csproj project file rather than in the obvious exercise. Visual Studio performs a background design-time build when loading a project to resolve dependencies and support editing. In this sample, the attackers overrode a build target that this initialization calls. The resulting background work copied payload files from the project’s Resources directory into a misleading Microsoft-named folder and launched a binary.

That explains why “I only opened it to inspect the code” is not a sufficient safety boundary in this case. The report describes execution through the IDE’s expected behavior, not a demonstrated vulnerability in every Visual Studio version or every project file. The supplied project was deliberately configured to turn loading into execution.

The file listing separates the decoy task in FlightManager.cs from the project configuration and payload resources. Checking only the visible bug would miss the component that starts the chain.

A Microsoft signature covered the host, not the code it loaded

The next step used a legitimate Microsoft-signed Visual Studio hosting process renamed RuntimeBroker.exe. Its accompanying configuration redirected the .NET startup manager to attacker-controlled code, a technique called AppDomainManager hijacking. The chain then used DLL sideloading to load RuntimeBroker.dll, which Unit 42 calls ShelbyLoader V2. The configuration also attempted to impair Event Tracing for Windows, a source of execution telemetry.

A familiar filename or valid signature on that host does not validate the configuration file or DLL beside it. Nor does the name mean that Windows’ genuine Runtime Broker is itself malicious. The report’s suspicious combination is the renamed host, its companion files and the unexpected location under the user’s local application data.

ShelbyLoader V2 established persistence through a current-user startup entry and staged ShelbyC2 V2, the remote-access payload. A separate module ran PowerShell inside the compromised process without starting PowerShell.exe. Another component, Blackwood, wrapped the Chisel tunneling utility to create a route into the internal network. These are reported capabilities and analyzed stages; the public report does not identify every affected organization or establish a total victim count.

GitHub carried orders—and an escape route for the orders

The loader used GitHub repositories for machine registration, commands and material needed to decrypt a later payload. If its token was revoked or the main channel returned an authorization error, it searched GitHub issues for encrypted fallback instructions hidden in comments. That gave the operators a way to change the destination without relying on the original channel staying available.

This was misuse of a legitimate cloud service. GitHub has removed the malicious infrastructure identified in the report. Removal disrupts that infrastructure; it does not demonstrate that a previously infected machine has been cleaned or that every alternate route was eliminated.

The actors’ own branding also helped investigators. Their public infrastructure borrowed names from Peaky Blinders, and an uploaded theme-song file retained metadata pointing to an Iranian music site. Infrastructure, victim targeting and other artifacts supported Unit 42’s high-confidence assessment of an Iranian state-aligned nexus. Similarities to specific known groups remained low confidence, so the report tracks the activity as CL-STA-1178 rather than conclusively assigning it to one of them.

What to check after an unfamiliar recruitment project

Before opening a supplied assessment, verify the recruiter and vacancy through independently located employer channels. Dubai Airports’ standing recruitment-fraud notice warns that it does not request recruitment payments and identifies its official email domain. That general notice is not a confirmation of this specific malware case, and a plausible sender alone cannot make a downloaded project trustworthy.

If you already opened the reported project, do not reopen it on your usual workstation to reproduce the behavior. Preserve the message, archive and timestamps, disconnect a suspected affected work device from the network and involve your security team. The case offers concrete leads for investigation:

• A MicrosoftRuntime startup value pointing into the unexpected Microsoft\RuntimeBrokers directory under local application data.
• The renamed RuntimeBroker.exe beside its configuration, RuntimeBroker.dll or RuntimeBrokerApi.dll, with provenance matching the assessment.
• Unusual GitHub API traffic following project loading, considered with process ancestry and the report’s published indicators rather than blocked as all GitHub traffic.

These clues require context: a filename alone is not a malware diagnosis, and their absence does not prove the machine is safe. Security tools may remove a visible payload while a startup entry, loader or related module remains. On a personal Windows device where suspicious code ran, Gridinsoft Anti-Malware provides a local scanning step; our fake-job and developer-tool cleanup guide explains the broader recovery decisions. Work devices need the organization’s incident-response process, including review of credentials and sessions exposed from that machine.

The separate WaterPlum fake-interview campaign shows why a familiar hiring workflow is a useful delivery disguise. Blinder Tunnel’s distinguishing lesson is where trust became execution: loading the project was already part of the attack.

References

1. Unit 42. Blinder Tunnel Campaign Targets Iraqi Infrastructure. Palo Alto Networks, October 6, 2026; accessed October 6, 2026.
2. Dubai Airports. Important Advisory: Recruitment Fraud. Standing guidance; accessed October 6, 2026.