DET0028: Detect Excessive or Unauthorized Bandwidth Usage for Botnet, Proxyjacking, or Scanning Purposes
MITRE ATT&CK DET0028: Detect Excessive or Unauthorized Bandwidth Usage for Botnet, Proxyjacking, or Scanning Purposes Detection Strategy details, with detection…
Security context for executives and security teams
This detection strategy matters because unusual or unauthorized bandwidth consumption can be an early business-impact signal: a system or cloud resource may be co-opted for bandwidth hijacking, botnet activity, proxyjacking, or scanning. Even when data theft is not the primary issue, excessive network use can degrade hosted services, raise cloud or network costs, and create incident-response urgency around availability and misuse of enterprise resources.
Executive priority
Treat this as an operational resilience and cost-control question as much as a security alerting question. Leaders should ask whether the organization can quickly identify which endpoint, server, or IaaS asset is consuming abnormal bandwidth, who owns it, whether the usage is authorized, and whether evidence is sufficient for incident response, compliance review, or cloud cost investigation. Priority is highest for internet-facing services, shared infrastructure, and environments where unexpected bandwidth spikes could affect availability.
Technical view
ATT&CK provides this as a detection strategy for T1496.002 Bandwidth Hijacking, an Impact technique associated with Linux, Windows, macOS, and IaaS in the related technique context. Because the detection strategy itself has no official detection text, teams should validate coverage by correlating network volume anomalies with asset identity, process or workload ownership where available, destination patterns, and expected baselines. SOC and IR teams should be able to distinguish approved high-bandwidth business activity from suspicious sustained outbound traffic, scanning-like connection patterns, or resource use inconsistent with the asset’s role.
Likely telemetry
- Network flow records or equivalent traffic volume summaries
- Firewall, proxy, secure web gateway, or egress control logs
- Cloud/IaaS network usage and billing or metering data
- Endpoint or server telemetry that can link network usage to a host, user, process, service, or workload
- DNS and destination reputation/context logs where available
Detection direction
- Establish normal bandwidth baselines by asset role, network segment, workload, and time of day before alerting on volume alone.
- Tune for sustained or recurring excessive outbound bandwidth, unusual destination diversity, or traffic inconsistent with the system’s business function.
- Correlate bandwidth anomalies with IaaS usage data to catch cost-impacting abuse that may not be obvious in endpoint-only telemetry.
- Include false-positive handling for backups, software distribution, media transfer, vulnerability scanning, data replication, and other legitimate high-volume activity.
- Validate that alerts identify the accountable asset owner and provide enough context for triage; bandwidth alerts without ownership often stall incident response.
Mitigation priorities
- Confirm egress visibility and retention first; without network and cloud usage evidence, this behavior is difficult to investigate after the fact.
- Maintain accurate asset inventory, workload ownership, and expected-use profiles so abnormal bandwidth can be judged quickly.
- Apply least-privilege network egress controls and segmentation appropriate to business function, especially for servers and cloud workloads that do not need broad outbound access.
- Use cloud cost and usage monitoring alongside security monitoring for IaaS environments where bandwidth abuse can create financial and availability impact.
- Prepare IR playbooks for isolating or throttling suspected co-opted systems while preserving evidence needed to determine authorization and scope.
Additional notes and limits
The source object is a detection strategy with no official description, no official detection text, and no platforms or tactics directly assigned. The practical interpretation comes from its name and its relationship to T1496.002 Bandwidth Hijacking, whose related context identifies Impact and platforms including Linux, Windows, macOS, and IaaS. Local baselines and asset context are essential to make this detection actionable.
This take does not assert active exploitation, specific adversary attribution, guaranteed detection logic, or vendor-specific controls. ATT&CK-supplied detail for DET0028 is sparse, so organizations must validate telemetry availability, thresholds, and response procedures against their own environments.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Detect Excessive or Unauthorized Bandwidth Usage for Botnet, Proxyjacking, or Scanning Purposes
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1496.002 | Bandwidth HijackingSub-technique | This object detects Bandwidth Hijacking. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Imported snapshots across ATT&CK releases(1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 95fd72635326… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
- [1]mitre-attackDET0028Open source URL
- [2]mitre-attackDET0028Open source URL
- [3]mitre-attackDET0028Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.