Threat Alert: Anatomy of Silentbob’s Cloud Attack

In the Silentbob's Cloud Attack, the attacker begins by exploiting exposed JupyterLab and Docker APIs to gain initial access. BlueRock's Container Capability Control effectively mitigates this by restricting the capabilities that can be granted to containers, thereby limiting unauthorized command execution. The attacker ensures persistence by setting containers to restart always, which is countered by BlueRock's Container Capability Control, limiting the potential for unauthorized command execution and maintaining system integrity.

• T1190: Exploit Public-Facing Application: The attack begins with the attacker exploiting exposed JupyterLab and Docker APIs. This initial access is facilitated by scanning for these exposed services, which is indicative of the technique 'Exploit Public-Facing Application' (T1190). The article states, 'This infrastructure is in early stages of testing and deployment, and is mainly consistent of an aggressive cloud worm, designed to deploy on exposed JupyterLab and Docker APIs.'
• T1046: Network Service Discovery: Once access is gained, the attacker uses the ZGrab application for banner grabbing to identify further vulnerable instances. This falls under 'Network Service Scanning' (T1046). The article details, 'ZGrab is an application layer scanner, developed with Go language, that enables the attacker to perform banner grabbing.'
• T1046: Network Service Discovery: The attacker uses masscan to scan IP ranges for exposed services, which is a continuation of 'Network Service Scanning' (T1046). The article mentions, 'Subsequently, the masscan tool scans and pipes the IP to be utilized by ZGrab for assessing whether there is an exposed Jupyter Lab instance.'
• T1041: Exfiltration Over C2 Channel: The gathered information is sent back to the attacker's Command and Control (C2) server, indicative of 'Exfiltration Over C2 Channel' (T1041). The article notes, 'The resulting information is organized and stored in the JupyterLab.txt file, which is then transmitted to the attacker’s C2 server.'
• T1105: Ingress Tool Transfer: The attacker's infrastructure is concealed using NGROK, aligning with 'Ingress Tool Transfer' (T1105) for transferring tools and 'Proxy' (T1090) for hiding communication. The article states, 'Through the use of NGROK, the attacker is able to conceal the infrastructure, thereby minimizing the risk of it being shut down.'
• T1059.004: Command and Scripting Interpreter: Unix Shell: The attack progresses with the execution of a script to scan for misconfigured Docker daemons and deploy a privileged container, demonstrating 'Command and Scripting Interpreter: Unix Shell' (T1059.004). The article describes, 'One layer incorporates the ELF system... Another layer houses ZGrab, while yet another contains the run.sh shell script, which is programmed to initiate as soon as the container starts.'
• T1496: Resource Hijacking: The attacker uses Docker to deploy a container with a cryptominer and Tsunami malware, indicative of 'Resource Hijacking' (T1496) and 'Deploy Container' (T1610). The article notes, 'It releases a cryptominer and includes the Tsunami malware, which acts as a backdoor.'
• T1090.002: Proxy: External Proxy: The attacker utilizes the TOR service to obscure network communication, indicative of 'Proxy: External Proxy' (T1090.002). The article mentions, 'Following this, the attacker launches the TOR service to obscure network communication.'
• T1568.002: Dynamic Resolution: Domain Generation Algorithms: The attacker uses anondns.net to mask their C2 server, aligning with 'Domain Generation Algorithms' (T1568.002). The article states, 'The attacker employs anondns.net to mask his C2 server.'
• T1552.001: Unsecured Credentials: Credentials In Files: The attacker scans for AWS keys and secrets, which aligns with 'Cloud Credential Dumping' (T1552.001). The article speculates, 'We strongly suspect that this script is designed to systematically scan the environment for AWS keys and secrets, thereby enabling the attacker to steal them.'
• T1609: Container Administration Command: The attacker sets the container to restart always, ensuring persistence, which aligns with 'Container Administration Command' (T1609). The article summarizes, 'The container is running with the flag --restart=always, which creates a persistence in case the container fails it will try to restart.'

F1: Scanning for exposed JupyterLab instances using the shanidmk/jltest2 container image.

