# Linux Data Acquisition Guide

**Methods:** 38 | **Generated:** 2026-03-07

---

## Physical Acquisition

### dd / dc3dd Raw Disk Image

Create a bit-for-bit raw image of a Linux disk using dd or its forensic-enhanced variant dc3dd, which adds built-in hashing, progress reporting, and error handling.

**Tools:** dd, dc3dd

**Prerequisites:**
- Hardware write blocker or forensic boot media
- Destination storage >= source disk size
- Root/sudo access on the forensic workstation

**Steps:**
1. Connect the target drive to the forensic workstation via write blocker (or use a live forensic boot).
2. Identify the device: lsblk or fdisk -l
3. Run: dc3dd if=/dev/sdX of=/evidence/case001.dd hash=sha256 log=acquisition.log
4. Monitor progress and wait for completion.
5. Verify the hash in the log file matches a separate manual hash.

**Pros:** Pre-installed on virtually all Linux systems | dc3dd adds hashing, logging, and split output | Raw format universally compatible with forensic tools
**Cons:** Raw format has no compression -- output equals source size | dd has no built-in error handling (dc3dd addresses this) | Command-line errors can overwrite the source (double-check if= and of=)
**Notes:** CRITICAL: Always double-check the if= (input) and of= (output) parameters before executing dd. A reversal will destroy the evidence. Use dc3dd for all forensic work.

### dcfldd Forensic Disk Image

DoD Computer Forensics Lab enhanced version of dd with forensic features including on-the-fly hashing, split output, and status reporting.

**Tools:** dcfldd

**Prerequisites:**
- dcfldd installed on forensic workstation
- Hardware write blocker
- Root access

**Steps:**
1. Connect target drive via write blocker.
2. Run: dcfldd if=/dev/sdX of=/evidence/case001.dd hash=sha256 hashlog=hashes.txt statusinterval=256
3. Wait for completion and verify hashes.

**Pros:** Built-in hashing during acquisition | Status/progress reporting | Split output file support for large disks | Pattern wiping capability for drive sanitization
**Cons:** Less actively maintained than dc3dd | Raw format only -- no compression
**Notes:** dcfldd and dc3dd serve similar purposes. Choose whichever is available on your forensic platform. Both are superior to plain dd for forensic work.

### ewfacquire E01 Disk Image

Use the libewf ewfacquire tool to create compressed E01 (Expert Witness Format) forensic images from Linux systems with built-in hashing and case metadata.

**Tools:** ewfacquire (libewf)

**Prerequisites:**
- libewf-tools installed
- Hardware write blocker
- Root access

**Steps:**
1. Install libewf-tools if not present: apt install ewf-tools
2. Connect target drive via write blocker.
3. Run: ewfacquire -t evidence /dev/sdX
4. Enter case metadata when prompted (case number, examiner, description).
5. Configure compression level and segment size.
6. Wait for acquisition to complete.
7. Verify hash upon completion.

**Pros:** E01 format with compression reduces storage requirements | Embedded case metadata and hash verification | Compatible with EnCase, FTK, Autopsy, and other tools | Free and open-source
**Cons:** Slower than raw dd due to compression overhead | Requires libewf installation
**Notes:** E01 format is preferred when storage space is limited. The compression ratio typically achieves 30-50% reduction depending on disk contents.

### Guymager Full Disk Image

Multi-threaded GUI forensic imager for Linux. Creates E01, AFF, or raw images with simultaneous hash computation.

**Tools:** Guymager

**Prerequisites:**
- Linux GUI environment (forensic distro recommended)
- Hardware write blocker

**Steps:**
1. Launch Guymager (included in CAINE, SIFT, Paladin).
2. Connect target drive via write blocker.
3. Right-click the target device and select "Acquire image".
4. Configure format, case metadata, hash algorithms, and destination.
5. Start acquisition and monitor multi-threaded progress.
6. Verify hashes upon completion.

**Pros:** Multi-threaded -- fastest open-source imaging tool | GUI interface reduces operator error | Supports E01, AFF, and raw formats
**Cons:** Requires X11/GUI environment | Not suitable for headless server acquisition
**Notes:** Preferred tool for forensic labs processing multiple drives due to its speed and ease of use.

## Logical Acquisition

### tar Logical Collection

Use tar to create compressed archives of specific directories or files for targeted forensic collection when full disk imaging is not feasible.

**Tools:** tar, sha256sum

**Prerequisites:**
- Root access for system directories
- Mount evidence partition with noatime to preserve timestamps

**Steps:**
1. Identify target directories for collection.
2. Run: tar czf /evidence/case001-logs.tar.gz /var/log/ /etc/ /home/
3. Generate hash: sha256sum /evidence/case001-logs.tar.gz > /evidence/case001-logs.sha256
4. Transfer the archive and hash to forensic storage.

**Pros:** Available on every Linux system without installation | Preserves file permissions, ownership, and timestamps | Compression reduces transfer size
**Cons:** Does not capture deleted files or unallocated space | File timestamps may be modified during access (use noatime mount) | No built-in forensic metadata or chain of custody
**Notes:** Always mount the source filesystem with noatime (or ro) before tar collection to preserve access timestamps. Document the exact tar command used for reproducibility.

