T1070

Indicator Removal

Defense Evasion Last updated:

Adversaries may delete or modify artifacts generated within systems to remove evidence of their presence or hinder defenses. Various artifacts may be created by an adversary or something that can be attributed to an adversary's actions. Typically these artifacts are used as defensive indicators related to monitored events, such as strings from downloaded files, logs that are generated from user actions, and other data analyzed by defenders. Removal of these indicators may interfere with event collection, reporting, or other processes used to detect intrusion activity. This may compromise the integrity of security solutions by causing notable events to go unreported. This activity may also impede forensic analysis and incident response, due to lack of sufficient data to determine what occurred.

What is T1070 Indicator Removal?

Indicator Removal (T1070) 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 Indicator Removal, covering the data sources and telemetry it touches: Windows Registry: Windows Registry Key Deletion, Process: Process Creation, Command: Command Execution, Microsoft Defender for Endpoint. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Defense Evasion
Technique
T1070 Indicator Removal
Canonical reference
https://attack.mitre.org/techniques/T1070/
Microsoft Sentinel / Defender
kusto
let RegistryCleanupPatterns = dynamic([
  "reg delete", "reg.exe delete",
  "Remove-ItemProperty", "Remove-Item.*HKLM", "Remove-Item.*HKCU",
  "RegDeleteKey", "RegDeleteValue"
]);
let FileCleanupPatterns = dynamic([
  "ProcessIdleTasks",
  "advapi32.dll",
  "DeleteLeftovers",
  "CleanupArtifacts"
]);
let SelfDeletionPatterns = dynamic([
  "cmd /c del", "cmd.exe /c del",
  "/c del \"", "ping -n 1",
  "del /f /q", "erase /f"
]);
// Registry deletion events
let RegDeletions = DeviceRegistryEvents
| where Timestamp > ago(24h)
| where ActionType in ("RegistryKeyDeleted", "RegistryValueDeleted")
| where RegistryKey has_any (
    "\\Run\\", "\\RunOnce\\", "\\Services\\",
    "\\Scheduled Tasks", "\\AppInit_DLLs",
    "\\NetworkProvider\\Order",
    "\\Internet Explorer\\notes",
    "\\CurrentVersion\\Image File Execution",
    "\\TESTSIGNING", "\\user32.dll"
  )
| extend DetectionSource = "RegistryDeletion"
| project Timestamp, DeviceName, AccountName, ActionType,
          RegistryKey, RegistryValueName,
          InitiatingProcessFileName, InitiatingProcessCommandLine,
          InitiatingProcessParentFileName, DetectionSource;
// Process-based cleanup commands
let ProcCleanup = DeviceProcessEvents
| where Timestamp > ago(24h)
| where ProcessCommandLine has_any (RegistryCleanupPatterns)
    or ProcessCommandLine has_any (SelfDeletionPatterns)
    or (InitiatingProcessFileName in~ ("cmd.exe", "powershell.exe", "wscript.exe", "cscript.exe")
        and ProcessCommandLine has "del" and ProcessCommandLine has ".exe")
| extend DetectionSource = "ProcessCleanupCommand"
| project Timestamp, DeviceName, AccountName,
          FileName, ProcessCommandLine,
          InitiatingProcessFileName, InitiatingProcessCommandLine,
          InitiatingProcessParentFileName, DetectionSource;
// Combine results
union RegDeletions, ProcCleanup
| extend SuspicionFlags = pack_array(
    iff(DetectionSource == "RegistryDeletion", "registry_key_deleted", ""),
    iff(ProcessCommandLine has_any (SelfDeletionPatterns), "self_deletion_pattern", ""),
    iff(ProcessCommandLine has_any (RegistryCleanupPatterns), "registry_cleanup_cmd", ""),
    iff(ProcessCommandLine has "del" and ProcessCommandLine has ".exe", "executable_deletion", "")
  )
| project Timestamp, DeviceName, AccountName,
          DetectionSource, RegistryKey, RegistryValueName,
          FileName, ProcessCommandLine,
          InitiatingProcessFileName, InitiatingProcessCommandLine,
          SuspicionFlags
| sort by Timestamp desc

