1200kmSECURITY RESEARCH
Loading interactive filters…

1200KM / simulation

T1485 Data Destruction — Attack Simulation

Adversaries may destroy data and files on specific systems or in large numbers on a network to interrupt availability to systems, services, and network resources. Data destruction is likely to render stored data irrecoverable by forensic techniques through overwriting files or data on local and remote drives. Common operating system file deletion commands such as del and rm often only remove pointers to files without wiping the contents of the…

Complete technique description

Adversaries may destroy data and files on specific systems or in large numbers on a network to interrupt availability to systems, services, and network resources. Data destruction is likely to render stored data irrecoverable by forensic techniques through overwriting files or data on local and remote drives.[Symantec Shamoon 2012][FireEye Shamoon Nov 2016][Palo Alto Shamoon Nov 2016][Kaspersky StoneDrill 2017][Unit 42 Shamoon3 2018][Talos Olympic Destroyer 2018] Common operating system file deletion commands such as <code>del</code> and <code>rm</code> often only remove pointers to files without wiping the contents of the files themselves, making the files recoverable by proper forensic methodology. This behavior is distinct from Disk Content Wipe and Disk Structure Wipe because individual files are destroyed rather than sections of a storage disk or the disk's logical structure.

Adversaries may attempt to overwrite files and directories with randomly generated data to make it irrecoverable.[Kaspersky StoneDrill 2017][Unit 42 Shamoon3 2018] In some cases politically oriented image files have been used to overwrite data.[FireEye Shamoon Nov 2016][Palo Alto Shamoon Nov 2016][Kaspersky StoneDrill 2017]

To maximize impact on the target organization in operations where network-wide availability interruption is the goal, malware designed for destroying data may have worm-like features to propagate across a network by leveraging additional techniques like Valid Accounts, OS Credential Dumping, and SMB/Windows Admin Shares.[Symantec Shamoon 2012][FireEye Shamoon Nov 2016][Palo Alto Shamoon Nov 2016][Kaspersky StoneDrill 2017][Talos Olympic Destroyer 2018].

In cloud environments, adversaries may leverage access to delete cloud storage objects, machine images, database instances, and other infrastructure crucial to operations to damage an organization or their customers.[Data Destruction - Threat Post][DOJ - Cisco Insider] Similarly, they may delete virtual machines from on-prem virtualized environments.

Official technique definition · Open in the interactive matrix

Parent and sub-techniques

Related pages are navigation context. Their tools, rules and lab results are not automatically inherited.

Detection telemetry and configuration

These contracts are selected through exact technique-to-data-component relationships or explicitly labelled planning overrides. Configure a collector at the relevant observation point; a telemetry name alone is not coverage.

Cloud Storage Deletion · source-mapped

DC0022 collection page — Collect bucket/container administrative deletion and final resource state. Object-delete events may be supporting context but are not the same infrastructure operation.

Providers and collection configuration

  • Choose only the lab buckets/containers and prefixes. Enable read/write data-event collection when object access is needed; management events alone are insufficient.
  • Keep administrative changes separately from object reads/writes. Set a cost budget and retention limit before enabling high-volume data logging.
  • Preserve object version/key, requesting identity, action, source address, result and request ID. Verify the collector actually receives one benign read and one benign write.

Required normalized fields: action, bucket, actor, result.

Illustrative collection event

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0022",
  "collector": "illustrative-lab-collector",
  "observation": {
    "action": "delete_bucket",
    "bucket": "lab-bucket",
    "actor": "lab-admin",
    "result": "success"
  }
}

Visibility limits: Storage metadata, listing, object access and bucket administration are different operations. Do not equate a successful request with proven exfiltration or complete content visibility.

Command Execution · source-mapped

DC0064 collection page — Collect process command lines and relevant shell/interpreter audit; shell history alone is neither complete nor tamper-resistant.

Providers and collection configuration

  • Enable Script Block Logging through the policy/configuration for the installed edition. Forward Microsoft-Windows-PowerShell/Operational for Windows PowerShell, or PowerShellCore/Operational for PowerShell 7.
  • Retain script-block ID and fragment ordering alongside process creation. Protect access to collected script text; secrets may be included.
  • On Linux, use narrowly scoped Audit execution rules for the lab account and supported architectures, and retain joined SYSCALL/EXECVE/PATH records.

