T1557

Adversary-in-the-Middle

Credential Access Collection Last updated:

Adversaries may attempt to position themselves between two or more networked devices using an adversary-in-the-middle (AiTM) technique to support follow-on behaviors such as Network Sniffing (T1040), Transmitted Data Manipulation (T1565.002), or replay attacks. By abusing features of common networking protocols (ARP, DNS, LLMNR, DHCP), adversaries force devices to communicate through an adversary-controlled system to harvest credentials, session tokens, and sensitive data. Sub-techniques include LLMNR/NBT-NS Poisoning and SMB Relay (T1557.001), ARP Cache Poisoning (T1557.002), DHCP Spoofing (T1557.003), and Evil Twin wireless attacks (T1557.004). Common attack frameworks include Responder, Bettercap, Ettercap, ntlmrelayx, mitmproxy, dnschef, and EvilGinx2. Threat groups including Kimsuky, Sea Turtle, and Mustang Panda have leveraged AiTM positioning for large-scale credential theft, session hijacking, and DNS record manipulation at service providers.

What is T1557 Adversary-in-the-Middle?

Adversary-in-the-Middle (T1557) maps to the Credential Access and Collection tactics — the adversary is trying to steal account names and passwords in MITRE ATT&CK.

This page provides production-ready detection logic for Adversary-in-the-Middle, covering the data sources and telemetry it touches: Process: Process Creation, Command: Command Execution, Windows Registry: Registry Key Modification, 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
Credential Access Collection
Technique
T1557 Adversary-in-the-Middle
Canonical reference
https://attack.mitre.org/techniques/T1557/
Microsoft Sentinel / Defender
kusto
let AiTMToolNames = dynamic([
  "responder.exe", "bettercap", "bettercap.exe", "ettercap", "ettercap.exe",
  "mitmproxy", "mitmdump", "mitmweb", "dnschef", "sslstrip",
  "ntlmrelayx.py", "smbrelayx.py", "multirelay.py",
  "evilginx", "evilginx2", "mitm6", "mitm6.py"
]);
let AiTMKeywords = dynamic([
  "responder", "bettercap", "ettercap", "mitmproxy", "ntlmrelayx",
  "smbrelayx", "multirelay", "dnschef", "sslstrip", "mitm6",
  "evilginx", "arpspoof", "arp-spoof", "impacket-ntlmrelayx"
]);
let ProcessDetections =
DeviceProcessEvents
| where Timestamp > ago(24h)
| where FileName has_any (AiTMToolNames)
    or ProcessCommandLine has_any (AiTMKeywords)
    or (FileName =~ "arp.exe" and ProcessCommandLine has "-s" and ProcessCommandLine has ".")
    or (FileName in~ ("python.exe", "python3", "python3.exe") and ProcessCommandLine has_any (AiTMKeywords))
    or (FileName =~ "netsh.exe" and ProcessCommandLine has "interface" and ProcessCommandLine has "dns" and ProcessCommandLine has "set")
    or (FileName =~ "powershell.exe" and ProcessCommandLine has "Set-DnsClientServerAddress")
| extend DetectionCategory = case(
    ProcessCommandLine has_any (["responder", "ntlmrelayx", "smbrelayx", "multirelay"]), "LLMNR_NBT_NS_Relay",
    ProcessCommandLine has_any (["bettercap", "ettercap", "arpspoof", "arp-spoof"]) or (FileName =~ "arp.exe" and ProcessCommandLine has "-s"), "ARP_Poisoning",
    ProcessCommandLine has_any (["mitmproxy", "mitmdump", "mitmweb", "sslstrip"]), "SSL_Interception",
    ProcessCommandLine has_any (["dnschef", "mitm6", "evilginx"]), "DNS_Spoofing",
    ProcessCommandLine has "Set-DnsClientServerAddress" or (FileName =~ "netsh.exe" and ProcessCommandLine has "dns"), "DNS_Config_Modification",
    "AiTM_Tool_Other"
)
| project Timestamp, DeviceName, AccountName, FileName, ProcessCommandLine,
    InitiatingProcessFileName, InitiatingProcessCommandLine, DetectionCategory,
    ActivityType="ProcessExecution";
