Background

On 6 October 2026, Palo Alto Networks Unit 42 described the Blinder Tunnel campaign, attributed to an Iranian-nexus cluster it tracks as CL-STA-1178. A target received a ZIP file posing as a Dubai Airports IT coding test. Inside was a Visual Studio project whose .csproj contained a custom GetFrameworkPaths target. When the project was opened, that target copied files into %LOCALAPPDATA%\Microsoft\RuntimeBrokers and launched them, before the developer built anything.

The rest of the chain is reported as follows: a renamed host binary (RuntimeBroker.exe) loaded attacker code through a .config file using an AppDomainManager (T1574.014), the config disabled ETW with <etwEnable enabled="false"/>, a malicious RuntimeBroker.dll was sideloaded (T1574.001), persistence was a MicrosoftRuntime Run key, and command and control ran over the GitHub API. Unit 42 says Cortex XDR blocked the chain. If you do not run that product, you need to build detections from the behaviours below. All artefact names are from Unit 42’s report. Operators can rename them, so use the behavioural rules first and the name-based ones as cheap, high-confidence extras.

Detection 1: Build file spawning execution at project open

Opening a project in Visual Studio should not launch a process out of a user profile folder. The relevant telemetry is a child process of devenv.exe or MSBuild.exe whose image path sits under %LOCALAPPDATA% or a temp folder.

title: Process Launched From User Profile by Visual Studio or MSBuild
id: 6c1d7f0e-5b7a-4c52-9d0a-2a1d6b3e9a41
status: experimental
description: Detects a child process of devenv.exe or MSBuild.exe running from a user-writable path, as seen when a malicious .csproj target launches a payload on project open
logsource:
  category: process_creation
  product: windows
detection:
  parent:
    ParentImage|endswith:
      - '\devenv.exe'
      - '\MSBuild.exe'
  path:
    Image|contains:
      - '\AppData\Local\'
      - '\AppData\Roaming\'
      - '\Temp\'
  filter_known:
    Image|contains:
      - '\AppData\Local\Microsoft\VisualStudio\'
      - '\AppData\Local\Microsoft\dotnet\'
  condition: parent and path and not filter_known
falsepositives:
  - Build scripts that run tools from a local cache or a build output folder
level: medium
tags:
  - attack.defense_evasion
  - attack.t1127

KQL for Microsoft Defender XDR:

DeviceProcessEvents
| where Timestamp > ago(30d)
| where InitiatingProcessFileName in~ ("devenv.exe","MSBuild.exe")
| where FolderPath has_any (@"\AppData\Local\", @"\AppData\Roaming\", @"\Temp\")
| where FolderPath !has @"\Microsoft\VisualStudio\" and FolderPath !has @"\Microsoft\dotnet\"
| project Timestamp, DeviceName, AccountName, FileName, FolderPath, ProcessCommandLine, InitiatingProcessCommandLine

Detection 2: AppDomainManager hijack through a .config file

A .NET host binary loads an AppDomainManager when an adjacent <name>.exe.config sets the appDomainManagerAssembly and appDomainManagerType values. Legitimate software almost never sets these. The report also describes etwEnable enabled="false" in the same file.

title: Suspicious .exe.config With AppDomainManager or ETW Disable
id: 1f4a9b2c-8d3e-4e6a-a7c1-5e9d0b2f7c13
status: experimental
description: Detects creation of a .exe.config file referencing an AppDomainManager or disabling ETW, a loader technique used to run attacker code inside a signed or renamed .NET host
logsource:
  category: file_event
  product: windows
detection:
  selection:
    TargetFilename|endswith: '.exe.config'
  path:
    TargetFilename|contains:
      - '\AppData\'
      - '\Temp\'
      - '\ProgramData\'
  condition: selection and path
falsepositives:
  - Per-user installs of .NET applications that ship a config file
level: low
tags:
  - attack.defense_evasion
  - attack.t1574.014

This file-creation rule is a low-severity pivot, since Sigma file events do not expose file contents. Pair it with a content check where your EDR supports it. The Defender query below at least confirms that the config sits next to an executable in a user-writable folder.

DeviceFileEvents
| where Timestamp > ago(30d)
| where FileName endswith ".exe.config"
| where FolderPath has_any (@"\AppData\", @"\Temp\", @"\ProgramData\")
| join kind=leftouter (
    DeviceProcessEvents
    | where FileName endswith ".exe"
    | project DeviceId, FolderPath, ExeName=FileName
  ) on DeviceId, FolderPath
| where isnotempty(ExeName)
| project Timestamp, DeviceName, FolderPath, FileName, ExeName

Detection 3: Name-based indicators from the report

These are cheap and precise while the operators keep the names. Unit 42 reports the folder %LOCALAPPDATA%\Microsoft\RuntimeBrokers (plural) and the Run value MicrosoftRuntime.

union
( DeviceRegistryEvents
  | where RegistryKey has @"\CurrentVersion\Run" and RegistryValueName =~ "MicrosoftRuntime"
  | project Timestamp, DeviceName, Detail=strcat("RunKey ", RegistryValueData) ),
( DeviceFileEvents
  | where FolderPath has @"\Microsoft\RuntimeBrokers"
  | project Timestamp, DeviceName, Detail=strcat("File ", FolderPath, FileName) ),
( DeviceProcessEvents
  | where FileName =~ "RuntimeBroker.exe" and FolderPath !startswith @"C:\Windows\System32"
  | project Timestamp, DeviceName, Detail=strcat("Process ", FolderPath) )

The real RuntimeBroker.exe lives in C:\Windows\System32. Any copy elsewhere deserves a look.

Detection 4: GitHub API use from the wrong process

The implants reportedly use the GitHub REST API for tasking, with a 63-second beacon and a 120-second check-in, and fall back to GitHub Issues search. A browser or git.exe talking to GitHub is normal. A process from a user-profile folder doing so on a regular timer is not.

DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteUrl has "api.github.com"
| where InitiatingProcessFileName !in~ ("git.exe","gh.exe","code.exe","devenv.exe","chrome.exe","msedge.exe","firefox.exe","git-remote-https.exe")
| where InitiatingProcessFolderPath has_any (@"\AppData\", @"\Temp\", @"\ProgramData\")
| summarize Hits=count(), First=min(Timestamp), Last=max(Timestamp) by DeviceName, InitiatingProcessFileName, InitiatingProcessFolderPath
| where Hits > 20
| order by Hits desc

Tuning for developer fleets

  • Expect noise from tooling. Developers run package managers, language servers and test runners from AppData. Start Detection 1 in report-only mode and allowlist by signer and path after a week of data.
  • Scope to risk. Apply the strictest alerting to hosts that hold production credentials or VPN profiles, and to non-developer hosts where any devenv.exe activity is itself unusual.
  • Add a pre-open control. The strongest fix is not detection. Open untrusted projects in a disposable VM or dev container, so a malicious build target has nothing to reach.

Response if one fires

  1. Isolate the host and preserve %LOCALAPPDATA%\Microsoft\RuntimeBrokers and the Run key.
  2. Review outbound connections to the relay IPs published by Unit 42, and rotate any credentials, tokens and VPN profiles present on the machine.
  3. Check for a reverse SOCKS proxy (Unit 42 reports R:0.0.0.0:10999:socks) and any internal sessions that originated from the host after the first execution time.

Sources

The queries and rules above are our own constructions from that report’s described behaviour. They have not been validated against live samples. Test them against your own telemetry before enabling alerting.