Required normalized fields: interpreter, command_line, actor_uid, session_id.

Illustrative collection event

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0064",
  "collector": "illustrative-lab-collector",
  "observation": {
    "interpreter": "/bin/sh",
    "command_line": "printf LAB_TELEMETRY_CHECK",
    "actor_uid": 1000,
    "session_id": "lab-session-1"
  }
}

Visibility limits: Script content and process command lines are different signals. Logging may be partial, fragmented, filtered or disabled; never assume a command line reveals everything executed.

File Creation · source-mapped

DC0039 collection page — Scope Sysmon FileCreate (11) to the lab directory; retain the process and file path. Differentiate creation/overwrite if the sensor can.

Providers and collection configuration

  • Microsoft Sysmon: Windows event-based collection; enable the event types needed below.
  • Linux Audit: Linux alternative for supported system-call and file events; different semantics and fields.
  • Apple Endpoint Security clients: macOS alternative where the subscribed event exists; requires an entitled, approved client, not an iOS collector.
  • On a disposable Windows host, review the installed Sysmon schema and current configuration; merge scoped event filters into the existing policy rather than replacing it.
  • Forward Microsoft-Windows-Sysmon/Operational to the lab collector. Preserve event ID, timestamp, computer, process identifiers and the original event.
  • For Linux or macOS, select the equivalent sensor separately and test its emitted fields; a Windows event ID does not transfer across platforms.

Required normalized fields: process_id, path, action, size_bytes.

Illustrative collection event

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0039",
  "collector": "illustrative-lab-collector",
  "observation": {
    "process_id": 4200,
    "path": "C:\\Lab\\demo.txt",
    "action": "create",
    "size_bytes": 64
  }
}

Visibility limits: Event filtering and sensor versions change coverage. High-volume image-load and process-access collection needs tuning; endpoint events alone do not establish intent.

File Deletion · source-mapped

DC0040 collection page — Prefer Sysmon FileDeleteDetected (26) when content retention is not needed; FileDelete (23) also archives files and requires a storage/privacy plan.

Providers and collection configuration

  • Microsoft Sysmon: Windows event-based collection; enable the event types needed below.
  • Linux Audit: Linux alternative for supported system-call and file events; different semantics and fields.
  • Apple Endpoint Security clients: macOS alternative where the subscribed event exists; requires an entitled, approved client, not an iOS collector.
  • On a disposable Windows host, review the installed Sysmon schema and current configuration; merge scoped event filters into the existing policy rather than replacing it.
  • Forward Microsoft-Windows-Sysmon/Operational to the lab collector. Preserve event ID, timestamp, computer, process identifiers and the original event.
  • For Linux or macOS, select the equivalent sensor separately and test its emitted fields; a Windows event ID does not transfer across platforms.

Required normalized fields: process_id, path, action, archived.

Illustrative collection event

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0040",
  "collector": "illustrative-lab-collector",
  "observation": {
    "process_id": 4200,
    "path": "C:\\Lab\\demo.txt",
    "action": "delete",
    "archived": false
  }
}

Visibility limits: Event filtering and sensor versions change coverage. High-volume image-load and process-access collection needs tuning; endpoint events alone do not establish intent.

Process Creation · source-mapped

DC0032 collection page — Collect Sysmon ProcessCreate (1); preserve ProcessGuid and parent identifiers. Security 4688 is an alternative with separate audit/command-line settings.

Providers and collection configuration

  • Microsoft Sysmon: Windows event-based collection; enable the event types needed below.
  • Linux Audit: Linux alternative for supported system-call and file events; different semantics and fields.
  • Apple Endpoint Security clients: macOS alternative where the subscribed event exists; requires an entitled, approved client, not an iOS collector.
  • On a disposable Windows host, review the installed Sysmon schema and current configuration; merge scoped event filters into the existing policy rather than replacing it.
  • Forward Microsoft-Windows-Sysmon/Operational to the lab collector. Preserve event ID, timestamp, computer, process identifiers and the original event.
  • For Linux or macOS, select the equivalent sensor separately and test its emitted fields; a Windows event ID does not transfer across platforms.

