Why direct volume access matters to a SOC for T1006
A SOC needs to know when a process reads raw volume data that bypasses the file system and its permissions. T1006 Direct volume access sits under the Stealth tactic (TA0005) in Enterprise ATT&CK 20.0, and it matters because it lets an actor reach file content without going through the normal access checks that protect individual files and folders. In practical terms, the actor is trying to read or copy data as if it were block storage, so that access control lists set on a file or directory no longer decide what can be seen. The technique is classed under Stealth because the reads can look like routine low-level disk activity rather than file access.
Within an intrusion, direct volume access is typically a means to an end rather than the goal. Its value to an actor is that it can help retrieve data that is otherwise locked by file permissions, or that is in use by another process, and it can help avoid the file-level events that many monitoring setups watch closely. Because the activity does not necessarily create or modify a file, ordinary file creation and file modification logs may show nothing useful. Before you rely on any single signal, confirm with your platform and endpoint vendors which telemetry they expose for raw volume handles and which process and command events they record on each platform in your estate.
The decision for your team is where to look. Start by inventorying which hosts, servers and network devices in your environment run tooling that could legitimately touch volumes at a low level, such as backup agents, imaging tools and forensic collectors, so that expected activity is documented before alerts are tuned. Then decide which data components from ATT&CK 20.0, such as Process Creation (DC0032) and Process Access (DC0035), your sensors can actually populate. Those choices shape every detection and exercise that follows on this page.
Which telemetry reveals T1006 and which open-source tool collects it
This table maps the data components that ATT&CK most often ties to Stealth techniques, including Process Creation, Command Execution and Process Access, to the signal each one can expose for T1006 and the open-source collector that gathers it. Treat each row as one source of evidence, since coverage depends on the ATT&CK version you target. Confirm the T1006 detection strategy mapping in the Enterprise ATT&CK STIX bundle for that version before you write rules.
| Telemetry source | Signal to look for | Open-source collector |
|---|---|---|
| Process Creation (DC0032) | Process starts that open raw volume or disk device paths outside normal disk management tools | Windows endpoint logging forwarded to Wazuh, or auditd on Linux agents |
| Command Execution (DC0064) | Command lines that reference raw device paths or volume identifiers | Wazuh agent log collection, with Security Onion for central search and case review |
| Process Access (DC0035) | A process obtaining a handle to a disk or volume object on Windows hosts | Sysmon-style process access events forwarded to Wazuh, after confirming event coverage on each Windows build |
| Network device logs | Administrative sessions on network devices that run commands touching storage or configuration | Syslog to Wazuh, with Zeek or Suricata for session metadata on management traffic |
| Baseline of legitimate tools | Backup, imaging and disk management tools producing the same events and needing documented allowlists | Wazuh rule tuning and review of false positives in Security Onion |
| Validation evidence | Test runs in the lab producing matching events that reach the SIEM | Replay of logged events in a private cyber range before production rollout |
Where T1006 telemetry gaps usually sit
Process and access events alone are rarely enough to see T1006 Direct volume access. Process Creation and Process Access (data components DC0032 and DC0035 in ATT&CK) tell you which program ran or opened a handle, but they only help if the operating system is configured to record them. On Windows, confirm that process creation auditing and command line capture are enabled on the hosts that matter most, such as domain controllers, backup servers and administrative jump hosts. Many SOC teams discover that these settings were never applied to a server build, or were turned off to reduce log volume. Treat each missing host as a blind spot in your coverage map, not as a minor configuration issue.
Retention is the second common gap. A detection that depends on a historical baseline or on a slow investigation needs enough stored events to cover the period when the activity would have occurred, and many environments roll logs over quickly on endpoints and forward only a subset to the central platform. Confirm, for each source, how long events are kept locally, how long they are kept in Wazuh or your SIEM, and whether the forwarding agent drops events during outages. Network devices deserve separate attention. Many send syslog without process context, so a switch or firewall log may show an administrative session but not what was executed inside it. For those devices, plan to correlate with authentication logs and configuration change records rather than expecting process-level detail.
Before you rely on any single data source, run a short inventory: list every host and device class in scope, record which data components you can actually observe for each, and test whether a known benign administrative action appears in the central platform within your expected time window. Ask your platform team to confirm the audit policy and forwarder state in writing, and ask your network team which devices emit only syslog. Where two independent sources cover the same behavior, such as process events plus file or volume access logs, you have corroboration. Where only one source exists, record that as an accepted risk with an owner and a review date. Use the results to decide what the cyber range exercise must prove.
Detection ideas for T1006 that a detection engineer can tune
T1006 Direct Volume Access is hard to see because the activity can look like routine disk tooling. The cards below group the signals that matter most: process activity against raw volumes, access to protected process memory or volume handles, and network device management events showing disk-level reads. Each idea needs a tuned allowlist built from your own backup, imaging, forensic and endpoint protection tools before it becomes actionable.
Raw volume access from processes
Process Creation and Command Execution telemetry can show a process launched with arguments that reference a raw volume device path rather than a file. Check the parent process, the signing certificate, the user context and whether the host is a server or workstation. Tune the threshold by counting distinct volume-level events per host per day, and expect backup agents, disk imaging appliances and forensic collectors to produce the most noise. Maintain a named allowlist of those binaries per host group, reviewed at each change window.
Access to protected process memory
Process Access telemetry records when one process opens a handle to another, including protected system processes. Flag handle requests from unexpected tools to the local security authority or to processes that hold volume handles, and check whether the requesting image is signed and was launched from a standard path. Tune by setting a baseline of normal handle requests per endpoint class. Endpoint protection, EDR agents and debugging utilities commonly generate legitimate handle requests, so confirm each vendor's behavior in a lab before alerting.
Volume handle requests by users
Volume handles are normally requested by a small set of service accounts and administrators. Compare the account making the request with its usual role, the logon type and the time of day, and alert when a standard user or a service account outside its schedule opens a raw volume. Tune by documenting which accounts are approved for imaging or backup on each asset group. Scheduled jobs and incident responders running forensic collection will appear here, so record their change tickets as suppression context.
Network device disk read events
Network devices and management planes can log administrative commands that read disk or flash contents, such as file copy or memory dump operations. Ingest these events through syslog and check for reads of storage paths by management sessions that were not opened from the approved jump host. Tune by building a list of sanctioned management IPs and maintenance windows. Configuration backup jobs and vendor support diagnostics are the main false positive sources and should be scheduled and tagged explicitly.
Imaging and backup baselines
Backup, imaging and forensic tools are the largest source of legitimate volume access, so their behavior should be measured rather than assumed. Record which binaries, hosts and schedules trigger each detection during a two-week observation period, then convert that record into scoped exceptions. Review exceptions when agent versions change, because a new release can alter the command structure and break a rule that was tuned against the old one. Confirm exception handling with your SOC runbook owner.
How to validate that the T1006 detection fires
This sequence proves, in a private cyber range, that the T1006 Direct Volume Access detection produces a trustworthy alert with the fields an analyst needs. It moves from scoping and approvals through a controlled emulation to a recorded measure of time to alert.
Define the emulation scope in the range
The detection owner and the range lead agree in writing which hosts, which Windows build, and which network device types are in scope, and which are excluded. The scope should name the telemetry that must be present before the test starts, such as Process Creation, Command Execution and Process Access, and the Wazuh, Security Onion or Velociraptor components that will receive it. The step is done when the scope document is signed off and every in-scope host is confirmed to be forwarding logs to the analysis platform.
Agree approval and rollback criteria
Before any activity, the security lead, system owner and range operator agree who can approve the run, what conditions stop it immediately, and how each test host returns to its baseline snapshot. Rollback criteria should cover unexpected impact on the range, loss of log flow, and any activity that reaches systems outside the range boundary. The step closes when the approval record and rollback procedure are stored with the test plan and the operator confirms the snapshot restore works on a non-critical host.
Confirm the baseline telemetry is clean
Before the emulation, the team records a baseline window on the in-scope hosts and checks that the expected event sources arrive without gaps or parsing errors. This establishes what normal administrative activity looks like on the same hosts, so that any later alert can be judged against a known starting point. The step is complete when the analyst can show the baseline events in the analysis platform and the team has noted any noisy legitimate activity that could cause false positives.
Run the approved emulation at a high level
An operator performs an approved emulation of the behavior described in the ATT&CK technique page for T1006, limited to the scope and timing agreed in the plan, and watched by a second person who can halt the run. The team logs the start and end times of each activity so that the alert can later be matched to a specific action. Detailed steps, tooling and syntax belong in the restricted test plan and are not reproduced in the page or the shared report. The step ends when the operator records that the emulation finished or was stopped under the rollback criteria.
Confirm the alert reaches the analyst
The analyst checks the Wazuh, Security Onion or equivalent queue for an alert that maps to the detection strategy and analytic for T1006 in the ATT&CK version the team targets. The check confirms that the alert is routed to the right queue, is not suppressed by an existing rule or exception, and is visible in the case management workflow. The step is done when the alert appears in the analyst's queue with a reference the team can trace back to the logged emulation window.
Verify the fields present in the alert
The analyst reviews the alert and confirms that the fields needed for triage are populated, including the host, the process or command context, the user account, the timestamp and the data component that triggered the logic. Missing or empty fields are logged as defects against the parsing or normalization pipeline. The step closes when a field checklist is completed for the alert and any gaps are assigned to an owner with a target fix in the backlog.
Record time to alert and document results
The team calculates the interval between the logged emulation start and the alert's arrival in the analyst queue, then records the figure with the fields present and any false positives or misses. Results are compared to the previous run, if one exists, and the detection owner decides whether to tune the rule, adjust the mitigation coverage or accept the result. The step is complete when the signed results record, including the ATT&CK version and the time-to-alert measure, is filed with the detection repository.
Preventive controls that reduce T1006 exposure
T1006 Direct volume access depends on two conditions: something on the host can read raw volume data, and an account with enough rights can run that activity. The cards below cover endpoint behavior controls that limit unexpected raw access and account management controls that narrow who can perform privileged operations on hosts and network devices.
Endpoint behavior prevention rules
Behavior Prevention on Endpoint (M1040) is the ATT&CK mitigation for blocking suspicious behavior at the endpoint before it completes. For T1006, the useful question is whether your endpoint product can flag or block processes that open raw volume handles on system drives, outside of backup and disk management tools you already trust. Confirm with your vendor which behaviors are detected in prevention mode versus detection-only mode, and whether that covers your Windows and Linux builds.
Allowlists for raw disk tools
Where your platform supports it, define which signed binaries may open raw volumes, and by which accounts and parent processes. Backup agents, imaging tools and forensic collectors usually need this access, so the allowlist should name them specifically. Review the list after each software change, because a broad exception for a backup product can quietly cover unrelated tooling. Ask your vendor how exceptions are scoped and logged.
Least privilege for local administrators
User Account Management (M1018) limits who holds the rights needed to open raw volumes or run disk-level utilities. Remove standing local administrator rights from routine users, and grant elevation only through a managed, logged workflow. Check that service accounts used by backup and monitoring tools are not shared with interactive users, and that their rights are limited to what those tools need.
Privileged access on network devices
Network devices and appliances also expose privileged modes that can read configuration and storage. Apply separate administrator roles, require named accounts rather than shared logins, and restrict which management networks can reach the device. Review who holds enable-level or root-equivalent access on each device class, and confirm with your vendor which role granularity the platform supports for file system and shell access.
Account review and removal cadence
Accounts that once needed raw access for a migration or a one-off repair often remain active afterward. Set a recurring review of accounts and group memberships that carry disk or device administration rights, and remove those that no longer have an owner. Pair the review with your identity provider's reporting so that changes to privileged groups are visible and tied to a ticket.
Test controls against your own platforms
Preventive settings behave differently across operating system versions, endpoint agent releases and device firmware. Before relying on a control, test it in a private cyber range that mirrors your production builds, and record which activities are blocked, alerted on, or allowed. Ask each vendor to document the exact prevention and audit capabilities for your platforms, and treat any gap as a monitoring requirement.
Triage and response when a T1006 alert fires
Start by establishing what touched the volume and who ran it. Confirm the process image, its parent process, its signer and its command line from Process Creation and Command Execution records, then identify the account and its logon context. Check whether the account is a backup service, a forensic or imaging account, or an administrator working from a privileged access workstation. Next, check whether an approved task explains the activity: a backup job window, a change ticket, a scheduled imaging run or an incident responder's case. Match the host, time window and account against the asset owner's records, and confirm with that owner rather than relying on a name that looks familiar. Treat a process that is unsigned, runs from a user profile or temp path, or has no matching approval as unexplained until proven otherwise.
Scope the signal before changing anything. Search other endpoints and servers for the same process name and hash, the same parent process, the same account and raw volume access within the same window. Preserve evidence while it still exists: export the alert and the underlying process, command execution and Process Access records to the case store, record hashes of any suspicious binary, and capture volatile data such as running processes and open handles before the host is rebooted or reimaged. Watch retention settings on your SIEM and endpoint platform, because short retention can remove the context you need. Escalate to incident response when the activity cannot be explained by an approved task within the agreed review period, or when the same signal appears on several hosts.
Decide containment by asset and account risk, not by alert severity alone. Isolate a host when the activity is unexplained and the host holds credentials, domain controllers or sensitive data. Disable or reset an account and revoke its sessions when it is a user account with no approved reason to read raw volumes, and coordinate with the backup owner before isolating a backup server, since that action can break recovery. Record the case with the alert identifier, UTC timestamps, host, volume, process chain, account, the approval reference or the statement that none was found, scope results, evidence hashes, each containment decision with its owner and time, and the ATT&CK version used for the mapping, which for these pages is Enterprise ATT&CK 20.0. Close the case by tuning the allowlist only from documented approvals.
Rehearsing T1006 detection and response in a private cyber range
Build the range as a small, isolated network that mirrors the production segments the team defends. Keep it closed to the internet and separate from corporate networks, and confirm with the range operator how traffic is contained. The scenario, scope and approvals are agreed in writing before the exercise, and the range should reproduce logging paths faithfully rather than hold copies of production data.
- Windows endpoints: Include at least one domain-joined workstation and one server image that match the production build, with the endpoint agent and process logging your standard uses.
- Network device segment: Add a management segment with a representative device or virtual appliance, and confirm which logs (authentication, configuration change, syslog) reach the collector.
- Collection path: Route endpoint and device logs through the same agents and forwarders used in production, so the SIEM sees what it would see in daily operation.
- Test accounts: Create dedicated standard and privileged test accounts so User Account Management controls can be checked during the exercise.
- Containment points: Document the isolation steps and the rollback point for each host and device before the exercise begins.
Check that every host and device appears in the SIEM with the expected telemetry before the exercise begins.
Injects are scripted events that the blue team receives during the exercise. They should describe what a defender would observe, such as an alert, a log entry or a stakeholder message, and should not hand participants operational detail. Release each inject on the schedule in the scenario document and record the release time so responses can be measured against it.
- Early signal (illustrative): A low-severity alert on a Windows endpoint shows unusual process activity around raw volume access, with no matching change ticket.
- Escalated signal (illustrative): A second host and a network device log entry suggest the same account is active outside its normal pattern.
- Benign look-alike (illustrative): A scheduled administrative task produces similar events, so the team practices deciding when evidence is not enough to escalate.
- Stakeholder request (illustrative): The application owner asks whether a backup job failed, which tests communication and case handling.
- Controller log: Keep a record of every inject, its release time and the analyst action expected for it, so the debrief has a fixed reference.
Confirm with the exercise lead that no inject reveals private range details or exposes production data.
Good detection shows up as correlated events in the SIEM, not as a single isolated alert. Measure whether the SIEM and case tool surface the events from the injects with enough context for an analyst to decide quickly. Map each rule to the ATT&CK version it targets, and record the data components it depends on, because the mapping changes between releases.
- Process telemetry: Process Creation (DC0032) and Command Execution (DC0064) events are present on the Windows endpoints, with parent process, user and host fields populated.
- Access telemetry: Process Access (DC0035) events are logged where your agent supports them, so analysts can see which process touched a protected resource.
- Network device logs: Authentication and configuration events from the device segment arrive in the same timeline, with time sources aligned.
- Rule governance: Each rule has documented false-positive notes, a named owner and a version under change control.
- Case creation: Alerts open a case that lists the affected assets, the inject reference and the linked ATT&CK technique.
Check that each detection fires within the window agreed in the scenario and that the case holds enough evidence to act on without re-querying the data.
The response timeline records what the team did, when it did it and why. Reviewers compare it with the inject log to find gaps in triage, escalation, containment and communication. Keep the record factual so the lessons feed back into detection rules, runbooks and the mitigations the organization relies on.
- Triage: Analysts confirm scope, check whether the activity matches an approved change, and note the decision and its basis.
- Containment: The team isolates the affected endpoint or restricts the device account using the agreed steps, and records the rollback point.
- Mitigation review: Reviewers check whether Behavior Prevention on Endpoint (M1040) and User Account Management (M1018) controls blocked, logged or missed the activity.
- Communication: Notifications to the incident lead, the application owner and, where the scenario requires it, the compliance contact are timed and logged.
- Lessons learned: Each gap becomes a tracked action with an owner before the debrief closes.
Check that the timeline matches the inject log and that every containment action has a matching approval or rollback record.
Questions SOC leads ask about T1006 detection
How do we separate backup tools from adversary activity for T1006?
Start by building a baseline from your own environment, not from assumptions. Inventory every backup, imaging, and endpoint security product that legitimately reads raw volumes, and record its binary path, code signer, parent process, service account, and schedule. Then alert on raw volume access that falls outside that baseline, such as an unsigned binary, an unexpected parent process, or access initiated from an interactive user session. Process Creation and Process Access telemetry give you the context needed to make that call. Replay your real backup jobs in a cyber range before you enable blocking under the Behavior Prevention on Endpoint mitigation. Keep each exception narrow, owned, and reviewed on a fixed cadence so that allowlists do not quietly grow into blind spots.
Which MITRE ATT&CK version should our T1006 rules target?
Pin every rule and coverage mapping to one named ATT&CK version, and record that version in the rule metadata. ATT&CK v18 was released on October 28, 2025, v19 on April 28, 2026, and v20 on October 13, 2026. Release notes show that releases can rename, deprecate, or revoke techniques. Version 19 also split the Enterprise Defense Evasion tactic into Stealth, which keeps ID TA0005, and Defense Impairment, ID TA0112, so older mappings may need review. Check the ATT&CK updates page before each planned upgrade, compare the technique and data component changes against your rules, and re-test any rule whose underlying mapping has changed.
How do we cover network devices that cannot run endpoint agents?
Most switches, firewalls, and appliances cannot host an endpoint agent, so detection has to rely on what the device logs and exports. Confirm with each vendor which management-plane events, authentication records, and configuration change logs are available, and whether they can be forwarded over syslog or an API. Forward those logs to your central pipeline, then write detections around administrative access patterns, unexpected configuration changes, and logins outside maintenance windows. Where network traffic visibility is possible, Zeek or Suricata sensors can add context. Document any gap as an accepted risk with an owner, rather than assuming the device is covered.
How do we measure T1006 detection coverage accurately?
Coverage should mean validated detection, not merely a deployed rule. Use the enterprise-attack STIX bundle for your target version to map each detection to the ATT&CK technique and to the data components it depends on, such as Process Creation, Command Execution, and Process Access. For each analytic, track four facts: whether the required data source is present and parsed, whether the rule is enabled, when it was last tested in the cyber range, and whether the test succeeded. Report coverage as the share of analytics that passed a recent test. Review the numbers each quarter so gaps surface before an assessor or incident finds them.
What should we test after changing a T1006 detection rule?
Treat every rule change as a regression test. Rerun the T1006 scenario in your cyber range and confirm that the alert still fires with the expected fields and severity. Then replay the benign backup and imaging jobs you inventoried to confirm they stay quiet. Check that log parsing still works after any field rename or agent upgrade, because a silently broken parser is one of the most common coverage failures. Confirm suppression windows and deduplication settings behave as intended, and record the test results, the ATT&CK version, and the approver in the change record before the rule goes live.
Does restricting user accounts reduce T1006 exposure?
Yes, it reduces the number of identities that can reach raw volume access, which is the intent of the User Account Management mitigation (M1018). Review membership of backup operator, administrator, and similar groups, remove standing access that is no longer needed, and confirm that service accounts used by backup software are scoped to their job. Alert on changes to those group memberships, since an added member is often the first visible sign of misuse. Confirm the exact controls your directory and identity platform support, because capabilities differ between Active Directory, Entra ID, and other identity providers.
Can our own team run T1006 detection, or do we need a partner?
Your team can run detection in-house if it has the telemetry, the staffing, and time to maintain it. Many organizations find the hardest part is ongoing validation after each ATT&CK release and each platform upgrade. DeployOpen plans, implements, and documents open-source detection platforms inside your own infrastructure, and runs cyber range rehearsals. Engagements are fixed-scope, with scope, deliverables, and timelines agreed in writing before work starts, and ongoing support is available as a retainer. Decide which responsibilities stay with your team, such as alert triage and exception approval, and ask any partner to state those boundaries in the written scope.
How DeployOpen builds T1006 detections and range scenarios
DeployOpen treats T1006 Direct volume access as a detection engineering task inside your own environment, not a generic checklist. Work starts with a written scope that names the platforms, telemetry and ATT&CK version in play, then moves through build, validation and handover.
How we scope
- Agree in writing which Windows hosts and network devices are in scope for T1006 monitoring.
- Confirm which telemetry exists today, such as Process Creation, Command Execution and Process Access, and where it is collected.
- Record the ATT&CK version the detections target, since releases can rename or revoke technique content.
How we build
- Map candidate detection logic for T1006 to Wazuh or Sigma rules, described in plain language and reviewed with your analysts.
- Tune rules against your known administrative activity so backup and disk tooling noise is documented and filtered deliberately.
- Review the ATT&CK mitigations Behavior Prevention on Endpoint and User Account Management against your current endpoint and identity controls.
How we hand over
- Deliver rule documentation with the data sources, expected fields, known false positives and the validation steps for each detection.
- Provide cyber range scenarios that rehearse T1006 detection and response in a private environment, with observed results recorded.
- Hand over runbooks that name triage steps, escalation paths and the evidence an auditor or incident lead would expect to see.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer once the initial scope is delivered.
- Re-validate T1006 detections after platform upgrades or when ATT&CK releases change related technique content.
- Quotes follow from the written scope, so ask for the included platforms, telemetry sources and handover items in each proposal.