### rsync Targeted Collection

Use rsync to efficiently copy specific files and directories while preserving metadata. Useful for remote collection over SSH.

**Tools:** rsync, sha256sum

**Prerequisites:**
- rsync installed on both source and destination
- SSH access for remote collection
- Root access for system files

**Steps:**
1. For local collection: rsync -avz --progress /source/ /evidence/destination/
2. For remote collection: rsync -avz -e ssh user@target:/var/log/ /evidence/target-logs/
3. Generate hashes of collected files.
4. Document the rsync command and transfer log.

**Pros:** Preserves timestamps, permissions, and ownership | Efficient incremental transfer -- only copies changes | Native SSH support for remote collection | Resumable transfers for large datasets
**Cons:** Does not capture deleted files or slack space | May trigger IDS alerts if used over network
**Notes:** rsync with --checksum flag provides additional verification. Use --dry-run first to preview what will be collected.

## Memory Acquisition

### LiME (Linux Memory Extractor)

LiME is a loadable kernel module (LKM) that captures full physical memory from Linux systems. The gold standard for Linux memory acquisition.

**Tools:** LiME

**Prerequisites:**
- LiME .ko compiled for target kernel (uname -r)
- Root access on the target
- Sufficient storage or network path for the dump

**Steps:**
1. Pre-compile the LiME kernel module for the target kernel version.
2. Transfer the .ko module to the target system.
3. Load the module: insmod lime-$(uname -r).ko "path=/evidence/memory.lime format=lime"
4. Wait for the memory dump to complete.
5. Verify file size matches system RAM.
6. Transfer the dump to the forensic workstation.

**Pros:** Minimal footprint on the target system | Dumps memory directly to file, network, or both | LiME format supported by Volatility and other frameworks | Free and open-source
**Cons:** Must be compiled for the exact target kernel version | Loading a kernel module modifies system state | May fail on systems with Secure Boot or module signing enforcement
**Notes:** Pre-compile LiME modules for all kernel versions in your environment and store them in your IR toolkit. For network dumping: insmod lime.ko "path=tcp:4444 format=lime" and receive with nc.

### AVML (Acquire Volatile Memory for Linux)

Microsoft AVML is a portable memory acquisition tool for Linux that works without kernel module compilation. Uses /dev/crash or /proc/kcore as memory sources.

**Tools:** AVML

**Prerequisites:**
- Root access on the target
- AVML binary for the target architecture

**Steps:**
1. Download the pre-compiled AVML binary for the target architecture.
2. Transfer to the target system.
3. Run: ./avml /evidence/memory.lime
4. Wait for the dump to complete.
5. Transfer the dump for analysis.

**Pros:** No kernel module compilation required | Single static binary -- no dependencies | Works across multiple kernel versions | Supports compressed output
**Cons:** Requires /dev/crash or /proc/kcore access | May not work on all kernel configurations | Newer kernels may restrict /proc/kcore access
**Notes:** AVML is the best option when you cannot pre-compile LiME for the target kernel. Keep both tools in your IR toolkit as fallbacks for each other.

### /proc/kcore Memory Extraction

Extract physical memory through the /proc/kcore pseudo-file, which presents system memory as an ELF core dump. A last-resort method when dedicated tools are unavailable.

**Tools:** dd, gdb

**Prerequisites:**
- Root access
- /proc/kcore enabled in kernel configuration

**Steps:**
1. Verify /proc/kcore is accessible: ls -la /proc/kcore
2. Use dd to copy: dd if=/proc/kcore of=/evidence/kcore.dump bs=1M
3. Alternatively, use gdb to selectively dump memory regions.
4. Transfer the dump for analysis.

**Pros:** No additional tools required -- uses built-in kernel interface | Available on most Linux systems
**Cons:** /proc/kcore may be disabled on hardened systems | ELF format requires conversion for some analysis tools | May not capture all physical memory regions | Kernel ASLR affects memory mapping
**Notes:** This is a fallback method when LiME and AVML are not available. The output requires more effort to analyze compared to LiME format dumps.

## Triage Acquisition

### Velociraptor Offline Collector (Linux)

Build and deploy a Velociraptor offline collector for Linux to capture targeted forensic artifacts without server infrastructure.

**Tools:** Velociraptor

**Prerequisites:**
- Velociraptor binary for building the collector
- Root access on target systems

**Steps:**
1. Build the offline collector from the Velociraptor server with Linux artifact selections.
2. Deploy the collector binary to the target system.
3. Run: ./collector --output /evidence/collection.zip
4. Transfer the output for analysis.

**Pros:** Self-contained binary | Customizable artifact collection | Encrypted output support | Free and open-source
**Cons:** Requires Velociraptor to build the collector | Binary may be flagged by security tools
**Notes:** Include Linux-specific artifacts like /var/log/auth.log, cron configurations, .bash_history, and systemd service files in the collector.

### UAC (Unix-like Artifacts Collector)

UAC is a free, open-source tool designed specifically for collecting forensic artifacts from Unix-like systems including Linux, macOS, and BSD.

**Tools:** UAC

