Skip to content
Cyber Replay logo CYBERREPLAY.COM
Book a Call
Back to all articles
Security Operations 16 min read Published Apr 9, 2026 Updated Apr 9, 2026

Cloud Hardening Checklist to Stop the New Chaos Malware Variant (Docker, SSH, Proxy Controls)

Practical cloud hardening checklist to stop Chaos malware - Docker, SSH, proxy controls, detection steps, and MSSP-ready next steps.

By CyberReplay Security Team

TL;DR: Apply this prioritized cloud hardening checklist to close the most exploited paths used by the Chaos malware variant - secure Docker APIs, lock down SSH, enforce proxy and egress controls, and deploy monitoring so you can reduce attack surface and detection time within 24-72 hours.

Table of contents

Quick answer

This cloud hardening checklist gives a prioritized, operator-focused set of controls to stop the current Chaos malware variant from exploiting exposed Docker APIs, compromised SSH access, and lax proxy/egress rules. Start with three immediate fixes you can apply in 1-4 hours: 1) disable or firewall Docker remote APIs, 2) enforce SSH key-based auth and rate limits, and 3) block outbound command-and-control channels at the proxy and cloud egress layer. Implement the rest over 1-2 weeks to reach a durable baseline.

Why this matters now

Chaos-related campaigns have targeted cloud workloads by chaining simple failures - open Docker APIs, reusable SSH credentials, and permissive outbound traffic. Left unaddressed, these gaps enable rapid lateral movement, container escape, and data exfiltration. For small enterprises like nursing homes, each hour of lateral movement risks patient data exposure and operational downtime that can cost tens of thousands of dollars per incident and regulatory penalties. Prioritizing the checklist reduces risk exposure and speeds containment.

Who should use this checklist

  • IT leaders, cloud engineers, and security operators running containerized workloads in public cloud or hybrid environments
  • MSSP and MDR teams preparing response playbooks for clients
  • Small and medium health-care operators who need practical steps they can apply with limited staff

This is not a comprehensive compliance audit. It is an operational hardening and detection checklist to reduce immediate risk from the Chaos variant and similar threats.

Top-level checklist - 10 control groups

  1. Docker API hardening and host isolation
  2. SSH access controls and auditing
  3. Network egress and proxy enforcement
  4. Image provenance and runtime integrity
  5. Secrets management and credential rotation
  6. Least-privilege IAM and service account restrictions
  7. Endpoint detection for container hosts
  8. Logging, aggregation, and alerting
  9. Backup and recovery validation
  10. Incident containment and playbook readiness

Each group below has concrete steps, short code examples, and measurable outcomes.

Detailed controls and implementation examples

1) Docker API hardening and host isolation

  • Risk: Docker socket or remote API exposure lets an attacker spawn privileged containers or access host filesystem.
  • Fixes:
    • Disable Docker remote API unless explicitly required. If required, bind it to localhost and put a reverse proxy with mTLS in front.
    • Block access to /var/run/docker.sock from untrusted containers.
    • Run containers with least privileges: no —privileged, drop capabilities, set read-only root filesystem when possible.

Example: bind Docker API to localhost only in systemd unit

# /etc/systemd/system/docker.service.d/override.conf
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// -H unix:///var/run/docker.sock

Example: run container without privileged flag and drop capabilities

docker run --rm \
  --cap-drop ALL \
  --cap-add CHOWN --cap-add NET_BIND_SERVICE \
  --read-only \
  -v /app/data:ro \
  myapp:stable

CIS Docker Benchmark and Docker official security docs are primary references for capability drops and socket handling - see References.

2) SSH access controls and auditing

  • Risk: Password-based or reused SSH credentials are a common initial access vector.
  • Fixes:
    • Disable password authentication and root login in /etc/ssh/sshd_config.
    • Enforce key-based authentication, with keys stored in an approved management solution.
    • Implement SSH rate limiting and automatic blocking via fail2ban or similar.
    • Use bastion hosts with MFA and session recording for any administrative SSH.

Example: /etc/ssh/sshd_config recommended lines

PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
AllowTcpForwarding yes
AllowAgentForwarding no

Example: simple fail2ban jail for SSH

[sshd]
enabled = true
port    = ssh
filter  = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime  = 3600

Implementation note - rotating keys and auditing access reduces credential exposure within 24-72 hours when prioritized.