Required normalized fields: process_guid, image, parent_image, command_line, user.

<EventFiltering>
  <ProcessCreate onmatch="include">
    <Image condition="is">C:\Windows\System32\whoami.exe</Image>
  </ProcessCreate>
</EventFiltering>

This fragment only selects the named process. It is not a complete production policy. Inspect the installed schema with sysmon64 -s; preserve existing rules, then apply the reviewed complete configuration with sysmon64 -c <configuration-file>.

Illustrative collection event

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0032",
  "collector": "illustrative-lab-collector",
  "observation": {
    "process_guid": "lab-process-001",
    "image": "C:\\Windows\\System32\\whoami.exe",
    "parent_image": "C:\\Windows\\System32\\cmd.exe",
    "command_line": "whoami",
    "user": "LAB\\analyst"
  }
}

Visibility limits: Event filtering and sensor versions change coverage. High-volume image-load and process-access collection needs tuning; endpoint events alone do not establish intent.

Process Termination · source-mapped

DC0033 collection page — Collect Sysmon ProcessTerminate (5) and join on ProcessGuid; do not assume every provider records an exit code.

Providers and collection configuration

  • Microsoft Sysmon: Windows event-based collection; enable the event types needed below.
  • Linux Audit: Linux alternative for supported system-call and file events; different semantics and fields.
  • Apple Endpoint Security clients: macOS alternative where the subscribed event exists; requires an entitled, approved client, not an iOS collector.
  • On a disposable Windows host, review the installed Sysmon schema and current configuration; merge scoped event filters into the existing policy rather than replacing it.
  • Forward Microsoft-Windows-Sysmon/Operational to the lab collector. Preserve event ID, timestamp, computer, process identifiers and the original event.
  • For Linux or macOS, select the equivalent sensor separately and test its emitted fields; a Windows event ID does not transfer across platforms.

Required normalized fields: process_guid, process_id, action.

Illustrative collection event

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0033",
  "collector": "illustrative-lab-collector",
  "observation": {
    "process_guid": "lab-process-001",
    "process_id": 4200,
    "action": "terminate"
  }
}

Visibility limits: Event filtering and sensor versions change coverage. High-volume image-load and process-access collection needs tuning; endpoint events alone do not establish intent.

Volume Deletion · source-mapped

DC0098 collection page — Collect volume-delete APIs and final state; join backup/attachment inventory to assess consequences.

Providers and collection configuration

  • In the isolated account/project/subscription, route administrative audit logs to a protected destination with retention and access controls.
  • Select the relevant service, regions and read/write operations. Confirm whether the API below is a management or data event in the provider documentation.
  • Preserve actor/session, resource, request ID, service, operation, region and error details. Check delivery latency and avoid logging credentials or sensitive request bodies.

Required normalized fields: volume_id, action, actor, result.

Illustrative collection event

Project-normalized synthetic JSON, not a native provider log, captured event, attack verdict or validated detection. A parser/adapter is required for a real SIEM. Example names, IPs and values are fictional.

{
  "schema": "1200km.telemetry.example.v1",
  "synthetic": true,
  "timestamp": "2026-09-27T12:00:00Z",
  "telemetry_id": "DC0098",
  "collector": "illustrative-lab-collector",
  "observation": {
    "volume_id": "vol-lab-1",
    "action": "delete",
    "actor": "lab-admin",
    "result": "requested"
  }
}

Visibility limits: AWS, Azure and Google expose different APIs and event schemas. An accepted API request does not prove the final resource state; join asynchronous outcomes and inventory.

Detection rules and analytic guidance

Open the dedicated detection workspace · Existing query engineering

DET0146 Detection of Data Destruction Across Platforms via Mass Overwrite and Deletion Patterns

MITRE detection strategy

AN0411 Analytic 0411

Adversary spawns command-line tools (e.g., del, cipher /w, SDelete) or scripts to recursively delete or overwrite user/system files. This may be correlated with abnormal file IO activity, registry writes, or tampering in critical system directories.

Platforms: Windows.

AN0412 Analytic 0412