let RegistryDetections =
DeviceRegistryEvents
| where Timestamp > ago(24h)
| where RegistryKey has_all ("Tcpip", "Parameters", "Interfaces")
| where RegistryValueName in~ ("NameServer", "DhcpNameServer")
| where isnotempty(RegistryValueData) and RegistryValueData !in ("", "0.0.0.0", "fec0:0:0:ffff::1")
| extend DetectionCategory = "DNS_Server_Registry_Modification"
| project Timestamp, DeviceName, AccountName=InitiatingProcessAccountName,
    FileName=InitiatingProcessFileName,
    ProcessCommandLine=InitiatingProcessCommandLine,
    InitiatingProcessFileName, InitiatingProcessCommandLine,
    DetectionCategory, ActivityType="RegistryModification";
union ProcessDetections, RegistryDetections
| sort by Timestamp desc

Detects Adversary-in-the-Middle tool execution and network configuration manipulation using Microsoft Defender for Endpoint tables. Combines a DeviceProcessEvents query identifying known AiTM tool binaries and command-line keywords (Responder, Bettercap, Ettercap, mitmproxy, ntlmrelayx, EvilGinx2, mitm6, dnschef, sslstrip, arpspoof), suspicious ARP table manipulation via arp.exe, and DNS configuration changes via netsh or PowerShell with a DeviceRegistryEvents query detecting DNS server registry modifications under the TCP/IP interface keys. Results are categorized by AiTM sub-technique variant to assist analyst triage.

high severity medium confidence

Data Sources

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

Required Tables

DeviceProcessEvents DeviceRegistryEvents

False Positives

  • Network engineers using arp -s for legitimate static ARP entry management on servers or network appliances
  • Security teams running authorized penetration tests or red team exercises using Responder, Bettercap, or Ettercap in approved lab segments
  • IT administrators reconfiguring DNS server settings via netsh or Set-DnsClientServerAddress during planned network migrations or failover procedures
  • Developers using mitmproxy, Burp Suite, or Charles Proxy for legitimate web application debugging, API testing, or certificate inspection
  • DHCP server changes during authorized network infrastructure replacements causing DNS server registry updates across endpoints

Sigma rule & cross-platform mapping

The detection logic for Adversary-in-the-Middle (T1557) 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 1ARP Static Entry Manipulation (Windows)

    Expected signal: Sysmon Event ID 1: Process Create with Image=C:\Windows\System32\arp.exe, CommandLine='arp -s 192.168.100.254 00-AA-BB-CC-DD-EE'. Security Event ID 4688 (if command-line auditing is enabled). No network events expected as this is a local table modification.

  2. Test 2DNS Server Change via netsh (Windows)

    Expected signal: Sysmon Event ID 1: Process Create with Image=C:\Windows\System32\netsh.exe, CommandLine containing 'interface ip set dns'. Sysmon Event ID 13: Registry value set under HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}\NameServer with new value '127.0.0.1'.

  3. Test 3DNS Server Change via PowerShell (Windows)

    Expected signal: Sysmon Event ID 1: Process Create with Image=powershell.exe, CommandLine containing 'Set-DnsClientServerAddress'. Sysmon Event ID 13: Registry modification at HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}\NameServer. PowerShell ScriptBlock Log Event ID 4104 showing the Set-DnsClientServerAddress call.

  4. Test 4ARP Poisoning Tool Execution — arpspoof (Linux)

    Expected signal: Syslog or auditd process creation event for arpspoof. On systems with Sysmon for Linux (sysmonforlinux): Event ID 1 Process Create with Image path to arpspoof binary and CommandLine '-i lo -t 127.0.0.1 127.0.0.2'. Auditd syscall records for execve with the arpspoof arguments.

  5. Test 5mitmproxy SSL Interception Tool Invocation (Linux/macOS)

    Expected signal: Process creation event for mitmproxy binary (path varies by pip install location, typically ~/.local/bin/mitmproxy or /usr/local/bin/mitmproxy). Sysmon Event ID 1 (if Sysmon for Linux deployed) with Image containing 'mitmproxy' and CommandLine '--version'. Auditd EXECVE syscall record.


Response Playbook