**Prerequisites:**
- Root access on the target
- Bash shell available

**Steps:**
1. Download or clone the UAC repository.
2. Transfer the UAC directory to the target system.
3. Run: ./uac -p full /evidence/output
4. UAC collects system info, logs, user artifacts, network state, and process data.
5. Transfer the output archive for analysis.

**Pros:** Purpose-built for Unix/Linux forensics | Comprehensive artifact collection with multiple profiles | No compilation or dependencies required (shell script) | Supports Linux, macOS, FreeBSD, Solaris, and AIX
**Cons:** Shell-based -- slower than compiled tools | May modify access timestamps during collection
**Notes:** UAC is the de facto standard for Linux/Unix triage collection. The "full" profile is recommended for comprehensive collection. Use "ir" profile for faster targeted response.

### CyLR Triage Collection (Linux)

CyLR cross-platform triage collector for rapid forensic artifact collection from Linux systems.

**Tools:** CyLR

**Prerequisites:**
- CyLR binary for Linux
- Root access

**Steps:**
1. Download the CyLR Linux binary.
2. Run with sudo on the target system.
3. CyLR collects common forensic artifacts automatically.
4. Output ZIP file contains collected artifacts.
5. Transfer for analysis.

**Pros:** Cross-platform consistency with Windows version | Minimal configuration | SFTP upload support
**Cons:** Smaller Linux artifact coverage than UAC | Less actively maintained
**Notes:** Consider UAC as the primary Linux triage tool and CyLR as a cross-platform fallback.

## Remote Acquisition

### Velociraptor Remote Collection (Linux)

Use Velociraptor with deployed Linux agents for remote forensic collection, live response, and threat hunting.

**Tools:** Velociraptor

**Prerequisites:**
- Velociraptor server and Linux agents deployed
- Network connectivity

**Steps:**
1. Ensure Velociraptor agents are deployed to target Linux endpoints.
2. Access the Velociraptor web console.
3. Navigate to the target client.
4. Launch Linux-specific artifact collections.
5. Monitor and download results.

**Pros:** Enterprise-scale remote collection | Powerful VQL for custom queries | Real-time endpoint visibility
**Cons:** Requires pre-deployed agents | Server infrastructure needed
**Notes:** Velociraptor supports Linux-specific artifacts including /var/log parsing, crontab enumeration, systemd analysis, and container inspection.

### SSH + dd Remote Disk Image

Create a remote forensic disk image by piping dd output over SSH to the forensic workstation. Works when physical access is not possible.

**Tools:** dd, SSH, dc3dd

**Prerequisites:**
- Root SSH access to the target
- Sufficient bandwidth for the disk size
- Forensic workstation with adequate storage

**Steps:**
1. From the forensic workstation: ssh root@target "dc3dd if=/dev/sda" | dc3dd of=/evidence/target.dd hash=sha256
2. Alternatively: ssh root@target "dd if=/dev/sda bs=4M" > /evidence/target.dd
3. Generate separate hash of the received image.
4. Verify hash consistency.

**Pros:** No additional tools needed on the target beyond dd and SSH | Encrypted transfer via SSH | Works over any network connection
**Cons:** Slow over WAN connections for large disks | Network interruption can corrupt the image | dd on the source is not write-blocked
**Notes:** Use screen or tmux on the target to prevent SSH timeout issues. Consider adding compression: ssh root@target "dd if=/dev/sda | gzip" > target.dd.gz for bandwidth-constrained links.

## Container Acquisition

### Docker Container Export

Export the complete filesystem of a running or stopped Docker container for forensic analysis using docker export.

**Tools:** Docker CLI

**Prerequisites:**
- Docker CLI access on the container host
- Permissions to interact with the Docker daemon

**Steps:**
1. Identify the target container: docker ps -a
2. Export the container filesystem: docker export container_id > /evidence/container.tar
3. Generate hash: sha256sum /evidence/container.tar > /evidence/container.sha256
4. Optionally save the container image: docker save image_name > /evidence/image.tar
5. Transfer archives for analysis.

**Pros:** Captures the complete container filesystem as a flat tar archive | Works on running and stopped containers | docker save preserves image layers for analysis
**Cons:** docker export flattens layers -- loses layer history | Does not capture container memory or process state | Requires Docker CLI access on the host
**Notes:** Use "docker export" for the current filesystem state and "docker save" for the full image with layer history. Combine with "docker inspect" and "docker logs" for complete container forensics.

### Docker cp Targeted Collection

Use docker cp to selectively copy specific files or directories from a container for targeted forensic collection.

**Tools:** Docker CLI

**Prerequisites:**
- Docker CLI access
- Knowledge of relevant file paths within the container

**Steps:**
1. Identify target files within the container.
2. Copy files: docker cp container_id:/var/log/ /evidence/container-logs/
3. Copy specific file: docker cp container_id:/etc/passwd /evidence/
4. Generate hashes of collected files.
5. Document which files were collected and which were excluded.

**Pros:** Targeted collection of specific artifacts | Works on running containers without disruption | Fast for small targeted collections
**Cons:** Manual file selection may miss evidence | Does not capture deleted files within the container
**Notes:** Use docker cp for rapid triage of known artifact locations, then follow up with docker export for complete collection if needed.