Detects broad indicator removal activity using Microsoft Defender for Endpoint tables. Monitors two primary signals: (1) registry key/value deletion targeting persistence and security-relevant registry paths using DeviceRegistryEvents, and (2) process-based artifact cleanup commands including reg delete, self-deletion patterns (cmd /c del <exe>), and Remove-Item against registry hives using DeviceProcessEvents. Results are unioned with a DetectionSource field to distinguish the signal type for triage. Targets behaviors observed in IPsec Helper, ShadowPad, SDBbot, EVILNUM, HermeticWiper, and Mustang Panda.

high severity medium confidence

Data Sources

Windows Registry: Windows Registry Key Deletion Process: Process Creation Command: Command Execution Microsoft Defender for Endpoint

Required Tables

DeviceRegistryEvents DeviceProcessEvents

False Positives

  • Software uninstallers that legitimately remove their own registry run keys and service entries during clean uninstallation
  • IT management tools (SCCM, Intune, Group Policy) that delete temporary registry values as part of deployment or policy application
  • System cleanup utilities (CCleaner, Windows Disk Cleanup) that remove cached artifacts and registry entries as part of routine maintenance
  • Developers running build/clean scripts that delete test artifacts, temporary executables, and configuration entries
  • Self-updating software that deletes old version run keys before writing new ones during an update cycle

Sigma rule & cross-platform mapping

The detection logic for Indicator Removal (T1070) 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:


Testing Methodology

