T1127

Trusted Developer Utilities Proxy Execution

Defense Evasion Last updated:

Adversaries may take advantage of trusted developer utilities to proxy execution of malicious payloads. Utilities used for software development tasks such as MSBuild, csc.exe, vbc.exe, WinDbg, cdb.exe, tracker.exe, dnx.exe, and rcsi.exe are typically signed with legitimate Microsoft certificates, allowing them to execute code and bypass application control solutions. These utilities can compile and execute inline C#, VB.NET, or native shellcode embedded in project files, scripts, or command-line arguments, effectively masquerading malicious execution as legitimate developer activity. Adversaries also leverage these tools to bypass Smart App Control by abusing the OS trust model for signed binaries that support arbitrary code execution.

What is T1127 Trusted Developer Utilities Proxy Execution?

Trusted Developer Utilities Proxy Execution (T1127) maps to the Defense Evasion tactic — the adversary is trying to avoid being detected in MITRE ATT&CK.

This page provides production-ready detection logic for Trusted Developer Utilities Proxy Execution, covering the data sources and telemetry it touches: Process: Process Creation, Command: Command Execution, Microsoft Defender for Endpoint. The queries below are rated high severity at high confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Defense Evasion
Technique
T1127 Trusted Developer Utilities Proxy Execution
Canonical reference
https://attack.mitre.org/techniques/T1127/
Microsoft Sentinel / Defender
kusto 
let TrustedDevUtils = dynamic([
  "msbuild.exe", "csc.exe", "vbc.exe", "jsc.exe",
  "dnx.exe", "rcsi.exe", "tracker.exe",
  "cdb.exe", "windbg.exe", "kd.exe", "ntsd.exe",
  "msdeploy.exe", "xwizard.exe", "mshta.exe"
]);
let SuspiciousParents = dynamic([
  "winword.exe", "excel.exe", "powerpnt.exe", "outlook.exe",
  "msedge.exe", "chrome.exe", "firefox.exe", "iexplore.exe",
  "wscript.exe", "cscript.exe", "mshta.exe", "cmd.exe",
  "powershell.exe", "pwsh.exe"
]);
let SuspiciousPaths = dynamic([
  "\\Temp\\", "\\AppData\\Local\\Temp\\", "\\AppData\\Roaming\\",
  "\\ProgramData\\", "\\Users\\Public\\", "\\Downloads\\"
]);
DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName in~ (TrustedDevUtils)
| extend LaunchedBySuspiciousParent = InitiatingProcessFileName in~ (SuspiciousParents)
| extend FileFromSuspiciousPath = ProcessCommandLine has_any (SuspiciousPaths)
| extend MSBuildInlineTask = FileName =~ "msbuild.exe" and ProcessCommandLine has_any (".csproj", ".proj", ".xml", ".targets", ".tasks")
| extend CompilerFromTemp = FileName in~ ("csc.exe", "vbc.exe", "jsc.exe") and ProcessCommandLine has_any (SuspiciousPaths)
| extend DebuggerShellcode = FileName in~ ("cdb.exe", "windbg.exe", "ntsd.exe", "kd.exe") and ProcessCommandLine has_any ("-pd", "-pv", "-cf", "-c ")
| extend TrackerExec = FileName =~ "tracker.exe" and ProcessCommandLine has_any ("/d3", "/dumpstartuplogging", ".dll", ".exe")
| extend RareUtility = FileName in~ ("dnx.exe", "rcsi.exe")
| where LaunchedBySuspiciousParent
     or FileFromSuspiciousPath
     or CompilerFromTemp
     or DebuggerShellcode
     or TrackerExec
     or RareUtility
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
         InitiatingProcessFileName, InitiatingProcessCommandLine,
         FolderPath,
         LaunchedBySuspiciousParent, FileFromSuspiciousPath, MSBuildInlineTask,
         CompilerFromTemp, DebuggerShellcode, TrackerExec, RareUtility
| sort by Timestamp desc

Detects execution of trusted developer utilities (MSBuild, csc.exe, vbc.exe, WinDbg, cdb.exe, tracker.exe, dnx.exe, rcsi.exe) in suspicious contexts using Microsoft Defender for Endpoint DeviceProcessEvents. Identifies execution spawned by Office applications, browsers, or script interpreters; compiler or build tool invocations referencing temp/user paths; debugger-based shellcode execution via -cf/-c flags; and rare utilities with no legitimate enterprise footprint. Each detection branch is flagged independently to help analysts prioritize.