### Kubernetes Container Checkpoint

Use Kubernetes checkpoint API or CRI-O checkpoint to capture a forensic snapshot of a running container including process state.

**Tools:** kubectl, crictl, CRI-O

**Prerequisites:**
- Kubernetes cluster access with appropriate RBAC
- Container runtime supporting checkpoint (CRI-O recommended)
- Checkpoint feature gate enabled (Kubernetes)

**Steps:**
1. Identify the target pod and container: kubectl get pods -o wide
2. For CRI-O runtime: crictl checkpoint --export=/evidence/checkpoint.tar container_id
3. For containerd: use ctr to snapshot the container.
4. Copy the checkpoint archive to forensic storage.
5. Analyze the checkpoint contents including process memory and filesystem state.

**Pros:** Captures running process state including memory | Non-destructive to the running container | Preserves container network connections and open files
**Cons:** Checkpoint API requires Kubernetes 1.25+ with feature gate enabled | Not all container runtimes support checkpointing | Analysis tooling for checkpoints is still maturing
**Notes:** Container forensics is an evolving field. Document your checkpoint methodology thoroughly as legal precedent is still being established.

### Kubernetes Resource Inventory Export

Export a point-in-time Kubernetes inventory covering workloads, RBAC, service accounts, events, and high-value resource definitions.

**Tools:** kubectl, jq, tar

**Prerequisites:**
- kubectl access with sufficient RBAC to read the required resources

**Steps:**
1. Export cluster resources: kubectl get all,configmap,secret,serviceaccount,role,rolebinding,clusterrole,clusterrolebinding -A -o yaml > k8s_inventory.yaml
2. Export current pod placement and node context: kubectl get pods -A -o wide > k8s_pods_wide.txt
3. Export chronological events: kubectl get events -A --sort-by=.metadata.creationTimestamp > k8s_events.txt
4. Hash the YAML and text exports and preserve the kubeconfig or auth context used for collection.

**Pros:** Rapid cluster-wide state capture | Useful for scoping workloads, identities, and RBAC abuse | Complements audit and node-level logs
**Cons:** Point-in-time only; deleted objects may already be gone | Secret export may require tighter handling and approval
**Notes:** Collect this as early as possible. Attackers often delete workloads or alter RBAC quickly after discovery.
**Collection Constraints:** This is a point-in-time inventory and cannot recover deleted objects that disappeared before collection. | Secrets and sensitive configuration in the export may require tighter handling and approval workflows.

### containerd State and Snapshot Export

Collect containerd runtime state, namespaces, snapshots, and configuration from a Linux container host or Kubernetes node.

**Tools:** ctr, crictl, tar, cp

**Prerequisites:**
- Root access on the container host or node
- containerd tooling installed or copied to the host

**Steps:**
1. Enumerate namespaces, containers, tasks, and snapshots with ctr and crictl.
2. Copy containerd configuration and runtime sockets metadata where accessible.
3. Create a tarball of /var/lib/containerd and /run/containerd for offline analysis.
4. Hash the tarball and command outputs before transferring them to evidence storage.

**Pros:** Captures modern container runtime evidence on Kubernetes nodes | Useful even when Docker is not installed
**Cons:** Large data volumes on busy nodes | Runtime state is technically dense and may require specialized analysis
**Notes:** Collect containerd state before node reboots or garbage collection remove the most useful snapshots and task metadata.
**Collection Constraints:** containerd state can be large and may change quickly with node churn or garbage collection. | Root access and runtime tooling are typically required to capture a complete snapshot safely.

## Cloud Acquisition

### AWS EC2 Linux Snapshot

Create EBS volume snapshots of Linux EC2 instances for forensic acquisition and analysis.

**Tools:** AWS CLI, AWS Console

**Prerequisites:**
- AWS IAM permissions for EC2/EBS operations
- Forensic analysis instance available

**Steps:**
1. Identify the target instance and its EBS volumes.
2. Create snapshots: aws ec2 create-snapshot --volume-id vol-xxx --description "Forensic - Case001"
3. Tag snapshots with case metadata.
4. Create a volume from the snapshot in the forensic account.
5. Attach to a forensic analysis instance.
6. Mount read-only: mount -o ro,noexec /dev/xvdf1 /mnt/evidence
7. Perform forensic analysis.

**Pros:** Non-intrusive to the running instance | Can be shared across accounts | Incremental snapshots are cost-efficient
**Cons:** No volatile memory capture | Snapshot consistency for non-EBS stores requires instance stop
**Notes:** Always mount acquired volumes as read-only with noexec. Capture memory first using LiME/AVML via SSM before disk snapshots.

### AWS CloudTrail Export

Export CloudTrail event history and preserved trail logs from S3 or CloudWatch Logs for forensic analysis.

**Tools:** AWS CLI, jq, Athena

**Prerequisites:**
- AWS IAM permissions for CloudTrail, S3, and CloudWatch Logs
- Knowledge of the trail bucket or log group destinations

