Blinder Tunnel Used Visual Studio Projects and GitHub for Stealthy Access

Blinder Tunnel shows how a developer’s normal workflow can become the entry point for a targeted intrusion. Attackers posing as Dubai Airports recruiters sent a tailored C# coding assessment that could run malicious instructions as soon as a developer opened the project in Visual Studio. The resulting tool chain combined configuration hijacking, DLL sideloading, memory based command execution and GitHub hosted command traffic.

Unit 42 tracks the activity as CL-STA-1178 and assesses with high confidence that it aligns with an Iranian state aligned threat actor. Researchers observed infrastructure staging as early as November 2025 and an attack against a person in Iraq’s infrastructure sector in March 2026. The investigation also connected the group’s infrastructure to a separate credential theft operation targeting an Israeli organization later that year. GitHub has removed the malicious infrastructure identified by the researchers.

A hiring lure built around a coding task

The attackers first presented themselves as members of Dubai Airports’ IT department and offered the target a development role. The approach used two stages. An installer named Dubai Airport Careers set up a self contained, offline careers portal. The target logged in with credentials supplied by the purported recruiters and completed a 10 question HR questionnaire.

The portal itself did not communicate over the network, extract information or run malware when the questionnaire was submitted. Unit 42 considers it a decoy: a convincing first step intended to make the hiring process seem plausible before the attackers delivered the harmful file. Researchers say they have no indication that Dubai Airports’ systems were breached or involved.

In April 2026, a VirusTotal submission from the same source that had reported the careers portal exposed the next stage. The target received a Visual Studio project archive called DubaiAirport_Carrers_IT_Test.zip, with “Carrers” misspelled. Its Readme.md file addressed the target personally and described an at home assessment from a purported senior IT manager.

The project, named Flight Management System, contained a small bug in a C# backend method: a for loop skipped the final element. The task asked the recipient to build and run the project to find the problem. That request gave the malware a natural reason to be opened in a developer tool—and made the malicious behavior harder to distinguish from the expected workflow.

The key detail is that the project did not need to compile before the attack began. Visual Studio performs background evaluation when a developer opens a project. The attackers modified the project’s .csproj configuration to exploit that initialization step.

During a design time build, Visual Studio runs a command called GetFrameworkPaths to resolve project information and support IDE features. The malicious project defined its own XML target with that name, replacing the expected behavior with attacker instructions. When Visual Studio performed its routine background check, the custom target ran without requiring the developer to start a build.

The instructions created %LOCALAPPDATA%\Microsoft\RuntimeBrokers, copied concealed binaries from the project’s Resources directory and launched RuntimeBroker.exe. The payload could therefore start while the recipient was still reading the assessment instructions. Unit 42 classifies this method as Trusted Developer Utilities Proxy Execution: a legitimate development process triggers the malicious activity.

Three layers of execution concealment

The initial project file set off a sequence involving AppDomainManager hijacking and DLL sideloading. These techniques let the attackers route execution through files and processes that resemble ordinary Windows or Visual Studio components.

First, MSBuild launched a signed Microsoft Visual Studio hosting process, vshost.exe. The attackers renamed it RuntimeBroker.exe and supplied a corresponding RuntimeBroker.exe.config file. That configuration redirected the application’s startup manager to the attacker’s version. Control passed to the malicious code before the host application’s usual startup, loading the custom remote access tool (RAT) that Unit 42 calls ShelbyLoader V2.

The configuration also included the directive <etwEnable enabled="false"/>. Event Tracing for Windows (ETW) helps security products and analysts track program activity. Disabling it can reduce visibility into execution, including activity that takes place in memory. Unit 42 describes AppDomainManager hijacking as an evasion method seen in other recent activity as well, including operations associated with Screening Serpens.

The final execution stage used DLL sideloading. Because the renamed RuntimeBroker.exe could load libraries from its application directory, attackers placed a malicious RuntimeBroker.dll beside it. The process loaded that library into memory, where it served as ShelbyLoader V2.

For defenders, the chain suggests looking beyond an executable’s filename or signature. A trusted binary loading an unexpected library from a user writable location, a project file defining unusual build targets, or a Visual Studio process creating a new runtime directory can each provide useful detection signals. Unit 42 says Cortex XDR flagged the initiating .slnx file as a high severity threat in the described case and blocked it before user interaction. It also reports that its product identified the execution chain as high risk.

ShelbyLoader V2 used GitHub for command traffic

The malware’s components were built for separate jobs. ShelbyLoader V2 acted as the first loader, performed basic checks on the compromised host, contacted its command server, then retrieved and decrypted a second stage. The recovered .NET files were obfuscated with the open source tool Obfuscar. The obfuscation used runtime string decryption and nonprinting Unicode characters in class and method names, making static inspection and reverse engineering more difficult.

