Blinder Tunnel: GitHub C2 Targets Iraqi Infrastructure

A campaign tracked by Palo Alto Networks Unit 42 shows how a convincing recruitment process can become the delivery mechanism for a multi-stage intrusion against critical infrastructure. The activity, which Unit 42 calls Blinder Tunnel, targeted an individual in Iraq’s critical-infrastructure sector with a fake Dubai Airports hiring process and a trojanized software-development assessment.

The campaign combined social engineering with abuse of trusted developer tooling. A malicious Microsoft Visual Studio project triggered execution through the project’s .csproj configuration, followed by AppDomainManager hijacking and DLL sideloading. The resulting tool set included the ShelbyLoader V2 loader, the ShelbyC2 V2 remote-access trojan and Blackwood, a tunneling component based on the open-source Chisel utility.

Unit 42 tracks the activity cluster as CL-STA-1178. The organization assesses with high confidence that the activity aligns with an Iranian state-aligned threat actor, while noting that overlaps with specific established Iranian groups remain low confidence and are not sufficient for a group-level attribution.

A recruitment process designed to establish trust

According to Unit 42, the campaign began with an impersonated Dubai Airports IT recruitment process. The target was encouraged to download an installer named Dubai Airport Careers. The installer deployed an offline website that presented itself as a careers portal, including a login screen and a tailored 10-question human-resources questionnaire.

The portal did not perform remote communication, steal submitted answers or execute malware when the questionnaire was completed. Unit 42 assessed this component as a decoy intended to make the interaction appear legitimate and reduce suspicion before the next stage.

The subsequent lure was more technically targeted. The victim received a ZIP archive named DubaiAirport_Carrers_IT_Test.zip, with the misspelling preserved in the filename. The archive contained a C# flight-management project and a personalized Readme.md. The recipient was instructed to open the project in an integrated development environment, build it and correct an intentionally introduced programming error.

This approach is significant for organizations that employ developers, engineers or contractors. The victim was not asked to open an obviously suspicious executable. Instead, the requested action resembled a normal technical screening exercise and relied on the recipient’s familiarity with development tools.

Three execution stages hidden inside a Visual Studio project

Unit 42 identified a three-stage execution sequence.

1. Malicious project evaluation

The first stage abused Visual Studio’s design-time project evaluation. When a developer opens a project, the IDE performs background operations to resolve dependencies and support development features. The malicious project defined a custom XML target named GetFrameworkPaths, overriding the expected behavior associated with that operation.

As a result, the project could execute its instructions when loaded, before the user deliberately compiled or ran the application. Those instructions created a directory under %LOCALAPPDATA%\Microsoft\RuntimeBrokers, copied hidden binaries from the project’s Resources directory and launched a file named RuntimeBroker.exe.

Unit 42 maps this behavior to trusted developer utilities proxy execution. The important defensive lesson is that monitoring only compiled applications or explicit launches is insufficient: project loading itself can become an execution event.

2. AppDomainManager hijacking

The next stage used a renamed, signed Microsoft Visual Studio hosting binary and a manipulated configuration file. The configuration redirected the application’s startup manager to attacker-controlled code, giving the malware control before the host application fully initialized.

The configuration also contained an <etwEnable enabled="false" /> directive. Unit 42 reported that this was intended to disable Event Tracing for Windows, a visibility mechanism used by security and monitoring tools. This is an evasion measure rather than a vulnerability in Dubai Airports infrastructure; Unit 42 explicitly stated that it was not aware of a breach, compromise or vulnerability within Dubai Airports systems.

3. DLL sideloading

The renamed host binary was susceptible to DLL search-order abuse. A malicious RuntimeBroker.dll placed alongside it was loaded into memory, completing the initial execution sequence. The DLL was identified by Unit 42 as ShelbyLoader V2.

The same general execution pattern was later used to deploy Blackwood. That package contained a legitimate Microsoft-signed executable, a configuration file and the malicious DLL. Organizations should therefore treat unusual combinations of signed binaries, adjacent configuration files and non-standard DLLs as a higher-risk pattern rather than trusting the signature alone.

Loader, backdoor and tunneling components

ShelbyLoader V2 performed several functions: it conducted host checks, created persistence, fingerprinted the system, established communication with its command-and-control infrastructure and retrieved a second-stage payload.

For persistence, the loader created a current-user startup registry value named MicrosoftRuntime. The value pointed to the copy of RuntimeBroker.exe in the RuntimeBrokers directory. Unit 42 reported that the malware checked persistence at 120-second intervals and recorded whether persistence already existed, had just been created, or could not be established.

Its primary beacon operated on a 63-second interval. The malware used a hard-coded GitHub personal access token to interact with a repository associated with the attackers. It uploaded a Base64-encoded machine fingerprint to a path based on a derived machine identifier, then polled another file for commands. The command content was decoded, executed and acknowledged through the repository.

This is an example of “living off the cloud”: malicious traffic is carried through a widely used service rather than an obviously dedicated command server. Blocking all GitHub access is rarely practical for development-heavy organizations, so detection must also examine unusual API behavior, repository paths, authentication patterns and endpoint processes making those requests.

