How T1496 resource hijacking turns your compute against you
A SOC lead usually first hears about T1496 Resource Hijacking as a finance or platform problem: CPU or GPU utilization climbs without a matching increase in business load, cloud invoices spike, and batch jobs or customer-facing services slow down for no obvious reason. T1496 describes an adversary using your compute, memory, or network capacity for its own purposes, such as mining cryptocurrency or running other resource-heavy workloads, and it sits under the Impact tactic (TA0040). In intrusions it often appears after an attacker already has access to a workload, a container, a virtual machine, or a cloud account, and it is frequently the most visible sign of that access because the attacker is monetizing your environment rather than hiding in it.
This page targets Enterprise ATT&CK version 20.0, and T1496 has four sub-techniques, so detection work should be scoped to those variants rather than to the parent technique alone. Because ATT&CK releases can rename, deprecate, or revoke techniques, the mapping you build should record the version it was written against. Confirm with your own threat intelligence and ATT&CK update notes which sub-techniques matter most for your platforms, since a Linux container fleet, a Windows estate, and an IaaS account will produce different telemetry and different baselines. Ask whether your current logging captures process creation and network traffic content on the workloads where GPU or CPU spikes would appear, because without that, the resource anomaly becomes a billing question instead of a security investigation.
The decision to make now is whether a resource anomaly triggers an incident or only a cost review. Agree in advance who owns the response, how compute spend and utilization alerts route to the SOC, and which workloads can be paused or isolated without breaking revenue-critical services. Treat unexplained sustained utilization on a workload that should be idle as a hypothesis to test, not as normal capacity growth, and record the baseline that makes that call defensible.
Which telemetry reveals resource hijacking and which open-source tool collects it
This table maps the data components most often tied to T1496 Resource Hijacking (Process Creation DC0032, Application Log Content DC0038 and Network Traffic Content DC0085) to the signal to watch for on each platform and the open-source collector that gathers it. Read each row as a question: what evidence would appear, and which agent or sensor would capture it. The main takeaway is that no single data component covers every platform, so confirm collection coverage for each host and cloud account before relying on a detection.
| Telemetry source | Signal to look for | Open-source collector |
|---|---|---|
| Process Creation (DC0032) on Windows | Unfamiliar miner-like executables or scripts starting under user or service accounts, especially with sustained high CPU use | Wazuh agent with Sysmon process events forwarded to Wazuh or Security Onion |
| Process Creation (DC0032) on Linux and macOS | Unexpected binaries or interpreters launched from temporary, hidden or user-writable directories, often as long-running processes | Wazuh agent or Velociraptor artifact collection on endpoints |
| Application Log Content (DC0038) on IaaS | Cloud audit records showing new compute instances, large instance sizes or regions the workload never used | Cloud audit logs forwarded to Wazuh or Security Onion |
| Application Log Content (DC0038) on Windows and Linux | Service logs showing unexpected scheduled tasks, cron entries or services created for a workload that should not run them | Wazuh log collection from endpoints and servers |
| Network Traffic Content (DC0085) | Outbound connections to mining pool endpoints or unusual proxy traffic on well-known pool ports, including long-lived sessions | Zeek connection and protocol logs, with Suricata rules for known pool protocols |
| Network Traffic Content (DC0085) for cloud workloads | Sustained egress from virtual machines or containers that normally serve only internal requests | Zeek sensors on cloud mirror or flow feeds, cross-checked with cloud flow logs |
| Host performance context | Sustained CPU or GPU saturation on hosts with no matching business job or change record | Wazuh agent metrics and Velociraptor collection on demand |
| Coverage check | Hosts or accounts missing from any of the above sources, which creates blind spots for hijacking | Confirm agent inventory and sensor placement with the operations team before the exercise |
Detection logic for resource hijacking that holds up in production
Resource hijacking is hard to alert on because the abnormal behavior often looks like legitimate compute work. The cards below pair each signal with the baseline, thresholds and benign sources that decide whether it stays useful after deployment. Tune every idea against your own host inventory and workload calendar before it pages anyone.
Sustained utilization by unexpected processes
Alert when a process that is not part of a host's expected workload holds high CPU or GPU use for longer than its normal peak window. Build the baseline per host group using process names, parent process, user context and hours of day, not a single global threshold. Expect false positives from build farms, rendering queues, video encoding and scheduled batch jobs, so maintain an allowlist tied to named change records. Check whether the process is signed, located in a user-writable path and launched by an interactive or service account that should not run compute.
New long-lived processes on idle hosts
Flag new processes that persist for hours on hosts with no compute role, such as domain controllers, file servers, database servers or jump hosts. Process Creation events joined with the host's asset role make this rule precise, because a long-lived compute process on a non-compute host is rare. Tune the duration threshold against your patch and maintenance windows, since agents and updaters can look similar. Confirm that the role inventory is current, because a stale CMDB will turn this idea into noise.
Mining-pool-like outbound connections
Review outbound network traffic for long-lived connections to destinations with stratum-like request patterns, repeated small messages over non-standard ports and unusual DNS lookups from servers that normally only call update hosts. Network Traffic Content and flow data from Zeek or Suricata can show these patterns without decrypting payloads. Set destination allowlists and egress rules first, because a short domain or port list is often the fastest way to cut false positives. Benign sources include blockchain node operators and licensed monitoring tools, so confirm those cases with the business owner before alerting.
Cloud instance launches outside normal patterns
Alert on compute instance launches that fall outside approved images, regions, instance families or change tickets, particularly when a new instance is created with a high-core or GPU type. Use the cloud control plane audit log as the primary source and join it with identity context to show which principal launched the instance. Build the baseline per account and team, since autoscaling, CI runners and data science notebooks can launch large instances legitimately. Review whether service quotas and budget alerts also exist so that a launch that bypasses one control is still visible to another.
How to validate that your T1496 detections fire
This sequence proves that your T1496 Resource Hijacking detections fire on a test host, reach the SIEM and do so within a known time, using a benign resource-consumption stand-in inside an authorized lab or cyber range. The output is a recorded validation result that ties each rule version to its alert timing and false positive rate.
Agree scope and authorization in writing
The security lead, the system owner and the SOC manager agree in writing which hosts, accounts, network segments and time window the test covers, and who can stop it. Any emulation must be authorized and contained, so the agreement also names the rollback path and the person who can halt the run at any time. Done means a signed scope document is filed with the change record and every participant knows the stop condition.
Build an isolated test host and baseline
Platform engineering provisions a dedicated test host for Windows, Linux or macOS, depending on which platforms your T1496 detections cover, in a segment with no route to production data. The team confirms the host is forwarding telemetry for Process Creation and the other data components your rules use, and captures a baseline of normal CPU and process activity. Done means the host appears in the SIEM and the baseline is saved so later results can be compared against it.
Select a benign resource-consumption stand-in
The detection engineer chooses a harmless workload that produces sustained, measurable resource use, such as a vendor-approved load generator or a purpose-built test binary that the team has reviewed. The choice is documented with its source, hash and expected resource profile, and it is kept out of production images. Done means the stand-in has been reviewed by a second person and its expected telemetry is written down before the run starts.
Run the stand-in under observation
The red team or detection engineer runs the agreed stand-in on the test host for the window in the scope document, while the SOC watches the console and the observer records start and stop times. The run is contained by network restrictions and a kill switch that the system owner can trigger. Done means the run log shows the start time, the stop time and any deviation from the plan.
Confirm alerts reach the SIEM
The detection engineer searches the SIEM for the events the run should have produced, checking that the Process Creation records and any Application Log Content or Network Traffic Content inputs arrived intact and with correct timestamps. Missing fields, dropped agents or delayed forwarding are logged as findings rather than hidden. Done means each expected alert is either present in the SIEM with its source event linked or recorded as a gap with a root cause.
Record time to alert and rule version
For each fired alert, the team records the time from the first event on the test host to the alert in the queue, the rule identifier and version, and the ATT&CK version the mapping targets. Because releases can rename or deprecate techniques, the record names the ATT&CK version used. Done means a results table exists with one row per rule, containing time to alert, rule version and ATT&CK version.
Measure false positives against the baseline
The SOC reviews every alert raised during the run and the baseline period on the same host, classifies each as true positive, benign or false positive, and calculates the false positive rate for each rule. The engineer tunes conditions only through a change record, then reruns the stand-in. Done means the false positive rate for each rule is written down with the classification notes and the tuning decision.
Close the loop with a signed validation report
The detection lead compiles the results, scope, stand-in details, timings, rule versions and false positive figures into a validation report, then the CISO or delegate signs off on any open gaps and their owners. The report feeds the next purple team review and the compliance evidence file, without being presented as an audit result. Done means the report is stored with the detection repository and each gap has an owner and a retest date.
Preventive controls that limit resource hijacking
Resource hijacking succeeds when an adversary can place and run its own workload on compute the organization pays for, and when that workload can reach the outside world. The five ATT&CK mitigations below work at different points in that chain: who can change what runs, where it can reach, and how people spot the first signs of misuse. Each card names what to confirm in your own environment before you rely on it.
Restrict file and directory permissions
Restrict File and Directory Permissions (M1022) limits which accounts can write to or execute from directories used by services, scheduled jobs and build agents. Miners and similar payloads usually need a writable location to land and a path to launch from, so tight write rights on those locations make the first step harder. Confirm that application install paths, cron or task scheduler directories and CI runner workspaces are not writable by ordinary users, and that changes to them are logged so unexpected binaries stand out.
Manage user accounts and privileges
User Account Management (M1018) covers how accounts are created, granted rights and removed. An attacker who holds a low-privilege credential often tries to gain rights that let it start processes across hosts or change cloud compute quotas. Review which accounts can create virtual machines, containers or GPU instances, remove standing administrator rights where a just-in-time process will do, and disable unused service accounts. Confirm that these reviews happen on a schedule and that the owner of each account is named.
Segment networks around workloads
Network Segmentation (M1030) decides which systems can talk to each other and to the internet. Cryptomining and botnet payloads depend on reaching mining pools or command infrastructure, so workloads that have no business reaching the internet should not be able to. Place build runners, batch clusters and GPU nodes in segments with explicit egress rules, and confirm which destinations each segment may reach. Document the exceptions and who approved them.
Filter network traffic at egress
Filter Network Traffic (M1037) applies allow and deny rules at firewalls, proxies and cloud security groups. Egress filtering is the control that most directly limits resource hijacking, because a mining client that cannot reach its pool produces little value. Allow outbound traffic only to required services, block known mining protocols and unapproved DNS resolvers, and record denied connections. Confirm that the rule set is tested after every change to cloud network configuration.
Train staff on suspicious workloads
User Training (M1017) prepares engineers and operations staff to recognize the common signs of misuse. Many hijacking cases start with a phishing email, a pasted install script or a pull request that adds an unexpected dependency. Teach staff to report unexpected compute charges, sudden CPU saturation on hosts, and unfamiliar scheduled jobs. Confirm that the reporting path is written down, that it reaches a team able to act on it, and that the training is repeated for new joiners.
Triage steps when a resource hijacking alert fires
Start by establishing who started the workload and what launched it. When a resource hijacking alert fires on a Linux host, a Windows server or an IaaS instance, the first decision is whether the process is a miner or similar consumer of compute, and whether anyone sanctioned it. Pull the process creation event (or the auditd or Sysmon equivalent in your environment) and record the process owner, the full parent chain, the start time and the working directory. Then check your change records, configuration management and container orchestrator for a matching deployment. Confirm with the application owner before concluding the workload is unauthorized, because build agents, data jobs and scheduled analytics can look identical to hijacked compute at first glance. Record the answers in the case ticket before you change anything, so the evidence trail stays intact.
Isolate the affected host or instance, and preserve evidence before you clean it. Contain by restricting network egress to the minimum your operations team needs, or by removing the instance from its load balancer or autoscaling group, rather than deleting it. Use Velociraptor to collect a triage package from the endpoint: running processes, network connections, scheduled tasks or cron entries, and a memory capture if your agreed procedure allows it. For cloud workloads, export the provider's audit trail (for example, the control plane activity and compute instance events covering the alert window) and store it in write-once storage. Confirm the retention period of those logs with your provider, since the window to recover them may be shorter than your incident timeline. Snapshot disks before any remediation so you can later show what was running.
Rotate exposed credentials and review related alerts for lateral movement. Resource hijacking often follows a credential compromise, so treat the instance role, service account keys, SSH keys and any secrets readable from the host as exposed until proven otherwise. Rotate them in an order that does not break recovery, and review the identity provider and cloud audit logs for logins or token issuance from unfamiliar sources during the same period. Search your SIEM or Wazuh alert history for other hosts that showed the same process name, hash, destination or container image, and for lateral authentication from the affected host. Decide, with your incident commander, whether the scope expands beyond one workload before you close the alert, and document the reason for that decision.
Rehearsing T1496 detection and response in a private cyber range
Build the range with a small set of Windows and Linux endpoints enrolled in your SIEM, with process creation auditing and command-line logging enabled and forwarded to Wazuh or your chosen platform. Keep the hosts isolated from production networks and seed them with a standard software baseline so benign activity has a realistic shape without touching live data. Run three injects: a benign consumption inject that drives sustained CPU use from a sanctioned workload, an unexpected outbound traffic inject that uses a lab-only destination, and a cloud launch inject that is covered in the IaaS tab.
- Benign baseline: Record normal CPU and process profiles for at least one full business cycle so the team knows what legitimate load looks like.
- Consumption inject: Start a sanctioned, labeled workload and confirm that the alert fires on sustained utilization and an unknown process name, not just on load averages.
- Outbound inject: Trigger connections from an unexpected process to a lab destination and check that process-to-network correlation appears in the case.
- Checkpoints: The facilitator records time to first alert, time to triage decision, time to host containment, and time to confirmed cleanup, each as a timestamp in the exercise log.
- Evidence: Confirm that process lineage, user context and parent process are present in the alert without manual queries.
Check that every checkpoint has a timestamp and that the team can name the owner of each decision.
Build a sandbox cloud account or project with its own identity boundary, budget guardrails set by the account owner, and audit logging for control plane activity routed to your monitoring stack. Use only resources you can stop at once, and never point the exercise at a production tenant. The inject here is a cloud launch: an unauthorized compute instance or service is created under a lab identity, and the team must detect the creation and the abnormal usage pattern that follows.
- Range build: Enable control plane audit logs and confirm that creation events reach the monitoring platform with the caller identity intact.
- Launch inject: A lab identity creates a compute resource outside the approved template list, then runs a sustained workload on it.
- Detection goal: Alert on resource creation outside approved images or regions and on usage that does not match the owner's declared workload.
- Checkpoints: Record time from creation event to alert, time to identity suspension, time to resource termination, and time to billing anomaly review.
- Verification: Confirm that the team can tie the resource back to the identity and the change record without vendor support.
Confirm with your cloud provider which audit events are retained by default and for how long, because retention varies by service and plan.
Place a monitored segment between the lab hosts and the range's simulated internet, with Zeek producing connection and protocol logs and Suricata raising signature and anomaly alerts. Mirror traffic from the segment to the sensors and confirm that both tools see the same flows before the exercise starts. The inject is unexpected outbound traffic to a lab destination that mimics a mining pool endpoint, using a benign placeholder so no real pool is contacted.
- Sensor check: Verify that Zeek connection logs and Suricata alerts reference the same source host and time window during a test flow.
- Outbound inject: Generate a long-lived, low-volume connection to a lab-controlled destination and observe whether Zeek logs the session duration and byte counts.
- Detection goal: Flag persistent outbound sessions to destinations outside the approved list, and correlate them with a host alert from the endpoint tab.
- Checkpoints: Record time from first flow to sensor alert, time to analyst correlation with a host, and time to a firewall block decision.
- Response test: Practice a segment-level block and confirm that the change is logged and reversible.
Confirm your sensor rule sources and their update cadence with the vendor or community maintainers before you rely on them in the exercise.
Questions SOC leads and detection engineers ask about T1496
How do I separate legitimate high CPU use from resource hijacking?
Start from the process, not the CPU graph. Hijacking usually shows a process that is unexpected for the host's role, running from an unusual path, launched by a parent that should not start compute work, or reaching out to network destinations the workload has never used. Build a baseline per host group (build servers, batch nodes, database hosts) covering normal CPU, process names, parent-child relationships and outbound destinations over a representative period. Then alert on deviations that combine two or more signals, such as an unknown binary with sustained high CPU and new outbound connections. A single CPU spike on a known batch job should rarely page anyone.
How should GPU workloads be handled in resource hijacking rules?
Treat GPU utilization as a separate baseline, because CPU-only rules will miss compute abuse on GPU hosts and generic GPU rules will flood on legitimate training and inference jobs. Inventory which hosts run GPU workloads, which service accounts and container images start them, and which processes are approved. Alert on GPU use from hosts or accounts outside that inventory, on new container images appearing on GPU nodes, and on GPU load that persists outside approved scheduling windows. Confirm with your vendor and telemetry source which GPU metrics your agents can collect, since the available fields differ by driver and collection method.
What should we do when an ATT&CK version change renames our mappings?
Pin every detection to the ATT&CK version it was written against, and record that version in the rule metadata. When a new release arrives, diff the technique and sub-technique IDs for T1496 and its neighbours in the STIX bundle for the new version, then check the detection strategy and data component references. ATT&CK v18 replaced technique-level detections with detection strategies and analytics and changed data components, so mappings written for older versions need review. Update the mapping table, retest the rules in the cyber range, and log the change in your detection-as-code repository so auditors can trace it.
How do we write Sigma rules for Windows, Linux, macOS and cloud platforms?
Write one Sigma rule per log source and behavior, not one rule for all platforms. For Windows, the rule logic usually relies on Process Creation events, with fields for image path, command line context, parent process and user. For Linux and macOS, use the process telemetry your agent collects and keep the field names in the rule matched to the converter you use. For IaaS and SaaS, rely on Application Log Content, such as cloud audit and API logs that show new compute resources or unexpected instance launches. Keep allowlists in separate, reviewed files, and validate each rule with a replay of recorded benign and simulated events before deployment.
Which logs should we retain, and for how long, to confirm a hijacking incident?
Retain the telemetry that lets you reconstruct process lineage, network destinations and account activity around the time of the alert. At minimum, keep process creation records, network connection records, cloud control plane and audit logs, and authentication events for the hosts in scope. Retention periods depend on your regulatory obligations, internal policy and storage budget, so confirm them with your compliance lead and legal team rather than adopting a default. Also confirm that log timestamps are synchronized across sources, because incident timelines fall apart when clocks disagree. Test retrieval periodically, since logs that exist but cannot be searched quickly do not help during an incident.
How do we tune resource hijacking alerts without blinding the SOC?
Tune by adding context, not by suppressing broad categories. Use allowlists scoped to a specific host group, parent process, signed binary and destination, and give each exception an owner and an expiry date. Track alert volume and the percentage of alerts that lead to real investigations, and review rules that stay noisy for weeks. Keep a small set of high-confidence rules that always page, and route lower-confidence rules to a review queue. Every tuning change should be replayed in the cyber range first, so you can show that a known hijacking scenario still fires after the change.
Can our own team run this detection program, or do we need outside help?
Many teams can run it in-house if they already operate a SIEM, collect endpoint and cloud telemetry, and have engineers who can maintain detection-as-code. The work that tends to stretch internal teams is building per-platform baselines, validating rules against realistic benign workloads, and rehearsing response. DeployOpen implements, hardens and documents self-hosted open-source platforms inside your environment, runs security testing, and operates private cyber ranges for detection exercises. Engagements are fixed-scope, with deliverables agreed in writing before work starts, and a quote follows from that written scope.
Official ATT&CK sources for T1496 and the Impact tactic
Start every T1496 detection design from the primary MITRE sources, not from secondary summaries. The Impact tactic page (TA0040) defines the goal of the tactic as manipulating, interrupting or destroying systems and data, and it is where the technique and its sub-techniques are listed in context with the other Impact techniques your detection program may already cover. Read it alongside the technique page for T1496 so that the scope of your rules matches what MITRE actually describes, including the four sub-techniques that cover different resource types. Record the page version you read in your detection documentation so the next reviewer can see what the rule was based on.
Pin every mapping to a named ATT&CK version. The ATT&CK updates page lists each release, and the release notes describe changes such as renamed, deprecated or revoked techniques and the move from detections on technique pages to detection strategies and analytics. Use the Enterprise v20.0 STIX bundle from the attack-stix-data repository as the machine-readable reference, and check the data component and sub-technique identifiers for T1496 against that bundle before you write or import any rule. Confirm with your own tooling team which ATT&CK version your SIEM content pack, Sigma rules and Wazuh mappings currently target, because a mismatch between the rule and the matrix is a common cause of silent coverage gaps during audits.
Schedule a review each time MITRE publishes a release, and assign an owner for the comparison. The owner should check whether T1496 or its sub-techniques changed, whether the data components used by your analytics still exist, and whether the mitigations you cite still map to the technique. Keep the diff with the rule history so that an assessor can trace a coverage claim back to a specific ATT&CK version and a specific date of review.
How DeployOpen builds T1496 detections and range scenarios
DeployOpen approaches T1496 Resource hijacking as a written, fixed-scope engagement inside your own environment. We map the detection to the ATT&CK version you run, build it on open-source tooling you can operate, and rehearse it in a private cyber range before it reaches production.
How we scope
- Confirm which platforms are in scope for T1496, such as Windows, Linux, macOS, IaaS and containers.
- Identify which telemetry sources exist today, including process creation, application logs and network traffic content.
- Agree the ATT&CK version to target, since releases can rename or revoke techniques, and record it in the written scope.
How we build
- Write detection logic for T1496 and its four sub-techniques in plain language, mapped to the relevant data components.
- Deploy and tune open-source components such as Wazuh, Zeek, Suricata or Sigma rules inside your infrastructure.
- Document known false positives, such as legitimate batch compute or build workloads, and the tuning applied to each.
How we hand over
- Deliver detection documentation covering data sources, logic, thresholds, validation results and response steps.
- Run a rehearsal in a private cyber range so your analysts can see the alert, triage it and close it.
- Provide the written evidence set that your internal team or external auditors may review later.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Re-validate detections when ATT&CK releases change T1496 mappings or your platform versions change.
- Ask for a written quote based on the agreed scope, since DeployOpen does not publish a price list.