Validate this detection against 5 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 1Registry Key Self-Cleanup — Delete Run Key

    Expected signal: Sysmon Event ID 12 (RegistryEvent - Object Create/Delete): TargetObject=HKCU\Software\Microsoft\Windows\CurrentVersion\Run\df00tech-test, EventType=DeleteValue. Sysmon Event ID 1: two cmd/reg.exe process creation events. Security Event ID 4657 (if object access auditing is enabled): ObjectName matching the Run key path.

  2. Test 2Executable Self-Deletion via cmd.exe

    Expected signal: Sysmon Event ID 1: Process creation for df00tech-cleanup-test.exe. Sysmon Event ID 1: cmd.exe with CommandLine containing 'del /f /q' and the .exe path. Sysmon Event ID 11: file create for df00tech-cleanup-test.exe. Sysmon Event ID 23 (if configured): FileDelete event for df00tech-cleanup-test.exe showing the file was archived by Sysmon before deletion.

  3. Test 3PowerShell Registry Key Deletion

    Expected signal: Sysmon Event ID 12 (RegistryEvent - Create/Delete): EventType=DeleteKey, TargetObject=HKCU\Software\Microsoft\Internet Explorer\notes. Sysmon Event ID 1: powershell.exe with CommandLine containing 'Remove-Item' and 'Internet Explorer\notes'. PowerShell ScriptBlock Log Event ID 4104 with full script content showing the create and delete sequence.

  4. Test 4Drop-Execute-Delete Pattern in Temp Directory

    Expected signal: Sysmon Event ID 11: file creation of svcupdate32.exe in C:\Users\Public\. Sysmon Event ID 1: execution of svcupdate32.exe. Sysmon Event ID 1: cmd.exe with del command. Sysmon Event ID 23 (FileDelete, if configured): svcupdate32.exe deletion. KQL hunting query matches execution in Public directory followed by file deletion within 60 minutes.

  5. Test 5Simulate BPFDoor Environment Variable Clearing

    Expected signal: Auditd syscall event for open(2) with flags O_WRONLY on /proc/<PID>/environ path. Syslog entry if auditd is configured to watch /proc/*/environ with inode watches. Linux audit event type=PATH with name matching /proc/[0-9]+/environ.


Response Playbook

Triage

  1. Identify which sub-signal fired: registry key deletion on a persistence path, self-deletion of an executable, or explicit reg delete / Remove-Item command — each has a distinct priority and investigation path
  2. For registry key deletions: determine which specific key was deleted (Run, RunOnce, Services, NetworkProvider\Order, AppInit_DLLs) — persistence key deletion after suspected compromise is a strong indicator of cleanup behavior
  3. For self-deletion patterns (cmd /c del <exe>.exe): check what binary was deleted — correlate with recent file creation events (Sysmon Event ID 11) to establish a timeline of drop-then-delete
  4. Examine the initiating process: was the deletion command launched by a legitimate parent (msiexec.exe for uninstallers, ccmexec.exe for SCCM) or an unusual parent (powershell.exe, cmd.exe launched from a suspicious process, scheduled task, or scripting host)?
  5. Check the account context: is the account a standard user, domain admin, or service account? Service account deleting persistence registry keys with no corresponding change management ticket is high-priority
  6. Look backward in time on the same host: what was installed, dropped, or executed in the hours prior to the cleanup event? Correlate with process creation events for initial execution chains
  7. Cross-reference against asset criticality: cleanup activity on a domain controller, file server, or privileged workstation should be escalated faster than the same pattern on a standard user endpoint

Containment

  1. If confirmed malicious cleanup following initial access: immediately isolate the endpoint using EDR network isolation to prevent further evidence destruction and potential lateral movement
  2. Capture a full memory image and disk snapshot before any further investigation activities — artifact removal may have already begun and volatile evidence may still be recoverable from RAM
  3. If a deleted registry key was a persistence mechanism that was previously unknown: audit all hosts in the environment for the original binary that maintained this persistence using Defender for Endpoint advanced hunting
  4. If self-deletion of a dropped executable is confirmed: preserve the deleted file if possible via VSS shadow copy, Recycle Bin, or $MFT recovery before it is overwritten
  5. Disable the identified user account or service account if it was used to execute the cleanup commands while change management investigation is performed
  6. If multiple hosts show the same cleanup pattern simultaneously: escalate to major incident — this suggests automated propagation or a coordinated attacker action post-compromise

Evidence Collection

  1. Sysmon Event ID 12/13/14 (Registry Events) — captures registry key creation, modification, and deletion with the full key path, process details, and timestamp
  2. Sysmon Event ID 11 (File Create) — check for any files recently written to disk that may have been subsequently deleted by the observed cleanup command
  3. Sysmon Event ID 23/26 (File Delete, File Delete Detected) — if Sysmon is configured with file deletion archiving, deleted files may be preserved in the Sysmon archive directory (typically C:\Sysmon\)
  4. Windows Event Log ID 4663 (Object Access) — if object access auditing is enabled, captures file/registry access including delete operations
  5. MFT ($MFT) — even after file deletion the Master File Table entry persists until overwritten; use tools such as MFTECmd or Autopsy to recover file metadata including original path, size, and timestamps
  6. Volume Shadow Copies — check for VSS snapshots predating the cleanup event using vssadmin list shadows; may contain copies of deleted files or registry hives
  7. Windows Registry transaction logs (.LOG1, .LOG2 files in C:\Windows\System32\config\) — may contain records of registry modifications made before cleanup
  8. Prefetch files (C:\Windows\Prefetch\) — even if a binary was self-deleted, prefetch entries persist and record the last 8 execution timestamps and referenced file paths
  9. Amcache.hve and Shimcache (AppCompatCache) — record execution of binaries that may have subsequently been deleted; parse with tools such as AmcacheParser or AppCompatCacheParser

Escalation Criteria

  • ! Self-deletion of a recently dropped executable where the binary's hash is unknown or matches no legitimate software baseline — indicates a malware dropper destroying its own loader after staging a payload
  • ! Deletion of a registry persistence key (Run, RunOnce, Services) within minutes of a new process creation that could not be attributed to a legitimate installer — suggests a threat actor cleaning up after implant staging
  • ! Cleanup activity observed on more than one endpoint within a short time window using the same command pattern — indicates automated or scripted post-exploitation behavior across multiple compromised hosts
  • ! Registry cleanup targeting NetworkProvider\Order — this path is used by credential-harvesting tools (NPPSPY) and its deletion post-compromise indicates an adversary removing evidence of credential theft infrastructure
  • ! Cleanup commands executed by a SYSTEM-level or domain admin account with no corresponding change ticket — privilege level combined with anti-forensic behavior is a critical escalation trigger
  • ! Evidence that Security event log, Sysmon operational log, or Windows Defender log was cleared in the same session as other cleanup activity — multi-artifact removal significantly raises incident severity

Investigation Guide

Forensic Artifacts

  • > MFT ($MFT at C:\$MFT) — file metadata including original path, size, MAC timestamps, and whether the file was deleted; parse with MFTECmd.exe (Eric Zimmermann tools)
  • > Prefetch files (C:\Windows\Prefetch\*.pf) — execution timestamps and loaded module paths persist after binary deletion; parse with PECmd.exe
  • > Amcache.hve (C:\Windows\AppCompat\Programs\Amcache.hve) — records SHA1 hash and path of executed binaries; provides evidence of execution even after file deletion
  • > Shimcache / AppCompatCache (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache) — records last modification time and execution flag for binaries; parse with AppCompatCacheParser.exe
  • > Registry transaction logs (C:\Windows\System32\config\*.LOG1, *.LOG2) — contain uncommitted registry transactions and may recover recently deleted keys
  • > Volume Shadow Copies — vssadmin list shadows; mount with vshadow.exe or Velociraptor to access pre-cleanup file/registry state
  • > Windows Event Log backup files (*.evtx in C:\Windows\System32\winevt\Logs\) — even if cleared, forensic tools may recover partial records from unallocated space within the .evtx file
  • > LNK files (C:\Users\*\AppData\Roaming\Microsoft\Windows\Recent\) — recent file access records that persist even after the target file is deleted
  • > Sysmon archive directory (typically C:\Sysmon\) — if Sysmon is configured with ArchiveDirectory, deleted files are copied here before deletion completes
  • > USN Journal ($UsnJrnl:$J) — NTFS change journal records file create, modify, and delete operations; parse with MFTECmd.exe in USN mode to reconstruct file system activity timeline

Tuning Guidance

The parent T1070 technique generates significant noise because many legitimate operations involve registry cleanup or file deletion. Prioritize tuning in three phases. Phase 1 — baseline allowlist: identify all legitimate software uninstallers, patch management tools (SCCM/Intune/WSUS), and monitoring agents that perform expected registry cleanup; build an allowlist of their executable paths and SHA256 hashes. Exclude these in your detection logic by adding 'not InitiatingProcessFileName in~ (allowlist)'. Phase 2 — context enrichment: add asset criticality context so that the same pattern on a Tier-0 asset (DC, PKI, PAW) generates a higher-severity alert than on a standard workstation. Phase 3 — temporal correlation: the highest-fidelity signal for T1070 is cleanup following another suspicious action. If you can correlate registry deletion events with a prior suspicious process execution on the same host within a 4-hour window, you dramatically reduce false positives while catching true adversary cleanup. Consider deploying Sysmon with FileDeleteArchiveDirectory enabled (Sysmon config option) so that deleted files are preserved for forensic analysis — this turns a detection event into a full evidence collection event. For the registry signal specifically, prune the monitored key list to your environment's actual persistence paths; not all environments use AppInit_DLLs or user32.dll watermarks. For self-deletion patterns, note that legitimate installers (especially those using NSIS or InstallShield) frequently delete their own temp extraction directories post-install — add the parent process context (msiexec.exe, setup.exe from known-good hash) to your allowlist.


Hunting Queries

Hunt for reg delete commands grouped by target registry key and initiating process. High counts or multiple hosts targeting the same key suggest scripted or automated cleanup. Keys appearing in this hunt that map to persistence locations (Run, Services, NetworkProvider) warrant immediate investigation.

Hunting — KQL
kql
DeviceProcessEvents
| where Timestamp > ago(7d)
| where ProcessCommandLine has_any ("reg delete", "reg.exe delete")
| extend TargetKey = extract(@"reg(?:\.exe)?\s+delete\s+([^\s]+)", 1, ProcessCommandLine)
| summarize
    Count = count(),
    Hosts = dcount(DeviceName),
    Accounts = make_set(AccountName),
    CommandLines = make_set(ProcessCommandLine),
    Earliest = min(Timestamp),
    Latest = max(Timestamp)
  by TargetKey, InitiatingProcessFileName
| where Count > 1 or Hosts > 1
| sort by Count desc
Hunting — SPL
spl
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
  (CommandLine="*reg delete*" OR CommandLine="*reg.exe delete*")
| rex field=CommandLine "reg(?:\.exe)?\s+delete\s+(?P<TargetKey>[^\s]+)"
| stats
    count as Count,
    dc(host) as Hosts,
    values(User) as Accounts,
    values(CommandLine) as CommandLines,
    earliest(_time) as Earliest,
    latest(_time) as Latest
  by TargetKey, ParentImage
| where Count > 1 OR Hosts > 1
| sort - Count

Hunt for cmd.exe processes launched to delete .exe files, with a join to file deletion events to confirm the deletion occurred. The SelfDeletion flag in SPL identifies cases where the deleted file path matches the parent process — a strong indicator of malware cleaning up after execution. This pattern is observed in droppers, stagers, and post-exploitation frameworks.

Hunting — KQL
kql
// Hunt for self-deletion pattern: process spawns cmd.exe to delete its own or a sibling executable
let Window = 5m;
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName =~ "cmd.exe"
| where ProcessCommandLine matches regex @"/[Cc]\s+del.*\.exe"
| extend DeletedFile = extract(@"/[Cc]\s+del(?:\s+/[fFqQ]\s+)*\"?([^\"\s]+\.exe)", 1, ProcessCommandLine)
| join kind=leftouter (
    DeviceFileEvents
    | where ActionType == "FileDeleted"
    | where FileName endswith ".exe"
    | project FileTimestamp=Timestamp, DeviceName, FileName, FolderPath, InitiatingProcessFileName
  ) on DeviceName
| where abs(datetime_diff('second', Timestamp, FileTimestamp)) < 30
| project Timestamp, DeviceName, AccountName, ProcessCommandLine, DeletedFile,
          FolderPath, InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
Hunting — SPL
spl
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
  Image="*\\cmd.exe"
  CommandLine="*/c del*.exe*"