Massive recursive deletions or overwrites via `rm -rf`, `shred`, `dd`, or wiper binaries. May include unlink syscalls, deletion of known config/data paths, or sequential overwrite patterns.

Platforms: Linux.

AN0413 Analytic 0413

Destruction via `rm -rf`, overwrite with `dd` or `srm`, often executed by script in /tmp or /private/tmp, may also involve file overwrite to political or decoy image data.

Platforms: macOS.

AN0414 Analytic 0414

Adversary deletes critical infrastructure: EC2 instances, S3 buckets, snapshots, or volumes using elevated IAM credentials. Frequently includes batch API calls with `Delete*` or `TerminateInstances`.

Platforms: IaaS.

  • Cloud Storage Deletion — AWS:CloudTrail; channel DeleteBucket, DeleteDBCluster, DeleteSnapshot, TerminateInstances.

AN0415 Analytic 0415

Adversary destroys virtual disks (VMDK), images, or VMs by invoking `vim-cmd`, deleting datastore contents, or purging snapshots.

Platforms: ESXi.

AN0416 Analytic 0416

Container process executes destructive file operations inside volume mounts or host paths. Includes `rm -rf /mnt/volumes/`, container breakout followed by host deletion attempts.

Platforms: Containers.

  • File Deletion — auditd:SYSCALL; channel unlink, unlinkat, rmdir.
  • Command Execution — docker:events; channel container exec rm|container stop --force.
Source rule directory and observation requirements

19 exact-tagged source rules. A source tag is a discovery aid, not a relevance verdict. Check the observation point and actual condition of each rule.

Before treating a rule as coverage

  1. Read the actual condition and logsource; identify attacker-side, victim-side or third-party visibility.
  2. Map native sensor fields, parse times and identities, then compile for the selected backend.
  3. Replay a behavior-positive case, a normal control, an authorized look-alike and a missing-telemetry case.
  4. Record matches and misses with rule version and source events. No match is inconclusive when required telemetry is absent.

Anomaly-based detection

Anomaly engineering worksheet

Start from the exact analytic above. The collection-specific lenses below are analyst recommendations; they do not assert that an arbitrary statistical deviation detects this technique.

  • Cloud storage: Per principal and bucket/container: unusual object-read counts, transferred volume, new access pairs and bulk permission/deletion activity. Model backups, migrations and lifecycle policies separately.
  • Script and command execution: Per host role and principal: rare interpreters, command argument patterns and parent-child sequences. Normalize scripts carefully; obfuscation, administrative automation and missing command lines change visibility.
  • Endpoint activity: Per host role and user: rare process/object combinations, bursts of object access or modification, and ordered parent/action sequences. Compare maintenance windows and signed software rollout activity.
  • Cloud control plane: Per account, role, region and API: rare actions, new role-resource relationships, enumeration bursts and configuration changes. Separate deployment automation and organization-level administrative activity.
  1. Define an entity/peer group and feature; exclude the evaluation period from baseline training.
  2. Use representative normal and maintenance activity. Do not invent a production threshold from a synthetic example.
  3. Evaluate held-out behavior-positive and benign cases; measure false positives, misses and telemetry loss separately.
  4. Keep abnormality separate from maliciousness. Correlate with the behavior-specific source evidence.

Anomaly Detection Atlas · Baseline, validation and blind spots

Attack tools and documented software

Software observed in source procedures

These are exact ATT&CK software-use relationships, including malware. They provide behavior context, not recommendations to download or execute malware. No safety or detector claim is inherited.

30 source-documented software associations

Simulation design and documented procedures

Atomic evidence: 5 compatible documented candidates. Live lab status: not run for these imported procedures.

Use disposable lab hosts and test accounts, explicit target allowlists, a clean snapshot, bounded egress and a restore plan. Review every candidate and dependency before any execution.

ESXi - Delete VM Snapshots

Deletes all snapshots for all Virtual Machines on an ESXi Host Reference

Pinned Atomic procedure · 1207ddff-f25b-41b3-aa0e-7c26d2b546d1 · windows · command_prompt.

Elevation: not declared required. Cleanup: not declared. This is source documentation, not an execution approval.