high severity high confidence

Data Sources

Process: Process Creation Command: Command Execution Microsoft Defender for Endpoint

Required Tables

DeviceProcessEvents

False Positives

  • Developer workstations where engineers legitimately invoke MSBuild, csc.exe, or vbc.exe from scripts and IDE terminal sessions
  • CI/CD agents (Azure DevOps, Jenkins, TeamCity) that build .NET code using MSBuild or csc.exe — often running as SYSTEM or a service account from non-standard working directories
  • IT automation frameworks that compile helper DLLs on-demand from scripts (e.g., some Ansible Windows modules use inline C# via csc.exe)
  • Debugging and crash analysis workflows where WinDbg or cdb.exe is legitimately invoked by developers or support engineers
  • Visual Studio and Roslyn toolchain processes that compile code from user profile temp directories during incremental builds

Sigma rule & cross-platform mapping

The detection logic for Trusted Developer Utilities Proxy Execution (T1127) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource: 

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for T1127 Sigma rules on detection.fyi

Platform-specific guides for T1127

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-04-18 Research depth: deep
References (10)

Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1MSBuild Inline Task Execution via Malicious Project File

    Expected signal: Sysmon Event ID 1: Process Create for MSBuild.exe with CommandLine referencing %TEMP%\malicious.csproj. Sysmon Event ID 11: File Create for %TEMP%\malicious.csproj. Sysmon Event ID 1 child: cmd.exe spawned by MSBuild.exe with /c whoami argument. Sysmon Event ID 11: File Create for %TEMP%\msbuild-test.txt. Security Event ID 4688 for both MSBuild.exe and cmd.exe if command line auditing is enabled.

  2. Test 2On-the-Fly C# Compilation and Execution via csc.exe

    Expected signal: Sysmon Event ID 11: File Create for %TEMP%\df00tech_test.cs. Sysmon Event ID 1: Process Create for csc.exe with CommandLine referencing %TEMP% source and output paths. Sysmon Event ID 11: File Create for %TEMP%\df00tech_test.exe and %TEMP%\df00tech_test.pdb. Sysmon Event ID 1: Process Create for %TEMP%\df00tech_test.exe (unsigned binary from temp path). AmCache will record the new executable's first execution.

  3. Test 3Shellcode Execution via CDB.exe Debugger with Command Script Flag

    Expected signal: Sysmon Event ID 1: Process Create for cdb.exe with CommandLine containing -c, -pv, and -pd flags. Sysmon Event ID 1: Process Create for notepad.exe spawned by cdb.exe. Security Event ID 4688 for cdb.exe if command line auditing enabled. The -c flag content (.echo) will appear in the command line.

  4. Test 4Tracker.exe Proxy Execution via /d3 Logging Flag

    Expected signal: Sysmon Event ID 1: Process Create for Tracker.exe with CommandLine containing /d3 and referencing a DLL. Sysmon Event ID 7: Image Load events for shell32.dll under the Tracker.exe process context. Sysmon Event ID 1: Process Create for whoami.exe as a child of Tracker.exe. Security Event ID 4688 for Tracker.exe and whoami.exe.

Response Playbook

Triage

  1. Identify which developer utility was invoked and from what parent process — was it spawned by an Office application, browser, or script interpreter (wscript.exe, mshta.exe, powershell.exe)? Unusual parent-child relationships are the highest-fidelity signal.
  2. Examine the full command line — for MSBuild, identify the project file being loaded and retrieve its contents from disk; inline tasks with <Code> elements embedding C# are the definitive indicator of abuse. For csc.exe/vbc.exe, check if the source file is in a temp or user-writable path.
  3. For debugger-based execution (cdb.exe, WinDbg, ntsd.exe, kd.exe): check for -cf (run commands from file), -c (run inline commands), or -pd (non-invasive attach) flags. The script or command content may reference shellcode loading APIs (VirtualAlloc, WriteProcessMemory, CreateThread).
  4. Assess the user account context — is this a standard endpoint user, a service account, or SYSTEM? Developers running build tools from their workstations in expected IDE paths are lower risk than these utilities appearing on servers, kiosks, or standard business user endpoints.
  5. Check for file creation events (Sysmon Event ID 11) associated with the process — did it write a DLL, executable, or script to disk? Was a compiled .exe or .dll dropped to a temp or staging path?
  6. Look for outbound network connections from the developer utility or its child processes (Sysmon Event ID 3) — MSBuild, csc.exe, and tracker.exe have no legitimate reason to initiate outbound connections to external IPs.
  7. Review process tree for child processes spawned by the developer utility — did csc.exe or MSBuild spawn cmd.exe, powershell.exe, or a network-connecting process? Legitimate compilers produce output files, not interactive shells.

Containment

  1. If inline task abuse confirmed (MSBuild .proj file with embedded C# payload): collect and preserve the project file as forensic evidence, then delete it and any compiled artifacts. Isolate the endpoint if outbound connections were observed.
  2. If the endpoint shows signs of post-exploitation (network beacons, lateral movement, new service installation): isolate via EDR network containment immediately and escalate to incident response.
  3. If a compromised user account is suspected (developer utility launched via phishing or malicious macro): disable the account in Active Directory and revoke all active tokens and sessions.
  4. Block any external IPs or domains the developer utility connected to at the perimeter firewall and proxy layer, and add IOCs to EDR block lists.
  5. If a compiled payload was dropped to disk and executed: identify and quarantine the malicious binary across all endpoints using the file hash via EDR.
  6. Apply application control rules (AppLocker, WDAC) to restrict MSBuild.exe, csc.exe, tracker.exe, dnx.exe, and rcsi.exe execution to authorized developer systems and CI/CD agents only.

Evidence Collection

  1. Project or script files referenced in the command line — for MSBuild: the .csproj, .proj, .xml, .targets file; for csc.exe: the .cs source file; for cdb.exe: the -cf script file. These contain the malicious payload or shellcode.
  2. Sysmon Event ID 1 (Process Create) — full command line, parent process, user, working directory, and image hash for the developer utility invocation.
  3. Sysmon Event ID 11 (File Create) — any binaries, DLLs, or scripts written to disk by the developer utility or its child processes.
  4. Sysmon Event ID 3 (Network Connection) — any outbound connections from the developer utility process, including destination IP, port, and protocol.
  5. Sysmon Event ID 7 (Image Load) — DLLs loaded by the developer utility process; unusual or unsigned DLLs being loaded indicate payload staging or injection.
  6. Security Event ID 4688 (Process Creation with command line auditing enabled) as a secondary source if Sysmon is unavailable.
  7. Prefetch files — C:\Windows\Prefetch\MSBUILD.EXE-*.pf, CSC.EXE-*.pf, CDB.EXE-*.pf — capture execution timestamps and recently accessed file paths.
  8. Windows Event Log: Microsoft-Windows-AppLocker/EXE and DLL channel — if AppLocker is deployed, may show blocked execution attempts preceding successful bypass.
  9. Memory forensics from the process if shellcode execution is suspected — use EDR live response to capture a full process memory dump for analysis.

Escalation Criteria

  • ! Developer utility spawned directly by an Office application (winword.exe, excel.exe, powerpnt.exe) or browser — strong indicator of macro-based or drive-by initial access.
  • ! MSBuild or csc.exe executing a project file or source file located in a user temp or AppData path — legitimate build pipelines use source-controlled project roots, not user temp directories.
  • ! Any outbound network connection from MSBuild.exe, csc.exe, tracker.exe, or a debugger utility to a public IP — these tools have no legitimate reason to initiate external connections.
  • ! Child process spawn from developer utility resulting in cmd.exe, powershell.exe, or mshta.exe — legitimate compilers produce binaries, not interactive shells.
  • ! Execution of dnx.exe or rcsi.exe on any endpoint — these utilities are effectively deprecated and have minimal legitimate enterprise use, making any execution high-priority.
  • ! Multiple endpoints showing the same developer utility execution pattern with identical or similar command lines within a short window — indicates automated propagation or a worm-like component.

Investigation Guide

Forensic Artifacts

  • > File System: MSBuild inline task project files (.csproj, .proj, .xml, .targets) in temp paths — contain embedded C# code with payload logic; retrieve with: dir /s /b %TEMP%\*.csproj %TEMP%\*.proj %TEMP%\*.xml
  • > File System: C:\Windows\Prefetch\MSBUILD.EXE-*.pf, CSC.EXE-*.pf, CDB.EXE-*.pf — execution timestamps and file path references
  • > File System: csc.exe output assemblies — typically .exe or .dll files in the same directory as the source file or system temp; may be the delivered payload
  • > Registry: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers — may contain shimming entries for developer tools to run with elevated trust
  • > Registry: HKCU\SOFTWARE\Classes\CLSID — COM object registrations that may be used by the spawned payload for persistence
  • > Event Log: Microsoft-Windows-AppLocker/EXE and DLL (Event IDs 8003, 8004) — AppLocker enforcement events for the utility if policies exist
  • > Event Log: Microsoft-Windows-CodeIntegrity/Operational (Event ID 3076, 3077) — WDAC audit/enforcement events for unsigned code execution
  • > Memory: Process memory dump of the developer utility and any child processes for shellcode or reflectively loaded PE detection
  • > AmCache: C:\Windows\AppCompat\Programs\Amcache.hve — records first execution timestamp and binary SHA1 for developer utilities
  • > Shimcache (AppCompatCache): HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache — may contain entries for dnx.exe, rcsi.exe, or tracker.exe

Tuning Guidance

Begin by inventorying which developer utilities legitimately exist in your environment and on which device classes. MSBuild, csc.exe, and vbc.exe are expected on developer workstations and CI/CD build agents but have no business purpose on standard business user endpoints, servers, or kiosks — detections on those device categories should have near-zero false positive rate and require no tuning. For developer workstations, build an allowlist keyed on the combination of parent process (devenv.exe, dotnet.exe, vstest.console.exe, code.exe), the working directory (must be under a known source code root), and the account (must be a named developer account, not SYSTEM or a service account). CI/CD agents should be baselining via the specific service account they run under — detections matching those accounts with known build pipeline parent processes (agent.exe, AzurePipelinesAgent.exe, jenkins.exe) can be suppressed. Tune most aggressively on MSBuild and csc.exe; apply zero tuning for dnx.exe and rcsi.exe as these utilities are effectively deprecated and their legitimate use is negligible. For debugger utilities (cdb.exe, WinDbg), restrict suppression only to security researchers and kernel engineers with explicitly approved workflows, and never suppress based on parent process alone.

Hunting Queries

Hunt for MSBuild.exe executions from non-standard installation paths. Legitimate MSBuild resides under Visual Studio or .NET Framework directories. Instances running from temp directories, user profiles, or other paths indicate potential LOLBin abuse where the adversary placed a copy of MSBuild in an attacker-controlled location.

Hunting — KQL
kql 
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName =~ "msbuild.exe"
| where FolderPath !startswith @"C:\Program Files\Microsoft Visual Studio"
     and FolderPath !startswith @"C:\Program Files (x86)\Microsoft Visual Studio"
     and FolderPath !startswith @"C:\Windows\Microsoft.NET"
| extend NonStandardPath = true
| summarize Count=count(), Devices=dcount(DeviceName), Accounts=make_set(AccountName),
           CommandLines=make_set(ProcessCommandLine, 10),
           ParentProcs=make_set(InitiatingProcessFileName)
  by FolderPath
| sort by Count asc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
  Image="*\\msbuild.exe"
  NOT (Image="*\\Microsoft Visual Studio*" OR Image="*\\Microsoft.NET*" OR Image="*\\MSBuild\\Current*")
| stats count as Count, dc(host) as Devices, values(User) as Accounts,
        values(CommandLine) as CommandLines, values(ParentImage) as Parents
  by Image
| sort + Count

Hunt for .NET compiler (csc.exe, vbc.exe, jsc.exe) executions followed within two minutes by a binary (.exe or .dll) being written to a temp or user-writable path. This correlation identifies on-the-fly compilation of malicious payloads — a hallmark of MSBuild inline task abuse and similar compiler-based LOLBin techniques where source code is compiled to disk immediately before execution.

Hunting — KQL
kql 
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("csc.exe", "vbc.exe", "jsc.exe")
| join kind=inner (
    DeviceFileEvents
    | where Timestamp > ago(7d)
    | where FileName endswith ".exe" or FileName endswith ".dll"
    | where FolderPath has_any ("\\Temp\\", "\\AppData\\", "\\ProgramData\\", "\\Users\\Public\\")
    | project FileTimestamp=Timestamp, DeviceName, CompiledFile=FileName, FilePath=FolderPath, InitiatingProcessFileName
  ) on DeviceName
| where abs(datetime_diff('minute', Timestamp, FileTimestamp)) <= 2
| project Timestamp, DeviceName, AccountName, CompilerName=FileName, CompilerCmdLine=ProcessCommandLine,
         CompiledFile, FilePath, InitiatingProcessFileName
| sort by Timestamp desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational"
  ((EventCode=1 (Image="*\\csc.exe" OR Image="*\\vbc.exe" OR Image="*\\jsc.exe"))
   OR (EventCode=11 (TargetFilename="*.exe" OR TargetFilename="*.dll")
       (TargetFilename="*\\Temp\\*" OR TargetFilename="*\\AppData\\*"
        OR TargetFilename="*\\ProgramData\\*" OR TargetFilename="*\\Users\\Public\\*")))
| eval EventType=if(EventCode=1, "CompilerExec", "FileCreate")
| transaction host maxspan=2m
| where mvcount(EventType) > 1
| table _time, host, User, Image, CommandLine, TargetFilename
| sort - _time

Hunt for Microsoft debugger utilities (cdb.exe, WinDbg, ntsd.exe, kd.exe) invoked with flags that enable script or command execution: -cf (run script file), -c (run inline command), -pv (non-invasive attach), -pd (prevent debugger from terminating). These flags are leveraged by adversaries to execute shellcode or arbitrary commands under the trust context of a signed Microsoft debugger binary, bypassing application whitelisting.

Hunting — KQL
kql 
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("cdb.exe", "windbg.exe", "ntsd.exe", "kd.exe")
| where ProcessCommandLine has_any ("-cf", "-c ", "-pv", "-pd")
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
         InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
Hunting — SPL
spl 
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
  (Image="*\\cdb.exe" OR Image="*\\windbg.exe" OR Image="*\\ntsd.exe" OR Image="*\\kd.exe")
  (CommandLine="*-cf*" OR CommandLine="*-c *" OR CommandLine="*-pv*" OR CommandLine="*-pd*")
| table _time, host, User, Image, CommandLine, ParentImage, ParentCommandLine
| sort - _time

Atomic Red Team Tests

Test 1 MSBuild Inline Task Execution via Malicious Project File
windows

Creates a minimal MSBuild project file containing an inline C# task that executes a benign system command (whoami). This replicates the technique used by numerous threat actors and tools (Casey Smith original PoC, various red team frameworks) to execute arbitrary .NET code by abusing MSBuild's legitimate inline task compilation feature. The project file is written to %TEMP% to simulate payload drop from a stager.

Command

powershell 
echo ^<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"^>^<Target Name="x"^>^<MSBuildTest/^>^</Target^>^<UsingTask TaskName="MSBuildTest" TaskFactory="CodeTaskFactory" AssemblyFile="C:\Windows\Microsoft.Net\Framework\v4.0.30319\Microsoft.Build.Tasks.v4.0.dll"^>^<Task^>^<Code Type="Class" Language="cs"^>^<![CDATA[using Microsoft.Build.Framework;using System.Diagnostics;public class MSBuildTest:ITask{public IBuildEngine BuildEngine{get;set;}public ITaskHost HostObject{get;set;}public bool Execute(){Process.Start(new ProcessStartInfo("cmd.exe","/c whoami > %TEMP%\msbuild-test.txt"){CreateNoWindow=true,UseShellExecute=false});return true;}}]]^>^</Code^>^</Task^>^</UsingTask^>^</Project^> > %TEMP%\malicious.csproj && C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe %TEMP%\malicious.csproj

Cleanup

powershell 
del %TEMP%\malicious.csproj %TEMP%\msbuild-test.txt 2>nul

Expected Telemetry

Sysmon Event ID 1: Process Create for MSBuild.exe with CommandLine referencing %TEMP%\malicious.csproj. Sysmon Event ID 11: File Create for %TEMP%\malicious.csproj. Sysmon Event ID 1 child: cmd.exe spawned by MSBuild.exe with /c whoami argument. Sysmon Event ID 11: File Create for %TEMP%\msbuild-test.txt. Security Event ID 4688 for both MSBuild.exe and cmd.exe if command line auditing is enabled.

Expected Detection

KQL: MSBuildInlineTask=true, FileFromSuspiciousPath=true. SPL: MSBuildInlineTask=1 + TempPathArg=1, SuspicionScore >= 2. Child process cmd.exe spawned from MSBuild.exe will trigger parent-child hunting query.

Test 2 On-the-Fly C# Compilation and Execution via csc.exe
windows

Writes a minimal C# source file to %TEMP% and compiles it using csc.exe (Roslyn C# compiler shipped with .NET Framework) to produce an executable, then runs it. This simulates adversary use of the C# compiler as a LOLBin to compile and execute arbitrary .NET payloads without touching application control policy — the compiled output is a new unsigned binary but execution started from a trusted signed compiler.

Command

powershell 
echo using System; class T { static void Main() { Console.WriteLine(Environment.MachineName); } } > %TEMP%\df00tech_test.cs && C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe /nologo /out:%TEMP%\df00tech_test.exe %TEMP%\df00tech_test.cs && %TEMP%\df00tech_test.exe

Cleanup

powershell 
del %TEMP%\df00tech_test.cs %TEMP%\df00tech_test.exe %TEMP%\df00tech_test.pdb 2>nul

Expected Telemetry

Sysmon Event ID 11: File Create for %TEMP%\df00tech_test.cs. Sysmon Event ID 1: Process Create for csc.exe with CommandLine referencing %TEMP% source and output paths. Sysmon Event ID 11: File Create for %TEMP%\df00tech_test.exe and %TEMP%\df00tech_test.pdb. Sysmon Event ID 1: Process Create for %TEMP%\df00tech_test.exe (unsigned binary from temp path). AmCache will record the new executable's first execution.

Expected Detection

KQL: CompilerFromTemp=true, FileFromSuspiciousPath=true. SPL: TempPathArg=1, SuspicionScore >= 1. File creation hunting query will correlate csc.exe execution with .exe drop to temp path within the 2-minute window.

Test 3 Shellcode Execution via CDB.exe Debugger with Command Script Flag
windows

Invokes cdb.exe (Microsoft Console Debugger, part of Debugging Tools for Windows) with the -c flag to run a debugger command. This test uses a benign command (.echo test) to demonstrate the execution vector without executing shellcode. In actual attacks, adversaries pass shellcode-loading debugger script content via -cf (script file) to execute arbitrary code under the signed cdb.exe process. Requires Debugging Tools for Windows to be installed.

Command

powershell 
"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe" -c ".echo df00tech-test; q" -pv -pd notepad.exe

Cleanup

powershell 
taskkill /f /im notepad.exe 2>nul

Expected Telemetry

Sysmon Event ID 1: Process Create for cdb.exe with CommandLine containing -c, -pv, and -pd flags. Sysmon Event ID 1: Process Create for notepad.exe spawned by cdb.exe. Security Event ID 4688 for cdb.exe if command line auditing enabled. The -c flag content (.echo) will appear in the command line.

Expected Detection

KQL: DebuggerShellcode=true (FileName in~ cdb.exe AND ProcessCommandLine has_any -pd, -pv, -c). SPL: DebuggerShellcode=1, SuspicionScore >= 1. Hunting query for debugger utilities with execution flags will fire.

Test 4 Tracker.exe Proxy Execution via /d3 Logging Flag
windows

Executes tracker.exe (Microsoft File Tracker, part of MSBuild) with the /d3 flag combined with a target DLL argument, replicating the documented LOLBAS technique. Tracker.exe can load arbitrary DLLs under its trusted context using the /d3 switch. This test uses a known benign system DLL (shell32.dll) to demonstrate the execution mechanism without triggering a payload.

Command

powershell 
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Tracker.exe /d3 C:\Windows\System32\shell32.dll /c C:\Windows\System32\whoami.exe

Expected Telemetry

Sysmon Event ID 1: Process Create for Tracker.exe with CommandLine containing /d3 and referencing a DLL. Sysmon Event ID 7: Image Load events for shell32.dll under the Tracker.exe process context. Sysmon Event ID 1: Process Create for whoami.exe as a child of Tracker.exe. Security Event ID 4688 for Tracker.exe and whoami.exe.

Expected Detection

KQL: TrackerExec=true (FileName =~ tracker.exe AND ProcessCommandLine has_any /d3, .dll). SPL: TrackerExec=1, SuspicionScore >= 1. Child process execution (whoami.exe spawned from Tracker.exe) represents an unusual parent-child relationship that hunting queries will surface.

Related Detections

Tactic Hub

TA0005Defense Evasion

Sub-techniques (3)

Related Techniques

T1127.001MSBuildT1127.002ClickOnceT1127.003JamPlusT1218System Binary Proxy ExecutionT1218.011Rundll32T1059.001PowerShellT1059.003Windows Command ShellT1105Ingress Tool TransferT1027.009Embedded PayloadsT1553.002Code SigningT1562.001Disable or Modify Tools

Same Tactic: Defense Evasion

Popular Detections