| rex field=CommandLine "/[Cc]\s+del(?:\s+/[fFqQ]\s+)*\"?(?P<DeletedFile>[^\"\s]+\.exe)"
| eval SelfDeletion=if(match(lower(DeletedFile), lower(ParentImage)), 1, 0)
| table _time, host, User, Image, CommandLine, DeletedFile, ParentImage, ParentCommandLine, SelfDeletion
| sort - _time

Hunt for executables in writable temp/staging directories that were executed and then deleted within 60 minutes. This drop-execute-delete pattern is a hallmark of fileless stagers, loaders, and anti-forensic malware that minimize persistent on-disk artifacts. Sysmon Event ID 23 (File Delete Detected) is required for the SPL query — ensure it is enabled in the Sysmon configuration.

Hunting — KQL
kql
// Hunt for processes that ran and then had their file deleted within a short window
// Indicates a drop-execute-delete pattern used by malware to minimize on-disk presence
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FolderPath has_any ("\\Temp\\", "\\AppData\\Local\\Temp\\", "\\Users\\Public\\", "\\ProgramData\\")
| project ExecutionTime=Timestamp, DeviceName, AccountName,
          FileName, FolderPath, SHA256,
          InitiatingProcessFileName, ProcessCommandLine
| join kind=inner (
    DeviceFileEvents
    | where ActionType == "FileDeleted"
    | where FolderPath has_any ("\\Temp\\", "\\AppData\\Local\\Temp\\", "\\Users\\Public\\", "\\ProgramData\\")
    | project DeletionTime=Timestamp, DeviceName, FileName, FolderPath
  ) on DeviceName, FileName, FolderPath
