Unit 42 has published research on Blinder Tunnel, an Iran-nexus campaign that targeted Iraqi critical infrastructure through fake Dubai Airports recruitment activity. The operation is worth attention because it did not start with a generic phishing attachment. It abused developer trust: a realistic hiring flow, a Visual Studio coding challenge, legitimate project files, cloud services, and tunneling utilities.

For small businesses and government contractors, the defensive lesson is direct: developer workstations and engineering workflows are high-value access paths. If a developer can run project files, access repositories, authenticate to cloud systems, or reach sensitive environments, that endpoint is not “just a laptop.” It is part of the trust boundary.

What Unit 42 reported

Unit 42 tracks the activity as CL-STA-1178 and assesses with high confidence that it aligns with an Iranian-nexus threat. The Blinder Tunnel campaign used fake Dubai Airports IT recruiting themes to engage a target connected to Iraq’s critical infrastructure sector. After an initial decoy career-portal stage, the actor delivered a malicious C# coding assessment packaged as a Visual Studio project.

The infection chain abused normal developer behavior. Unit 42 reports that the attackers weaponized a .csproj file so Visual Studio’s design-time build process could trigger execution when the project was opened. The chain then used AppDomainManager hijacking and DLL sideloading to run custom malware, including ShelbyLoader V2, inside a trusted-looking process path.

The campaign also blended into common enterprise traffic. The malware used GitHub API infrastructure for command-and-control functions, including payload retrieval, decryption-key handling, host registration, tasking, and a fallback mechanism through GitHub issue data. Unit 42 says GitHub removed the malicious infrastructure identified during the investigation. The tooling also included an in-memory wrapper for Chisel, an open-source tunneling utility, to bridge attacker infrastructure and compromised networks.

Why this matters

Blinder Tunnel is a good example of where phishing, supply-chain risk, and post-compromise tunneling overlap. The lure was not only a fake job offer; it was a workflow that asked the target to do something normal for a developer: open, inspect, build, and debug a project. That makes the campaign especially relevant to organizations with software teams, OT engineering staff, managed service providers, and cleared or government-adjacent contractors.

The GitHub abuse also matters. Many organizations allow developer workstations broad access to GitHub, package registries, cloud APIs, CI/CD systems, and collaboration services. Blocking those services outright is usually unrealistic. That means detection has to focus on context: which process is talking to the service, what data is being fetched, whether the endpoint recently opened untrusted code, and whether outbound behavior changes after the project is loaded.

Defensive takeaways

  • Treat coding challenges as untrusted code. Require developers, recruiters, and hiring teams to open external assessment projects in disposable VMs, cloud sandboxes, or isolated lab systems instead of daily-driver workstations.
  • Watch developer tooling for child-process abuse. Monitor Visual Studio, MSBuild, IDEs, compilers, package managers, and scripting tools spawning unexpected binaries, PowerShell, renamed system processes, or code from user-profile paths.
  • Harden project-file execution paths. Review controls around .csproj, build events, custom targets, dependency restore actions, and IDE extensions. Security teams should understand which project features can execute code before a developer intentionally runs the application.
  • Baseline GitHub and cloud API usage. GitHub traffic is not automatically safe. Look for unusual API calls from non-browser processes, unexpected repository paths, encoded payload retrieval, repeated issue/comment queries, or traffic that appears immediately after opening external code.
  • Detect tunneling from endpoints. Chisel and similar tools are legitimate but dangerous in the wrong context. Alert on new tunnel binaries, long-lived outbound connections, unusual listening ports, and developer endpoints bridging traffic into internal systems.
  • Separate developer identity from production access. Enforce least privilege, phishing-resistant MFA, conditional access, device compliance, short-lived credentials, and separate administrative paths for production, cloud, and CI/CD actions.
  • Preserve forensic evidence. If a suspicious project was opened, collect the archive, project files, process tree, endpoint telemetry, GitHub/API logs, browser history, identity logs, and network flows before wiping the host.

Bulwark Black assessment

Blinder Tunnel shows that critical infrastructure targeting does not always begin at the firewall or the PLC. It can begin with a developer believing they are completing a normal hiring exercise. From there, the attacker gets code execution, persistence, cloud-based tasking, and a tunnel into the environment.

The practical response is to make developer trust conditional. External code should run in controlled environments. Developer workstations should have strong endpoint telemetry. GitHub and cloud API access should be monitored by process and identity context. Tunneling behavior should be treated as a high-priority investigation trigger, especially when it appears on systems with access to engineering, cloud, or production networks.

For SMBs and government contractors, the near-term move is simple: document how your team handles external code samples, vendor projects, recruitment tests, proof-of-concept tools, and GitHub-hosted utilities. If the current answer is “developers open them locally,” that is a gap worth closing before an attacker turns a coding test into an access path.

Source: Unit 42 — “Blinder Tunnel Campaign Targets Iraqi Infrastructure”.