Source-defined inputs

  • vm_host: Specify the host name or IP of the ESXi server. (type string; source default atomic.local)
  • vm_user: Specify the privilege user account on the ESXi server. (type string; source default root)
  • vm_pass: Specify the privileged user's password. (type string; source default password)
  • plink_file: Path to Plink (type path; source default PathToAtomicsFolder\..\ExternalPayloads\plink.exe)

Review the upstream command, dependencies and cleanup at the source link. Source defaults may refer to real infrastructure or destructive actions; they are not authorized targets. No automatic install, prerequisite download or command execution is provided.

1 prerequisite definitions:

  • Check if we have plink
Overwrite deleted data on C drive

RansomEXX malware removes all deleted files using windows built-in cipher.exe to prevent forensic recover.
This process is very slow and test execution may timeout.
https://www.cybereason.com/blog/cybereason-vs.-ransomexx-ransomware
https://support.microsoft.com/en-us/topic/cipher-exe-security-tool-for-the-encrypting-file-system-56c85edd-85cf-ac07-f2f7-ca2d35dab7e4

Pinned Atomic procedure · 321fd25e-0007-417f-adec-33232252be19 · windows · command_prompt.

Elevation: not declared required. Cleanup: not declared. This is source documentation, not an execution approval.

No input arguments declared.

Review the upstream command, dependencies and cleanup at the source link. Source defaults may refer to real infrastructure or destructive actions; they are not authorized targets. No automatic install, prerequisite download or command execution is provided.

FreeBSD/macOS/Linux - Overwrite file with DD

Overwrites and deletes a file using DD.
To stop the test, break the command with CTRL/CMD+C.

Pinned Atomic procedure · 38deee99-fd65-4031-bec8-bfa4f9f26146 · linux, macos · sh.

Elevation: not declared required. Cleanup: not declared. This is source documentation, not an execution approval.

Source-defined inputs

  • overwrite_source: Path of data source to overwrite with (type path; source default /dev/zero)
  • file_to_overwrite: Path of file to overwrite and remove (type path; source default /var/log/syslog)

Review the upstream command, dependencies and cleanup at the source link. Source defaults may refer to real infrastructure or destructive actions; they are not authorized targets. No automatic install, prerequisite download or command execution is provided.

Windows - Overwrite file with SysInternals SDelete

Overwrites and deletes a file using SysInternals SDelete. Upon successful execution, "Files deleted: 1" will be displayed in
the powershell session along with other information about the file that was deleted.

Pinned Atomic procedure · 476419b5-aebf-4366-a131-ae3e8dae5fc2 · windows · powershell.

Elevation: not declared required. Cleanup: not declared. This is source documentation, not an execution approval.

Source-defined inputs

  • sdelete_exe: Path of sdelete executable (type path; source default PathToAtomicsFolder\..\ExternalPayloads\Sdelete\sdelete.exe)
  • file_to_delete: Path of file to delete (type path; source default PathToAtomicsFolder\..\ExternalPayloads\T1485.txt)

Review the upstream command, dependencies and cleanup at the source link. Source defaults may refer to real infrastructure or destructive actions; they are not authorized targets. No automatic install, prerequisite download or command execution is provided.