Triage

  1. Identify which AiTM sub-technique is indicated by the DetectionCategory field: LLMNR_NBT_NS_Relay suggests T1557.001 (Responder/ntlmrelayx), ARP_Poisoning suggests T1557.002, DNS_Spoofing or DNS_Config_Modification suggests poisoning or redirection, SSL_Interception suggests credential proxy tooling
  2. Examine the parent process of the detected tool — was it launched interactively from a user shell (cmd.exe, PowerShell spawned by a user), from a scheduled task, or from a remote execution service (WMI, PsExec, svchost)? Interactive execution on a non-security workstation is strongly suspicious
  3. Check the user account — does this user have a legitimate reason to run network interception tools? Cross-reference with IT/security team rosters and any open change tickets for network work in this subnet
  4. Determine the network segment of the affected host. AiTM attacks are most dangerous when the attacker is on the same subnet as targets. Check which servers, domain controllers, or VPN concentrators share the Layer 2 broadcast domain with the attacker host
  5. Search for concurrent NTLM authentication events (Security Event ID 4624, 4648, 4776) on domain controllers and SMB servers in the same time window — Responder captures NTLM hashes that appear as authentication attempts from victim IPs to the attacker's IP
  6. Review DNS query logs or network flow data for the suspect host: is it responding to DNS queries for legitimate domains? Is it listening on port 53, 389 (LDAP), 80, 443, or 5353 (mDNS)? This indicates active interception is occurring

Containment

  1. Immediately isolate the attacker host from the network using EDR network isolation or VLAN reassignment — AiTM attacks are ongoing as long as the tool is running and the attacker remains on the same broadcast domain
  2. If LLMNR/NBT-NS relay is confirmed, identify all hosts that may have sent NTLM challenges to the attacker's IP by reviewing Security Event 4776 (NTLM validation) on DCs — force password resets for all captured accounts before the hashes can be cracked
  3. If DNS server was modified on the host registry, restore the correct DNS server addresses: run 'netsh interface ip set dns name="<adapter>" dhcp' or use Group Policy to push the correct DNS configuration via gpupdate /force
  4. If ARP poisoning is suspected, flush ARP caches on affected systems with 'arp -d *' (Windows) or 'ip neigh flush all' (Linux), and consider implementing Dynamic ARP Inspection (DAI) on managed switches in the affected segment
  5. Block the attacker's IP at the network layer (switch port-level if on-prem, NSG/security group if cloud) and reset any SSL/TLS sessions that may have been terminated by an intercepting proxy
  6. Revoke and reissue any session tokens, OAuth tokens, or authentication cookies that may have been captured during the interception window — check Identity Provider sign-in logs for anomalous token use from unfamiliar IPs

Evidence Collection

  1. ARP table snapshot from the attacker host: 'arp -a' (Windows) or 'arp -n' (Linux) — compare against network documentation to identify spoofed entries
  2. DNS configuration state: 'ipconfig /all' (Windows) or 'cat /etc/resolv.conf' (Linux) — document any unauthorized nameserver entries
  3. Registry export of TCP/IP interface settings: 'reg export HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces <output.reg>' to capture DNS server history
  4. Process list with listening sockets: 'netstat -anob' (Windows) or 'ss -tulnp' (Linux) — document any unexpected listeners on ports 53 (DNS), 80, 443, 445 (SMB), 5355 (LLMNR), 137-138 (NBT-NS)
  5. Network packet capture: if a span/mirror port or TAP is available, capture traffic to/from the attacker IP for forensic analysis of intercepted sessions — focus on ports 445, 80, 443, 53
  6. Windows Event Log export: Security log for Event IDs 4624, 4625, 4648, 4776 on domain controllers covering the attack window to identify all accounts whose NTLM credentials were relayed
  7. Sysmon Event ID 3 (Network Connections) from the attacker host to identify all systems the AiTM tool established connections to during the interception period
  8. Hosts file: collect 'C:\Windows\System32\drivers\etc\hosts' (Windows) or '/etc/hosts' (Linux) for unauthorized domain-to-IP mappings

Escalation Criteria

  • ! Evidence that NTLM credentials were successfully relayed — Security Event 4624 with LogonType 3 sourced from the attacker IP on any server or domain controller indicates a successful relay attack
  • ! Detection of EvilGinx2 or AiTM phishing proxy: these tools capture both credentials AND session cookies, bypassing MFA — any confirmed EvilGinx instance requires immediate escalation to incident response and IdP token revocation
  • ! Multiple victim hosts affected — if ARP or DNS poisoning is confirmed across more than one subnet or site, the scope indicates a sophisticated actor with network traversal capabilities
  • ! Privileged account exposure — if domain admin, service account, or Azure AD Global Admin credentials were potentially captured during the interception window, escalate immediately for emergency credential rotation
  • ! Evidence of lateral movement following AiTM setup: new process execution, scheduled task creation, or service installation on remote systems using the timeframe of the detected AiTM activity
  • ! AiTM tool running as SYSTEM or under a service account with no corresponding change ticket — indicates persistence mechanism rather than one-time red team activity

