Blinder Tunnel Used Visual Studio Projects and GitHub for Stealthy Network Access

A coding assessment can run malware before a developer compiles a line of code. That was the entry point in Blinder Tunnel, a set of targeted operations that Unit 42 attributes with high confidence to an Iran-aligned threat actor. The attackers posed as Dubai Airports recruiters, delivered a weaponized Visual Studio project to a software professional in Iraq, and used routine developer tooling to load malware in the background.

The operation’s technical significance lies in how its parts fit together. A malicious project configuration triggered execution when opened in Visual Studio; configuration hijacking and DLL sideloading then helped load the custom ShelbyLoader V2 backdoor. The malware used GitHub’s API for command and control (C2), with encrypted fallback instructions hidden in issue comments. A separate loader deployed Chisel, enabling encrypted tunnels and SOCKS proxy access to compromised networks.

Unit 42 tracks the activity as CL-STA-1178 and calls the March 2026 operation Blinder Tunnel. Researchers saw related infrastructure being staged from November 2025. The assessment links the activity to a wider set of Middle Eastern operations, including a credential-harvesting effort aimed at an Israeli entity in May and June 2026. The researchers connect the cluster to earlier activity described by Elastic Security Labs as The Shelby Strategy, while cautioning that the available overlaps do not identify a specific established group.

A recruitment process built to earn trust

The first lure presented itself as a development job at Dubai Airports. The attackers claimed to represent its IT department and asked a likely software engineer in Iraq to complete an assessment. Unit 42 says it found no evidence that Dubai Airports’ own systems had been breached or involved.

The initial download, named Dubai Airport Careers, was an Inno Setup installer. It installed an offline career portal that asked the target to log in with credentials supplied by the supposed recruiters, then presented a tailored, 10-question HR questionnaire. Completing the questionnaire did not cause network communication, data theft, or malware execution. Its role appears to have been to make the hiring process feel credible before the malicious technical test arrived.

In April 2026, another submission from the same VirusTotal source revealed the next step: a project archive named DubaiAirport_Carrers_IT_Test.zip, with “Carrers” misspelled. A personalized Readme.md addressed the recipient as a candidate and described an at-home assessment. The sender claimed to be a senior manager in the airport’s IT department and instructed the target to open a C# “Flight Management System” project in an integrated development environment.

The exercise included a deliberately faulty backend method: a for loop that skipped the final element. The task looked plausible for an experienced developer, but fixing the bug was beside the point. The project’s .csproj file was the trigger, and loading the project into Visual Studio could start the infection before the developer tried to build or run the application.

Execution hidden in Visual Studio’s background work

Visual Studio performs a design-time build when it opens a project. This background process resolves dependencies and supports editor features. Unit 42 found that the malicious project exploited this initialization by defining its own XML target called GetFrameworkPaths, a name used during the environment’s normal evaluation process. The custom target replaced the expected behavior and ran attacker instructions as Visual Studio initialized the project.

The instructions created %LOCALAPPDATA%\Microsoft\RuntimeBrokers, copied concealed binaries from the project’s Resources directory, and launched RuntimeBroker.exe. That executable was a renamed, signed Microsoft Visual Studio hosting process. The launch could occur while the developer was still reading the assessment instructions, under the cover of expected activity from msbuild.exe and Visual Studio.

This use of a trusted developer utility is classified as Trusted Developer Utilities Proxy Execution. It shifts the security question from whether a user knowingly ran a suspicious program to whether a normal project-loading event caused a trusted tool to perform unexpected work. For teams that accept source code or project archives from outside their organization, the project configuration itself deserves scrutiny alongside the code.

The next stage used AppDomainManager hijacking. The malware altered RuntimeBroker.exe.config so the .NET host would load an attacker-controlled startup manager before the legitimate application began. That gave the malicious code control inside a process that looked like a trusted host. The configuration also included <etwEnable enabled="false"/>, an instruction intended to disable Event Tracing for Windows (ETW), which security products can use to observe execution.

The chain ended with DLL sideloading. Because the renamed host could load libraries from its execution directory, the attackers placed a malicious RuntimeBroker.dll beside it. The host loaded that library into memory, starting the custom malware. Unit 42 says this sequence combines three execution techniques: a weaponized project file, AppDomainManager hijacking, and DLL sideloading. Its research also points to the growing use of AppDomainManager manipulation by other Iran-linked operators; Unit 42 has previously described the technique in activity it tracks as Screening Serpens.