**Steps:**
1. Capture recent event history immediately: aws cloudtrail lookup-events --start-time T_START --end-time T_END --output json > cloudtrail_event_history.json
2. Identify the active trail and delivery targets: aws cloudtrail describe-trails and aws cloudtrail get-trail-status
3. Copy the trail-delivered log files from S3 or export from CloudWatch Logs for the investigation window.
4. Hash all exported files and preserve them outside the affected AWS account if possible.

**Pros:** Captures the authoritative AWS management-plane timeline | Works without touching the target workloads | Can be automated across multiple accounts and regions
**Cons:** Event history only covers recent management events | Data events may be absent unless the trail was configured for them | Organizations with many accounts may require delegated-admin coordination
**Notes:** Do not rely on CloudTrail event history alone for production investigations. Export the retained trail data and preserve evidence of trail status or tampering.
**Collection Constraints:** CloudTrail event history is not a substitute for retained trail data; investigators must confirm which trails and sinks actually preserved the incident window. | Cross-account or organization-wide collection may require delegated access and careful region scoping.

### AWS IAM Credential Report Export

Export IAM credential reports, access-key metadata, and key last-used information for emergency credential scoping.

**Tools:** AWS CLI, base64, jq

**Prerequisites:**
- AWS IAM permissions for credential report and user metadata APIs

**Steps:**
1. Generate the current credential report if needed: aws iam generate-credential-report
2. Download the report: aws iam get-credential-report --output text --query Content | base64 --decode > iam_credential_report.csv
3. Export users, access keys, and key last-used data for identities in scope.
4. Hash the CSV and JSON outputs and attach the relevant case metadata.

**Pros:** Fast way to scope long-lived credential exposure | Identifies stale privileged users and keys with no MFA | Minimal operational impact
**Cons:** Does not show full API activity on its own | Requires follow-up with CloudTrail for timeline reconstruction
**Notes:** Pair the report with CloudTrail to determine which identities were actually used during the compromise window.
**Collection Constraints:** The credential report is a snapshot and must be paired with CloudTrail or access-key activity for timeline reconstruction. | It does not cover every federated or temporary credential path present in the environment.

### AWS VPC Flow Log Export

Export VPC Flow Logs from CloudWatch Logs or S3 together with flow-log configuration metadata.

**Tools:** AWS CLI, Athena, CloudWatch Logs Insights

**Prerequisites:**
- AWS IAM permissions for EC2, S3, and CloudWatch Logs
- Knowledge of the relevant VPCs, subnets, or ENIs

**Steps:**
1. Identify enabled flow logs and their destinations: aws ec2 describe-flow-logs
2. Export the relevant log-group or S3-delivered records for the investigation window.
3. Preserve the flow-log configuration JSON along with the exported data.
4. Hash the exported records and note the account, VPC, subnet, and ENI scope.

**Pros:** Provides network evidence without packet capture | Useful for exfiltration and lateral-movement scoping | Can be preserved centrally without host access
**Cons:** No packet payloads | May not exist if flow logs were never enabled | High-volume environments can produce large datasets
**Notes:** Capture both the raw records and the configuration state so you can prove which resources were and were not covered.
**Collection Constraints:** Flow logs provide metadata only and depend on pre-existing VPC, subnet, or ENI coverage. | High-volume environments may require exporting from centralized sinks rather than the console alone.

### Amazon Route 53 Resolver Query Log Export

Export Route 53 Resolver query logs and query-log configuration metadata for cloud DNS investigations.

**Tools:** AWS CLI, Athena, CloudWatch Logs Insights

**Prerequisites:**
- AWS IAM permissions for Route 53 Resolver, S3, and CloudWatch Logs

**Steps:**
1. List query-log configurations: aws route53resolver list-resolver-query-log-configs
2. Export the relevant CloudWatch or S3 log data for the affected VPCs and time window.
3. Preserve the configuration metadata that identifies destination, owner, and VPC associations.
4. Hash the raw exports before parsing them into analysis pipelines.

**Pros:** High-value DNS evidence for cloud workloads | Useful for C2 and exfiltration analysis | Centralized collection without logging into instances
**Cons:** Only available if query logging was configured | May require multiple destinations to be collected across accounts
**Notes:** Resolver query logging is often missing in AWS estates. Preserve evidence of that gap when it affects the case.
**Collection Constraints:** Resolver query logs exist only when the affected VPCs were associated with a query-log configuration before the incident. | Multiple accounts or destinations may need to be collected to avoid partial DNS coverage.

### AWS GuardDuty Finding Export

Export GuardDuty detector metadata and findings for the incident scope, including EKS-related detections where available.

**Tools:** AWS CLI, jq

**Prerequisites:**
- AWS IAM permissions for GuardDuty detectors and findings

**Steps:**
1. List the detectors in scope: aws guardduty list-detectors
2. Export finding IDs and then full finding documents for the affected detector.
3. Preserve the detector settings and any delegated-administrator relationships.
4. Hash the exported JSON and note the AWS accounts and regions covered.