Investigation Guide

Forensic Artifacts

  • > Windows ARP table: 'arp -a' — look for the gateway MAC address duplicated for multiple IPs, or a single MAC responding for many IPs (indicative of ARP spoofing)
  • > Registry: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}\NameServer — contains statically configured DNS servers; unexpected IPs indicate DNS hijacking
  • > Windows Event Log — Security, Event ID 4776: NTLM authentication validation events on DCs with Workstation Name field showing the attacker's hostname indicate hash relay attempts
  • > Windows Event Log — Security, Event ID 4624/4648: Network logons (LogonType 3) from unexpected source IPs to servers in the attack window indicate successful relay
  • > Sysmon Event ID 3: Network connection events showing the AiTM tool process (responder, bettercap, python) making inbound connections on ports 445, 80, 443 from victim hosts
  • > Linux /proc/net/arp: ARP table showing gateway IP mapped to an unexpected MAC address indicates active ARP poisoning of a Linux host
  • > Linux /etc/resolv.conf: unauthorized nameserver entries indicate DNS hijacking on Linux endpoints
  • > Windows Prefetch: C:\Windows\Prefetch\RESPONDER.EXE-*.pf or BETTERCAP.EXE-*.pf — execution timestamps and referenced DLLs
  • > Network flow logs (NetFlow/IPFIX): anomalous traffic volumes where a single host is receiving traffic from many peers simultaneously indicates AiTM interception position
  • > Wireless IDS/IPS logs: duplicate BSSID/ESSID entries with stronger signal or DHCP responses from unauthorized APs indicate Evil Twin attack (T1557.004)

Tuning Guidance

Start by baselining legitimate ARP management: servers with static ARP entries for gateway redundancy are common in data centers and should be added to an allowlist keyed on DeviceName + AccountName. For DNS changes, identify the standard DHCP servers and management workstations in your environment and exclude their InitiatingProcessFileName (svchost.exe for DHCP-pushed changes). To reduce false positives from security tooling, create a named-group exclusion for authorized red team systems and developer workstations with known-good mitmproxy usage. For LLMNR/NBT-NS hunting, the fastest noise reduction is to enforce GPO disabling LLMNR (Computer Config > Administrative Templates > Network > DNS Client > Turn off multicast name resolution) and NBT-NS (WINS tab in network adapter properties); once these protocols are disabled org-wide, any activity on ports 5355, 137, or 138 becomes immediately suspicious with near-zero false positives. Consider enriching alerts with the DHCP lease table to map attacker IPs to MAC addresses and physical switch port locations for rapid physical containment in on-premises environments.


Hunting Queries

Hunt for NTLM relay indicators — a single source IP authenticating to many different target computers via NTLM is a strong signal of credential relay. Legitimate systems authenticate to a consistent set of servers; relay tools forward captured hashes to multiple targets opportunistically.

Hunting — KQL
kql
SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID in (4624, 4776)
| where AuthenticationPackageName =~ "NTLM" or EventID == 4776
| where IpAddress != "-" and IpAddress != "::1" and IpAddress !startswith "127."
| summarize
    AuthCount=count(),
    TargetAccounts=make_set(TargetUserName, 20),
    TargetComputers=make_set(Computer, 20),
    UniqueTargetComputers=dcount(Computer),
    FirstSeen=min(TimeGenerated),
    LastSeen=max(TimeGenerated)
  by IpAddress
| where UniqueTargetComputers > 3 or AuthCount > 20
| sort by AuthCount desc
Hunting — SPL
spl
index=wineventlog sourcetype="WinEventLog:Security" EventCode IN (4624, 4776) AuthenticationPackageName=NTLM NOT src_ip IN ("-", "::1", "127.0.0.1")
| stats count as AuthCount, dc(dest) as UniqueTargetComputers, values(user) as TargetAccounts, earliest(_time) as FirstSeen, latest(_time) as LastSeen
    by src_ip
| where UniqueTargetComputers > 3 OR AuthCount > 20
| sort - AuthCount