| where DeletionTime > ExecutionTime
| extend MinutesBeforeDeletion = datetime_diff('minute', DeletionTime, ExecutionTime)
| where MinutesBeforeDeletion between (0 .. 60)
| project ExecutionTime, DeletionTime, MinutesBeforeDeletion,
          DeviceName, AccountName, FileName, FolderPath, SHA256,
          InitiatingProcessFileName, ProcessCommandLine
| sort by MinutesBeforeDeletion asc
Hunting — SPL
spl
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational"
  EventCode IN (1, 23)
  (Image="*\\Temp\\*" OR Image="*\\AppData\\Local\\Temp\\*" OR Image="*\\Users\\Public\\*" OR Image="*\\ProgramData\\*")
| eval EventType=if(EventCode=1, "Execution", "FileDeletion")
| eval FilePath=coalesce(Image, TargetFilename)
| stats
    values(EventType) as EventTypes,
    min(eval(if(EventCode=1, _time, null()))) as ExecutionTime,
    max(eval(if(EventCode=23, _time, null()))) as DeletionTime,
    values(CommandLine) as CommandLines
  by host, FilePath
| where mvcount(EventTypes) > 1
| eval MinutesBeforeDeletion=round((DeletionTime - ExecutionTime) / 60, 1)
| where MinutesBeforeDeletion >= 0 AND MinutesBeforeDeletion <= 60
| sort MinutesBeforeDeletion

