How T1564 hide artifacts lets an attacker blend in
For a SOC lead, T1564 Hide artifacts is the technique behind alerts that look routine while the telemetry never explains why they fired. Under the Stealth tactic (TA0005), MITRE ATT&CK describes the goal as trying "to hide and conceal their actions, appearing as normal behavior." T1564 is the part of that goal that concerns the artifacts an intrusion leaves behind, such as files, attributes and other objects that could otherwise draw an analyst's attention. The practical consequence is that a triage queue can contain the right signal in a form that reads as ordinary administration, so the question for the SOC is whether the telemetry it already collects is enough to show intent.
At a high level, hidden artifacts let an intruder keep working inside an environment without tripping the obvious checks. The technique has 14 sub-techniques, and they span several platforms, including ESXi, Linux, macOS and Office Suite, along with other platforms that depend on the client's estate. Each platform produces different evidence, so a single rule set rarely covers them all. Before tuning any alert, the detection lead should inventory which of these platforms are in scope, confirm which of them actually send process, command and file creation events to the central log platform, and record the gaps as named risks rather than assuming coverage.
This page targets MITRE ATT&CK Enterprise version 20.0, released on 2026-10-13. Stealth was created when ATT&CK v19 split the old Defense Evasion tactic, so any detection mapping written against earlier material should be checked against the current tactic and technique IDs. ATT&CK can rename, deprecate or revoke techniques between releases, so each detection should record the version it targets. The team should confirm with its own rule catalog which mappings still reference the older tactic structure before the next validation cycle, and should review the ATT&CK updates page for the release notes that apply.
Which telemetry reveals hidden artifacts
This table maps the data components ATT&CK most often references for T1564 Hide Artifacts to the signal each one reveals, the platforms where it applies and the open-source collector that gathers it. Read each row as a starting point, then confirm coverage in your own environment before relying on it for detection.
| Data component | Signal for T1564 | Platforms and open-source collector |
|---|---|---|
| Process Creation (DC0032) | Hidden or attribute-altered processes, unusual parent-child relationships and process names that do not match expected binaries or paths | Windows: Sysmon-style logging forwarded through Wazuh agents. Linux and macOS: auditd or Wazuh agent process monitoring. Confirm event coverage per host. |
| Command Execution (DC0064) | Shell or utility commands that set hidden attributes, change file visibility or unhide content on ESXi, Linux, macOS and Office hosts | Linux and macOS: auditd command records through Wazuh. Windows: PowerShell script block and command logging. ESXi: shell and host logs forwarded to a collector. Confirm each source is enabled. |
| File Creation (DC0039) | New files placed in hidden locations, dot-prefixed or system-looking names, alternate data streams or unexpected archives in user profiles | Windows and Linux: file integrity and creation events via Wazuh syscheck or Sysmon. Use Velociraptor to hunt artifact locations on demand. Confirm monitored paths. |
| File Modification and File Metadata | Changes to hidden attributes, timestamps or permissions on existing files that would not appear in creation events alone | Linux and macOS: Wazuh file integrity monitoring. Windows: file change events. Velociraptor can collect metadata for review. Confirm which attributes the agent records. |
| Module Load (DC0016) | Hidden or injected libraries and drivers loaded by processes, a useful context signal where artifacts are concealed inside loaded code | Windows and Linux: Sysmon image load events or auditd and Wazuh inventory data. Referenced by related Stealth detections, so consider where relevant. Confirm collection overhead and coverage. |
| Network Connection Creation (DC0082) | Outbound traffic from hidden processes or artifacts retrieving or staging content, useful for correlating a host finding with network activity | Zeek or Suricata sensors for network context, with host connection logs from Wazuh or Sysmon. Confirm sensor placement and visibility of encrypted traffic. |
Detection logic for hidden files, processes and configuration
The four to six ideas below are written as detection logic in words, with a tuning approach against a baseline and the false positive sources to exclude. Each is expressed as a Sigma rule and mapped to ATT&CK v20.0, so the team can version, test and review them together. Thresholds are starting points that must be set against your own telemetry before alerts reach an analyst queue.
Hidden file creation in system locations
Alert when a process creates a file whose name begins with a dot, or whose attributes mark it hidden or system-owned, inside user profiles, web roots, temporary directories or system paths. The logic relies on the File Creation data component (DC0039) and the path and owner fields in that event. Start by counting new hidden files per host per day in a two-week baseline, then alert on hosts that exceed a high percentile of that baseline. Expect false positives from backup agents, package managers and developer tooling that create dot-directories, so allowlist by parent process and signed publisher rather than by file name alone.
Attribute changes through command execution
Alert when a command interpreter or utility runs with arguments that change file visibility, ownership or hidden flags on existing files, particularly in directories that normally hold configuration or logs. The logic uses Command Execution (DC0064) and Process Creation (DC0032) together, so the alert fires on the action rather than the artifact. Tune by grouping events per user and host and flagging only changes outside approved maintenance windows. Installers, configuration management agents and administrators running scheduled hardening scripts generate most false positives, so record their parent processes and change tickets as exclusions.
Process creation with hidden or stripped names
Alert when a process image name is empty, consists of a single character, uses a dot-prefixed name, or differs from the original file name recorded in the binary metadata. This pattern is detected through Process Creation (DC0032) with the image path and original file name fields. Set the threshold by first listing every unique image name observed across your fleet, then alert only on names that appear on fewer than a small number of hosts over the baseline period. Legitimate sources include renamed vendor binaries, containerized workloads and some update agents, so maintain a reviewed list of renamed signed binaries.
ESXi configuration and datastore artifact changes
On ESXi hosts, alert when hidden files appear in datastore directories holding virtual machine configuration, or when shell commands modify visibility flags on those files. Because the ATT&CK mapping for this technique includes ESXi, collect host logs centrally and treat any change outside a vSphere change window as a priority. Baseline the expected file set for each datastore, then alert on deviations rather than on every new file, since snapshots and backup jobs legitimately create transient files. Ask your virtualization team to confirm which backup products and replication tools run on each host before writing exclusions.
Office Suite artifact changes
Alert when an Office application writes hidden or system-attributed files, or when a macro-enabled document leads to a new file in a profile location that is then hidden. The signal combines File Creation (DC0039) with the parent process of the Office application. Tune by setting a per-user threshold on new hidden files created by Office processes, and exclude add-ins, sync clients and collaboration tools that write cache files. Confirm with your desktop team which add-ins and synchronization clients are approved, because their cache behavior varies by version.
How to validate that the T1564 detection fires
This sequence turns the T1564 detection logic into a tested control: a scoped, emulated run in an isolated lab, confirmation that alerts reach the SIEM with usable fields, and a recorded view of latency, gaps and false positives. The output is evidence that names the ATT&CK version tested and shows which sub-techniques are covered.
Agree scope and rules of engagement
The security lead, the SOC manager and the platform owners agree in writing which platforms, hosts and accounts are in scope, which T1564 sub-techniques are in the test plan, and what must stop the run. Confirm that the lab is isolated from production identity, backup and management networks. Record the ATT&CK version the team is targeting, because detection strategies and sub-techniques can change between releases. The step is done when a signed scope document exists and the SOC knows the test window.
Map sub-techniques to platforms and telemetry
Using the ATT&CK technique page and its sub-technique list, the detection engineer selects the sub-techniques that match the platforms in the lab, such as Linux, macOS, Windows, ESXi or Office Suite hosts. For each selection, the engineer lists the expected data components, including Process Creation, Command Execution and File Creation, and the log sources that should carry them. Sub-techniques with no matching log source are marked as coverage gaps before testing starts. The output is a coverage matrix that the rest of the sequence uses as its checklist.
Run a controlled emulation in isolation
A red team member or a trained tester performs the agreed emulation steps in the isolated cyber range, one sub-technique at a time, with timestamps recorded for each action. The tester logs what was done, on which host and under which account, so the SOC can later match each action to alerts. Stop conditions from the rules of engagement are checked between runs. The step is complete when every planned action has a start time, an end time and an operator note in the test log.
Confirm alerts reach the SIEM with fields
The SOC checks that each emulated action produced events in the SIEM, such as a Wazuh or Security Onion dashboard, and that the events carry the fields the detection depends on, including host, user, process name, command line where collected, file path and timestamp. A missing field is treated as a logging defect, not a detection failure, and is raised with the platform owner. The check passes when each covered sub-technique has at least one event with the required fields, and the results are written against the coverage matrix.
Verify that the detection rules fire
The detection engineer confirms that the Sigma or native SIEM rules mapped to each sub-technique produced alerts, and records whether each alert fired on the expected event and not on an unrelated one. Where a rule did not fire, the engineer determines whether the cause is the rule logic, the log source, the parsing or the threshold. The output is a result per sub-technique marked as detected, partially detected or not detected, with the rule version attached.
Record latency, gaps and false positives
The team measures the time between each emulated action and the alert reaching the analyst queue, and records any false positives seen during the run or in normal baseline activity from the same hosts. Coverage gaps from step two and any sub-techniques that did not fire are listed with an owner and a planned fix. Ask the SIEM and platform vendors or your own environment owners to confirm how ingestion delay is measured before comparing results across runs. The step closes when the gap register and false positive list are reviewed by the SOC lead.
Publish results with the ATT&CK version
The team writes a validation report that names the ATT&CK version tested, the list of sub-techniques exercised, the platforms and log sources involved, the rule versions, and the results for each step above. The report is stored with the detection repository so future changes can be compared against this baseline. Where an auditor or customer asks for evidence, the report is the starting point, and the team should confirm with its assessor what format they expect. The sequence is complete when the report is approved and the gap fixes are scheduled.
Preventive controls that reduce hidden-artifact risk
ATT&CK maps a small set of mitigations to T1564 and its sub-techniques, and each one addresses a different point in the attack path. Read them together: auditing shows what was hidden, endpoint protection stops known hiding methods, and permissions limit who can create or conceal artifacts in the first place. Confirm the exact mapping for your ATT&CK version before you write it into a control register.
Audit (M1047)
Audit is the ATT&CK mitigation that asks you to configure logging so that the activity behind hidden artifacts is recorded. For T1564, the useful question is whether your endpoints, hypervisors and collaboration platforms log file creation, attribute changes and command execution with enough detail to reconstruct what was hidden and by whom. Check that audit policies are enabled on each platform in scope, that logs are forwarded to a central store such as Wazuh, and that retention covers the period in which a hidden file would typically be found.
Antivirus and antimalware
Antivirus and antimalware products can flag known hiding tools, suspicious file attributes and payloads stored in unusual locations. This control reduces risk from commodity techniques but does not see activity that uses only native tooling or new methods. Confirm which platforms your product covers, including ESXi, Linux and macOS hosts, since coverage often differs by operating system. Test alerting on a sample hidden file in a lab before relying on it.
Behavior prevention on endpoint
Behavior Prevention on Endpoint (M1040) is mapped to several T1564 sub-techniques in the ATT&CK mapping for the version you target. Endpoint products that block suspicious behavior, such as unexpected attribute changes on system files or command sequences that conceal content, add a layer that signature-based scanning misses. Confirm the mapping for your version on the ATT&CK technique page, and review which behaviors your product can block in prevention mode rather than only alert on.
Restrict file and directory permissions
Restrict File and Directory Permissions (M1022) limits who can write, rename or set attributes on files in shared and system locations. Hidden artifacts often depend on write access to a directory that users or services should not change. Review write permissions on system paths, shared drives and hypervisor datastores, and confirm the mapping to T1564 sub-techniques for your ATT&CK version before you cite it as a control.
Privileged account management
Hiding artifacts on a host usually requires elevated rights, so the accounts that hold those rights matter. Privileged account management limits who holds administrative access, rotates credentials and reviews privileged sessions. Confirm with your ATT&CK mapping whether this mitigation applies to the sub-techniques in your environment, and align the review cadence with the access reviews your compliance program already runs.
Triage and response when a hidden-artifact alert fires
When a hidden-artifact alert fires, the first decision is whether the artifact is real and whether it is malicious, and both questions must be answered before anyone deletes anything. Confirm the artifact on the host itself: check that the file, directory, alternate data stream, hidden user or hidden process named in the alert exists, and compare the alert's path and hash with what the host reports now. Next, identify the process and the user responsible. Pull the parent-child chain from Process Creation and Command Execution telemetry, note the account context, and record whether the activity matches a known administrative job, a software installer or a change ticket. Where the artifact is a hidden file, check its integrity against a known-good copy or package manifest, and review its owner, group, permissions and creation time, since a file that was placed by a different account than the one that normally writes to that directory is a strong signal on its own.
Once the artifact and actor are clear, pivot to related host telemetry for the same time window. Look at File Creation and File Modification events around the artifact, outbound Network Connection Creation from the responsible process, new logons, and any scheduled task or service that references the same path. Decide on containment based on what the pivot shows: isolating the host from the network is usually justified when the artifact sits next to unexplained outbound traffic or a privileged account is involved, while a lone hidden file with a clear benign origin may only need a ticket and owner confirmation. Before any cleanup, preserve evidence. Velociraptor or an equivalent collection tool can capture the artifact, the process listing, the relevant event logs and the file metadata with hashes, and the chain of custody should record who collected what and when. Remove the artifact only after the collection is verified.
Escalate to incident response as soon as the artifact is tied to unauthorized access, to a second host, to credential use, or to data movement, and do not wait for certainty on the full scope. Document the decision at each step in the case record: the alert, the evidence reviewed, the containment choice, the person who approved it and the reason for not escalating if you choose not to. Confirm your escalation thresholds and retention requirements with your incident response plan and legal or compliance team, since those determine how long evidence must be kept. Review the outcome afterward to tune the Sigma or Wazuh rule, because repeated false positives from a legitimate tool are a reason to add an allow-list entry with an owner and an expiry date, not to suppress the alert.
Rehearsing T1564 detection in a private cyber range
The endpoint range is the most direct place to rehearse T1564 because hidden files, hidden attributes and dot-prefixed artifacts are common on both platforms. Build a small isolated network with a Windows workstation and a Linux server, each running an agent such as Wazuh with file integrity monitoring and Sysmon-equivalent process and file telemetry enabled. The red team or exercise control script places benign marker artifacts in agreed locations so the blue team can practice finding them without any real misuse.
- Topology: One Windows endpoint, one Linux host and one Wazuh manager, all on a dedicated VLAN with no route to production.
- Injects: Staged hidden files in user profile and temp paths, a dot-prefixed directory under a service account home, and a file attribute change made after initial creation.
- Good detection: Process Creation and File Creation events fire within the agreed window, the alert carries the host, user, parent process and full file path, and the analyst notes why the attribute change matters.
- Good response: The analyst isolates the host from the range network, captures the artifact and its hash, preserves the process tree, and records whether the alert was triaged to the correct severity.
- Lessons learned: Confirm which fields were missing from the alert and whether the Audit mitigation settings on each platform actually produced the expected records.
After the exercise, check that each detection maps to a named ATT&CK version and that analysts can reproduce the alert from the stored logs.
The virtualization segment tests whether hidden artifacts on hypervisor hosts and guest images are visible to the platform team. Use a nested ESXi lab or a non-production cluster that forwards host logs to a central collector. Keep the range isolated, use only exercise-owned virtual machines and make sure that no management plane is reachable from production networks.
- Topology: A nested ESXi host, a management workstation, a log collector and a Security Onion or Wazuh node receiving syslog from the host.
- Injects: Exercise-created hidden datastore files and a guest VM folder with a non-standard hidden attribute, introduced through the normal administrative interface by the exercise control team.
- Good detection: Command Execution and File Creation records from the host reach the collector, the alert identifies the datastore path and the account used, and the analyst can distinguish an expected change from an unscheduled one.
- Good response: The team snapshots the affected VM before any change, verifies the datastore inventory against the known baseline, and documents the chain of custody for the evidence.
- Lessons learned: Check whether host logging was complete, whether log forwarding delays affected alert timing and whether the change control record matched the injected activity.
Confirm with your virtualization vendor which host audit settings are supported in your version before you plan the exercise.
The Office Suite or SaaS scenario tests hidden artifacts in shared document stores, collaboration spaces and administrative audit trails. In a private range, use a self-hosted collaboration platform or a sandbox tenant owned by the client, with synthetic documents and test accounts. The objective is to see whether the audit pipeline records hidden or unlisted items and whether analysts can correlate them with the owning user.
- Topology: A self-hosted document or collaboration service, a test identity provider, an audit log export to the SIEM and a blue team workstation with read-only access to logs.
- Injects: Synthetic documents placed in hidden or unlisted folders, plus a permission change that makes an item invisible to standard views.
- Good detection: Audit events for creation and permission change appear in the SIEM, the alert names the item, the actor and the time, and the analyst notes whether the item was expected.
- Good response: The analyst restricts the item's access, exports the audit record and the item metadata as evidence, and confirms with the owner whether the activity was authorized.
- Lessons learned: Verify that audit retention covers the exercise window, that hidden items are not excluded from search, and that the owner notification path worked.
Check with the platform vendor which audit events are emitted for your edition and configuration before you build the scenario.
Questions SOC leads ask about detecting T1564
How do we keep detections mapped to ATT&CK v20.0 when technique content changes?
Pin every detection to the ATT&CK version it targets, and record that version in the rule metadata. MITRE publishes ATT&CK content as STIX 2.1 bundles in the mitre-attack/attack-stix-data repository, one bundle per domain and version, so your team can diff the Enterprise bundle between releases and see which sub-techniques, data components or mitigations changed. ATT&CK v18 replaced technique-page detections with detection strategies and analytics, and releases can rename, deprecate or revoke techniques. Assign an owner to review each release, update the mapping table, and retire rules whose underlying technique moved. Confirm the exact version your SIEM content pack expects before you import it.
Which data components should we prioritize for hidden artifact detection?
Start with Process Creation (DC0032), Command Execution (DC0064) and File Creation (DC0039). These three cover most of the Stealth detection strategies that reference T1564 and its sub-techniques, and they map to telemetry most Linux, macOS, Windows and ESXi estates can already collect. Add Module Load (DC0016) where you need visibility into loaded code, and Network Connection Creation (DC0082) for hidden or staged communication. Confirm coverage for each data component against the detection strategies in the ATT&CK version you target, because some sources have been deprecated in recent releases.
How do we reduce noise from legitimate hidden files and folders?
Hidden files are common in healthy systems, from dotfiles in user profiles to application caches and package manager directories. Build an allowlist from a documented baseline per host role, and scope rules to the locations and file types that matter, such as executables, scripts or archives written into system or user directories where they should not appear. Score rather than alert on single events, and require a second signal such as a process spawned from the file or an unusual parent. Review suppressions monthly, and record why each one exists so an auditor or new analyst can follow the decision.
How do we test sub-techniques without disrupting production?
Run tests in a private cyber range or a staging environment that mirrors production logging, endpoint agents and log pipelines. Use a written test plan that names each sub-technique, the expected telemetry, the expected alert, and the owner who signs off on the result. Keep the test scope to controlled, non-destructive actions, and agree a stop condition and a rollback path before any run. DeployOpen runs private cyber ranges and security testing as fixed-scope work, so the test scope, systems involved and deliverables are agreed in writing before work starts.
How often should we rerun validation for hidden artifact detections?
Rerun validation on three triggers: after each ATT&CK version update that touches Stealth techniques, after any change to logging agents, log sources or SIEM parsers, and on a fixed cadence set by your risk owner. The cadence itself is a governance decision, so set it in your control documentation rather than copying a number from a vendor guide. Record each run with the ATT&CK version, the rule version, the test artifacts, the expected and observed alerts, and any gaps with an owner and a due date. Ask your assessor which evidence format they expect before you start.
Can our own team run these detections and tests, or do we need outside help?
Many SOC teams can run the detections themselves if they already operate a SIEM, endpoint telemetry and a repeatable test process. The work that tends to need outside help is building the cyber range, maintaining mappings across ATT&CK releases, and producing validation evidence for a compliance assessment. Cost depends on the number of log sources, the number of sub-techniques in scope, how much of the range is already built, and how often testing recurs. Ask any provider for a written scope listing the platforms, data sources, deliverables and retesting approach, and confirm who keeps the mappings current after handover.
How DeployOpen builds T1564 detections and range exercises
DeployOpen works on T1564 Hide artifacts as a fixed-scope engagement inside your own environment, starting from the telemetry you already collect. The written scope sets which platforms, data sources and sub-techniques are covered, and the deliverables are documented so your team can run them after handover.
How we scope
- Confirm which T1564 sub-techniques apply to your ESXi, Linux, macOS, Office Suite and other platforms in scope.
- Inventory the Process Creation, Command Execution and File Creation telemetry your sensors already collect.
- Record the ATT&CK version the detection mappings target so later releases can be compared cleanly.
How we build
- Write detection logic for T1564 in open formats such as Sigma and deploy it to your Wazuh or Security Onion stack.
- Map each rule to the Audit and Antivirus/Antimalware mitigations and to the matching data components.
- Test each rule against benign administrative activity to measure noise before it reaches analysts.
How we hand over
- Deliver a runbook describing triage steps, required fields and escalation paths for each T1564 detection.
- Document the validation method, including the test scenarios used and the expected alert output.
- Run a rehearsal in a private cyber range so your SOC practices detection and response before go-live.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, rule tuning and continuous testing for T1564 are available as a retainer.
- Review rules when ATT&CK releases change techniques or data components, and confirm impact with your team.