**Pros:** Rapid triage of suspicious identities, workloads, and network behavior | Captures managed detections with severity and evidence context
**Cons:** Findings are summaries, not replacements for raw logs | Coverage depends on enabled GuardDuty plans and data sources
**Notes:** Use GuardDuty as a scoping accelerator, then validate each finding with the underlying CloudTrail, VPC Flow, DNS, or EKS evidence.
**Collection Constraints:** GuardDuty findings are not raw evidence and require corroboration from the underlying log sources. | Coverage varies with enabled plans and data sources in the account or organization.

### AWS Session Manager Log Export

Export Session Manager session history together with transcript logs from CloudWatch Logs or S3 when logging is enabled.

**Tools:** AWS CLI, CloudWatch Logs, S3

**Prerequisites:**
- AWS IAM permissions for SSM, CloudWatch Logs, and S3

**Steps:**
1. Export session history: aws ssm describe-sessions --state History --output json > ssm_session_history.json
2. Identify the configured transcript destinations for Session Manager.
3. Export the relevant CloudWatch Logs or S3 transcript objects for the case window.
4. Hash the session metadata and transcript exports.

**Pros:** Preserves interactive-access evidence for managed instances | Does not require SSH or RDP access to the target
**Cons:** Command transcripts do not exist unless logging was enabled | Session Manager history alone may be insufficient for full command reconstruction
**Notes:** Preserve proof of whether transcript logging was enabled at the time of the incident. That can itself become a post-incident hardening finding.
**Collection Constraints:** Session transcripts do not exist unless transcript logging was enabled to CloudWatch Logs or S3 before the session occurred. | Session history by itself may show access timing without preserving the full command stream.

### Amazon EKS Control Plane Log Export

Export enabled EKS control-plane log types from CloudWatch Logs and preserve cluster logging configuration.

**Tools:** AWS CLI, CloudWatch Logs Insights, kubectl

**Prerequisites:**
- AWS IAM permissions for EKS and CloudWatch Logs
- Knowledge of the cluster names and regions in scope

**Steps:**
1. Capture the current logging configuration: aws eks describe-cluster --name <cluster-name> --query "cluster.logging"
2. Export the /aws/eks/<cluster>/cluster log group for the relevant time window from CloudWatch Logs.
3. Preserve the log streams covering api, audit, authenticator, controllerManager, and scheduler as available.
4. Hash the exported log bundle and record the cluster, account, and region metadata.

**Pros:** Preserves the core managed-cluster control-plane evidence | Captures multiple EKS log types in one workflow
**Cons:** No historical control-plane logs exist if logging was never enabled | Large clusters can generate substantial CloudWatch data volumes
**Notes:** Record which EKS log types were enabled before you export. Missing audit or authenticator streams are visibility gaps, not collection errors.
**Collection Constraints:** Only the EKS log types enabled before the incident will be available for export. | Cluster and region scoping must be accurate early, or the export will silently miss the relevant evidence.

### Amazon EKS Container Insights Export

Export CloudWatch Container Insights telemetry for EKS clusters, including performance and application log groups.

**Tools:** AWS CLI, CloudWatch Logs Insights, kubectl

**Prerequisites:**
- AWS IAM permissions for CloudWatch Logs and EKS
- Cluster access for kubectl inventory capture

**Steps:**
1. List the Container Insights log groups for the cluster: aws logs describe-log-groups --log-group-name-prefix "/aws/containerinsights/<cluster-name>"
2. Export the performance and application log groups for the investigation window.
3. Capture a point-in-time pod and node inventory with kubectl for context.
4. Hash the exported telemetry and inventory files.

**Pros:** Bridges control-plane events with runtime workload behavior | Useful for suspicious image, pod, and node activity
**Cons:** Available only when Container Insights was deployed and retained | High-volume clusters can generate large exports
**Notes:** Container Insights is especially useful when pod logs rotate quickly or attacker workloads were ephemeral.
**Collection Constraints:** Container Insights exports are available only if the feature was deployed and retained before the incident. | Workload telemetry can be high volume and may require targeted time scoping to stay practical.

### Amazon ECR Evidence Export

Export ECR repository metadata, image inventories, and CloudTrail events related to registry activity.

**Tools:** AWS CLI, jq

**Prerequisites:**
- AWS IAM permissions for ECR and CloudTrail

**Steps:**
1. Enumerate repositories and images in scope using aws ecr describe-repositories and aws ecr describe-images.
2. Export CloudTrail events for ecr.amazonaws.com covering the incident window.
3. Preserve any repository policies or lifecycle policies that may explain image access or cleanup behavior.
4. Hash all JSON exports and note the repository URIs and regions covered.

**Pros:** Captures registry evidence without touching running workloads | Useful for supply-chain and malicious image investigations
**Cons:** Does not capture container runtime state by itself | Requires separate cluster or host evidence to confirm image execution
**Notes:** Use this with EKS control-plane or runtime evidence to prove where and how a suspicious image was deployed.
**Collection Constraints:** Registry metadata alone does not prove image execution; investigators still need host or cluster runtime evidence. | Historical registry visibility depends on CloudTrail retention and any repository cleanup that occurred after the incident.

### GCP Compute Engine Disk Snapshot

Create persistent disk snapshots of GCP Compute Engine Linux instances for forensic analysis.

**Tools:** gcloud CLI, GCP Console