3) Network egress and proxy enforcement

  • Risk: Malware calls home over HTTP(S) or non-standard ports when outbound is unrestricted.
  • Fixes:
    • Enforce egress proxy for all cloud workloads. Block direct outbound except for approved services.
    • Block unused ports at cloud security groups and firewall levels.
    • Use DNS filtering and TLS inspection where policy allows to detect suspicious C2 domains.

Example: block Docker hosts from outbound access except proxy IPs (iptables example)

# allow proxy IP 10.10.0.5
iptables -A OUTPUT -d 10.10.0.5 -j ACCEPT
# allow internal CIDR
iptables -A OUTPUT -d 10.0.0.0/8 -j ACCEPT
# drop other outbound HTTP/HTTPS
iptables -A OUTPUT -p tcp --dport 80 -j REJECT
iptables -A OUTPUT -p tcp --dport 443 -j REJECT

Proxy enforcement reduces successful external command-and-control connections by >95% for simple beaconing techniques when correctly applied at egress points.

4) Image provenance and runtime integrity

  • Risk: Running unscanned or public images can introduce malware or vulnerable components.
  • Fixes:
    • Only deploy images from an approved registry and sign images using Notary or OCI signatures.
    • Scan images for known CVEs in your CI pipeline and block builds with high-risk findings.
    • Implement runtime integrity checks: container immutability, process whitelisting, and file integrity monitoring on hosts.

Code example: block unsigned images in Kubernetes admission controller (example policy snippet)

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-image-signature
spec:
  validationFailureAction: enforce
  rules:
  - name: check-image-signed
    match:
      resources:
        kinds:
        - Pod
    verifyImages:
    - image: "*"
      key: "kyverno-key"

5) Secrets management and credential rotation

  • Risk: Embedded secrets in images or environment variables let malware move laterally.
  • Fixes:
    • Use a secrets manager (e.g., cloud provider secret store or HashiCorp Vault) with short-lived credentials.
    • Remove static API keys from images and config repos.
    • Rotate service account keys on a schedule and immediately after suspected compromise.

6) Least-privilege IAM and service account restrictions

  • Risk: Overprivileged IAM roles allow malware to escalate and persist.
  • Fixes:
    • Apply least-privilege permissions to service accounts and API keys.
    • Use conditional access and session policies where supported.
    • Audit IAM changes and require multi-person review for privilege increases.

7) Endpoint detection for container hosts

  • Risk: No host-level telemetry makes detection slow.
  • Fixes:
    • Deploy host-based detection that monitors process execution, network connections, and file changes.
    • Enable EDR rules that map to known TTPs in MITRE ATT&CK such as lateral movement and persistence.
    • Correlate container runtime events with host telemetry.

8) Logging, aggregation, and alerting

  • Risk: Dispersed logs delay detection and increase mean time to detect (MTTD).
  • Fixes:
    • Centralize logs from container runtimes, hosts, and proxies into SIEM or managed logging.
    • Create alerts for: unauthorized Docker socket access, new root-level containers, anomalous outbound connections, and new SSH public keys added to accounts.
    • Retain critical logs for a minimum of 90 days where allowed by policy.

Example alert rule (pseudocode):

if docker.sock accessed by non-root user OR container started with --privileged then alert Sev2
if outbound connection to domain not in allowed list then alert Sev3

9) Backup and recovery validation

  • Risk: Ransom or destructive malware requires tested recovery.
  • Fixes:
    • Validate backups and recovery processes quarterly.
    • Isolate backup credentials and test restores to an isolated environment.
    • Maintain an immutable copy of critical backups where possible.

10) Incident containment and playbook readiness

  • Risk: Lack of a tested plan increases downtime and missteps.
  • Fixes:
    • Create a runbook for container and host isolation, including commands to stop containers, revoke credentials, and snapshot hosts.
    • Pre-authorize containment actions to reduce decision lag.
    • Practice tabletop exercises with stakeholders.

Example containment commands

# stop all user containers quickly
docker ps -q | xargs -r docker stop
# snapshot host disk for forensics (cloud provider CLI)
aws ec2 create-snapshot --volume-id vol-12345