Defenders can look for project files that define unexpected build targets, binaries launched from unusual locations under a developer’s profile, changes to .NET host configuration, and trusted executables loading DLLs outside normal system directories. Unit 42 reports that Cortex XDR flagged the relevant project and execution chain as high risk and blocked the threat in the cases described. That result is specific to the vendor’s analysis; the broader detection challenge is recognizing a suspicious sequence across project loading, file creation, configuration changes, and library loading.

GitHub as a command channel and fallback directory

After starting, ShelbyLoader V2 used GitHub’s API to communicate with its operators. The approach, often called “living off the cloud,” puts malicious traffic on a service that organizations may already use for software work. The technique can make network activity harder to distinguish from ordinary platform use, though a legitimate service does not make the activity harmless.

The backdoor contacted the peakyblinders-tm/myLic repository and uploaded a Base64-encoded machine fingerprint to /{machineId}/Lic.txt. The malware derived the identifier from the first 16 lowercase hexadecimal characters of a SHA-256 hash combining the machine fingerprint with the string Peaky Blinders 2.1. Once registered, it repeatedly fetched /{machineId}/Inf.txt, decoded a Base64 command from the response, and executed it. It then sent an acknowledgment containing a SHA-256 file value so the repository entry could be updated or cleared.

GitHub’s API rate limits shaped the malware’s timing. When the API returned HTTP 403, the implant entered a one-hour sleep loop. The backdoor also checked whether it was running in a virtualized environment, examined host hardware including CPU, memory, and disk space, and required that it be launched by explorer.exe. These checks can delay or prevent execution in analysis environments.

The malware had a fallback for a revoked token or an HTTP 401 response from its primary channel. It searched GitHub Issues using the current date in yyyymmdd format, together with a repository identifier and issue-type filter. It then retrieved matching issue comments and looked for ciphertext placed between ordinary HTML comment markers, <!-- and -->.

To decode the recovered instructions, the malware used AES-256-CBC. Its key depended on an MD5 hash of the date string and the unique machine identifier; the initialization vector was derived from that key, with the derivation iterated five times. The resulting text could update the C2 owner, repository path, and access token. Because the identifier is specific to a target machine, the embedded fallback data could not be decoded without that machine’s value.

This fallback design helps explain why the GitHub takedown did not erase all evidence of the operation. Unit 42 identified an issue comment posted on April 16, 2026, as a possible additional source of C2 instructions. Researchers had also seen an earlier test of the dead-drop mechanism on Nov. 18, 2025. In that test, an encrypted block in a public repository comment appears to have let the operators check whether their malware could retrieve fallback routing information.

GitHub removed the malicious infrastructure identified by Unit 42. The report nevertheless illustrates a practical limitation of blocking one repository: implants designed to discover replacement routes through issue comments can keep a secondary path available. Monitoring should therefore consider unusual API searches and comment retrieval, alongside known repository names and tokens.

Memory-based command execution and a second payload

The operators’ tool set was modular. Unit 42 found that the recovered .NET binaries had been processed with the open-source Obfuscar tool. Obfuscation, runtime string decryption, and non-printable Unicode characters in class and method names complicated both manual review and automated analysis.

RuntimeBroker.dll, which Unit 42 named ShelbyLoader V2, was a newer version of the loader described in Elastic’s earlier Shelby Strategy analysis. Its job was to perform initial checks, establish communication, and retrieve a second-stage payload. That payload, RuntimeBrokerApi.dll, was encrypted with AES-CBC and loaded as a .NET assembly directly into memory. The decryption key came from the full SHA-256 hash of license content fetched from the GitHub C2; the first 16 bytes of the same hash served as the initialization vector.

Unit 42 calls this main remote access tool ShelbyC2 V2. It managed commands through another module, PsProxy.dll, and could stage a tunneling tool. PsProxy provided a way to run PowerShell commands without starting PowerShell.exe. Instead, it connected to the core PowerShell engine, System.Management.Automation.dll, and created an in-memory runspace inside the hijacked host process.

Running scripts this way avoids a familiar process-based detection signal: the appearance of PowerShell.exe. It also avoids writing malicious scripts to disk. The module was designed to run in a separate memory context, so a script failure would be less likely to interrupt the backdoor’s C2 connection. The main implant passed each raw script to PsProxy for execution.

On May 1, 2026, the peakyblinders-tm account created a public repository named pubs containing Client.zip. Unit 42’s analysis found an executable identified as Blackwood, a payload previously covered by CPX and submitted to VirusTotal in May 2025. The archive used the same broad launch pattern as the earlier malware: a trusted hosting process, AppDomainManager hijacking, and DLL sideloading. Its files included Blackwood.dll and a renamed host, vshost32.exe.