Atomic Red Team Tests

Test 1 Registry Key Self-Cleanup — Delete Run Key
windows

Simulates post-exploitation registry cleanup by creating a Run key (as a persistence mechanism would) and then immediately deleting it using reg.exe. This mirrors the behavior of malware families like SDBbot, SILENTTRINITY, Mustang Panda, and Metamorfo that delete their own registry persistence artifacts during cleanup or before exiting.

Command

powershell
reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v df00tech-test /t REG_SZ /d C:\Windows\Temp\test.exe /f && reg delete HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v df00tech-test /f

Cleanup

powershell
reg delete HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v df00tech-test /f 2>nul

Expected Telemetry

Sysmon Event ID 12 (RegistryEvent - Object Create/Delete): TargetObject=HKCU\Software\Microsoft\Windows\CurrentVersion\Run\df00tech-test, EventType=DeleteValue. Sysmon Event ID 1: two cmd/reg.exe process creation events. Security Event ID 4657 (if object access auditing is enabled): ObjectName matching the Run key path.

Expected Detection

KQL: DeviceRegistryEvents with ActionType=RegistryValueDeleted and RegistryKey containing \Run\, plus DeviceProcessEvents with ProcessCommandLine containing 'reg delete'. SPL: Sysmon EventCode=12 with TargetObject matching Run path AND EventCode=1 with CommandLine matching reg delete. SuspicionScore >= 2.

Test 2 Executable Self-Deletion via cmd.exe
windows

Simulates a malware self-deletion pattern where a process spawns cmd.exe to delete its own binary after execution. The technique uses a ping delay to ensure the parent process exits before deletion occurs. This pattern is used by droppers and loaders to minimize on-disk artifacts and is observed in numerous malware families including those from Agrius, FIN7, and commodity loaders.

Command

powershell
copy C:\Windows\System32\whoami.exe C:\Windows\Temp\df00tech-cleanup-test.exe && C:\Windows\Temp\df00tech-cleanup-test.exe && cmd.exe /c ping -n 2 127.0.0.1 > nul && del /f /q C:\Windows\Temp\df00tech-cleanup-test.exe

Cleanup

powershell
del /f /q C:\Windows\Temp\df00tech-cleanup-test.exe 2>nul

Expected Telemetry

Sysmon Event ID 1: Process creation for df00tech-cleanup-test.exe. Sysmon Event ID 1: cmd.exe with CommandLine containing 'del /f /q' and the .exe path. Sysmon Event ID 11: file create for df00tech-cleanup-test.exe. Sysmon Event ID 23 (if configured): FileDelete event for df00tech-cleanup-test.exe showing the file was archived by Sysmon before deletion.

Expected Detection

KQL: DeviceProcessEvents with ProcessCommandLine matching /c del.*\.exe pattern from cmd.exe parent. SPL: Sysmon EventCode=1 Image matching cmd.exe with CommandLine matching self-deletion pattern. SelfDeletion flag set to 1.

Test 3 PowerShell Registry Key Deletion
windows

Simulates the PowerShell-based registry cleanup used by tools like SILENTTRINITY and IPsec Helper. Creates a test registry value simulating a post-exploitation artifact store and then deletes it using Remove-ItemProperty — a common pattern in PowerShell-based implants that store configuration or stage data in the registry.