**Prerequisites:**
- GCP IAM permissions for Compute Engine disk operations
- Forensic analysis VM in the same region

**Steps:**
1. Identify the target instance and attached disks.
2. Create snapshot: gcloud compute disks snapshot DISK_NAME --snapshot-names=forensic-snap --zone=ZONE
3. Create a new disk from the snapshot.
4. Attach the disk to a forensic analysis VM.
5. Mount read-only for analysis.

**Pros:** Non-intrusive acquisition | Can be shared across GCP projects | Fast snapshot creation
**Cons:** No memory capture | Requires GCP IAM permissions
**Notes:** GCP snapshots are global resources and can be used to create disks in any region. Use labels to tag forensic snapshots with case metadata.

### Google Workspace Audit and Reports Export

Export Google Workspace audit evidence from the Admin Console and Reports API for admin, login, Drive, OAuth, Takeout, and related audit surfaces.

**Tools:** Google Admin Console, Reports API, curl, jq

**Prerequisites:**
- Google Workspace admin access with Reporting permissions
- API access and OAuth scopes if using the Reports API programmatically

**Steps:**
1. Confirm the investigator has a Workspace admin role with access to Reporting and the Audit and investigation tool.
2. Export the required log families from the Admin Console and preserve the applied filters, actor identifiers, and date ranges used for each export.
3. Use the Reports API for bulk or scripted collection where needed, preserving raw JSON responses for the same incident window.
4. Hash all exported CSV and JSON files and record the tenant, time zone, and account used for collection.

**Pros:** Covers multiple high-value Google Workspace log families in one workflow | Preserves raw API and UI exports for later offline analysis
**Cons:** Retention and available data sources vary by service and Workspace edition | Does not preserve underlying mailbox or document content by itself
**Notes:** Collect both the exported events and screenshots or metadata showing which data sources were available. Missing log families are often an important investigation finding.
**Collection Constraints:** Available audit families and lookback windows depend on Workspace edition, admin scope, and retention settings. | This workflow preserves audit metadata only; use Vault separately when content preservation is required.

### Google Vault Search and Export

Preserve Gmail, Drive, Chat, and related Workspace content through Google Vault matters, searches, holds, and exports.

**Tools:** Google Vault, Google Admin Console

**Prerequisites:**
- Google Vault licensing and investigator access
- Defined matter scope and approved custodians

**Steps:**
1. Create or identify the matter that will hold the investigation content and record the custodians and scope used.
2. Run targeted searches against Gmail, Drive, Chat, or other in-scope data sources for the incident window.
3. Preview the result set, place holds if required, then export the preserved content with case metadata and hashes.
4. Document the export identifier, source scope, and retention context alongside the downloaded evidence package.

**Pros:** Best native preservation workflow for Workspace content | Supports defensible export and legal hold requirements
**Cons:** Requires the right Google edition and Vault permissions | Exports can be large and slow for broad custodian scopes
**Notes:** Use Vault when investigators need evidence that survives normal mailbox or audit-log retention windows.
**Collection Constraints:** Vault availability depends on licensing, retention configuration, and the permissions of the investigator. | Vault is a point-in-time preservation workflow; content already removed outside retention is not recoverable through this process.

### Google Cloud Logging Export

Export Google Cloud audit, VPC flow, DNS, and Cloud Storage log evidence from Cloud Logging and related sink destinations.

**Tools:** gcloud CLI, Cloud Logging, BigQuery, jq

**Prerequisites:**
- GCP IAM permissions to read Cloud Logging and relevant project metadata
- Knowledge of the projects, buckets, or sink destinations in scope

**Steps:**
1. Identify the projects, folders, and organizations in scope and confirm where logs were retained or exported.
2. Use gcloud logging read or Logs Explorer to export the required log families for the incident window in JSON format.
3. Capture the logging, bucket, and sink configuration so missing Data Access or DNS visibility is documented explicitly.
4. Hash the JSON exports and preserve the query expressions used to generate them.

**Pros:** Covers multiple GCP evidence families in one collection workflow | Preserves both events and logging-configuration evidence
**Cons:** High-volume log families may require sink or BigQuery access for practical export | Some key evidence depends on Data Access logging already being enabled
**Notes:** Always collect the logging configuration. Missing audit streams are important findings, not merely operational inconveniences.
**Collection Constraints:** Data Access, DNS, and some service-specific visibility require pre-incident logging configuration. | Retention may be split across Cloud Logging, buckets, BigQuery, or third-party SIEM sinks and must be mapped before export.

### GKE Audit and Runtime Log Export

Export Google Kubernetes Engine audit, control-plane, and workload log evidence together with a point-in-time cluster inventory.

**Tools:** gcloud CLI, kubectl, Cloud Logging, jq

**Prerequisites:**
- GCP IAM access to cluster logging and metadata
- kubectl access with sufficient RBAC for inventory collection

**Steps:**
1. Export the relevant Cloud Logging streams for the cluster, covering audit, control-plane, container, and node-related logs for the incident window.
2. Capture a point-in-time inventory of pods, nodes, namespaces, RBAC objects, and cluster events with kubectl.
3. Record the cluster logging configuration and any gaps in audit or workload logging coverage.
4. Hash the log exports and the cluster inventory before moving them to evidence storage.