The malware included a fallback mechanism using GitHub’s Issues Search API. If the primary token was revoked or the primary channel returned an unauthorized response, the implant searched for date-based issues and parsed data hidden inside HTML comment markers. Unit 42 reported that the extracted material was encrypted and used to update the repository owner, repository path and authentication token. This design allowed the operators to change routing information without modifying the initial implant.

After communication was established, ShelbyLoader V2 decrypted and loaded RuntimeBrokerApi.dll in memory. Unit 42 named this second-stage remote-access trojan ShelbyC2 V2. The payload used the separate PsProxy.dll module to run PowerShell commands through the .NET automation engine without launching PowerShell.exe and without writing scripts to disk. This reduced the value of detections that focus only on a visible PowerShell process.

The final tool described by Unit 42 was Blackwood. It embedded an encrypted Chisel payload inside a .NET loader and reflectively loaded it into memory. Chisel provided encrypted TCP tunneling over HTTP and SOCKS5 proxy functionality. In the analyzed configuration, the tunneling endpoint was 91.107.156[.]29, with a reverse SOCKS proxy configuration. Unit 42 assessed that this capability could provide a bridge into the compromised network and support lateral movement.

The recovered .NET components were obfuscated with the open-source Obfuscar tool. Unit 42 also reported runtime string decryption and non-printable Unicode characters in class and method identifiers, complicating static analysis.

Attribution and campaign scope

Unit 42 linked Blinder Tunnel to a wider activity cluster affecting Middle Eastern telecommunications, aviation and other critical entities. The organization reported related activity involving Iraq, Israel and the United Arab Emirates, including a separate credential-harvesting operation using conflict-themed lures and lookalike Google-themed domains.

The attribution assessment is based on several artifacts: infrastructure associated with an Iranian ISP, Persian-language domain relationships, metadata embedded in an audio file hosted in an attacker-controlled GitHub repository and regional victimology. Unit 42 also identified recurring “Peaky Blinders” naming across malware and infrastructure, including repository and component names.

These indicators support Unit 42’s high-confidence assessment of an Iranian state-aligned nexus. They do not establish that a particular named Iranian group conducted the campaign. Unit 42 described similarities to activity associated with Screening Serpens and Agent Serpens, but characterized those overlaps as low confidence.

What organizations should do now

• Restrict project execution. Review whether developers can open untrusted Visual Studio projects on production-connected workstations. Use isolated development environments for external coding tests and require project archives to undergo security inspection before opening.
• Monitor design-time build activity. Alert on unusual MSBuild or Visual Studio behavior, especially project files that define unexpected targets, write executables into user profile directories or launch renamed binaries.
• Hunt for AppDomainManager and DLL sideloading. Examine configuration files adjacent to signed .NET executables, unexpected startup-manager settings and DLL loads from user-writable directories. Pay particular attention to binaries named like Windows components but located outside normal system paths.
• Review user-startup persistence. Search current-user startup registry locations for unusual values, including MicrosoftRuntime, and investigate references to RuntimeBroker.exe under the reported RuntimeBrokers path.
• Inspect GitHub API traffic. Identify endpoints that access repositories, issues or comments from unexpected processes. Correlate API use with newly created files, in-memory .NET loading, encoded content and developer workstations that do not normally automate GitHub.
• Improve PowerShell visibility. Do not rely solely on process creation for PowerShell detection. Collect .NET assembly-load telemetry, script-block visibility where available, memory events and parent-child relationships involving Visual Studio, MSBuild and signed hosting binaries.
• Control tunneling behavior. Monitor outbound HTTP connections that establish proxy-like sessions, unusual SOCKS activity and connections to the reported indicator 91.107.156[.]29. Network controls should be paired with endpoint investigation because cloud-hosted services and legitimate hosting providers can change over time.
• Strengthen recruitment workflows. Verify hiring requests through independent channels, especially when candidates are asked to install software or open source projects. Security awareness programs should cover technical screening scams, not only conventional document-based phishing.

What remains unknown

The supplied research does not establish the full number of victims, the extent of any successful lateral movement or whether data was exfiltrated from the Iraqi target. It also does not identify a specific Iranian organization as the operator. Some infrastructure was used for testing, and Unit 42 distinguished fabricated test data from routable network indicators. Organizations should therefore use the reported indicators as starting points for investigation rather than treating them as a complete list of campaign infrastructure.

Conclusion

Blinder Tunnel demonstrates how a targeted intrusion can begin with a credible professional interaction and progress through trusted developer workflows. The campaign’s defensive challenge lies in the combination: a harmless-looking recruitment portal, a realistic coding task, project-file execution, configuration-based hijacking, sideloaded DLLs, memory-resident payloads and GitHub-mediated command traffic.

For critical-infrastructure operators and software-focused organizations, the priority is to extend monitoring beyond conventional executables. Project loading, signed-host abuse, user-profile persistence, API behavior and in-memory .NET execution all belong in the same investigative picture.

Sources

Palo Alto Networks Unit 42: Blinder Tunnel Campaign Targets Iraqi Infrastructure