DET0883: Detection of Botnet
DET0883 is a MITRE ATT&CK detection strategy for identifying adversary botnet resource development. The key business issue is not a specific endpoint or cl...
Analyst context for executives and security teams
DET0883 is a MITRE ATT&CK detection strategy for identifying adversary botnet resource development. The key business issue is not a specific endpoint or cloud platform alert; it is whether the organization can recognize when external compromised infrastructure is being prepared or used as part of targeting. Because the related ATT&CK technique is pre-compromise resource development, this is most useful for threat intelligence, SOC enrichment, incident scoping, and executive early-warning decisions rather than only traditional host-based detection.
Executive priority
Treat this as a readiness question: can the security program distinguish routine internet noise from coordinated botnet-enabled activity that may precede or support attacks? Leaders should ask whether threat intelligence, managed detection, incident response, and network monitoring processes can preserve evidence, correlate indicators over time, and escalate credible botnet-related activity before it becomes an operational incident. Since ATT&CK provides no official detection text or platform scope for this object, priority should be on validating local visibility and decision workflows rather than assuming a predefined control fully covers it.
Technical view
The ATT&CK relationship ties this detection strategy to T1584.005 Botnet under Resource Development on the PRE platform. SOC and detection teams should validate how they identify infrastructure patterns consistent with botnet activity, how those observations are enriched, and how they are connected to cases involving scanning, credential attacks, denial-of-service preparation, spam, proxying, or other suspicious external coordination when locally observed. Because the detection strategy object has no official detection logic, teams should avoid overfitting to a single signature and instead test whether telemetry correlation, threat intelligence context, and incident documentation can support confident triage.
Likely telemetry
- Network security logs showing inbound or outbound connections, source distribution, volume, timing, and protocol context
- DNS resolver and passive DNS evidence for suspicious domains, fast-changing infrastructure, or repeated lookups tied to known suspicious infrastructure
- Proxy, web gateway, firewall, and IDS/IPS events that preserve external IPs, user agents, ports, and request metadata
- Threat intelligence observations and blocklist hits, including confidence, source, age, and context of indicators
- SIEM case history showing repeated, distributed, or coordinated activity over time
Detection direction
- Validate that detections are based on correlated behavior and context, not only single IP reputation hits, because botnet nodes can be transient, shared, or misclassified.
- Tune for distributed and repeated activity patterns across time windows, while accounting for legitimate high-volume services, vulnerability scanners, CDNs, VPNs, and security testing that can resemble coordinated external activity.
- Confirm that threat intelligence indicator matches include source, confidence, expiration, and rationale so analysts can separate actionable botnet context from stale reputation data.
- Use the relationship to T1584.005 to frame detection as pre-compromise or preparatory adversary infrastructure where appropriate, and avoid treating every botnet-linked observation as proof of compromise inside the environment.
- Ensure alert workflows preserve enough metadata for incident responders to determine whether the activity was blocked, merely observed, or associated with an affected internal asset.
Mitigation priorities
- Establish baseline visibility first: network, DNS, proxy, firewall, IDS/IPS, and threat intelligence data should be available for correlation and retrospective review.
- Define triage criteria for botnet-related observations, including when to escalate to incident response, when to block infrastructure, and when to monitor for follow-on behavior.
- Maintain indicator lifecycle controls so stale botnet infrastructure does not create excessive false positives or unnecessary blocking decisions.
- Harden exposed services and identity entry points that may be targeted by distributed infrastructure, prioritizing controls based on observed activity and business criticality.
- Document detection assumptions and evidence for audit and compliance readiness, especially where botnet-related monitoring supports incident response, resilience, or threat intelligence requirements.
Analyst notes and limits
The supplied ATT&CK object is a detection strategy with no official description, no official detection text, and no specified platforms or tactics. The only substantive context is the relationship to T1584.005 Botnet, a Resource Development technique on PRE. This means the most defensible Glexia interpretation is to focus on defensive validation, telemetry readiness, enrichment, and triage governance rather than a specific analytic rule.
This take is constrained to the supplied ATT&CK fields and relationship context. It does not assert active exploitation, adversary attribution, specific affected products, guaranteed detection coverage, or platform-specific implementation. Local environment data is required to determine actual exposure, alert quality, and response priority.
Detection of Botnet
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.
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 | ec2a029116a8… |
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-attack DET0883Open 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.