• Attacker launches the shanidmk/jltest2 container. (Cited from: "The first attack on our honeypot was launched in early June using this container image.")
  • BR-57: Cluster Drift Protection - This mechanism is applicable because it prevents unauthorized deployment of new pods/containers outside the Kubernetes control API. If the attacker attempts to launch this container via a compromised Docker API directly, bypassing Kubernetes orchestration, this mechanism would detect and potentially block the deployment.
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable because it prevents processes whose lineage does not originate from the trusted kubelet service from accessing the container runtime socket (e.g., containerd.sock). If the attacker tries to launch the container by directly interacting with the Docker socket after gaining initial access, this mechanism would block that interaction.
  • BR-47: Container Capability Control - This mechanism is applicable because it enforces specific, limited capabilities for containers, overriding defaults. Even if the container launch is permitted, this mechanism can prevent it from running with unnecessary or dangerous privileges (like --privileged) often sought by attackers for subsequent actions.
• Inside the container, a run.sh script executes, first downloading necessary packages/utilities. (Cited from: "one layer includes a run.sh shell script designed to initiate when the container starts up.", "the process begins with the downloading of some packages to secure the necessary utilities for the environments.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of any new executable binaries or scripts that were not part of the original container image at load time. If the downloaded packages include executables or scripts needed for the attack, this mechanism would block their subsequent execution.
  • BR-90: Process Exec Deny - This mechanism is applicable because it blocks the execution of processes based on a deny list of path suffixes (defaulting to /nc, /wget, /curl). If the script uses wget or curl to download packages, this mechanism would block the execution of these tools.
  • BR-80: Tainted File Download Protection - This mechanism is applicable because it monitors specific processes like wget or curl and blocks the subsequent execution of any compiled or interpreted code downloaded by them. If the downloaded packages are fetched via wget/curl and contain executable code, this mechanism would block that code execution.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent specified processes (like wget or curl) from initiating network connections. If the policy denies network access for the download tools, the download itself would fail.
• The script builds the ZGrab application layer scanner and moves it to /bin. (Cited from: "Following this, the ZGrab application is built and relocated to the /bin library.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of binaries not present in the original image. This would block the execution of the compiler (e.g., go build) used to build ZGrab, and subsequently block the execution of the newly built ZGrab binary itself.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it restricts process execution to allowed paths. If the compiler or the resulting ZGrab binary resides in or is executed from a path not on the allow list (e.g., a temporary build directory), this mechanism would block the execution.
• The script uses masscan to scan IP addresses and pipes the results to ZGrab. (Cited from: "Subsequently, the masscan tool scans and pipes the IP to be utilized by ZGrab")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of masscan and ZGrab if they were not part of the original container image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks the execution of masscan and ZGrab if they are run from a filesystem path not included in the allow list.
  • BR-90: Process Exec Deny - This mechanism is applicable because it could block the execution of masscan or ZGrab if their paths match the configured deny list suffixes.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the masscan process from initiating outgoing network connections required for scanning, if masscan is on the deny list for socket operations.
• ZGrab attempts banner grabbing to identify exposed JupyterLab instances running at http://[IP]:8888/lab. (Cited from: "assessing whether there is an exposed Jupyter Lab instance operating at http://CurrentlyfoundIP_Address:8888/lab.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of ZGrab if it wasn't in the original image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks the execution of ZGrab if run from a non-allowed path.
  • BR-90: Process Exec Deny - This mechanism is applicable because it could block ZGrab execution if its path matches the deny list.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent ZGrab from making outgoing network connections for banner grabbing if ZGrab is denied socket access.
• Identified IPs of exposed JupyterLab instances are stored in JupyterLab.txt. (Cited from: "The resulting information is organized and stored in the JupyterLab.txt file")
• The list of IPs (JupyterLab.txt) is exfiltrated to the attacker's C2 server using curl. (Cited from: "which is then transmitted to the attacker’s C2 server through a specific command.", "Figure 3 presents the curl command used to send the IPs of the exposed Jupyter Lab instances to the C2 server")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of curl if it wasn't part of the original image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks curl execution if run from a non-allowed path.
  • BR-90: Process Exec Deny - This mechanism is applicable because it blocks the execution of any process whose path ends in /curl by default.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent curl from initiating the outgoing network connection needed for exfiltration if curl is denied socket access.
• The script enters a loop, requesting IP ranges (/8 CIDR blocks) from the C2 server (potentially concealed via NGROK using the HTTP_SOURCE environment variable) for further scanning. (Cited from: "The next step involves the activation of a loop set to run whenever the C2 server returns an IP range for scanning.", "which subsequently scans a CIDR range of /8, equating to approximately 16.7 million IP addresses.", "Through the use of NGROK, the attacker is able to conceal the infrastructure")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it would block the execution of the tool (e.g., curl) used to contact the C2 server if it's not in the original image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks the C2 communication tool if run from a non-allowed path.
  • BR-90: Process Exec Deny - This mechanism is applicable because it would block curl (if used) by default.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the process making the C2 request from initiating network connections if it's on the socket deny list.

​

F2: Scanning for and exploiting exposed Docker Daemon APIs using the shanidmk/sysapp container image to deploy cryptominers and potentially steal AWS credentials.

• Attacker launches the shanidmk/sysapp container. (Cited from: "This container image is composed of six layers... contains the run.sh shell script, which is programmed to initiate as soon as the container starts.")
  • BR-57: Cluster Drift Protection - This mechanism is applicable because it prevents unauthorized deployment of new pods/containers outside the Kubernetes control API. Launching this container via a direct, exposed Docker API bypasses Kubernetes control.
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable because it prevents non-kubelet processes from accessing the container runtime socket. If the attacker interacts directly with the Docker socket, this blocks it.
  • BR-47: Container Capability Control - This mechanism is applicable because it enforces least privilege by restricting container capabilities, preventing the launch of overly privileged containers needed for subsequent steps.
• The run.sh script selects a random initial IP octet and a Docker port (2375, 2376, 2377, 4244, or 4243). (Cited from: "a random initial octet of the IP address is chosen. It is then passed to the function pwn_d along with the random range, a potentially exposed Docker Daemon port, and a rate (2375, 2376, 2377, 4244, 4243).")
• The script executes the pwn_d function to scan for misconfigured Docker daemons (v1.16). (Cited from: "The pwn_d function, based on the provided arguments, scans for misconfigured docker daemons v1.16.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of the pwn_d script/function if it wasn't part of the original container image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks the script execution if run from a non-allowed path.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the script/process performing the scan from making outgoing network connections if it's on the deny list.
• The script attempts to gather target environment information using docker info remotely via the exposed API. (Cited from: "The first docker info seeks to gather information about the target environment")
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable because it blocks processes not originating from kubelet from interacting with the container runtime socket, preventing the remote docker info command.
  • BR-57: Cluster Drift Protection - This mechanism is applicable because interacting with the Docker API outside the K8s control plane constitutes drift.
• The script attempts to run a privileged Alpine container (docker run) via the exposed API, mounting the host filesystem (/), using the host network, and executing an echo command with a base64 encoded script. (Cited from: "the second is a remote command to the docker daemon, commanding it to run a privileged alpine container. This container mounts the host filesystem, utilizes the host network, and executes an ‘echo’ command of a base64 script.")
  • BR-57: Cluster Drift Protection - This mechanism is applicable because deploying a container via a direct API call bypasses the Kubernetes control plane.
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable because it blocks non-kubelet processes from interacting with the runtime socket to launch the container.
  • BR-47: Container Capability Control - This mechanism is applicable because it enforces least privilege and can prevent the container from running as privileged (--privileged), using the host network (--net=host), or gaining capabilities needed for mounting host paths.
  • BR-66: Host FS Mount Control - This mechanism is applicable because it enforces an allow list for host filesystem mounts within containers. Mounting the root filesystem (/) would likely be denied by policy.
• A second persistent (--restart=always) privileged container is run via the exposed API, using the host network. (Cited from: "the attacker persistently runs a privileged container that restarts, utilizes the host network")
  • BR-57: Cluster Drift Protection - This mechanism is applicable because deploying a container via a direct API call bypasses the Kubernetes control plane.
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable because it blocks non-kubelet processes from interacting with the runtime socket to launch the container.
  • BR-47: Container Capability Control - This mechanism is applicable because it can prevent the container from running as privileged or using the host network.
• This second container downloads ELF files x.noback and x.back (suspected cryptominer backups or Tsunami malware). (Cited from: "downloads the ELF files x.noback and x.back. These binaries were unavailable during our investigation; thus, we speculate that these could either be backup cryptominers or the Tsunami malware")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of these downloaded ELF files as they were not part of the original container image.
  • BR-80: Tainted File Download Protection - This mechanism is applicable because if wget or curl is used for the download, the subsequent execution of the downloaded ELF files will be blocked.
  • BR-90: Process Exec Deny - This mechanism is applicable because it would block the execution of the downloader tool (wget/curl) if used.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it would block the execution of the downloader tool if run from a non-allowed path.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the download process by blocking network connections if the downloader tool is on the deny list.
• The container retrieves and executes setupc3poolminer.sh to deploy a cryptominer. (Cited from: "In addition, the script retrieves the setupc3poolminer.sh script, which is specifically designed to deploy a cryptominer.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of the setupc3poolminer.sh script as it was downloaded/retrieved after the container started.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks the script execution if it occurs from a non-allowed path.
  • BR-90: Process Exec Deny - This mechanism is applicable because it could block the script execution if its name/path matches the deny list.
• The container downloads aws.sh.txt, suspected to be a script for scanning and stealing AWS keys/secrets from the environment. (Cited from: "Finally, the script is configured to download aws.sh.txt. We strongly suspect that this script is designed to systematically scan the environment for AWS keys and secrets, thereby enabling the attacker to steal them.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of the downloader tool if not in the original image, and later blocks the execution of aws.sh.txt itself.
  • BR-80: Tainted File Download Protection - This mechanism is applicable because if wget/curl downloads the script, its subsequent execution is blocked.
  • BR-90: Process Exec Deny - This mechanism is applicable because it blocks the downloader (wget/curl) by default.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks the downloader if run from a non-allowed path.
  • BR-87: Process Socket Deny - This mechanism is applicable because it blocks the network connection needed for the download if the downloader process is denied.
  • BR-59: Cloud IMDS Firewall (AWS) - This mechanism is applicable later when the aws.sh.txt script attempts to access the AWS Instance Metadata Service (IMDS) to steal credentials. It intercepts requests to IMDS and blocks unauthorized access, preventing credential theft.

​

F3: Scanning for exposed Docker Daemon APIs using the shanidmk/blob container image, deploying Tsunami malware, and exfiltrating discovered Docker image information.

• Attacker launches the shanidmk/blob container. (Cited from: "This container image is an updated version of sysapp... intended to find exposed Docker Daemon instances.", "The remaining layer holds the shell script docker_entrypoint.sh, which is programmed to execute when the container launches.")
  • BR-57: Cluster Drift Protection - This mechanism is applicable because launching containers via direct Docker API access bypasses Kubernetes control.
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable because it prevents non-kubelet processes from accessing the Docker socket.
  • BR-47: Container Capability Control - This mechanism is applicable because it restricts container capabilities, preventing potentially privileged operations needed by the malware.
• The docker_entrypoint.sh script installs necessary packages/dependencies. (Cited from: "the attacker initiates the process by installing certain packages or dependencies to facilitate the attack.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of package managers (like apt, apk) or any newly installed executables if they weren't part of the original image layers.
• The script executes ELF systems identified as Tsunami malware. (Cited from: "Subsequently, the ELF systems (MD5= 87c8423e0815d6467656093bff9aa193), classified as Tsunami malware by VirusTotal, are executed.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of the Tsunami malware ELF files as they were not present in the initial image layers loaded at runtime (or were added in layers after the manifest was created).
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks the malware execution if it occurs from a path not on the allow list.
• The script starts the TOR service to obscure network communication. (Cited from: "Following this, the attacker launches the TOR service to obscure network communication.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of the TOR service binary if it wasn't part of the original image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks TOR execution if run from a non-allowed path.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the TOR process from establishing any network connections if TOR is on the deny list for socket operations.
• The script determines an appropriate masscan rate based on available memory (/proc/meminfo). (Cited from: "The attacker then conducts a rate scan test by checking /proc/meminfo... Based on this information and subsequent adjustments, the attacker determines the scan rate of masscan.")
• The script enters a loop calling the dAPIpwn function. (Cited from: "Next, a loop invokes the primary function dAPIpwn (Docker API pwn).")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of the dAPIpwn script/function if it wasn't part of the original container image.
• The dAPIpwn function uses anondns.net (via the silentbob subdomain) to mask C2 server communication. (Cited from: "The attacker employs anondns.net to mask his C2 server... The attacker has created a subdomain in the anondns domain named silentbob")
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the process performing the C2 communication from making network connections if it's on the deny list.
• The function uses proxychains3 to route TCP connections through a proxy. (Cited from: "It uses the proxychains3 application, which is designed to force any TCP connection made by any given TCP client to follow through a proxy (or proxy chain).")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of proxychains3 if it wasn't part of the original image.
• Masscan is used (via proxychains) to scan large IP ranges (/8) for exposed Docker APIs. (Cited from: "Masscan then scans a specified range of approximately 16.7 million IP addresses in search of exposed Docker APIs.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks masscan execution if not in the original image.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks masscan execution if run from a non-allowed path.
  • BR-90: Process Exec Deny - This mechanism is applicable because it could block masscan execution if its path matches the deny list.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent masscan from making outgoing scan connections if it's denied socket access.
• For each discovered exposed Docker API, the script lists the images available on that host (docker images). (Cited from: "For each target obtained, the function lists the images on the host with exposed Docker API.")
  • BR-61: Container Runtime Socket Protection - This mechanism is applicable because it blocks non-kubelet processes from interacting with the Docker socket to run docker images.
  • BR-57: Cluster Drift Protection - This mechanism is applicable because interacting with the Docker API outside the K8s control plane constitutes drift.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of the docker client binary used to run docker images if it wasn't part of the original container image.
• The list of Docker images is sent back to the attacker's C2 server. (Cited from: "The output is then sent back to the C2 server.")
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the process handling the C2 communication from making network connections if it's on the deny list.

​

F4: Manual scanning activity observed on a compromised third-party server, likely related to the same campaign for testing purposes.

• Attacker gains access to an exposed JupyterLab server (method not specified, but exploitation is implied). (Cited from: "we turned to Shodan to help us identify 51 servers with exposed JupyterLab instances in the wild. All of these exposed instances had been actively exploited or had recently suffered exploitation attempts by an attacker.")
• Attacker manually executes masscan on the compromised server to scan for exposed Docker APIs. (Cited from: "We discovered a live manual attack on one of the servers that employed masscan to scan for exposed Docker APIs.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the JupyterLab server is running in a container and masscan was downloaded/added after the container started. It blocks the execution of binaries not in the original image.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if JupyterLab is running directly on the host. It blocks the execution of code (masscan) not installed via trusted package managers after boot.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it blocks masscan execution if run from a directory not on the allow list (e.g., /tmp).
  • BR-90: Process Exec Deny - This mechanism is applicable because it could block masscan execution if its path matches the deny list.
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent masscan from making outgoing network connections for scanning if masscan is denied socket access.
• The manual scan targeted a specific range (scan range 124 observed). (Cited from: "The scan range was set to 124")
• Simultaneously or subsequently, the attacker queried their C2 server (http[:]//silentbob[.]anondns[.]com) which returned a response ('124') matching the scan range, suggesting active testing or coordination. (Cited from: "when we queried the attacker’s server (http[:]//silentbob[.]anondns[.]com), the response was a number strikingly similar, further supporting our suspicion that this is related to our campaign. To us, it appeared as if the attacker was conducting some tests.")
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the process making the C2 query (e.g., curl) from initiating network connections if that process is denied socket access.
  • BR-90: Process Exec Deny - This mechanism is applicable because it would block curl by default if used for the query.