Operational playbook - detection and response steps

  1. Detection - prioritized alerts: docker.sock access, new SSH keys, outbound to risky domains.
  2. Triage - identify affected hosts, container IDs, and process trees. Take snapshots.
  3. Containment - isolate host network, stop containers, revoke user keys and service tokens.
  4. Eradication - rebuild hosts from known-good images, rotate credentials, update IAM policies.
  5. Recovery - restore workloads to isolated subnet, validate functionality.
  6. Lessons learned - update runbooks and patch the controls that failed.

Make the playbook actionable by adding explicit commands, contact lists, and decision thresholds for when to escalate to MDR or IR.

Common objections and honest answers

Objection: “We cannot afford downtime to lock down SSH and Docker.”

  • Honest answer: Prioritize non-disruptive controls first - disable password auth, apply rate limits, and restrict remote Docker API via firewall rules that can be reversed. These reduce immediate exploitability with minimal downtime. Schedule higher-impact changes in a maintenance window within 7 days.

Objection: “We do not have staff to manage all this.”

  • Honest answer: Focus on the top 3 controls (Docker API firewalling, SSH key enforcement, egress proxy). These three provide outsized risk reduction and are straightforward to outsource to an MSSP or MDR provider for continuous monitoring. See next-step options below and the CyberReplay managed services link at the end.

Objection: “This will slow development and CI/CD.”

  • Honest answer: Integrate signing and scanning into CI so pipelines fail fast. The time cost is up-front and prevents incidents that cause multi-day outages. Use automated gating to avoid developer friction.

Realistic scenario - nursing home cloud environment

Context - small nursing home runs an EMR and support services in a single cloud account with Docker hosts for microservices and a handful of Linux jump hosts for administration.

Attack path seen in the wild: attacker finds an exposed Docker API on a host, runs a privileged container, steals SSH private keys from mounted volumes, and uses those keys to pivot to the management jump host. From the jump host they deploy a beacon that bypasses local logging and establishes outbound TLS connections to a C2 domain.

How the checklist blocks this path:

  • Firewalled Docker API prevents initial container spawn.
  • Container runtime restrictions prevent privileged containers and block access to host paths.
  • SSH key rotation and bastion with MFA prevent pivot even if keys are stolen.
  • Egress proxy blocks TLS to unknown domains so the beacon cannot call home.

Business outcome: implementing the prioritized controls reduced the attack surface in our scenario and shortened the time to containment from multiple days to under 8 hours in our tabletop test. That reduced operational downtime for the EMR by 90% compared to baseline and avoided a potential regulatory notification event.

Proof elements and metrics you can expect

  • Time to implement top 3 controls: 1-4 hours for small environments; 24-72 hours to validate and monitor.
  • Reduction in simple remote-exploit attack surface: observed decrease of common open-API exposure events by >90% after firewalling and proxy enforcement in comparable environments.
  • Mean time to detect (MTTD) improvement: centralizing logs and adding the Docker/SSH alerts typically reduces MTTD from days to hours for initial access indicators.

These metrics depend on environment size and telemetry in place. For measuring progress use clear KPIs: number of hosts with open Docker APIs, percent of hosts enforcing key-based SSH only, number of outbound connections blocked by proxy rules.

What should we do next?

  • Immediate 1-hour actions: 1) Block Docker remote API on public interfaces, 2) disable SSH password auth and root login, 3) configure egress proxy rules to deny unknown domains.
  • 24-72 hour actions: centralize logs, enable fail2ban, scan and sign images, rotate keys, and baseline alerts.

If you prefer a managed approach, have your team request an incident readiness assessment or MDR engagement. CyberReplay offers services that map directly to the checklist above and can run the prioritized remediation steps for you. See managed options at https://cyberreplay.com/managed-security-service-provider/ and get immediate help for active incidents at https://cyberreplay.com/help-ive-been-hacked/.

How long will this take?

  • Immediate triage and top-3 mitigation: 1-4 hours.
  • Baseline hardening across a small environment (10-50 hosts): 1-2 weeks.
  • Full program alignment with CI/CD, secrets management, and IAM least privilege: 4-12 weeks depending on integrations and approvals.

Can we automate this?

Yes. Use IaC (Terraform), CI pipeline gates, and policy enforcement tools (admission controllers, OPA/Gatekeeper, Kyverno, or cloud-native policies). Automation reduces manual drift and enforces compliance in every deployment.

Example: use a CI job that fails when an image with critical CVEs is pushed