1 prerequisite definitions:

  • Secure delete tool from SysInternals must exist on disk at specified location (#{sdelete_exe})
GCP - Delete Bucket

This Atomic will create a Google Storage Bucket then delete it. The idea for this Atomic came from a Rule published by the Elastic team.

Identifies when a Google Cloud Platform (GCP) storage bucket is deleted. An adversary may delete a storage bucket in order to disrupt their target's business operations.
This atomic will create a bucket then delete the bucket.

Reference: https://github.com/elastic/detection-rules/blob/main/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml

Pinned Atomic procedure · 4ac71389-40f4-448a-b73f-754346b3f928 · iaas:gcp · sh.

Elevation: not declared required. Cleanup: defined upstream; review required. This is source documentation, not an execution approval.

Source-defined inputs

  • project_id: ID of the GCP Project you to execute the command against. (type string; source default atomic-test-1)
  • bucket_name: The name of the bucket to delete. (type string; source default atomic-red-team-bucket)

Review the upstream command, dependencies and cleanup at the source link. Source defaults may refer to real infrastructure or destructive actions; they are not authorized targets. No automatic install, prerequisite download or command execution is provided.

4 prerequisite definitions:

  • Requires gcloud
  • Check if user is logged in
  • Check if terraform is installed.
  • Create dependency resources using terraform

Technique-specific experiment contract

  1. Choose one procedure implementing T1485 Data Destruction; identify the observable behavior in the source definition, not just its tactic.
  2. Record exact target, tool/version, inputs, privileges, network limits and approval. Never run an imported default target automatically.
  3. Enable the collection sources above and verify a benign baseline reaches the detector.
  4. Run only the approved isolated scenario; capture native events and an independent behavior observable.
  5. Evaluate the exact rule/model, restore the lab, and preserve configuration, event hashes, alerts, controls and misses.

Synthetic logs and offline contract check

Download synthetic collection fixture (JSON) · Download the complete engineering workbook

This fixture exercises the listed collection fields. It does not reproduce Data Destruction, label its example events as malicious, or measure detection effectiveness. Use the exact analytic and selected procedure to build an independently labelled behavior-positive dataset.

Not run in this browser. No network scan or attack command is executed by this control.

Validation status and remaining work

Source identity
Joined by exact technique/object IDs against hash-pinned sources.
Collection fixture
Available for offline schema exercises; not attack emulation.
Native telemetry / backend / real attack
Not validated for these imported procedures. Source fidelity and page tests cannot establish sensor or detector effectiveness.

All-page audit and evidence inventory · This page’s machine-readable workbook

Sources and evidence boundaries

Pinned MITRE STIX source · SHA-256 81113ba98afa2928f3dcff62022539f7ce30c315c32e14422f11ff95ce534352. Definition and procedure context are reproduced from this snapshot, not independently re-investigated incidents.

Source-linked mitigations
  • M1018 User Account Management

    In cloud environments, limit permissions to modify cloud bucket lifecycle policies (e.g., `PutLifecycleConfiguration` in AWS) to only those accounts that require it. In AWS environments, consider using Service Control policies to limit the use of the `PutBucketLifecycle` API call.

  • M1032 Multi-factor Authentication

    Implement multi-factor authentication (MFA) delete for cloud storage resources, such as AWS S3 buckets, to prevent unauthorized deletion of critical data and infrastructure. MFA delete requires additional authentication steps, making it significantly more difficult for adversaries to destroy data without proper credentials. This additional security layer helps protect against the impact of data destruction in cloud environments by ensuring that only authenticated actions can irreversibly delete storage or machine images.

  • M1053 Data Backup

    Consider implementing IT disaster recovery plans that contain procedures for taking regular data backups that can be used to restore organizational data.[Ready.gov IT DRP] Ensure backups are stored off system and protected from common methods adversaries may use to gain access and destroy the backups to prevent recovery.

Connected ecosystem references

Linked tags

enterprisecloudcloud-hosted-endpointcontainersonpremvirtualizationContainersESXiIaaSLinuxmacOSWindowsimpactisolated_authorized_labprocedure_review_requiredtelemetry_configuration_requireddisposable_tenant_and_cost_controlspotential_disruption_requires_individual_review
Atomic candidate documentedtechniquesource_mapped

Source procedure platform / method / executor tags:

windowsautomatedcommand_promptlinuxmacosshpowershelliaas:gcp

Detection and collection

T1485 detection workspace

Threat actor context

These are explicit actor-to-technique associations in the existing Threat Matrix snapshot, not attribution of an event or proof that a detector identifies the actor. No tool-to-actor relationship is inferred.

Existing research

Threat Matrix: knowledge routes, evidence and actor context

Connected anomaly research

Curated research views reached through an exact source technique, a catalog model, or a reviewed collection reference. These are navigation associations, not claims of detector effectiveness or sensor equivalence.

Telemetry contracts · Maintained query examples · Validation and blind spots

Pinned research references. No browser attack runner or production-validated detector is asserted. Imported procedures remain unvalidated; any bounded lab evidence has its own scope. ATT&CK / Atomic provenance · Detection provenance.