AN1226: Analytic 1226
Detects suspicious curl, wget, or custom socket traffic that leverages DNS, HTTPS, or IRC-style protocols with unbalanced traffic or beacon-like intervals.
Analyst context for executives and security teams
This analytic matters because it focuses on suspicious Linux network behavior from common transfer tools such as curl and wget, or custom socket traffic, where DNS, HTTPS, or IRC-style communications show unbalanced volumes or beacon-like timing. For leaders, the decision value is not the tool name alone: curl and wget are common in normal administration, so coverage depends on whether the organization can distinguish routine Linux automation from command-and-control-like or unauthorized outbound communication patterns.
Executive priority
Prioritize this as a validation item for Linux monitoring and egress visibility. It can support incident response readiness and compliance evidence by showing whether the SOC can observe suspicious outbound patterns from Linux systems, especially where business-critical servers rely on automated scripts that may otherwise blend with malicious-looking activity. Because ATT&CK provides no tactic mapping, relationship context, or detection logic here, leaders should treat it as a coverage hypothesis to test rather than a proven control.
Technical view
SOC and detection teams should validate visibility into Linux process execution and outbound network activity involving curl, wget, and custom socket-based clients. The key analytic concept is behavioral: DNS, HTTPS, or IRC-style traffic with uneven request/response patterns or repeated beacon-like intervals. Detection engineering should baseline expected administrative, patching, monitoring, and application traffic before alerting on timing or volume anomalies. Incident responders should be prepared to correlate suspicious outbound patterns with process lineage, command-line context, user/account context, destination reputation, and host role.
Likely telemetry
- Linux process creation events, including executable name and command-line arguments
- Network connection telemetry from Linux hosts, including destination, port, protocol, byte counts, and timing
- DNS query logs or resolver telemetry associated with Linux workloads
- HTTPS metadata such as destination host, SNI where available, certificate context, and connection timing
- Proxy, firewall, or egress gateway logs showing outbound volume asymmetry and periodicity
Detection direction
- Confirm that Linux hosts actually produce process-to-network correlation; network-only telemetry may identify beacon-like intervals but may not identify the responsible tool or process.
- Tune separately for common administrative uses of curl and wget, such as package retrieval, health checks, CI/CD jobs, backups, and monitoring scripts, to reduce false positives.
- Look for repeated outbound communications with consistent intervals, unusual destinations, or unbalanced byte patterns over DNS, HTTPS, or IRC-style protocols.
- Review blind spots around encrypted HTTPS visibility, NAT or shared egress points, short-lived containers, and Linux systems not covered by EDR or centralized logging.
- Because no official detection logic is supplied, test candidate analytics against local baselines before using them for high-severity alerting.
Mitigation priorities
- Establish and document expected Linux egress paths for servers, workloads, and administrative automation.
- Restrict unnecessary outbound access where operationally feasible, especially from sensitive Linux servers.
- Maintain centralized logging for Linux process execution, DNS, proxy, firewall, and egress telemetry to support investigation.
- Use allowlisting or approved automation patterns for recurring curl and wget activity where appropriate.
- Create incident response playbooks for suspicious Linux outbound traffic that include process lineage review, destination analysis, credential/account review, and containment decision points.
Analyst notes and limits
This Glexia take is based only on the supplied ATT&CK analytic fields. The object is a detection analytic for Linux and describes suspicious curl, wget, or custom socket traffic using DNS, HTTPS, or IRC-style protocols with unbalanced traffic or beacon-like intervals. No related techniques, tactics, campaigns, software, groups, or mitigations were supplied, so the guidance is framed as defensive validation rather than attribution or confirmed threat behavior.
Official detection content is not provided, tactics are not specified, and no relationship context is supplied. The analytic cannot by itself establish maliciousness because curl, wget, DNS, and HTTPS are common in legitimate Linux operations. Local baselining, telemetry quality, and process-to-network correlation are required to determine practical coverage and alert fidelity.
Analytic 1226
Detects suspicious curl, wget, or custom socket traffic that leverages DNS, HTTPS, or IRC-style protocols with unbalanced traffic or beacon-like intervals.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 933f76c826d6… |
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 AN1226Open 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.