Hunt for DNS server changes propagating across multiple endpoints in a short window. A single DNS value change appearing on many hosts simultaneously may indicate DHCP spoofing (T1557.003) delivering a rogue DNS server, or a worm-like mechanism pushing DNS configuration changes for mass redirection.

Hunting — KQL
kql
DeviceRegistryEvents
| where Timestamp > ago(7d)
| where RegistryKey has_all ("Tcpip", "Parameters", "Interfaces")
| where RegistryValueName in~ ("NameServer", "DhcpNameServer")
| where isnotempty(RegistryValueData) and RegistryValueData !in ("", "0.0.0.0")
| summarize
    ChangeCount=count(),
    AffectedDevices=dcount(DeviceName),
    NewDNSValues=make_set(RegistryValueData, 20),
    Devices=make_set(DeviceName, 20)
  by bin(Timestamp, 1h), RegistryValueData
| where AffectedDevices > 2 or ChangeCount > 5
| sort by Timestamp desc
Hunting — SPL
spl
index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=13
    TargetObject="*Tcpip*Parameters*Interfaces*"
    (TargetObject="*NameServer*" OR TargetObject="*DhcpNameServer*")
| stats count as ChangeCount, dc(host) as AffectedDevices, values(Details) as NewDNSValues, values(host) as Devices
    by bin(_time, 1h), Details
| where AffectedDevices > 2 OR ChangeCount > 5
| sort - _time

Hunt for hosts responding to LLMNR (port 5355) or NBT-NS (ports 137-138) queries from multiple systems. Legitimate hosts rarely respond to LLMNR/NBT-NS queries in well-configured environments where these protocols are disabled. A host answering these queries from many peers is exhibiting Responder-like poisoning behavior consistent with T1557.001.

Hunting — KQL
kql
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where LocalPort in (5355, 137, 138) and Direction == "Inbound"
| where RemoteIPType !in ("Loopback", "LinkLocal")
| summarize
    ResponseCount=count(),
    UniqueQueryingSystems=dcount(RemoteIP),
    QueryingSystems=make_set(RemoteIP, 30)
  by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine
| where UniqueQueryingSystems > 3
| sort by ResponseCount desc
Hunting — SPL
spl
index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
    (DestinationPort=5355 OR DestinationPort=137 OR DestinationPort=138)
    NOT (DestinationIp="127.*" OR DestinationIp="::1" OR DestinationIp="224.*" OR DestinationIp="239.*")
| stats count as QueryCount, dc(SourceIp) as UniqueQueriers, values(SourceIp) as QueriersIPs
    by host, Image, CommandLine
| where UniqueQueriers > 3
| sort - QueryCount

Atomic Red Team Tests

Test 1 ARP Static Entry Manipulation (Windows)
windows

Adds a static ARP table entry mapping an IP address to a spoofed MAC address, simulating the end-state of an ARP cache poisoning attack. The arp -s command is the Windows equivalent of what tools like Bettercap and Ettercap achieve via crafted ARP reply packets. This test generates process creation telemetry for arp.exe with the -s flag, which triggers the KQL and SPL detection rules.

Command

powershell
arp -s 192.168.100.254 00-AA-BB-CC-DD-EE

Cleanup

powershell
arp -d 192.168.100.254

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=C:\Windows\System32\arp.exe, CommandLine='arp -s 192.168.100.254 00-AA-BB-CC-DD-EE'. Security Event ID 4688 (if command-line auditing is enabled). No network events expected as this is a local table modification.

Expected Detection

KQL: Matches ProcessDetections branch where FileName =~ 'arp.exe' and ProcessCommandLine has '-s' and ProcessCommandLine has '.'. DetectionCategory='ARP_Table_Modification'. SPL: IsARPPoisonTool=1 from the arp\s+-s\s+\d+\. regex match. SuspicionScore >= 1.

Test 2 DNS Server Change via netsh (Windows)
windows

Modifies the DNS server configuration of a network interface to point to an attacker-controlled resolver, simulating DNS hijacking as used by Sea Turtle and DNS changer malware. This is the technique-level observable for DNS-based AiTM: any DNS queries from this host will now be resolved by the attacker. The test uses a loopback address to avoid actual impact.

Command

powershell
netsh interface ip set dns name="Ethernet" static addr=127.0.0.1

Cleanup

powershell
netsh interface ip set dns name="Ethernet" dhcp

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=C:\Windows\System32\netsh.exe, CommandLine containing 'interface ip set dns'. Sysmon Event ID 13: Registry value set under HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}\NameServer with new value '127.0.0.1'.