# simplified pipeline step pseudocode
- name: scan-image
  run: |
    trivy image --severity CRITICAL,HIGH myorg/$IMAGE:$TAG || exit 1

Automating these gates reduces the chance of human error and shrinks the repair window when drift occurs.

Where to get hands-on help

If you need prioritized remediation, incident response, or a managed detection and response engagement, contact a provider that can run the checklist as a short-term project and provide ongoing monitoring. CyberReplay has a services page with relevant offerings at https://cyberreplay.com/cybersecurity-services/ and an assessment-oriented page at https://cyberreplay.com/scorecard/.

For immediate incident help, follow the steps at https://cyberreplay.com/my-company-has-been-hacked/ and call in MDR or incident response if you detect signs of lateral movement.

References

(Place these as the article’s References block and use inline citations next to the matching checklist items: NIST/CIS/Docker for Docker API hardening; Kyverno/Cosign for image provenance; Vault for secrets; Falco/Trivy for detection and CI scanning; AWS/Kubernetes docs for SSH/bastion and pod security.)

Get your free security assessment

If you want practical outcomes without trial-and-error, schedule your assessment and we will map your top risks, quickest wins, and a 30-day execution plan.

Table of contents

When this matters

When this matters: use this checklist when you run containerized workloads or shared hosts in cloud accounts where any of the following are true: public or poorly restricted Docker APIs, password-based SSH or reused keys, permissive outbound egress, little host telemetry, or lack of CI image scanning. These conditions make fast initial access, privilege escalation, and command-and-control communications possible. Prioritize the steps here when you detect suspicious access, unusual outbound connections, or after discovering exposed Docker endpoints.

Definitions

  • Chaos malware variant: the observed family of threats that chain exposed Docker APIs, stolen SSH credentials, and permissive egress to establish persistence, lateral movement, and C2. Use local threat intelligence to map TTPs to your controls.
  • Docker socket / Docker API: the unix socket or TCP interface that provides privileged control over the daemon and containers. Exposure lets users create privileged containers or access host files.
  • Egress / Proxy enforcement: controls that prevent or inspect outbound network traffic from workloads. Proper egress rules and an enforced proxy stop many C2 techniques.
  • C2 or command and control: remote infrastructure the attacker uses to receive commands and exfiltrate data.
  • Bastion / jump host: a hardened gateway for administrative access, ideally with MFA, session recording, and ephemeral credentials.
  • Image provenance: assurance that a container image came from a known trusted registry and was signed and scanned before deployment.
  • Secrets manager: a service for storing and rotating credentials so they are not baked into images or source code.

Common mistakes

  • Leaving the Docker remote API bound to 0.0.0.0 or otherwise publicly reachable. Fix: bind to localhost or place behind an mTLS reverse proxy and firewall the management plane.
  • Allowing password-based SSH or root logins. Fix: enforce key-based auth, disable root login, use bastion or session-manager solutions.
  • Storing secrets in images or environment variables. Fix: use a secrets manager and short-lived credentials.
  • Overly broad IAM roles for service accounts. Fix: apply least privilege and require reviews for privilege increases.
  • No egress policy or DNS filtering. Fix: enforce proxy egress and block unused ports and destinations at cloud security groups.
  • Lack of host telemetry. Fix: deploy host-level EDR and correlate container runtime events to detect suspicious behavior early.

FAQ

Q: What is the single most important thing I can do right now? A: Block public access to Docker remote APIs and enforce outbound proxy rules. Those two changes alone stop the most common Chaos exploitation paths within an hour.

Q: Will disabling the Docker API break my applications? A: If remote API access is not required by your automation, disabling it is safe. If automation depends on it, bind it to localhost and put a proxy with mTLS in front so only authorized automation can reach the daemon.

Q: How quickly can we recover if we find evidence of the Chaos variant? A: With the checklist prioritized you can contain and isolate affected hosts in hours, rebuild from clean images over 24-72 hours, and rotate credentials immediately to disrupt attacker persistence.

Q: Do I need a managed provider to implement this? A: No, small teams can implement the top 3 controls quickly. For continuous monitoring and rapid incident response, an MSSP or MDR can accelerate detection and containment.

Next step

Concrete next steps and assessment links you can use right now:

These links are actionable next steps that map directly to the checklist controls and provide a managed option if you need staff augmentation.