Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN0768: Analytic 0768

The adversary uses native utilities like base64, gzip, tar, or openssl to decode, decompress, or decrypt files that were previously staged or downloaded. These tools may be chained with curl/wget and executed via bash/zsh, often to extract an embedded payload or reverse shell script.

EnterpriseAN0768AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This analytic describes a Linux behavior where an attacker uses built-in command-line utilities such as base64, gzip, tar, or openssl to unpack, decode, or decrypt content that was already staged or downloaded. The business issue is that these utilities are legitimate and common, so the risk is not the tool name alone; it is whether the organization can distinguish normal administration or application activity from payload preparation that may precede execution of malicious scripts or other follow-on activity.

Executive priority

Prioritize this as a coverage-validation item for Linux estates, especially systems where command-line activity, downloads, and script execution matter to business continuity. Leaders should ask whether SOC and incident response teams can reconstruct who downloaded or staged a file, which process unpacked or decoded it, and what executed afterward. Because ATT&CK provides no official detection logic for this analytic, the decision value is in confirming telemetry quality and tuning, not assuming existing alerts are sufficient.

Technical view

For Linux monitoring, validate visibility into process creation and command-line arguments involving native utilities such as base64, gzip, tar, and openssl, especially when chained with curl or wget and invoked through bash or zsh. Investigations should correlate the unpacking or decoding event with the parent shell, the source of the staged/downloaded file, created output files, permission changes, and any subsequent script or binary execution. Tactics are not specified and no relationship context is supplied, so detection engineering should treat this as a behavior pattern requiring local baselining rather than a fully scoped ATT&CK technique mapping.

Likely telemetry

  • Linux process creation events with full command-line arguments
  • Parent-child process relationships for bash, zsh, curl, wget, base64, gzip, tar, and openssl
  • File creation and modification events for staged, decoded, decompressed, or decrypted files
  • Shell history or session telemetry where available and appropriate
  • Network or proxy logs showing curl/wget retrievals where collected

Detection direction

  • Baseline legitimate administrative, backup, deployment, and application packaging workflows that commonly use compression, encoding, or encryption utilities.
  • Look for suspicious chains where download utilities are followed by decode, decompress, decrypt, or extraction utilities and then script or binary execution.
  • Prioritize command-line context, parent process, working directory, user, and output path over utility name alone to reduce false positives.
  • Validate whether logging captures piped commands and shell-launched tool chains; this is a common blind spot for this behavior.
  • Because the official object provides no detection text, convert this into a local analytic hypothesis and test it against known-good Linux operations before alerting broadly.

Mitigation priorities

  • Maintain strong Linux endpoint and audit logging so responders can reconstruct file staging, transformation, and execution.
  • Restrict unnecessary shell and download-tool use on high-value systems where operationally feasible.
  • Apply least privilege so ordinary users and service accounts cannot easily stage and execute arbitrary payloads in sensitive paths.
  • Use change control and allowlisted automation patterns to separate expected packaging/deployment activity from unusual interactive shell activity.
  • Ensure incident response playbooks include triage steps for decoded, decompressed, or decrypted files and their subsequent execution chain.
Analyst notes and limits

This is a detection analytic object for Linux with a concise behavior description and no supplied tactic, official detection text, or relationship context. The most defensible use is as a prompt to validate Linux command-line telemetry and correlation logic around native file transformation utilities, especially when combined with download and shell execution context.

The supplied ATT&CK fields do not identify a specific technique, campaign, adversary, impact, or detection implementation. Any assertion about exposure, maliciousness, or coverage requires local telemetry, asset context, and baselining.

Official MITRE ATT&CK definition

Analytic 0768

The adversary uses native utilities like base64, gzip, tar, or openssl to decode, decompress, or decrypt files that were previously staged or downloaded. These tools may be chained with curl/wget and executed via bash/zsh, often to extract an embedded payload or reverse shell script.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
28b1cac027767420...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 28b1cac02776…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN0768
    Open source URL
Source and licensing

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.