Expected Detection

KQL ProcessDetections: FileName='netsh.exe', ProcessCommandLine has 'interface' AND 'dns' AND 'set', DetectionCategory='DNS_Config_Modification'. KQL RegistryDetections: RegistryKey has_all 'Tcpip','Parameters','Interfaces', RegistryValueName='NameServer', RegistryValueData='127.0.0.1'. SPL: IsDNSConfigChange=1.

Test 3 DNS Server Change via PowerShell (Windows)
windows

Uses the Set-DnsClientServerAddress cmdlet to redirect DNS resolution to an attacker-controlled server. This PowerShell-based approach is commonly used by malware and post-exploitation frameworks (Cobalt Strike, Empire) to redirect victims to attacker-controlled infrastructure without needing netsh or direct registry writes. The test uses localhost to avoid actual impact.

Command

powershell
powershell.exe -Command "Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ServerAddresses ('127.0.0.1')"

Cleanup

powershell
powershell.exe -Command "Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ResetServerAddresses"

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=powershell.exe, CommandLine containing 'Set-DnsClientServerAddress'. Sysmon Event ID 13: Registry modification at HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}\NameServer. PowerShell ScriptBlock Log Event ID 4104 showing the Set-DnsClientServerAddress call.

Expected Detection

KQL ProcessDetections: FileName='powershell.exe', ProcessCommandLine has 'Set-DnsClientServerAddress', DetectionCategory='DNS_Config_Modification'. KQL RegistryDetections: Fires on the resulting registry write. SPL: IsDNSConfigChange=1 from Set-DnsClientServerAddress match in cmd_lower. SuspicionScore >= 1.

Test 4 ARP Poisoning Tool Execution — arpspoof (Linux)
linux

Installs and invokes arpspoof from the dsniff package to send gratuitous ARP replies positioning the attacker between a target and its default gateway. This is the canonical Linux ARP cache poisoning method. The command sends a single ARP packet and exits — it does not sustain poisoning — making it safe for detection validation in an isolated lab network segment.

Command

bash
sudo apt-get install -y dsniff 2>/dev/null; sudo arpspoof -i lo -t 127.0.0.1 127.0.0.2 -n 1

Cleanup

bash
sudo apt-get remove -y dsniff 2>/dev/null || true

Expected Telemetry

Syslog or auditd process creation event for arpspoof. On systems with Sysmon for Linux (sysmonforlinux): Event ID 1 Process Create with Image path to arpspoof binary and CommandLine '-i lo -t 127.0.0.1 127.0.0.2'. Auditd syscall records for execve with the arpspoof arguments.

Expected Detection

SPL (if Sysmon for Linux is deployed): IsARPPoisonTool=1 from match on 'arpspoof' in cmd_lower. KQL ProcessDetections: ProcessCommandLine has 'arpspoof', DetectionCategory='ARP_Poisoning'. Without Sysmon, the tool name appears in syslog or auditd EXECVE records.

Test 5 mitmproxy SSL Interception Tool Invocation (Linux/macOS)
linux

Installs mitmproxy and runs it with --version to verify installation, generating process creation telemetry for the mitmproxy binary. In a real attack, mitmproxy is launched with a transparent proxy configuration to intercept and inspect HTTPS traffic after ARP poisoning or DNS redirection routes victim traffic through the attacker host. This test validates that the detection fires on the mitmproxy binary name without establishing an actual interception session.

Command

bash
pip3 install mitmproxy --quiet 2>/dev/null; mitmproxy --version

Cleanup

bash
pip3 uninstall mitmproxy -y 2>/dev/null || true

Expected Telemetry

Process creation event for mitmproxy binary (path varies by pip install location, typically ~/.local/bin/mitmproxy or /usr/local/bin/mitmproxy). Sysmon Event ID 1 (if Sysmon for Linux deployed) with Image containing 'mitmproxy' and CommandLine '--version'. Auditd EXECVE syscall record.

Expected Detection

SPL: IsSSLInterceptTool=1 from match on 'mitmproxy' in both img_lower and cmd_lower. KQL ProcessDetections: FileName has_any AiTMToolNames match on 'mitmproxy', DetectionCategory='SSL_Interception'. The --version invocation is sufficient to trigger binary-name based detection regardless of arguments.

Related Detections