---
{
  "title": "Hide Artifacts",
  "summary": "Artifact hiding uses system features or configuration to make activity less visible.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [
    "T1564"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1564: Hide Artifacts",
      "url": "https://attack.mitre.org/techniques/T1564"
    }
  ],
  "editorialVersion": 2
}
---

## Visibility can be reduced without deleting content

Hiding artifacts makes files, processes, configuration, or other activity less apparent through system features or altered presentation. The artifact may still exist and operate. This differs from deleting traces, although the two behaviors can occur in the same incident.

Many legitimate applications use hidden files, background processes, and noninteractive interfaces. An artifact's hidden status is therefore context, not a verdict. Investigators should examine provenance, purpose, permissions, execution, and relationships to the observed incident.

## An application file is absent from an ordinary view

In a fictional endpoint case, a program references a file that the user's normal directory view does not display. The analyst checks the file's attributes, location, metadata, access controls, and relevant process activity using an authorized investigation method.

An application support file could legitimately be hidden to reduce user confusion. Alternatively, the setting may conceal an unauthorized component. Compare the artifact with the application's expected installation and a trusted baseline where available.

The team should avoid assuming that an item absent from one interface is absent from the system. Different tools expose different views, and some views may omit objects because of permissions or formatting rather than deliberate concealment.

## Separate concealment from content

A hidden flag or suppressed interface explains presentation; the file's behavior still requires analysis. Likewise, an unusual process argument display may not reveal the complete invocation. Preserve the original records and identify what the source actually exposes.

[[masquerading]] changes apparent legitimacy through names or metadata. [[indicator-removal]] removes or alters traces. [[rootkit]] concerns deeper interference with system visibility. These distinctions help select evidence rather than assigning every concealment label to one observation.

Where one view may be untrustworthy, seek independent sources appropriate to the platform. A discrepancy is a reason to investigate, not automatic proof of a particular concealment mechanism.

## Respond to the underlying behavior

Preserve relevant artifact information before cleanup where practical. Restrict unauthorized execution or access and review how the hidden item was introduced. Simply making a file visible does not remove its behavior or the access that created it.

Coordinate changes with the application owner because deleting normal hidden support files can break software. Define verification around the actual harmful behavior and intended configuration, not only the visibility setting.

For practice, compare a legitimate hidden application directory with a fictional hidden executable launched by an unexplained startup entry. Identify the provenance, configuration, and runtime evidence needed for a decision. [[logs-and-telemetry]] supports the comparison, while [[incident-reporting]] keeps the concealment observation separate from unproven claims about intent.

## Related concepts

- [[mitre-attack]]
- [[incident-response]]