Command

powershell
New-Item -Path 'HKCU:\Software\Microsoft\Internet Explorer' -Name 'notes' -Force | Out-Null; New-ItemProperty -Path 'HKCU:\Software\Microsoft\Internet Explorer\notes' -Name 'config' -Value 'implant_data' -PropertyType String -Force | Out-Null; Remove-Item -Path 'HKCU:\Software\Microsoft\Internet Explorer\notes' -Recurse -Force

Cleanup

powershell
Remove-Item -Path 'HKCU:\Software\Microsoft\Internet Explorer\notes' -Recurse -Force -ErrorAction SilentlyContinue

Expected Telemetry

Sysmon Event ID 12 (RegistryEvent - Create/Delete): EventType=DeleteKey, TargetObject=HKCU\Software\Microsoft\Internet Explorer\notes. Sysmon Event ID 1: powershell.exe with CommandLine containing 'Remove-Item' and 'Internet Explorer\notes'. PowerShell ScriptBlock Log Event ID 4104 with full script content showing the create and delete sequence.

Expected Detection

KQL: DeviceRegistryEvents with ActionType=RegistryKeyDeleted and RegistryKey containing 'Internet Explorer\notes'. DeviceProcessEvents with ProcessCommandLine containing 'Remove-Item'. SPL: Sysmon EventCode=12 with TargetObject matching the key path. RegCleanup flag set to 1. SuspicionScore >= 1.

Test 4 Drop-Execute-Delete Pattern in Temp Directory
windows

Simulates the full drop-execute-delete lifecycle used by stagers and loaders: copies an executable to a writable temp directory, executes it, and then deletes it within a short timeframe. This mirrors behavior observed in numerous threat actor operations where a first-stage dropper delivers a payload and then removes itself to avoid forensic detection.

Command

powershell
copy C:\Windows\System32\cmd.exe C:\Users\Public\svcupdate32.exe && C:\Users\Public\svcupdate32.exe /c whoami > C:\Windows\Temp\out.txt && timeout /t 2 /nobreak > nul && del /f /q C:\Users\Public\svcupdate32.exe && del /f /q C:\Windows\Temp\out.txt

Cleanup

powershell
del /f /q C:\Users\Public\svcupdate32.exe 2>nul && del /f /q C:\Windows\Temp\out.txt 2>nul

Expected Telemetry

Sysmon Event ID 11: file creation of svcupdate32.exe in C:\Users\Public\. Sysmon Event ID 1: execution of svcupdate32.exe. Sysmon Event ID 1: cmd.exe with del command. Sysmon Event ID 23 (FileDelete, if configured): svcupdate32.exe deletion. KQL hunting query matches execution in Public directory followed by file deletion within 60 minutes.

Expected Detection

KQL hunting query: ExecutionTime and DeletionTime both present for same FileName+FolderPath within 60 minutes. SPL hunting query: EventTypes containing both Execution and FileDeletion for same FilePath. MinutesBeforeDeletion will be < 1 minute for this test.

Test 5 Simulate BPFDoor Environment Variable Clearing
linux

Simulates the BPFDoor technique of clearing process environment variables to remove forensic evidence. BPFDoor clears /proc/<PID>/environ on Linux to hide its configuration and operational parameters. This test simulates the Linux variant of indicator removal by overwriting the environment file for the current shell process.

Command

bash
echo $$ && python3 -c "import os; pid=os.getpid(); f=open(f'/proc/{pid}/environ','wb'); f.write(b''); f.close()" && cat /proc/$$/environ | xxd | head -5

Expected Telemetry

Auditd syscall event for open(2) with flags O_WRONLY on /proc/<PID>/environ path. Syslog entry if auditd is configured to watch /proc/*/environ with inode watches. Linux audit event type=PATH with name matching /proc/[0-9]+/environ.

Expected Detection

Linux auditd rule: -w /proc -p wa -k indicator_removal. Splunk SPL on linux_audit sourcetype: search for write operations against /proc/*/environ paths. Low confidence detection as this requires auditd configuration targeting the /proc filesystem.

Related Detections