Blackwood was a loader for Chisel, an open-source tunneling utility available on GitHub. The loader carried the Go-compiled Chisel payload as an 8.4 MB embedded resource named Blackwood.Cheese.xml, encrypted with AES-256-CBC. It decrypted the resource using a SHA-256 hash of a hard-coded passphrase, then reflectively loaded the resulting DLL into memory. Chisel read its settings from Blackwood.dll.conf, stored beside the executable.

The configuration identified 91.107.156[.]29 as a tunneling endpoint and instructed the infected host to create a reverse SOCKS proxy on port 10999. Chisel can carry encrypted TCP connections over HTTP and support SOCKS5 proxying. In this setup, that created a route through which an operator could reach services on the internal network by relaying traffic through the compromised system. The result was an access path suited to moving beyond the initial host.

Related activity and attribution evidence

Unit 42 connected the Iraqi recruitment operation with a separate credential-harvesting effort targeting an Israeli entity in May and June 2026. A Blackwood configuration submitted to VirusTotal pointed to 65.109.214[.]145, a server that hosted both the malware component and lookalike domains styled after Google services. The domains included cloud.g-drive[.]cam, which presented a page made to resemble a Google Drive error and prompted a download of WarUnPublishedDocuments.zip. The download link led to a counterfeit sign-in page at hxxps[:]//cloud.g-drive[.]cam/signin/v2/identifier?from=landing.

Unit 42 reported the activity to Google. Google said its Drive systems and infrastructure were not compromised or involved, and that its Safe Browsing and Chrome protections block the identified malicious domains. The report also identified an earlier staging domain, asdfafadafg[.]online, which resolved to 38.180.136[.]127. Timeline analysis suggested the operators tested the phishing setup there in early May before shifting to the main server.

Additional operational traces show the operators checking their own infrastructure. An April 24, 2026, GitHub issue in the peakyblinders-tm repository contained apparent test strings, automated login and device alerts, and mock connection details. One entry paired an Iraq country code with 138.256.21[.]23. Since 256 is outside the valid range for an IPv4 address segment, Unit 42 assessed that the address was fabricated to avoid generating real network traffic while the operators tested their logging.

Several clues support Unit 42’s attribution to an Iran-aligned actor. The operators’ public GitHub profile contained an audio file named Peaky Blinders Team.mp3, featuring the television show’s theme. Its metadata retained the comment value MusicDel[.]ir, which Unit 42 identified as an Iranian music distribution site. The researchers also point to infrastructure ownership, malware metadata, regional victim targeting, and repeated “Peaky Blinders” naming across tools and repositories.

The targeting profile included telecommunications, aviation, and other high-value organizations in Iraq, Israel, and the United Arab Emirates. Unit 42 sees low-confidence tradecraft overlaps with groups it tracks as Screening Serpens and Agent Serpens, including tailored recruitment lures, .NET configuration manipulation, GitHub-based fallback routing, and PowerShell execution inside .NET. Those similarities provide context, but the researchers say they are not strong enough to attribute CL-STA-1178 to either group specifically.

What defenders should take from the operation

Blinder Tunnel puts pressure on controls at several points in the developer workflow. A source archive can carry executable behavior in its project settings, and opening it may be enough to start a chain involving trusted build tools. Endpoint monitoring that focuses only on unfamiliar executables or visible command shells can miss activity launched through signed hosts and in-memory .NET components.

For engineering and security teams, the practical response is to treat externally supplied project files as executable content. Review build configuration before opening unfamiliar projects, restrict which tools can load code from writable directories, and watch for unexpected DLL loads, changes to .NET configuration files, and process activity from developer applications. Network monitoring can add context by flagging unusual GitHub API access, especially repeated issue searches and comment retrieval that does not match normal developer workflows.

The campaign also shows why incident review should follow the chain beyond the first loader. ShelbyLoader V2 used GitHub for tasking, PsProxy for quiet command execution, and ShelbyC2 V2 to stage Blackwood. Blackwood then used Chisel to create a route into internal networks. Each component had a distinct role, so evidence limited to the initial project may understate what an intruder could do after execution.

Unit 42 says Cortex AgentiX Agentic Assistant helped its researchers query investigation data and develop follow-up recommendations. Palo Alto Networks also shared the findings with Cyber Threat Alliance members. The central defensive question remains concrete: can teams identify when a routine project load causes a trusted developer process to copy files, alter runtime configuration, load an unexpected library, and reach cloud APIs in an unusual pattern?

Blinder Tunnel’s blend of tailored hiring lures and developer tooling makes that sequence the useful point to watch. Project review, endpoint telemetry, and cloud-service monitoring need to meet at the same investigation, because the intrusion’s parts were designed to look ordinary when viewed alone.