TeamTNT’s Docker Gatling Gun Campaign

The attacker began by exploiting exposed Docker daemons (T1190) using a script called "Docker Gatling Gun," deploying a container with malicious commands (T1059). Container Drift Protection (Binaries & Scripts) prevents the execution of unauthorized binaries and scripts, thus mitigating the deployment of the malicious container. Subsequently, the attacker used Sliver malware (T1211) for command and control (T1071.004, T1090), and to execute further commands (T1059). Container Drift Protection (Binaries & Scripts) again plays a crucial role by preventing the execution of any unauthorized binaries or scripts introduced by the malware. Finally, the attacker leveraged compromised Docker instances in a Docker Swarm (T1578.002) for persistence and to hijack resources (T1496) for cryptomining.

• T1190: Exploit Public-Facing Application: The attack gains initial access by exploiting exposed Docker daemons on ports 2375, 2376, 4243, and 4244. This is a well-known technique used to compromise systems that have publicly accessible services.
• T1059: Command and Scripting Interpreter: The initial script, TDGGinit.sh, is executed on compromised systems to launch subsequent malicious actions.
• T1578.002: Modify Cloud Compute Infrastructure: Create Cloud Instance: TeamTNT appends compromised Docker instances to a Docker Swarm, allowing them to persist in the environment as part of a larger cluster, ensuring continued access and control.
• T1211: Exploitation for Defense Evasion: TeamTNT uses Sliver malware, which replaces their previous Tsunami malware. Sliver is harder to detect and evades traditional detection methods by dynamically compiling with per-binary encryption keys.
• T1036: Masquerading: TeamTNT uses names like Chimaera and other familiar naming conventions to evade detection by masquerading as legitimate processes or infrastructure.
• T1014: Rootkit: We found the prochider rootkit ready to deploy in TeamTNT’s download server. They are known to use this in the past.
• T1552: Unsecured Credentials: TeamTNT deploys local searches for keys and credentials, such as SSH, cloud metadata server calls, etc., once they gain access.
• T1046: Network Service Discovery: TeamTNT uses tools like Masscan to aggressively scan the internet for exposed Docker daemons and other vulnerable systems, identifying additional targets.
• T1018: Remote System Discovery: The campaign involves local network scanning to find additional systems that can be compromised.
• T1102.001: Web Service: Dead Drop Resolver: TeamTNT uses Docker Hub and web servers as part of their infrastructure to store and distribute malware and to manage infected systems.
• T1071.004: Application Layer Protocol: DNS: TeamTNT’s use of Sliver malware supports DNS for Command and Control (C2) communication, in addition to HTTP(S) and mTLS.
• T1090: Proxy: Sliver supports WireGuard and other proxy techniques to tunnel C2 communications through legitimate channels, bypassing detection.
• T1496: Resource Hijacking: Running a cryptominer as part of the campaign or selling the computational power of their victims.

‍

F1: Initial access phase leveraging exposed Docker daemons using the 'Docker Gatling Gun' technique.