Rather than communicate with a conventional server for every instruction, the loader misused GitHub’s API. This “living off the cloud” approach can make malicious traffic resemble ordinary use of a familiar developer platform. Before GitHub removed the identified infrastructure, a repository under the peakyblinders-tm account carried the command exchange.

The malware registered a device by sending a Base64 encoded machine fingerprint to /{machineId}/Lic.txt in the peakyblinders-tm/myLic repository. It calculated the machine identifier from the first 16 lowercase hexadecimal characters of a SHA 256 hash, using the text Peaky Blinders 2.1 joined with the machine fingerprint.

After registration, the implant repeatedly fetched /{machineId}/Inf.txt and checked for a Base64 encoded command. It decoded and ran any instruction, then sent an acknowledgment containing the SHA 256 hash of the file it was updating. If GitHub returned HTTP 403 because of rate limits, the malware waited in a one hour sleep loop.

The loader also checked for signs of virtualization, reviewed the host’s CPU, memory and disk, and required that it be started by explorer.exe. Such checks can delay execution in analysis environments or on machines that do not match the operators’ expectations.

A second GitHub route provided a fallback if the main repository or its authentication token stopped working. On an HTTP 401 response, ShelbyLoader V2 queried the GitHub Issues Search API for issues matching a date formatted as yyyymmdd, the repository identifier and an issue type filter. It then fetched matching comments and searched between HTML comment markers, <!-- and -->, for encrypted routing instructions.

The malware decrypted that data with AES 256 CBC. Its key came from an MD5 hash of the current date and the device’s unique machineId; it derived the initialization vector from the key and iterated the process five times. The decoded configuration could update the command server’s account, repository path and access token. This gave the operators a way to redirect the implant through public issue comments if the main channel became unavailable.

Unit 42 found evidence that the operators tested this fallback as early as November 18, 2025, by placing an encrypted payload in a public GitHub comment. A comment posted on April 16, 2026, may have supplied another fallback configuration, though the researchers note that it could not be decrypted without a target’s machine identifier.

Commands ran inside memory

ShelbyLoader V2 used a separate module, PsProxy.dll, to run local commands. The module had no independent network or persistence functions. Its role was to execute PowerShell scripts without starting the familiar PowerShell.exe process, which security monitoring often watches for suspicious script activity.

Instead, PsProxy loaded the PowerShell engine through System.Management.Automation.dll and created a custom runspace inside the hijacked process. A runspace is an execution context for PowerShell commands. The main implant passed raw script content to this module, which ran it in memory without writing a script file to disk or starting a separate console process.

This division also provided some operational resilience: a failure in the script execution module did not necessarily interrupt the loader’s GitHub connection. For defenders, process monitoring alone may miss this style of command execution. Visibility into .NET module loads, unusual runspace activity and the parent process remains relevant.

Once it had established communication, ShelbyLoader V2 read an encrypted file named RuntimeBrokerApi.dll from its base directory. Unit 42 calls this second stage ShelbyC2 V2, following the name used for an earlier version. The loader derived an AES CBC key from the full SHA 256 hash of license content retrieved from GitHub; the first 16 bytes of the hash served as the initialization vector. It decrypted the file and loaded the result into memory as a .NET assembly.

ShelbyC2 V2 coordinated command execution through PsProxy and prepared the next tool: Blackwood, which gave the operators a route into the victim’s internal network.

Blackwood added an encrypted Chisel tunnel

On May 1, 2026, the operators created a public repository called pubs under peakyblinders-tm. It contained one archive, Client.zip. Inside was a malicious executable named Blackwood.dll, a tool previously described by CPX and submitted to VirusTotal in May 2025.

The attackers reused the same execution approach: AppDomainManager hijacking followed by DLL sideloading. A trusted vshost32.exe process read its configuration and loaded Blackwood.dll into memory.

Blackwood was a loader for Chisel, an open source tunneling utility. The tool can form encrypted TCP tunnels over HTTP and support SOCKS5 proxying, allowing traffic to pass through a compromised machine and reach other systems on its network. In this case, the configuration directed the infected host to connect to 91.107.156[.]29 and create a reverse SOCKS proxy on port 10999.

The Chisel payload was concealed inside the .NET loader as an 8.4 MB resource named Blackwood.Cheese.xml. It was encrypted with AES 256 CBC. Blackwood derived the decryption key by hashing the hard coded passphrase y0Da+QH#pwSg38E?=8R;71-jQu8Tqq with SHA 256. After decrypting the resource, the loader reflectively loaded the Go compiled Chisel library into memory. The file Blackwood.dll.conf, stored alongside the executable, supplied its operating settings.

