A hiring process as the attack surface
Unit 42 at Palo Alto Networks disclosed a campaign it calls Blinder Tunnel, attributed with high confidence to an Iranian state aligned actor the firm tracks under the designation CL-STA-1178. The operation's opening move was social engineering built around something almost every working technical professional has experienced firsthand: a coding challenge sent as part of a hiring process. The attackers impersonated the Dubai Airports IT department directly and sent trojanized coding exercises to a set of high value targets, counting on each recipient to treat a plausible looking recruitment test as routine background activity rather than something worth scrutinizing closely before opening it.
That framing matters because it exploits a genuine blind spot that most security awareness training programs simply do not cover at all. Employees are trained extensively to distrust unsolicited invoices, urgent password reset links, and messages demanding immediate action. They are rarely, if ever, trained to distrust a recruiter's coding assessment, particularly one that references a real, well known, and entirely legitimate employer like Dubai Airports by name. The lure succeeded precisely because, on its surface, it did not resemble an attack in any way a trained employee would recognize.
Three steps from a project file to full compromise
Once a target opened the trojanized challenge, Unit 42 found that the attackers used a deliberate three step chain to establish their initial foothold on the machine. First, they exploited legitimate Windows developer project files, the kind of ordinary file any working engineer opens dozens of times every single week without giving it a second thought. Second, they performed what is known as AppDomainManager hijacking, a technique that abuses a legitimate built in .NET feature to load attacker controlled code inside an otherwise fully trusted process on the system. Third, they executed binaries through DLL sideloading, tricking a legitimate signed application into loading a malicious library in place of the genuine one it expected to find.
That three step chain ultimately deployed custom malware Unit 42 has named ShelbyLoader V2. Every individual technique inside that chain has a legitimate, everyday use case on its own, which is exactly what makes the combination so effective against defenders. None of the three steps looks remotely like malware behavior to a signature based detection tool running in isolation. The actual compromise happens quietly in the gaps between ordinary developer workflows, not inside some obviously malicious file that traditional antivirus software was ever specifically built to catch and flag.
Hiding command and control inside GitHub itself
The most notable element of the entire Blinder Tunnel campaign is how it chose to communicate with machines it had already compromised. Rather than standing up dedicated command and control servers of its own, which defenders have gotten reasonably good at spotting, the campaign misused GitHub's own API infrastructure directly, fetching decryption keys and downloading payloads straight from ordinary repositories, and falling back on GitHub issues as a resilient communication channel whenever its primary method failed for any reason. GitHub has since taken down the specific malicious infrastructure Unit 42 identified during its investigation, but the underlying technique itself is the lesson that clearly outlasts any single takedown action.
Traffic headed to GitHub looks like completely ordinary developer activity to almost every network monitoring tool in use today and to almost every analyst reviewing a flow log during a routine review, because it genuinely is ordinary developer activity for the overwhelming majority of an organization's engineers on any given day. An attacker who can successfully blend command and control traffic into that everyday baseline does not need to evade detection in any traditional sense at all. They simply need the detection tooling in place to categorize their traffic as normal, and GitHub's sheer ubiquity inside modern engineering organizations makes that categorization happen almost automatically.
The campaign that named itself after a crime drama
Unit 42 found that the attackers incorporated a Peaky Blinders theme throughout the entire operation, naming individual infrastructure components after the show's distinctive branding and even embedding its theme song directly inside the malware's own metadata. Researchers ultimately named the campaign Blinder Tunnel after the attackers' own infrastructure naming conventions combined with the malware's underlying tunneling capability, a fitting reminder that a threat actor's own operational choices, even purely stylistic ones made for fun, regularly end up becoming the exact evidence that eventually unravels the whole operation.
Those same stylistic choices produced genuine operational security failures that researchers could follow. The attackers exposed working tools on public repositories where anyone could find them, combined phishing and tunneling infrastructure together in ways that created clearly traceable links between campaigns, and left identifying metadata inside the embedded theme song that connected Blinder Tunnel directly to a separate campaign using conflict themed Google Drive lures for credential harvesting against an Israeli entity between May and June of 2026. Real discipline in the technical attack chain did not carry over into equivalent discipline around the smaller operational details.
What this means for enterprises outside Iraq
No organization should read this disclosure as a purely regional story that stays regional and therefore does not apply to them. The specific techniques involved, AppDomainManager hijacking, DLL sideloading delivered through ordinary legitimate project files, and command and control traffic hidden inside a mainstream developer platform, are fully reusable against any organization whose engineers routinely interact with recruiting processes, open source repositories, and standard Windows development tooling in their daily work. The targeting in this particular campaign was Iraqi critical infrastructure specifically. The toolkit behind it is not geography specific in any meaningful way at all.
Security teams should start treating recruitment adjacent files, coding challenges, take home assessments, and candidate submitted repositories as a distinct risk category carrying its own dedicated scanning and sandboxing requirements, kept separate from the general email attachment pipeline most organizations already monitor closely. Teams should also extend active monitoring for anomalous API usage to developer platforms like GitHub specifically and by name, since the sheer volume of legitimate everyday traffic on those platforms is exactly what made this particular campaign's command and control so difficult to distinguish from completely normal engineering work happening in parallel.