**Pros:** Preserves both control-plane and workload context | Captures ephemeral cluster state before workloads disappear
**Cons:** Requires both cloud-admin and cluster-read access for full coverage | High-volume clusters can generate large exports quickly
**Notes:** Use this early. Cluster state and short-lived pod evidence can change materially once containment begins.
**Collection Constraints:** The exact log surface depends on GKE logging configuration and retention in Cloud Logging or export sinks. | kubectl inventory is point-in-time only; deleted workloads may already be gone.

### Okta System Log Export

Export Okta tenant audit evidence from the System Log API and admin console for the incident window.

**Tools:** Okta Admin Console, curl, jq

**Prerequisites:**
- Okta admin access or API token with System Log permissions

**Steps:**
1. Confirm the investigator has an API token or admin role that can read the Okta System Log.
2. Export the incident window through the System Log API, preserving pagination and filters used for actor, IP, and event type constraints.
3. Capture any related admin-console views or exports used to validate the API data set.
4. Hash the resulting JSON and record the tenant, time zone, and token owner used for collection.

**Pros:** Authoritative source for Okta authentication and administrative events | API export is straightforward and SIEM-friendly
**Cons:** Older events fall out of the standard query window | API rate limits can slow large tenant exports
**Notes:** If the incident predates the available query window, preserve any SIEM or streaming copies before they age out as well.
**Collection Constraints:** System Log API queries do not return events older than 90 days through standard access paths. | High-volume tenants may require filtered or paginated export runs to avoid rate-limit gaps.

### Slack Audit Log Export

Export Slack audit events through the Slack Audit Logs API or admin console for tenant and workspace administrative investigations.

**Tools:** Slack Audit Logs API, curl, jq, Slack Admin Console

**Prerequisites:**
- Slack admin access and an audit token if using the API

**Steps:**
1. Confirm the Slack plan and token scope support Audit Logs API access for the organization in scope.
2. Export the relevant incident window through the API, preserving pagination cursors and query parameters used.
3. Capture the equivalent admin-console filters or screenshots if the UI was used to validate key actions.
4. Hash the JSON exports and document the workspace or organization scope they cover.

**Pros:** Best native evidence source for Slack administrative and governance actions | Suitable for SIEM ingestion and timeline analysis
**Cons:** Audit surface depends on Slack plan and organization features | Does not preserve message content or file payloads by itself
**Notes:** Export both the events and the plan or scope limitations that applied at collection time. Missing audit coverage is often a material finding.
**Collection Constraints:** Slack audit logging requires the appropriate Slack plan and administrative scope; not every workspace exposes the same evidence surface. | These logs show administrative activity, not message content or preserved file copies.

### Slack Access Log Export

Preserve Slack access-log evidence for suspicious-user and account-takeover investigations.

**Tools:** Slack Admin Console

**Prerequisites:**
- Slack administrative access to the relevant workspace or organization

**Steps:**
1. Open the workspace or org access-log view and filter the relevant user accounts and date range.
2. Preserve the access-log results or screenshots together with any session or device context available.
3. Record the administrative scope and Slack plan under which the access-log data was collected.
4. Hash any exported files and place them with the rest of the case evidence.

**Pros:** Direct evidence source for suspicious Slack sign-ins | Simple to capture when the admin view is available
**Cons:** Feature availability depends on Slack plan and admin role | Access logs are narrower than full audit or message evidence
**Notes:** Use this together with identity-provider and endpoint evidence to tie suspicious Slack sessions to the broader incident timeline.
**Collection Constraints:** Access-log availability and detail vary by Slack plan and administrative scope. | Access logs alone do not preserve message or file activity and may have shorter practical retention than external archives.

### GitHub Enterprise Audit Log Export

Export GitHub enterprise or organization audit logs and preserve any configured audit-stream destination evidence for the investigation window.

**Tools:** gh CLI, GitHub REST API, GitHub Enterprise UI, SIEM

**Prerequisites:**
- GitHub enterprise or organization administrative access
- CLI or API credentials with permission to read the relevant audit scope

**Steps:**
1. Identify whether the relevant evidence lives at the enterprise or organization level and confirm the investigator privileges required.
2. Export the relevant audit events via the REST API or UI filters for the incident window, preserving the exact queries used.
3. Document any audit-log streaming configuration and collect the downstream SIEM or sink records if long-term history is needed.
4. Hash the exported JSON or CSV evidence and store it together with the stream configuration notes.

**Pros:** Authoritative source for GitHub administrative and token-related activity | Can bridge UI-visible history with streamed long-term retention
**Cons:** Native audit history is limited without a streaming destination | Requires enterprise-level access for the broadest scope
**Notes:** Preserve both the audit events and the stream configuration. Investigators often need to explain whether missing history is due to retention or missing streaming setup.
**Collection Constraints:** GitHub native audit history is limited unless audit-log streaming was already configured and retained externally. | Enterprise-wide collection requires the right administrative scope; organization-only access may not show the full blast radius.

---
*Generated by DFIR Assist*