How T1048 exfiltration over alternative protocol shows up in a SOC
The SOC lead's question is simple: is data leaving the environment over a protocol that this channel does not normally use? ATT&CK places T1048 under the Exfiltration tactic (TA0010), which defines the goal as "The adversary is trying to steal data." For an attacker, the technique matters because it moves stolen data out through a different protocol from the one the environment expects, often after the data has already been gathered and staged. The outbound path may be a non-standard port, a protocol that bypasses web proxies, or a service that legitimate workloads rarely call. For a defender, this means the signal is often a mismatch between what a host or workload normally sends and what it suddenly sends.
The technique shows up across ESXi hosts, IaaS workloads, Linux servers and macOS endpoints, and each platform produces different evidence. Hypervisors and cloud instances often have stable, narrow egress patterns, so an unexpected protocol is easier to spot there than on a busy user workstation. Decisions to make now include which outbound protocols each platform class is permitted to use, who owns the approved list, and whether egress from management networks is logged in enough detail to show protocol and destination. Ask your team to confirm which of these flows reach a central log platform today, because a gap in egress visibility is usually the first thing an investigation exposes.
T1048 has three sub-techniques in ATT&CK, and this page covers all of them. Confirm the exact names, IDs and descriptions on the ATT&CK v20 technique page before you write detection content, because sub-technique scope can change between releases. Name the ATT&CK version in every detection rule and coverage record so that later updates can be mapped without guesswork. Your SOC should review the ATT&CK updates page when a new release arrives and record which sub-techniques your current detections address.
Which telemetry reveals T1048 and which open-source tool collects it
This table maps each data source that can reveal T1048 activity to the signal to look for and the open-source collector that gathers it. Read each row as a question: what would show a transfer over a non-standard protocol, and which sensor sees it first. Coverage per platform must be confirmed in your own environment before you rely on any row.
| Data source | Signal to look for | Open-source collector or platform |
|---|---|---|
| Process Creation (DC0032) | Unexpected utilities or interpreters started on hosts that do not normally move data, especially with arguments that name remote hosts, unusual ports or raw socket use | Wazuh agents on Linux, macOS and Windows; Velociraptor for on-demand process history |
| Network Connection Creation (DC0082) | Outbound connections on ports or protocols that do not match the host role, such as DNS, ICMP or uncommon high ports from servers that should not initiate them | Wazuh agent network telemetry; Zeek connection logs; Security Onion dashboards |
| Network Traffic Flow (DC0078) | Sustained asymmetric flows where outbound volume greatly exceeds inbound volume on an unusual protocol or to a destination with no business relationship | Zeek conn logs; Security Onion; Suricata flow records where enabled |
| Network Traffic Content (DC0085) | Payloads on a protocol that do not match the expected grammar, such as non-DNS content inside DNS queries or tunneled data inside an allowed port | Zeek protocol analyzers; Suricata rules and protocol parsers at sensors inside the perimeter |
| File Access (DC0055) | Creation or reading of archive or staging files shortly before outbound connections, or access to sensitive directories by tools that normally do not read them | Wazuh file integrity monitoring; Velociraptor artifact collection on endpoints |
| Coverage by platform | Linux and macOS endpoints usually provide process and file telemetry through agents, while ESXi, IaaS and other platforms may need network sensors or cloud logs instead | Confirm agent support for each platform, including ESXi and IaaS, with the collector vendor or project documentation in your environment |
Detection ideas for T1048 that engineers can tune
Each card describes one detection idea for T1048 Exfiltration over alternative protocol, the logic behind it, and how to set thresholds against your own baseline. Every idea needs local tuning, because the same traffic pattern can be routine on one network and suspicious on another. Map each rule to the ATT&CK version your team targets before you deploy it.
Outbound volume on non-standard ports
Alert when a host sends an unusually large volume of data outbound on a port that is not normally used for that destination class, such as high-volume uploads on ports reserved for other services. Measure bytes sent per host, per destination and per port over a rolling window, then compare against that host's own history rather than a fleet-wide average. Tune the threshold by reviewing several weeks of flow data for the host group. Likely false positives include backup agents, replication jobs, log shippers and approved VPN tunnels, so maintain an allowlist keyed by host, process and destination.
Protocol and port mismatches
Flag flows where the observed application protocol does not match the port it runs on, for example traffic that parses as a shell or tunnel protocol on a port that is expected to carry web or DNS traffic. Use Network Traffic Flow records for coarse matching and Network Traffic Content only where your policy permits deeper inspection. Start in alert-only mode and review hits by source host and destination owner. Expect false positives from legacy applications, custom internal services and monitoring probes that intentionally run on unusual ports, so document each exception with an owner and an expiry date.
New processes opening network sessions
On servers that rarely initiate outbound sessions, alert when a process that has not previously made network connections starts one, especially when it is launched from an unusual parent or from a temporary directory. Combine Process Creation with Network Connection Creation events and key the baseline on the binary path and parent process, not only the process name. Tune by building a per-role inventory of expected network-initiating processes for each server group. Likely false positives include configuration management agents, package updaters, new monitoring agents and deployment pipelines that run after a change window.
Long-lived sessions to rare destinations
Track sessions that remain open for an unusually long time to destinations that the host has rarely or never contacted, since sustained low-rate channels can carry data without producing a volume spike. Use Network Traffic Flow duration and byte-count fields, and compare each destination against the organization's historical destination set. Thresholds should come from measured session durations for each application tier, not from a default value. Expect false positives from database replication, streaming telemetry, remote support sessions and cloud API clients that hold persistent connections.
Sigma rule structure and version mapping
Express each detection as a Sigma rule with a title, a description that names the ATT&CK technique, a logsource that matches the telemetry available, a detection block with selection and filter conditions, and a tuning note that lists known exceptions. Keep allowlists in separate filter blocks so reviewers can see exactly what is excluded. Record the ATT&CK version the rule targets, because technique names, detection strategies and data components change between releases. Confirm that your SIEM or Wazuh pipeline supports the Sigma backend you use before importing rules.
How to validate that T1048 detections fire
This sequence proves, in a private range, that each T1048 detection rule fires on the behavior it targets, that the telemetry it depends on arrives on time, and that the alert volume is understood well enough to tune. It produces evidence an auditor or security lead can review.
Fix the ATT&CK version and scope
Before any emulation, the detection owner records the ATT&CK version the rules map to, the T1048 sub-techniques in scope, and the platforms covered (ESXi, IaaS, Linux, macOS and other platforms). Version matters because MITRE can rename, deprecate or revoke techniques between releases, so the plan should name the version it targets, for example the Enterprise ATT&CK version used in the detection mappings. The step is done when the scope is a signed one-page table that lists each sub-technique and the rules expected to cover it.
Agree the emulation plan with the owner
The range lead writes an emulation plan describing the behavior class for each sub-technique in words only, with no commands or payloads. The plan names the systems involved, the lab segment, the expected alerts, who watches the console, the stop conditions, and who can halt the exercise. The control owner, the SOC lead and the system owner of the range sign it. The step is complete when the plan is approved and a copy is filed with the change record.
Run the behavior in a controlled segment
A tester, working from the approved plan, runs the agreed behavior class against lab hosts in an isolated segment with egress limited to the range. Each run is logged with a start time, a run identifier, the target system and the sub-technique being exercised. Outbound traffic is captured at the range boundary so that the same activity can be traced later. The step is done when each planned run has a timestamped log entry and the run sheet matches the plan.
Confirm the telemetry arrives
Before judging any rule, the analyst confirms that the data sources the rules depend on reached the SIEM for each run. For T1048 this typically means process creation events, network connection creation events and network traffic flow records from the lab hosts and perimeter sensors, for example through Wazuh, Zeek or Suricata where those are the chosen tools. Missing telemetry is recorded as a gap, not a pass. The step closes when every run has a telemetry check showing which sources were received and their delay.
Check each rule alert
For every rule mapped to T1048 and its sub-techniques, the analyst checks whether an alert was raised for the matching run, whether the alert carries the expected fields, and whether it routed to the right queue. A rule that did not fire is marked as a miss and sent back to the rule owner with the run identifier and the captured telemetry. The step is complete when each rule has a recorded outcome of fired, missed or partially fired for each run.
Measure time to alert and false positives
Using the timestamps from the run log and the alert records, the analyst calculates the time between the emulated behavior and each alert, and the number of alerts raised during the baseline window that were not tied to a planned run. Both figures are reported per rule. Where the range has no baseline, the report says so rather than inventing one. The step is done when a table lists time to alert and false positive counts for each rule, with the observation window stated.
Record evidence for audit review
The final report is filed with the detection owner and kept with the change record. It should include the ATT&CK version and scope, the signed plan, the run log, telemetry checks, alert outcomes, time to alert, false positive results, tuning actions and retest dates. Each item is tied to a rule identifier and a run identifier so an independent auditor can trace a claim back to raw evidence. Assessment conclusions remain with the independent auditor or certification body. The step is complete when the package is versioned and the open gaps have named owners.
Triage and response when a T1048 detection fires
The first decision on a T1048 alert is whether the outbound flow is explained by an approved business purpose, and the SOC answers that by comparing the observed destination, protocol and transfer volume against the asset owner's expected behavior for that host or segment. Analysts should confirm the destination against the approved list of external endpoints for the workload, check whether the protocol (for example, DNS, ICMP or a non-standard port) is one the owner has ever sanctioned, and compare the byte count with the host's historical baseline over the same time window. A match with a documented backup, replication or monitoring job closes the alert with a recorded reason, while an unexplained mismatch moves it into active investigation. Confirm these baselines with the asset owner before the first incident, because a triage decision made without them tends to rely on guesswork.
Once the flow is in question, the analyst pivots to correlated activity. Process creation records show which binary or service owned the connection, and network connection records tie that process to the session. The analyst also checks the identity that started the process, any recent authentication events on the host, and whether a scheduled job, service or configuration change preceded the traffic. The containment decision is made here: isolate the host when the owning process is unknown or the identity is unverified, and segment or block only the destination path when the workload is critical and the owner can confirm the activity is not theirs. Record who approved each containment action, since the business owner and incident response lead may need that trail later.
Evidence must be preserved before containment changes the state of the host. Flow records from the network sensor, the relevant time window of firewall or proxy logs, host process and connection snapshots, and the hash and path of the owning binary should be exported and hashed, with the collection time and the analyst's identity noted. Escalate to incident response when the destination is unknown, when data classified as sensitive could be involved, or when the same identity appears on other hosts; involve the data owner so they can judge what the transfer might have contained. Close the loop by tuning the rule thresholds, adding the verified destination or protocol to the asset baseline, and recording the outcome in the detection case so that the next alert on this workload starts from better information.
Preventive controls that reduce T1048 exposure
T1048 moves data out over protocols that often bypass the web proxy and standard outbound rules, so preventive controls matter most at the network edge and on data paths. The cards below cover the ATT&CK mitigations most often mapped to this technique, plus a related egress control, and each names what the control cannot see.
Data loss prevention (M1057)
Data Loss Prevention policies inspect content and context to flag or block sensitive data leaving the organization. For T1048, the question is whether the control sees the protocols in use at all, since many alternative channels carry data in ways a web-focused policy never inspects. Deploy it on egress points and on endpoints where bulk transfers start. Its blind spots include encrypted payloads that are not decrypted, compressed or archived data that the engine cannot parse, and small transfers below its thresholds. Confirm with the product owner which protocols, file types and decryption methods the product actually supports before assuming coverage.
Network intrusion prevention (M1031)
Network Intrusion Prevention inspects traffic against signatures and protocol rules and can drop matching flows inline. For T1048 it helps when rules cover unusual protocol use on ports or services that should not carry bulk outbound data, such as DNS, ICMP or non-standard TCP. Place sensors where traffic crosses trust boundaries, including the data center and cloud egress path. Blind spots include encrypted sessions without inspection, traffic that stays inside segments with no sensor, and protocols the signature set does not describe. Ask the vendor which protocol decoders are included and how inline blocking is tuned.
Egress filtering (M1037)
Filter Network Traffic is a related control that restricts which destinations and protocols hosts can reach outbound. Default-deny egress for servers, with explicit allow lists for required services, removes many routes that an alternative protocol channel would need. This control is relevant only if your team uses it as an egress policy, so confirm that it is deployed and reviewed for workloads that have no business reason to reach the internet. Its limits are that permitted destinations can still carry abused traffic, and that workloads behind shared proxies or NAT may hide the source host from policy logs.
Data path inventory
Preventive controls work only where the data flows are known. Maintain a current map of which workloads hold sensitive data, which protocols they use to reach outside networks, and which service accounts can initiate transfers. Use this map to decide where DLP and intrusion prevention must be placed and where exceptions need approval. Gaps usually sit in backup jobs, database replication, file sync tools and administrative tunnels, which are easy to overlook. Ask the team who owns each path and whether its exceptions have an expiry date.
Rehearsing T1048 detection and response in a private cyber range
The cyber range for T1048 should be private and isolated from production networks, corporate identity systems and the internet. Its purpose is to generate realistic telemetry from ESXi hosts, Linux and macOS targets and an egress path, so that sensors and the log pipeline can be tested end to end. Build it as a segmented network with its own sensors, not as a copy of production with monitoring bolted on.
- Segmented networks: Place targets, the simulated egress path and the monitoring network in separate zones, with explicit allow rules between them and no default route to production.
- Sensors: Deploy network sensors such as Zeek or Suricata at the egress boundary and host telemetry agents such as Wazuh agents on Linux and macOS targets, and confirm ESXi host logs reach the pipeline.
- Log pipeline: Confirm that Network Connection Creation, Process Creation and Network Traffic Flow events arrive with timestamps, host identifiers and enough fields for correlation.
- ESXi and Linux or macOS targets: Use disposable, snapshot-restorable hosts so the range can be reset between runs.
- Access control: Limit range administration to named people and record who can change the segmentation rules.
Before the first exercise, confirm with your own platform team that the range cannot reach production and that every sensor is writing to the pipeline.
Injects are the scripted events that the exercise team introduces to test detection. For T1048, describe each inject as an observable behavior, such as an unusual outbound protocol from a host that does not normally use it, or data leaving on a schedule. Do not write commands, scripts or payloads into the scenario sheet, and keep the executed activity in the hands of the range operators who are authorized to run it.
- Behavior-level injects: Write each inject as what a defender should see in telemetry, for example a new outbound session on an uncommon port, not as the steps used to produce it.
- Pacing: Space injects so that baseline activity, the first signal and the escalation each have time to be observed and recorded.
- Variations: Vary the sub-technique focus across runs, and include benign look-alike traffic so triage is tested as well as detection.
- Stop conditions: Define when the exercise halts, such as unexpected impact on range services or traffic that reaches an external address.
- Scenario ownership: Name one exercise lead who controls timing and one observer who records the timeline.
Ask your provider to show the scenario sheet and stop conditions before the exercise begins.
A rehearsal is only useful if the team can say whether it worked. Define success criteria before the exercise, and score each run against them. The goal is to measure how the detection and response process performs, not to assign blame for a missed signal.
- Alert timing: Record the time between each inject and the first alert, and compare it with the target your team agreed in advance.
- Triage accuracy: Check whether analysts classified benign look-alike traffic correctly and escalated true positives with the right context.
- Documented handoffs: Confirm that each escalation has a written record that names the owner, the affected hosts and the next action.
- Containment decisions: Note whether the decision to isolate a host or block an egress path was made within the response procedure, and by whom.
- Post-exercise review: Log gaps in sensors, rules and runbooks as tracked actions with owners and due dates.
For each target, ask whether the rule, the sensor or the people were the limiting factor, and track the answer.
Questions detection engineers ask about T1048
How do you detect T1048 when the egress traffic is encrypted?
Encryption hides payload content, so detection should lean on metadata rather than inspecting bytes. Network Traffic Flow records show which hosts talk to which destinations, on which ports, for how long and in what volume, and these fields remain visible under TLS. Pair them with Network Connection Creation events from endpoint telemetry to tie an unusual outbound session to the process that opened it. Where your architecture allows TLS inspection, Network Traffic Content adds visibility, but confirm the inspection point and its legal and privacy approval before relying on it.
How do you tell T1048 apart from T1567 or T1041 in alerts?
The difference is the channel and the destination pattern, so write rules that key on those properties rather than on a generic 'large upload' signal. T1048 covers transfers over a protocol other than the one the command channel uses, so alerts should flag non-standard protocol use on ports and services that a host does not normally use. T1567 concerns legitimate web services as the destination, and T1041 concerns reuse of an existing command and control channel. Tag each rule with its sub-technique so analysts see which pattern fired and can route it correctly.
How do you tune T1048 alerts for backup and replication traffic?
Backup and replication jobs produce large, sustained outbound transfers that look like exfiltration, so tuning should use an approved baseline of source host, destination, protocol and schedule. Maintain that inventory as a version-controlled allowlist with an owner and a review date, and scope each exception to a specific job rather than a whole subnet. Check that alerts still fire when a permitted host sends the same volume to an unapproved destination or outside the scheduled window. Test the tuning in your cyber range with replayed backup traffic before it reaches production.
How should we map T1048 detections to ATT&CK v20?
Name the ATT&CK version in every detection record, because releases can rename, deprecate or revoke techniques and sub-techniques. The current release line in these pages is Enterprise ATT&CK 20.0, and the machine-readable content is in the STIX 2.1 bundle published in the attack-stix-data repository. Pull the technique and sub-technique IDs from that bundle rather than from memory, and record the data components each analytic depends on, such as Process Creation and Network Traffic Flow. Recheck the mapping whenever a new release is published, starting with the ATT&CK updates page.
How do we confirm sub-technique coverage for T1048?
Treat each of the three sub-techniques as a separate test case with its own expected telemetry and alert. For each one, document the data sources, the analytic logic in plain language, the expected alert severity and the response step. Validate with a scripted exercise in a private cyber range, record whether the expected event was collected, normalized and matched, and keep the results with the rule version. Coverage claims should rest on these recorded results, not on the presence of a rule.
Which mitigations should we verify for T1048?
ATT&CK maps two mitigations most directly to this technique: Data Loss Prevention (M1057) and Network Intrusion Prevention (M1031). Confirm that DLP policies cover the egress protocols and destinations in your environment, including non-standard ports, and that network intrusion prevention rules are tuned rather than only in monitor mode. Ask your platform team to show the policy configuration and the blocked and allowed events from a recent test. Document any protocol you cannot inspect or block so the residual risk is owned and reviewed.
Can our own team run T1048 detection and validation without outside help?
Many teams can build and maintain these detections in-house, provided they have the telemetry, skills and time to test them. The work splits into collecting the right network and endpoint data, writing and tuning rules, building a repeatable validation exercise and keeping the mapping current. Ask whether your team already has Network Traffic Flow and endpoint process telemetry in one searchable store, and whether anyone owns rule testing. DeployOpen plans, implements and documents open-source detection stacks in your own infrastructure and runs cyber range exercises, and it can scope either a full build or a targeted review in writing.
How DeployOpen builds T1048 detections and range exercises
DeployOpen approaches T1048 Exfiltration over alternative protocol as a fixed-scope engagement inside the client's own infrastructure, starting from the written scope and the telemetry the client already collects. Detection logic is built on open-source tooling, validated in a private cyber range, and handed over with documentation the client's own team can run.
How we scope
- Confirm which T1048 sub-techniques and platforms apply to your estate, such as ESXi, IaaS, Linux and macOS.
- Inventory the existing Network Connection Creation, Process Creation and Network Traffic Flow telemetry and where it is stored.
- Agree the ATT&CK version the detection mappings will target before any rule work begins, in writing.
How we build
- Write detection logic in open-source formats such as Sigma rules, mapped to the relevant detection strategies and analytics.
- Deploy and tune collection with tools such as Wazuh, Zeek and Suricata inside your environment, against your own baseline traffic.
- Document data-source gaps and the Data Loss Prevention and Network Intrusion Prevention controls that support detection and blocking.
How we hand over
- Deliver rule documentation, test results and an exercise runbook for the private cyber range rehearsal of T1048 activity.
- Walk your security engineers through triage steps, escalation paths and how each alert is validated against the range.
- Provide evidence packs that show controls and detections are in place, for use with your independent auditor or assessor.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial delivery.
- Review detection mappings when ATT&CK releases rename, deprecate or revoke techniques, so your coverage stays current.
- Ask for a written quote tied to the agreed scope, which sets out one-time build effort and any recurring support costs.
