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 Access · source-mapped
DC0025 collection page — Explicitly select relevant object-read data events; keep principal, key, request ID and result without object contents.
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, key, actor, result.
[
{
"Name": "LabObjectReads",
"FieldSelectors": [
{
"Field": "eventCategory",
"Equals": [
"Data"
]
},
{
"Field": "resources.type",
"Equals": [
"AWS::S3::Object"
]
},
{
"Field": "resources.ARN",
"StartsWith": [
"arn:aws:s3:::lab-bucket/demo/"
]
},
{
"Field": "readOnly",
"Equals": [
"true"
]
}
]
}
]
Replace the placeholder with an owned lab bucket/prefix. Review costs and merge with required selectors; applying selectors can replace an existing selection. This does not enable management-event retention or object-write coverage.
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": "DC0025",
"collector": "illustrative-lab-collector",
"observation": {
"action": "get_object",
"bucket": "lab-bucket",
"key": "demo.txt",
"actor": "lab-reader",
"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.
Cloud Storage Enumeration · source-mapped
DC0017 collection page — Log list operations at the applicable API layer and preserve target prefix, caller, pagination and outcome; check event-selector support for the specific API.
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, prefix, 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": "DC0017",
"collector": "illustrative-lab-collector",
"observation": {
"action": "list_objects",
"bucket": "lab-bucket",
"prefix": "demo/",
"actor": "lab-reader",
"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.
Simulation design and documented procedures
Atomic evidence: 4 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.
Azure - Enumerate Storage Account Objects via Shared Key authorization using Azure CLI
This test enumerates all existing storage accounts and tries to fetch for each account the contained storage account objects. The access to storage objects is only possible if Shared Key authorization is enabled (e.g this is the case per default for storage objects creaded by Azure Function Apps).
Requirements:
- The test is intended to be executed in interactive mode (with -Interactive parameter) in order to complete the az login command when MFA is required.
- The EntraID user must have the role "Storage Account Contributor", or a role with similar permissions.
Output format: Csv file that contains the found storage account objects
- Columns: ResourceGroup, StorageAccountName, FileShareName, ContainerName, BlobName, TableName, QueueName
- The content of these columns is filled out depending on the object. Not-required columns are left empt. Example: For a blob object the ResourceGroup, StorageAccountName, ContainerName, BlobName are filled out, the other fields are left empty.
Pinned Atomic procedure · 070322a4-2c60-4c50-8ffb-c450a34fe7bf · iaas:azure · powershell.
Elevation: not declared required. Cleanup: defined upstream; review required. This is source documentation, not an execution approval.
output_file: Csv file path for results (type path; source default $env:temp\T1619_storage_account_objects.csv)
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:
- Azure CLI must be installed
Azure - Scan for Anonymous Access to Azure Storage (Powershell)
Upon successful execution, this test will test for anonymous access to Azure storage containers by invoking a web request and outputting the results to a file.
The corresponding response could then be interpreted to determine whether or not the resource/container exists, as well as other information.
See https://ninocrudele.com/the-three-most-effective-and-dangerous-cyberattacks-to-azure-and-countermeasures-part-2-attack-the-azure-storage-service
Pinned Atomic procedure · 146af1f1-b74e-4aa7-9895-505eb559b4b0 · iaas:azure · powershell.
Elevation: not declared required. Cleanup: defined upstream; review required. This is source documentation, not an execution approval.
base_name: Azure storage account name to test (type string; source default T1619Test2)output_file: File to output results to (type string; source default $env:temp\T1619Test2.txt)container_name: Container name to search for (optional) (type string; source default blob_name: Blob name to search for (optional) (type string; source default
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.
AWS S3 Enumeration
This test will enumerate all the S3 buckets in the user account and lists all the files in each bucket.
Pinned Atomic procedure · 3c7094f8-71ec-4917-aeb8-a633d7ec4ef5 · iaas:aws · sh.
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.
1 prerequisite definitions:
- Check if ~/.aws/credentials file has a default stanza is configured
Azure - Enumerate Azure Blobs with MicroBurst
Upon successful execution, this test will utilize a wordlist to enumerate the public facing containers and blobs of a specified Azure storage account.
See https://www.netspi.com/blog/technical/cloud-penetration-testing/anonymously-enumerating-azure-file-resources/ .
Pinned Atomic procedure · 3dab4bcc-667f-4459-aea7-4162dd2d6590 · iaas:azure · powershell.
Elevation: not declared required. Cleanup: defined upstream; review required. This is source documentation, not an execution approval.
base: Azure blob keyword to enumerate (Example, storage account name) (type string; source default secure)output_file: File to output results to (type string; source default $env:temp\T1619Test1.txt)wordlist: File path to keywords for search permutations (type string; source default PathToAtomicsFolder\..\ExternalPayloads\permutations.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.
2 prerequisite definitions:
- The Invoke-EnumerateAzureBlobs module must exist in PathToAtomicsFolder\..\ExternalPayloads.
- The wordlist file for search permutations must exist in PathToAtomicsFolder\..\ExternalPayloads.
Technique-specific experiment contract
- Choose one procedure implementing T1619 Cloud Storage Object Discovery; identify the observable behavior in the source definition, not just its tactic.
- Record exact target, tool/version, inputs, privileges, network limits and approval. Never run an imported default target automatically.
- Enable the collection sources above and verify a benign baseline reaches the detector.
- Run only the approved isolated scenario; capture native events and an independent behavior observable.
- Evaluate the exact rule/model, restore the lab, and preserve configuration, event hashes, alerts, controls and misses.