This added a distinct capability to the tool chain. ShelbyLoader and ShelbyC2 handled access and tasking; PsProxy ran commands; Blackwood supplied a tunnel that could support movement through a compromised network. The architecture was modular, so operators could use separate components for communication, execution and network access.

Testing and a related credential theft operation

Researchers found signs of infrastructure testing across the activity’s timeline. In November 2025, an encrypted GitHub comment appears to have tested the dead drop mechanism. On April 24, 2026, the operators used a GitHub issue as a mock activity dashboard, posting what looked like device and login alerts alongside test strings and host information.

One entry listed an Iraqi country code and the address 138.256.21[.]23. Since 256 is outside the valid range for an IPv4 address component, Unit 42 assesses that the address was fabricated to avoid creating real network traffic. The country code still points to the operators’ intended geographic context. The researchers also observed staging activity related to phishing infrastructure in May.

A Blackwood sample submitted to VirusTotal on May 24, 2026, exposed another server: 65.109.214[.]145. Unit 42 linked the server to a credential harvesting operation that ran from May through June and reused infrastructure associated with Blackwood. The server hosted lookalike domains and a backend Blackwood component on port 8080.

One lure, submitted by a VirusTotal user in Israel on May 16, used cloud.g-drive[.]cam to imitate a Google Drive file page. The page prompted the visitor to download WarUnPublishedDocuments.zip; the download link led to a fake Google sign in page intended to collect credentials. Unit 42 says it reported the activity to Google, which confirmed that its Drive systems and infrastructure were not compromised or involved. Google Safe Browsing and Chrome protections block the identified domains, according to the source report.

Infrastructure analysis also found a likely staging server at 38.180.136[.]127, reached through the domain asdfafadafg[.]online. The timeline suggests that operators tested the phishing setup there in early May before shifting to the primary server. The overlap connects the credential theft operation to the same broader cluster, though the available evidence does not establish that every activity used the same malware or operator.

Attribution and what defenders should watch

Unit 42 attributes CL-STA-1178 to an Iranian state aligned actor with high confidence, while stopping short of assigning it to a specific named group. Its assessment draws on infrastructure links, targeting, code and operational artifacts. The researchers found a public GitHub profile using the peakyblinders-tm name, along with an audio file called Peaky Blinders Team.mp3. The track’s embedded metadata retained the value MusicDel[.]ir, the name of a public Iranian music distribution site. That artifact contributes to the attribution picture but is not, by itself, proof of an operator’s identity.

The group’s recurring “Peaky Blinders” references also appear in malware and repository names. Unit 42 says this pattern links the activity to the Shelby Strategy cluster previously documented by Elastic Security Labs. Other vendors had described individual incidents, but Unit 42’s report brings those events together with the 2026 activity and its full Blinder Tunnel tool chain.

The tactics share some features with activity attributed to Screening Serpens, including tailored recruiting lures for technical professionals and use of AppDomainManager hijacking to alter application configuration and disable ETW. Unit 42 describes the overlap as insufficient to attribute CL-STA-1178 to that group. It also notes similarities to Agent Serpens operations, including GitHub based fallback command resolution and in memory PowerShell execution. These are tradecraft parallels, not a definitive group match.

The operational picture matters to organizations with developer teams and valuable internal networks. A recruitment message can make a project archive feel like routine work, while a Visual Studio project can run custom instructions during background evaluation. Teams can reduce exposure by treating unsolicited coding tests as executable content, reviewing project configuration before opening unfamiliar archives, and monitoring unexpected child processes, build targets and DLL loads from user directories.

Network monitoring also needs to account for services developers use every day. GitHub API traffic can be legitimate, so useful detections depend on context: unusual repository access, repeated polling, encoded device identifiers, suspicious issue searches or traffic from unexpected processes may deserve closer review. The same is true of encrypted HTTP tunnels and SOCKS proxy behavior originating from developer workstations or servers.

Blinder Tunnel’s defining shift is the way it joins social engineering to developer tooling and cloud services. The first stage looks like a hiring process; the next exploits Visual Studio’s project loading; subsequent stages hide inside trusted .NET processes and use GitHub to manage tasking. For security teams, the practical takeaway is to inspect the project and the behavior it triggers as a single chain—from the archive and IDE configuration to memory activity and outbound platform traffic.

Cortex AgentiX Agentic Assistant helped Unit 42 query investigation data and develop context and recommendations. The source report also describes protections available to Palo Alto Networks customers and provides contact details for the Unit 42 Incident Response team.

Related technical references include research on The Shelby Strategy, AppDomainManager hijacking, DLL sideloading, Chisel, and the GitHub Issues Search API. Unit 42 also cites work on Screening Serpens, Iranian Dream Job lures, Obfuscar and CPX’s Blackwood analysis.