AN1382: Analytic 1382
Detects GCC or Clang invoked on suspicious file paths (e.g., /tmp/, ~/Downloads) with output to executable binaries, followed by execution or outbound traffic from these binaries.
Analyst context for executives and security teams
This analytic matters because it looks for Linux systems compiling code from user-writable or download-oriented locations, then running the resulting binary or making outbound connections. For leaders, the practical value is not the compiler itself—GCC and Clang are legitimate—but whether the organization can distinguish normal development activity from suspicious local build-and-run behavior on servers, workstations, or other Linux assets.
Executive priority
Prioritize this as a coverage-validation item for Linux environments where compilers are present outside expected development workflows. It can inform decisions about endpoint telemetry, egress visibility, software build governance, and incident response readiness. The key business question is: do we know where compiling is expected, and can the SOC prove when compilation from temporary or download paths leads to execution or network activity?
Technical view
Validate monitoring for Linux processes where gcc or clang are invoked from suspicious paths such as /tmp/ or ~/Downloads, produce executable outputs, and are followed by execution of those outputs or outbound traffic from them. Because no ATT&CK tactic or detailed detection logic is supplied, teams should treat this as an analytic pattern to implement and tune against local baselines rather than a complete rule. Focus on correlation across process creation, file creation/permissions, execution, and network telemetry.
Likely telemetry
- Linux process creation events including command line, parent process, user, working directory, and executable path
- File creation or modification events for compiler outputs, especially in temporary or download directories
- File permission or executable-bit changes where available
- Execution events for newly created binaries
- Outbound network connection telemetry tied to the resulting binary/process
Detection direction
- Baseline legitimate GCC and Clang use by host role, user, path, and build workflow before alerting broadly.
- Correlate compiler invocation from suspicious paths with creation of executable binaries and subsequent execution or outbound traffic.
- Treat compiler use alone as insufficient; reduce false positives by requiring suspicious path context and post-compilation behavior.
- Watch for blind spots where endpoint telemetry lacks full command lines, file lineage, or process-to-network attribution.
- Separate developer workstations and build systems from production Linux systems to tune severity and reduce noise.
Mitigation priorities
- Inventory where GCC and Clang are installed and whether they are required on each Linux asset class.
- Restrict or remove compilers from systems where local compilation is not operationally necessary.
- Apply least-privilege controls around writeable directories and execution from temporary or download locations where feasible.
- Ensure outbound network monitoring can attribute connections to Linux processes.
- Document expected compiler usage as compliance and SOC tuning evidence.
Analyst notes and limits
The supplied object is a detection analytic for Linux only. It provides a high-level behavioral description but no formal detection logic, no tactic mapping, and no relationship context. Use it as a validation prompt for telemetry and correlation maturity rather than as a standalone detection rule.
Official detection content is not provided, and no relationships, tactics, threat groups, campaigns, software, or mitigations are supplied. Local asset roles, developer workflows, and telemetry availability are required to determine relevance, severity, and false-positive handling.
Analytic 1382
Detects GCC or Clang invoked on suspicious file paths (e.g., /tmp/, ~/Downloads) with output to executable binaries, followed by execution or outbound traffic from these binaries.
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 | 6aebcb683d37… |
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 AN1382Open 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.