• Attacker utilizes a script known as the 'Docker Gatling Gun' to scan a wide range of IP addresses (~16.7 million) for exposed Docker daemon ports (2375, 2376, 4243, 4444). (Cited from: "The campaign gains initial access by exploiting exposed Docker daemons on ports 2375, 2376, 4243, and 4444", "The attack script, which scans for these ports, is known as the Docker Gatling Gun. It targets a wide range of IP addresses (~16.7 million)")
• Upon finding an exposed Docker daemon, the script deploys a container from a compromised Docker Hub account (nmlm99). (Cited from: "deploys a container from TeamTNT’s compromised Docker Hub account, running an Alpine Linux image with malicious commands.", "Docker Hub Accounts nmlm99")
• BR-57: Cluster Drift Protection - This mechanism is applicable because it prevents the unauthorized deployment of new pods/containers outside the designated control API (like Kubernetes API). Deploying a container directly via an exposed Docker daemon bypasses the orchestrator's control plane, which BR-57 is designed to detect and block.
• BR-61: Container Runtime Socket Protection - This mechanism is applicable because it prevents processes whose lineage doesn't trace back to a trusted orchestrator component (like kubelet) from accessing the container runtime socket (e.g., docker.sock, containerd.sock). The 'Docker Gatling Gun' script, running externally, would likely interact directly with the daemon socket without this trusted lineage, and BR-61 would block this interaction, preventing container deployment.
• BR-47: Container Capability Control - This mechanism is applicable because it enforces policies on the capabilities granted to containers, potentially overriding requests made during deployment. If the malicious container requested excessive capabilities (e.g., privileged mode) disallowed by the BR-47 policy, the container might be blocked from running even if the deployment command itself succeeded initially.
• BR-67: Container Root User Control - This mechanism is applicable because it detects and prevents processes from running as root within a container (except PID 0). If the malicious container deployed by the attacker attempts to run its primary process or subsequent processes as root (and it's not PID 0), BR-67 could detect and block this behavior.
• The deployed container runs an Alpine Linux image configured to execute an initial malicious script named TDGGinit.sh. (Cited from: "running an Alpine Linux image with malicious commands. The image executes an initial script called TDGGinit.sh")
• BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of any binary or script that was not part of the original container image manifest at load time. If TDGGinit.sh is introduced into the container after the initial load (e.g., downloaded or mounted) rather than being baked into the image layers from the compromised Docker Hub, BR-54 would block its execution.
• BR-88: Process Path Exec Allow - This mechanism is applicable because it restricts process execution to specific allowlisted filesystem paths. If the TDGGinit.sh script is executed from a location within the container (e.g., /tmp, /app) that is not included in the BR-88 allowlist policy, the mechanism will intercept the exec() syscall and block the script's execution.
• BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because it uses NSJail to enforce that only authorized processes can start within the container environment. If the execution of TDGGinit.sh (or the shell interpreter running it) is not permitted by the configured NSJail policy, BR-82 would prevent the process from starting.
• BR-90: Process Exec Deny - This mechanism is applicable if the policy is configured to deny the execution of specific script names or interpreters. While default rules target nc, wget, curl, if the policy were extended to block execution based on script names like TDGGinit.sh or paths like /bin/sh when used suspiciously, it could prevent execution.

F2: Deployment of malware (Sliver/Tsunami), establishment of Command and Control (C2), and infrastructure setup using compromised servers and Docker Hub.

• Following initial access (F1), the TDGGinit.sh script likely initiates the download and execution of further payloads from attacker-controlled infrastructure. (Implicit from F1's execution step and overall attack flow)
• BR-90: Process Exec Deny - This mechanism is applicable because it blocks the execution of processes based on a deny list, defaulting to paths ending in /nc, /wget, or /curl. If TDGGinit.sh attempts to use wget or curl to download further payloads, BR-90 would block the execution of these tools.
• BR-88: Process Path Exec Allow - This mechanism is applicable if the download tools (wget, curl) or the subsequently executed payloads reside in paths not specified in the allowlist. BR-88 would block their execution.
• BR-87: Process Socket Deny - This mechanism is applicable because it can prevent specified processes (like wget, curl, or the shell running the script) from initiating outgoing network connections needed to download payloads, if they are not on the network allowlist.
• BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it prevents the execution of any downloaded payloads (binaries or scripts) as they were not part of the container's original image manifest.
• BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because it prevents unauthorized processes from starting. If the download tools or the subsequent payload execution are not allowed by the NSJail policy, BR-82 blocks them.
• Attacker deploys Sliver malware implants (identified binaries: SPLENDID_ISLAND, bioset), replacing the older Tsunami backdoor for potentially stealthier C2. (Cited from: "A new tool used in this campaign is the Sliver malware, which replaces the previously used Tsunami backdoor.", "Binary file MD5=8b553728900ba2e45b784252a1ff6d17 Sliver Malware (SPLENDID_ISLAND)", "Binary file MD5=9dc2819c176c60e879f28529b1b08da1 Sliver Malware (bioset)")
• BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because it blocks the execution of any binaries (like SPLENDID_ISLAND, bioset) that were not present in the original container image manifest. Since these are deployed post-compromise, BR-54 prevents them from running.
• BR-88: Process Path Exec Allow - This mechanism is applicable because it restricts execution to allowed paths. If the Sliver binaries are executed from a non-allowlisted directory (e.g., /tmp), BR-88 blocks the exec() call.
• BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because it uses NSJail to prevent unauthorized processes. If the Sliver malware processes are not explicitly permitted by the policy, BR-82 prevents them from starting.
• BR-62: Linux/Host Drift Protection - This mechanism is applicable if the malware is deployed on the host itself (not just container). It blocks execution of files added to the host filesystem outside of trusted package managers.
• BR-65: Container Host Drift Prevention - This mechanism is applicable if the malware files are new/modified on the host filesystem post-boot and executed by a non-allowlisted process or container. BR-65 blocks such execution.
• Sliver establishes C2 communication using protocols like mTLS, WireGuard, HTTP(S), or DNS. Specific infrastructure observed includes IP 45.154.2.77 (solscan.one) potentially using port 8888 for Sliver C2. (Cited from: "Its implants support Command and Control (C2) over multiple protocols, including mTLS, WireGuard, HTTP(S), and DNS", "Meanwhile, solscan.one (IP 45.154.2.77) has port 8888 open, used for Sliver C2 communication.")
• BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the Sliver malware process from initiating any outgoing network connections (sockets) required for C2 communication if the Sliver process name is not on the allowlist policy.
• BR-55: Reverse Shell Protection - This mechanism is applicable if the Sliver C2 communication involves binding shell STDIN/STDOUT/STDERR to the network socket for interactive control. BR-55 specifically blocks this pattern, preventing interactive reverse shells.
• BR-86: PTrace Protection - This mechanism is applicable because it intercepts and monitors the ptrace system call. If Sliver malware attempts to use ptrace for process injection or manipulation as part of its C2 activities, BR-86 could block these unauthorized memory access attempts.
• Attacker maintains infrastructure possibly including Tsunami C2, suggested by an open port 6670 on solscan.life (IP 95.182.101.23). (Cited from: "the domain solscan.life (hosted on IP 95.182.101.23) has an open port 6670, typically used for IRC servers. This suggests that TeamTNT may still use Tsunami malware as a C2 server")
• BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the Tsunami malware process from initiating outgoing network connections (sockets) to the C2 server if the Tsunami process name is not on the allowlist policy.
• BR-55: Reverse Shell Protection - This mechanism is applicable if the Tsunami C2 communication relies on binding shell I/O streams to the network socket for interactive command execution. BR-55 would detect and block this specific behavior.
• Attacker uses compromised web servers (e.g., hosted on IPs 188.114.96.7, 104.21.8.145, 172.67.130.114) and registered domains (solscan.life, solscan.one, etc.) to host malicious binaries and scripts. (Cited from: "The group is using both compromised web servers and Docker Hub registries to disseminate malware", "TeamTNT registered several new domains on September 24th, 2024, including solscan.life, solscan.one, solscan.online, and solscan.store. These domains host malicious binaries and scripts", IOC list)
• Attacker utilizes Anondns (devnull.anondns.net) to obfuscate the IP address (45.154.2.77) of their web/C2 server infrastructure. (Cited from: "TeamTNT is also using anondns... They use devnull.anondns.net to point on IP address 45.154.2.77.")
• Attacker uses the compromised Docker Hub account (nmlm99) to host and distribute malware images ('Infrastructure Images'). (Cited from: "TeamTNT used it to host malware... Infrastructure Images: These 10 images are used to deploy malware or worms to detect new victims.")

F3: Resource hijacking through cryptomining deployment and compute power rental, alongside persistence techniques.

• Attacker deploys cryptomining software (including XMRIG, T-Rex miner, CGMiner, BFGMiner, SGMiner) onto compromised systems using specific Docker images ('Impact Images') hosted on the compromised nmlm99 Docker Hub account. (Cited from: "Impact Images: The remaining 20 images focus on running cryptominers... This group of images includes the following cryptomining software: XMRIG, T-Rex miner, CGMiner, BFGMiner, and SGMiner.")
• BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the cryptominer binaries are downloaded or introduced after the container starts, rather than being part of the image layers themselves. If they are part of the malicious image deployed, this mechanism's effectiveness depends on the baseline definition.
• BR-88: Process Path Exec Allow - This mechanism is applicable if the cryptominer binaries are executed from paths within the container that are not on the configured allowlist.
• BR-82: Process Runtime Execution Guardrails - This mechanism is applicable because it prevents unauthorized processes from starting. If the cryptominer processes (e.g., xmrig) are not permitted by the NSJail policy, BR-82 blocks their execution.
• BR-87: Process Socket Deny - This mechanism is applicable because cryptominers require network connectivity to communicate with mining pools. By adding the names of known cryptominer processes (xmrig, t-rex, etc.) to the deny policy, BR-87 can block their necessary network socket operations, rendering them useless.
• BR-90: Process Exec Deny - This mechanism is applicable if the cryptominer binaries are named in a way that matches the deny list patterns (e.g., ending in /nc, /wget, /curl) or if the policy is customized to block known miner names.
• BR-62: Linux/Host Drift Protection - This mechanism is applicable if cryptominers are deployed directly onto the host filesystem outside of trusted package managers. It would block their execution.
• BR-65: Container Host Drift Prevention - This mechanism is applicable if cryptominer files are added/modified on the host post-boot and executed by a non-allowlisted process/container.
• Attacker utilizes GPU mining capabilities (SGMiner) to potentially increase mining revenue. (Cited from: "The latter is utilizing GPU mining to earn more money.")
• BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if SGMiner is introduced post-load. Prevents execution if not in the original manifest.
• BR-88: Process Path Exec Allow - This mechanism is applicable if SGMiner executes from a non-allowlisted path.
• BR-82: Process Runtime Execution Guardrails - This mechanism is applicable if the SGMiner process is not authorized by the NSJail policy.
• BR-87: Process Socket Deny - This mechanism is applicable as SGMiner needs network access. Denying socket operations for the sgminer process blocks its connection to mining pools.
• BR-90: Process Exec Deny - This mechanism is applicable if the binary name matches deny patterns or custom rules.
• BR-62: Linux/Host Drift Protection - This mechanism is applicable if deployed on the host outside package managers.
• BR-65: Container Host Drift Prevention - This mechanism is applicable if deployed on the host post-boot and run by an unauthorized entity.
• Alternatively, or additionally, attacker rents out the computational power of compromised victim servers to third parties via platforms like 'Mining Rig Rentals'. (Cited from: "renting the victims’ computational power to third parties... appending victim servers to platforms like Mining Rig Rentals, where computational power is rented in exchange for cryptocurrency.")
• BR-87: Process Socket Deny - This mechanism is applicable if the software used to connect to 'Mining Rig Rentals' (which might be the miner itself or a dedicated agent) is identified and added to the process socket deny list, preventing it from establishing the necessary network connections.
• BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the rental agent software is deployed post-load.
• BR-88: Process Path Exec Allow - This mechanism is applicable if the rental agent executes from a non-allowlisted path.
• BR-82: Process Runtime Execution Guardrails - This mechanism is applicable if the rental agent process is unauthorized by policy.
• BR-90: Process Exec Deny - This mechanism is applicable if the rental agent binary name matches deny patterns or custom rules.
• Attacker enhances persistence by adding compromised Docker instances into a Docker Swarm, managing them as a single entity. (Cited from: "appending compromised Docker instances to a Docker Swarm", "Persistence Modify Cloud Compute Infrastructure – Create Cloud Instance: TeamTNT download Docker and Dockerswarm binaries and actively exposed Docker instances to a Docker Swarm")
• BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the attacker downloads docker or dockerswarm binaries into an already running container/host to manage the swarm. BR-54 would block the execution of these newly introduced binaries.
• BR-88: Process Path Exec Allow - This mechanism is applicable if the docker or dockerswarm binaries are executed from non-allowlisted paths.
• BR-82: Process Runtime Execution Guardrails - This mechanism is applicable if the execution of docker or dockerswarm commands is not authorized by the NSJail policy.
• BR-62: Linux/Host Drift Protection - This mechanism is applicable if docker/dockerswarm binaries are added to the host outside trusted package managers.
• BR-65: Container Host Drift Prevention - This mechanism is applicable if docker/dockerswarm files are added/modified on the host post-boot and executed by non-allowlisted entities.
• Attacker prepares or deploys rootkits like prochider (identified files xmrig.so, systemd.so) for defense evasion and persistence. (Cited from: "Rootkit: We found prochider rootkit ready to deploy in TeamTNT’s download server.", IOC list for prochider MD5s)
• BR-26: Driver ACL Protection - This mechanism is applicable because rootkits often involve loading malicious kernel modules. BR-26 enforces an ACL (allow/deny list) for kernel module loading, preventing unauthorized modules like prochider from being loaded.
• BR-34: Driver Signature Enforcement - This mechanism is applicable because it ensures only cryptographically signed kernel modules can be loaded (if the kernel is configured appropriately). The prochider rootkit module is unlikely to be signed, so BR-34 would block its loading.
• BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the user-space component used to load the rootkit (e.g., insmod) or the rootkit file itself (.so file treated as executable/script) is introduced post-load.
• BR-88: Process Path Exec Allow - This mechanism is applicable if the tool used to load the module (e.g., insmod) or the rootkit components are executed from non-allowlisted paths.
• BR-62: Linux/Host Drift Protection - This mechanism is applicable if the rootkit files are added to the host filesystem outside of trusted package managers.
• BR-65: Container Host Drift Prevention - This mechanism is applicable if the rootkit files are added/modified post-boot and executed/loaded by unauthorized entities.
• BR-24: File Operations Protection - This mechanism is applicable because rootkits like prochider often hook file operations to hide processes or files. BR-24 detects and prevents modifications to file operation data structures in the kernel.
• BR-31: Privileged Inode Protection - This mechanism is applicable if the rootkit attempts to modify privileged inodes (e.g., of system binaries) to gain persistence or hide.
• BR-35: Kernel Integrity Protection - This mechanism is applicable because it protects kernel code and read-only data regions from unauthorized writes. If the rootkit attempts to patch kernel code directly, BR-35 would detect or block it.
• BR-45: Page Table Protection - This mechanism is applicable if the rootkit attempts to manipulate kernel page tables to hide memory or redirect execution.
• BR-32: Tracepoint Protection - This mechanism is applicable if the rootkit attempts to tamper with kernel tracepoints for hooking or evasion.
• BR-42: Core Pattern String Protection - This mechanism is applicable if the rootkit attempts to modify the core_pattern sysctl for arbitrary code execution on process crashes.
• BR-63: ModProbe Path String Protection - This mechanism is applicable if the rootkit attempts to modify the modprobe_path sysctl to control kernel module loading.

F4: Lateral movement, credential access, and broader targeting associated with the integrated 'Chimaera' campaign elements.

• Attacker performs external network scanning using tools like Masscan and ZGrab to identify additional vulnerable targets beyond the initial Docker daemon exploit. (Cited from: "External and Local Lateral Movement: Aggressive detection and infection methods using tools like Masscan and ZGrab")
• BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if scanning tools like masscan or zgrab are downloaded/introduced into a compromised container post-load. BR-54 would block their execution.
• BR-88: Process Path Exec Allow - This mechanism is applicable if masscan or zgrab are executed from paths not on the allowlist.
• BR-87: Process Socket Deny - This mechanism is applicable because network scanners require extensive socket operations. If the masscan or zgrab processes are added to the deny list, BR-87 can block their ability to initiate scanning connections.
• BR-82: Process Runtime Execution Guardrails - This mechanism is applicable if the execution of masscan or zgrab is not permitted by the NSJail policy.
• BR-90: Process Exec Deny - This mechanism is applicable if the scanner binary names match deny patterns or custom rules.
• Attacker conducts local network searches/scanning from compromised hosts to propagate the infection laterally within the target's network. (Cited from: "local searches to propagate the infection across additional servers within the target’s network.", "Remote System Discovery: The campaign involves local network scanning to find additional systems that can be compromised.")
• BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if tools used for local scanning are introduced post-load. Blocks execution.
• BR-88: Process Path Exec Allow - This mechanism is applicable if scanning tools execute from non-allowlisted paths.
• BR-87: Process Socket Deny - This mechanism is applicable by denying network socket access to the processes performing the local network scanning.
• BR-82: Process Runtime Execution Guardrails - This mechanism is applicable if the scanning processes are unauthorized by policy.
• BR-90: Process Exec Deny - This mechanism is applicable if scanner names match deny patterns or custom rules.
• As part of the broader 'Chimaera' infrastructure (referenced via solscan[.]life/chimaera/sh), the attacker actively targets misconfigurations in SSH, Jupyter, Docker, and Kubernetes. (Cited from: "In the Chimeara capmaign... it appears that TeamTNT are actively targeting SSH, Jupyter, Docker, Kubernetes misconfigurations")
• BR-57: Cluster Drift Protection - This mechanism is applicable to prevent unauthorized actions against Kubernetes if the attacker tries to deploy pods outside the API.
• BR-61: Container Runtime Socket Protection - This mechanism is applicable to prevent unauthorized Docker operations if the attacker tries to interact directly with the socket without proper lineage.
• BR-53: SSH Deep Auth & SSH Least Privilege - This mechanism is applicable because it enhances SSH security with ephemeral certificates and IdP integration, making simple misconfigurations or credential theft less effective for gaining SSH access.
• Attacker searches for and attempts to steal various types of credentials stored on compromised systems or accessible via misconfigurations, including SSH keys, AWS credentials, Docker credentials, s3cfg files, GitHub tokens, Shodan keys, gcloud credentials, Ngrok tokens, Pidgin, FileZilla, HexChat credentials, MoneroGuiWallet files, CloudFlared credentials, davfs2 secrets, PostgreSQL credentials, and smbClients credentials. (Cited from: "targeting... credentials of SSH, AWS, Docker, s3cfg, GitHub, Shodan, gcloud, Ngrok, Pidgin, FileZilla, HexChat, MoneroGuiWallet, CloudFlared, davfs2, PostgreSQL, smbClients.", "Credentials access Unsecured Credentials: Credentials in Files: TeamTNT deploy among other a local search of keys and credentials, such as SSH, cloud metadata server calls etc.")
• BR-91: Sensitive File Access - This mechanism is applicable because it monitors and can block access attempts to predefined sensitive files and patterns. This list includes common credential files like /etc/shadow and SSH keys (*/.ssh/id_*) by default, and can be customized to protect other files like s3cfg, cloud credential files, etc. BR-91 would alert or block attempts by the attacker's scripts/tools to read these files.
• BR-75: Critical Directory Write Protection - This mechanism is applicable if the attacker attempts to modify credential files or system configuration files residing in directories designated as critical (e.g., /etc, user .ssh directories if policy dictates). BR-75 blocks unauthorized writes to these locations.
• BR-52: Data Resource Mandatory Access Control - This mechanism is applicable if credential files reside within directories protected by BR-52. Only allowlisted binaries would be permitted to read/write, potentially blocking credential harvesting tools.
• BR-25: Read-Only File Protection - This mechanism is applicable if credential files are marked read-only and the attacker attempts to use a pipe-based write exploit (like Dirty Pipe variants) to modify them. BR-25 specifically targets this type of write.
• BR-59: Cloud IMDS Firewall (AWS) - This mechanism is applicable specifically for attempts to steal AWS credentials via the Instance Metadata Service (IMDS). It acts as a firewall, controlling access to the IMDS endpoint and blocking unauthorized requests, preventing metadata credential theft.
• BR-30: Process Credential Protection - This mechanism is applicable if the attacker attempts credential theft via privilege escalation that involves tampering with process credential structures in the kernel.
• BR-46: DirtyCred Protection - This mechanism is applicable if the attacker uses DirtyCred-like exploits (swapping kernel credentials via file writes) to gain privileges needed to access credential files.
• BR-88: Process Path Exec Allow - This mechanism is applicable if the credential searching scripts/tools are executed from non-allowlisted paths.
• BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if credential searching tools/scripts are introduced post-load.

‍