Game of Emperor: Unveiling Long Term Salt Typhoon/Earth Estries Cyber Intrusions

In the Earth Estries cyber intrusion campaign, the attackers initially exploited public-facing server vulnerabilities to gain access to Linux servers, deploying the MASOL RAT for persistent access. Once inside, they utilized the MASOL RAT to maintain a foothold within the compromised systems, targeting Southeast Asian government networks. BlueRock's Container Drift Protection (Binaries & Scripts) effectively mitigates this threat by ensuring that only authorized binaries and scripts from the original container image are allowed to execute. This mechanism prevents unauthorized modifications to system processes, thereby blocking the execution of malicious payloads like MASOL RAT, and maintaining the integrity of the server environment.

• T1190: Exploit Public-Facing Application: The Earth Estries group exploits public-facing server vulnerabilities to establish initial access. The article specifically mentions 'Earth Estries is aggressively targeting the public-facing servers of victims' and lists vulnerabilities like Ivanti Connect Secure VPN Exploitation, Fortinet FortiClient EMS SQL Injection, and ProxyLogon. This aligns with the MITRE ATT&CK technique for Exploit Public-Facing Application (T1190).
• T1021: Remote Services: After gaining initial access, the attackers used living-off-the-land binaries (LOLBINs) such as WMIC.exe and PSEXEC.exe for lateral movement within networks. This is described in the article as 'After gaining control of the vulnerable server, we observed that the attackers leveraged living-off-the-land binaries (LOLBINs) like WMIC.exe and PSEXEC.exe for lateral movement.' This corresponds to the MITRE ATT&CK technique for Lateral Movement via Remote Services (T1021).
• T1071: Application Layer Protocol: The Earth Estries group deploys malware like SNAPPYBEE, DEMODEX, and GHOSTSPIDER for espionage. The article mentions 'deployed customized malware such as SNAPPYBEE, DEMODEX, and GHOSTSPIDER to conduct long-term espionage activities.' This indicates the use of malware to maintain persistence and conduct operations, aligning with the MITRE ATT&CK technique for Command and Control via Application Layer Protocol (T1071).
• T1090.003: Proxy: Multi-hop Proxy: The attackers used a complex C&C infrastructure, which suggests sophisticated Command and Control operations. The article notes 'Earth Estries uses a complex C&C infrastructure managed by different teams,' which aligns with the MITRE ATT&CK technique for Multi-hop Proxy (T1090.003).
• T1014: Rootkit: The use of the DEMODEX rootkit by Earth Estries for long-term persistence is highlighted in the article: 'We found that they implanted the DEMODEX rootkit on vendor machines.' This corresponds to the MITRE ATT&CK technique for Rootkit (T1014).
• T1505.002: Server Software Component: Transport Agent: The Earth Estries group uses backdoors like GHOSTSPIDER, SNAPPYBEE, and MASOL RAT for persistent access. The article describes 'A key finding from our recent investigation is the discovery of a new backdoor, GHOSTSPIDER,' indicating the use of backdoors for persistence, aligning with the MITRE ATT&CK technique for Implant Internal Image (T1505.002).
• T1574.001: Hijack Execution Flow: DLL Search Order Hijacking: The attackers use 'DLL search order hijacking' as part of their GHOSTSPIDER infection flow, as noted in 'On the infected endpoint, the threat actor deploys a legitimate executable file alongside a malicious DLL file for DLL search order hijacking.' This aligns with the MITRE ATT&CK technique for Hijack Execution Flow: DLL Search Order Hijacking (T1574.001).
• T1059.001: Command and Scripting Interpreter: PowerShell: The attackers' use of PowerShell scripts for initial infection is described in the article: 'the attackers used another variant of DEMODEX... the first-stage PowerShell script requires a decryption key as an argument.' This corresponds to the MITRE ATT&CK technique for Scripting (T1059.001).

F1: Initial access via exploitation of public-facing server vulnerabilities followed by lateral movement using LOLBINs and deployment of backdoors (SNAPPYBEE/GHOSTSPIDER) for espionage.

• Attacker identifies and targets public-facing servers of organizations in critical sectors like telecommunications and government. (Cited from: "Earth Estries is aggressively targeting the public-facing servers of victims.", "primarily targeting critical industries such as telecommunications and government entities")
• Attacker exploits known N-day vulnerabilities on these servers, such as Ivanti Connect Secure flaws (CVE-2023-46805, CVE-2024-21887), Fortinet FortiClient EMS SQL Injection (CVE-2023-48788), Sophos Firewall RCE (CVE-2022-3236), or Microsoft Exchange ProxyLogon (CVE-2021-26855, etc.). (Cited from: "We have observed them exploiting server-based N-day vulnerabilities, including the following:", Table 1 listing CVEs)
  • BR-48: Java Deserialization Protection - This mechanism is applicable because if the exploited vulnerability involves Java deserialization from the network leading to OS command execution attempts, this mechanism would detect the origin (network deserialization) and the subsequent attempt to run OS commands, blocking the execution. This specifically applies if the vulnerability (e.g., within Ivanti, Fortinet, Sophos, or Exchange components if Java-based) relies on Java deserialization.
  • BR-76: Python Deserialization Protection - This mechanism is applicable because if the exploited vulnerability involves Python deserialization from the network leading to OS command execution attempts, this mechanism would detect the origin (network deserialization) and the subsequent attempt to run OS commands, blocking the execution. This applies if the vulnerability relies on Python deserialization.
  • BR-74: Java OS Command Injection Prevention - This mechanism is applicable because if the exploited vulnerability leads to OS command injection within a Java-based application on the server (e.g., Ivanti, Fortinet, Sophos, Exchange components if Java-based), this mechanism monitors the Java runtime for patterns indicative of OS command execution and blocks unauthorized attempts.
  • BR-77: Python OS Command Injection Prevention - This mechanism is applicable because if the exploited vulnerability leads to OS command injection within a Python-based application on the server, this mechanism monitors the Python runtime for patterns indicative of OS command execution and blocks unauthorized attempts.
  • BR-70: Back-Link Directory Traversal - This mechanism is applicable because if the vulnerability exploited involves directory path traversal at the application layer (e.g., accessing files outside the intended scope via manipulated paths in web requests like in SQLi or RCE payloads), this mechanism intercepts and analyzes file path requests, blocking traversal attempts.
• After gaining initial access, the attacker uses living-off-the-land binaries (LOLBINs) like WMIC.exe and PSEXEC.exe to move laterally within the compromised network. (Cited from: "After gaining control of the vulnerable server, we observed that the attackers leveraged living-off-the-land binaries (LOLBINs) like WMIC.exe and PSEXEC.exe for lateral movement")
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it restricts process execution to specific allowed paths. If WMIC.exe or PSEXEC.exe (or the tools used to invoke them remotely) are executed from a path not on the configured allowlist, BlueRock would block the execution, preventing lateral movement via these LOLBINs.
  • BR-90: Process Exec Deny - This mechanism is applicable because it blocks the execution of processes based on a deny list (e.g., path suffixes). If paths ending in /wmic.exe or /psexec.exe were added to the deny list, BlueRock would prevent their execution, hindering lateral movement.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if the LOLBINs (WMIC.exe, PSEXEC.exe, or custom scripts invoking them) were introduced to a Linux host after the initial baseline (boot) and were not installed via a trusted package manager, this mechanism would block their execution.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if the attacker attempts to introduce and execute WMIC.exe, PSEXEC.exe, or wrapper scripts inside a container, and these executables/scripts were not part of the original container image, BlueRock would block their execution, preventing lateral movement originating from or pivoting through the container.
  • BR-87: Process Socket Deny - This mechanism is applicable because lateral movement tools like PSEXEC.exe and WMIC.exe rely on network communication (e.g., SMB). If the policy denies these specific processes (or the parent process invoking them) from creating network sockets, BlueRock could prevent the lateral movement attempt.
• Attacker deploys customized malware, including backdoors like SNAPPYBEE and GHOSTSPIDER, onto compromised systems. (Cited from: "deployed customized malware such as SNAPPYBEE, DEMODEX, and GHOSTSPIDER to conduct long-term espionage activities")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if the malware (SNAPPYBEE, GHOSTSPIDER, DEMODEX) is deployed as a new executable binary or script into a monitored container environment, and it was not part of the original container image manifest, BlueRock will detect this drift and block the execution attempt.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because it restricts process execution to allowed paths. If the attacker attempts to save and execute the malware from a non-standard or temporary directory (e.g., /tmp, C:\Windows\Temp) that is not on the execution allowlist, BlueRock would block the malware's execution.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if the malware is deployed onto a Linux host filesystem after the initial baseline and not via a trusted package manager, this mechanism would detect the drift and block the execution of the malware binary or script.
  • BR-80: Tainted File Download Protection - This mechanism is applicable because if the malware (compiled or interpreted code) is downloaded using specific tools like wget or curl onto the host and then subsequently executed, this mechanism would detect this sequence of actions (network download by monitored process + execution) and block the execution.
  • BR-90: Process Exec Deny - This mechanism is applicable because if the malware executable names or paths (e.g., ending in /snappybee.exe or /ghostspider.dll if executed directly) are added to the deny list, BlueRock would block their execution.
  • BR-89: Library Load Path Allow - This mechanism is applicable because if the malware involves loading malicious DLLs (like GHOSTSPIDER components) from paths not included in the library load allowlist, BlueRock would block the mmap() call, preventing the library from being loaded and executed.
• The deployed backdoors establish communication with attacker-controlled Command-and-Control (C&C) servers for receiving commands and exfiltrating data. (Cited from: "The C&C infrastructure used by various backdoors seems to be managed by different infrastructure teams", referring to C&C details for SNAPPYBEE and GHOSTSPIDER)
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent specific processes (like the backdoors SNAPPYBEE or GHOSTSPIDER) from initiating any outgoing network connections or accepting incoming ones if they are not on the configured allowlist. This would sever the C&C communication channel.
  • BR-55: Reverse Shell Protection - This mechanism is applicable because although these backdoors might use custom protocols, if they attempt to spawn a standard shell (bash, cmd.exe) and redirect its input/output directly to a network socket for interactive control, this mechanism would detect and block the binding of shell STDIN/STDOUT/STDERR to the socket.
  • BR-59: Cloud IMDS Firewall (AWS) - This mechanism is applicable because if the compromised system is an AWS EC2 instance and the backdoor attempts to abuse the IMDS (Instance Metadata Service) to retrieve credentials or other metadata (potentially as part of its C&C communication or data gathering), this mechanism would filter and potentially block malicious requests to the IMDS endpoint.
• The attacker conducts long-term espionage activities, potentially targeting critical services like database servers, cloud servers, or vendor networks. (Cited from: "conduct long-term espionage activities against their targets", "attackers targeted not only critical services (like database servers and cloud servers) used by the telecommunications company, but also their vendor network.")
  • BR-91: Sensitive File Access - This mechanism is applicable because during espionage, attackers often seek sensitive files (config files, credentials, SSH keys). This mechanism monitors access to predefined sensitive files/patterns (e.g., /etc/shadow, /.ssh/id_) and can alert or block unauthorized read/write attempts by the backdoor process.
  • BR-52: Data Resource Mandatory Access Control - This mechanism is applicable because if critical data directories (e.g., containing database files, configuration secrets) are protected by this policy, only explicitly allow-listed binaries can access them. The backdoor process, being unauthorized, would be blocked from reading or writing to these directories.
  • BR-30: Process Credential Protection - This mechanism is applicable because if the attacker attempts to escalate privileges by manipulating the backdoor process's credentials (e.g., overwriting UID/GID) to gain access to sensitive resources, this mechanism detects and blocks unauthorized credential modifications.
  • BR-87: Process Socket Deny - This mechanism is applicable because accessing other internal services like databases or cloud servers often involves network communication. If the backdoor process is denied socket access, it cannot connect to these other services to exfiltrate data or pivot.
  • BR-86: PTrace Protection - This mechanism is applicable because if the attacker attempts to use ptrace (potentially via the backdoor's capabilities) to inspect the memory of other processes (e.g., database services, authentication agents) to steal credentials or sensitive data, this mechanism would block unauthorized memory access attempts via ptrace.

​

F2: Deployment and execution of the DEMODEX rootkit using PowerShell and PSEXEC for stealthy persistence.

• Attacker gains initial access to a target machine, potentially through methods described in F1.
• Attacker uses PSEXEC.exe to remotely execute a PowerShell script (onedrived.ps1) on the target machine, providing a decryption key as an argument. (Cited from: "Based on our telemetry, we discovered that the attacker used PSEXEC.exe to execute the following commands to install the DEMODEX rootkit: Powershell.exe -ex bypass c:\windows\assembly\onedrived.ps1 password@123", "The first-stage PowerShell script requires a decryption key as an argument.")
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if PSEXEC.exe or Powershell.exe are executed from a path not on the allowlist, or if the script onedrived.ps1 itself is executed via an interpreter not in an allowed path, the execution would be blocked.
  • BR-90: Process Exec Deny - This mechanism is applicable because if PSEXEC.exe, Powershell.exe, or the script path suffix were on the deny list, their execution would be blocked.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if this action occurs within a container and PSEXEC.exe or onedrived.ps1 were not part of the original image, their execution would be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if this occurs on a Linux host and PSEXEC.exe (if used via Wine/equivalent) or the PowerShell script were added post-boot without a package manager, execution would be blocked.
• The PowerShell script initiates the installation of the DEMODEX rootkit components.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if the script attempts to write and execute new DEMODEX binary/script components within a container, and those components weren't in the original image, their execution would be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if the script attempts to write and execute new DEMODEX components onto a Linux host filesystem post-boot without using a package manager, their execution would be blocked.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the script drops DEMODEX components to a non-allowed execution path and attempts to run them, the execution would be blocked.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable because if the PowerShell script attempts to write DEMODEX components into critical system directories (e.g., System32, /usr/bin) protected by this policy, the write operation would be blocked.
• A second-stage service loader component of DEMODEX is executed, which uses the target computer's name as an AES decryption key to decrypt further payloads or configuration. (Cited from: "The second-stage service loader uses the computer name as the AES decryption key.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if the service loader is a new executable/script executed within a container and wasn't part of the original image, its execution would be blocked.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the service loader is executed from a path not on the allowlist, its execution would be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if the service loader was added to a Linux host post-boot without a package manager, its execution would be blocked.
  • BR-90: Process Exec Deny - This mechanism is applicable because if the service loader's name/path is on the deny list, its execution would be blocked.
• Alternatively, in a newer variant, required registry data (encrypted configuration and shellcode payload) is bundled in a CAB file, deployed possibly via PowerShell or other means, and deleted after installation. (Cited from: "In this new installation flow, the attackers no longer use a first-stage PowerShell script... Instead, the required registry data... are bundled in a CAB file. The CAB bundle will be deleted after installation is finished.")
  • BR-80: Tainted File Download Protection - This mechanism is applicable because if the CAB file containing malicious code is downloaded via wget or curl by the initial script/process, and then subsequently code extracted from it is executed, this mechanism could detect the download+execute sequence and block it.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if the process extracting/executing the shellcode from the CAB file is itself a new binary/script within a container (and not part of the image), its execution would be blocked. It would also block the execution of the shellcode if it were written to a file first.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if the process extracting/executing the shellcode was added to a Linux host post-boot without a package manager, its execution would be blocked. It would also block the shellcode if written to disk first.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the process extracting/executing the shellcode runs from a disallowed path, or if the shellcode is written to a file in a disallowed path before execution, it would be blocked.
• The DEMODEX rootkit components utilize control flow flattening techniques to hinder analysis. (Cited from: "Notably, we discovered that all components related to the DEMODEX rootkit use control flow flattening techniques to increase the difficulty of analysis (Figure 6).")
• The core DEMODEX implant establishes communication with its C&C server (e.g., 103.91.64[.]214). (Cited from: Figure 7 showing core-implant configuration with C&C)
  • BR-26: Driver ACL Protection - This mechanism is applicable because if the DEMODEX rootkit involves loading a kernel module (driver) and that driver is not on the explicitly defined allowlist (or is on the blocklist), this mechanism would prevent the driver from loading, thus breaking the rootkit's core functionality, including C&C.
  • BR-34: Driver Signature Enforcement - This mechanism is applicable because if the DEMODEX rootkit relies on loading an unsigned kernel module on a system where signature enforcement is enabled (and protected by BlueRock), the kernel would refuse to load the malicious driver, preventing the rootkit from functioning.
  • BR-35: Kernel Integrity Protection - This mechanism is applicable because if the DEMODEX rootkit attempts to modify protected kernel code or read-only data sections (e.g., to install hooks), this mechanism would detect and potentially block these unauthorized write attempts.
  • BR-24: File Operations Protection - This mechanism is applicable because rootkits often hook file operations (e.g., to hide files/processes). This mechanism checks file operation pointers against legitimate kernel instances and can detect/block modifications made by the rootkit.
  • BR-87: Process Socket Deny - This mechanism is applicable because if the user-mode component or process associated with the DEMODEX rootkit attempts C&C communication, and that process is denied socket access by policy, the communication would be blocked.

​

F3: Deployment and operation of the GHOSTSPIDER multi-modular backdoor for sophisticated C&C and payload delivery.

• Attacker uses regsvr32.exe to install the first-stage GHOSTSPIDER stager DLL (e.g., core.dll, spider.dll) as a service on a compromised machine. (Cited from: "Based on our telemetry, we observed that the threat actor installs the first-stage stager via regsvr32.exe, which is used to install a DLL (with export names such as core.dll or spider.dll) as a service.")
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if regsvr32.exe is executed from a disallowed path, or if the DLL (core.dll, spider.dll) resides in a disallowed path when loaded by regsvr32.exe, the execution/loading could be blocked.
  • BR-90: Process Exec Deny - This mechanism is applicable because if regsvr32.exe is on the deny list, its execution would be blocked.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if regsvr32.exe or the DLLs are new files introduced into a container environment post-load, their execution/loading would be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if this occurred on Linux (e.g., via Wine) and regsvr32.exe or the DLLs were added post-boot without a package manager, execution/loading would be blocked.
  • BR-89: Library Load Path Allow - This mechanism is applicable because regsvr32.exe loads the specified DLL. If the DLL (core.dll, spider.dll) is located in a path not specified in the library load allowlist, the loading operation via mmap() would be intercepted and blocked.
• The stager DLL checks if it's running on the intended target machine by comparing the hostname against a hard-coded value. (Cited from: "The stager is designed to check for a specific hostname hard-coded in the DLL, ensuring that it only runs on the targeted machine.")
• The stager connects to its C&C server, sending a connection ID (CRC32/CRC64 of UUID4) in the HTTP Cookie header (phpsessid), to register the new infection. (Cited from: "it connects to the stager's C&C server to register a new connection", "A connection ID is placed in the HTTP header's cookie as “phpsessid”. The connection ID is calculated using CRC32 or CRC64 with UUID4 values.")
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the stager process (e.g., regsvr32.exe or rundll32.exe hosting the DLL) from initiating outgoing network connections if the process name is denied network access by policy.
• The stager receives a 'login' module (login.dll) from the C&C, loads it into memory, and executes it. (Cited from: "subsequently receives a module (DLL export name: login.dll) to load and execute in memory.")
  • BR-89: Library Load Path Allow - This mechanism is applicable if the received module is first written to disk in a non-allowed path before being loaded. If loaded directly into memory without touching disk paths, this mechanism might not apply. However, the initial stager DLL load (Step 1) is covered.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the received module (login.dll) is written to the container filesystem first before execution and wasn't part of the original image. It would block the subsequent execution.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if the received module (login.dll) is written to the Linux host filesystem first after boot without a package manager. It would block the subsequent execution.
• The 'login' module collects basic endpoint information and sends it back to the stager's C&C server. (Cited from: "This login module collects basic information about the infected endpoint and sends it back to the stager's C&C server.")
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the process hosting the 'login' module from making outgoing network connections to send the collected data if the process is denied socket access.
  • BR-91: Sensitive File Access - This mechanism is applicable because if collecting 'basic information' involves reading sensitive system files (e.g., /etc/passwd, specific config files) protected by this policy, the access attempt could be alerted or blocked.
• The attacker deploys a legitimate executable alongside a malicious GHOSTSPIDER beacon loader DLL (loader.dll) to perform DLL search order hijacking, persisting via a scheduled task. (Cited from: "the threat actor deploys a legitimate executable file alongside a malicious DLL file for DLL search order hijacking. This malicious DLL, another GHOSTSPIDER module known as the beacon loader (DLL export name: loader.dll)", "A scheduled task is created to launch the executable.")
  • BR-89: Library Load Path Allow - This mechanism is applicable because DLL search order hijacking relies on loading the malicious DLL (loader.dll) from an unintended path (often the application's current directory). If this path is not on the explicit allowlist for loading libraries, this mechanism will block the mmap() call, preventing the hijack.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if the legitimate executable or the malicious loader.dll are new files introduced into a container post-load, their execution/loading would be blocked. The scheduled task attempting to run the executable would fail.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if the legitimate executable or loader.dll were added to a Linux host post-boot without a package manager, their execution/loading would be blocked by the scheduled task.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the scheduled task attempts to run the legitimate executable from a path not on the execution allowlist, it will be blocked.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable because if the attacker attempts to place the malicious DLL or the legitimate executable into a protected critical directory to facilitate the hijack, the write operation would be blocked.
• The beacon loader decrypts an embedded .NET payload (client.dll) and executes it in memory. (Cited from: "The beacon loader contains an encrypted .NET DLL payload (DLL export name: client.dll), which is decrypted and executed in memory.")
• The beacon communicates with its own C&C server using a similar TLS-protected protocol, receiving command codes (e.g., upload, create, update, heartbeat) to load and execute further functional modules (delegates) reflectively in memory. (Cited from: "This backdoor communicates with its C&C server using a custom protocol protected by Transport Layer Security (TLS)", "the GHOSTSPIDER beacon uses an almost identical format to communicate with the beacon C&C server to receive command codes.", Table 4, "These modules are retrieved from the C&C server and are reflectively loaded into memory as dictated by specific command codes.")
  • BR-87: Process Socket Deny - This mechanism is applicable because it can prevent the process hosting the beacon (client.dll in memory, likely hosted by the legitimate executable from step 6) from initiating outgoing C&C connections if that process is denied socket access by policy.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if any of the received functional modules (delegates) are written to disk within a container before execution and were not part of the original image.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if any received delegates are written to a Linux host filesystem post-boot without a package manager before execution.

​

F4: Targeting of Linux servers within Southeast Asian government networks using the MASOL RAT backdoor.

• Attacker identifies Linux servers within target networks, specifically Southeast Asian government entities. (Cited from: "Earth Estries has been deploying MASOL RAT on Linux devices targeting Southeast Asian government networks.", "targeting Southeast Asian government entities")
• Attacker gains initial access to the Linux server, potentially exploiting vulnerabilities like CVE-2022-3236 (Sophos Firewall RCE) although confidence is low, or through other unspecified means. (Cited from: "we currently only have low confidence that Earth Estries has previously deployed the MASOL RAT through CVE-2022-3236")
  • BR-48: Java Deserialization Protection - This mechanism is applicable if the exploited vulnerability (e.g., CVE-2022-3236 if it involves Java) uses Java deserialization from the network leading to OS command execution.
  • BR-76: Python Deserialization Protection - This mechanism is applicable if the exploited vulnerability uses Python deserialization from the network leading to OS command execution.
  • BR-74: Java OS Command Injection Prevention - This mechanism is applicable if the vulnerability leads to OS command injection within a Java application on the Linux server.
  • BR-77: Python OS Command Injection Prevention - This mechanism is applicable if the vulnerability leads to OS command injection within a Python application on the Linux server.
• Attacker deploys a Linux variant of the MASOL RAT backdoor (e.g., filename dash_board). (Cited from: "Deploying the MASOL backdoor (aka Backdr-NQ) on a Linux server", "we observed the new Linux variant of MASOL in the wild after 2021.")
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if the MASOL RAT binary (dash_board) is added to the Linux host filesystem after boot and was not installed via a trusted package manager, this mechanism will detect the drift and block its execution.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if the Linux server is running within a container, and the MASOL RAT binary is introduced post-load (not part of the original image), its execution will be blocked.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the MASOL RAT binary is placed in and executed from a directory not included in the process execution allowlist, the execution will be blocked.
  • BR-80: Tainted File Download Protection - This mechanism is applicable because if the MASOL RAT binary is downloaded using wget or curl and then executed, this mechanism will detect the sequence and block the execution.
• The deployed MASOL RAT communicates with its C&C server (e.g., 103.159.133[.]251). (Cited from: "we tracked the associated C&C IP (103.159.133[.]251) to a Linux backdoor... Our analysis confirmed that this sample is linked to the MASOL RAT", "Our Deep Discovery Inspector (DDI) detected a compromised Linux server communicating with the MASOL RAT C&C.")
  • BR-87: Process Socket Deny - This mechanism is applicable because it can be configured to deny the MASOL RAT process (e.g., dash_board) from initiating outgoing network connections, thus blocking C&C communication.
• The backdoor facilitates long-term access and potential espionage activities on the compromised Linux server.
  • BR-91: Sensitive File Access - This mechanism is applicable because if MASOL RAT attempts to access predefined sensitive files (e.g., /etc/shadow, private keys, config files) during espionage, the access can be alerted or blocked.
  • BR-52: Data Resource Mandatory Access Control - This mechanism is applicable because if critical data directories are protected, MASOL RAT (an unauthorized binary) would be blocked from accessing them.
  • BR-75: Critical Directory Write Protection - This mechanism is applicable because if MASOL RAT attempts to modify files within protected critical system directories for persistence or tampering, the write operation would be blocked.
  • BR-86: PTrace Protection - This mechanism is applicable because if MASOL RAT attempts to use ptrace to inspect or inject into other processes on the Linux server for credential theft or lateral movement, the unauthorized ptrace call would be blocked.
  • BR-30: Process Credential Protection - This mechanism is applicable because if MASOL RAT attempts to escalate privileges by modifying its own process credentials, this mechanism would detect and block the unauthorized modification.

​

F5: Targeting a telecommunications provider's vendor network to gain indirect access, deploying the DEMODEX rootkit on vendor machines.

• Attacker identifies a primary contractor (vendor) associated with a target telecommunications provider. (Cited from: "This vendor is a primary contractor for the region’s main telecommunications provider")
• Attacker gains access to the vendor's network, potentially using methods described in F1 (exploiting public-facing servers or other means).
• Attacker implants the DEMODEX rootkit onto machines within the compromised vendor network. (Cited from: "We found that they implanted the DEMODEX rootkit on vendor machines.")
  • BR-26: Driver ACL Protection - This mechanism is applicable because if DEMODEX installation involves loading a kernel module, and that module is not on the allowlist (or is on the blocklist), the loading will be blocked.
  • BR-34: Driver Signature Enforcement - This mechanism is applicable because if DEMODEX uses an unsigned kernel module and signature enforcement is active, the module load will fail.
  • BR-35: Kernel Integrity Protection - This mechanism is applicable because if DEMODEX attempts to modify protected kernel code or read-only data, the modification will be detected and potentially blocked.
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable if the vendor machines are containers and the DEMODEX components (user-mode launchers/scripts) are new files not in the original image; their execution would be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable if the vendor machines are Linux hosts and DEMODEX components are added post-boot without a package manager; their execution would be blocked.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if DEMODEX user-mode components are executed from disallowed paths, they will be blocked.
• The attacker leverages the compromised vendor network and the persistent access provided by DEMODEX to facilitate subsequent access into the primary target (the telecommunications provider). (Cited from: "we believe that attackers use this approach to facilitate access to more targets.")
  • BR-87: Process Socket Deny - This mechanism is applicable because if the DEMODEX process (or associated user-mode component) attempts to initiate connections from the vendor network into the primary target network, and the process is denied socket access, this pivot attempt could be blocked.
  • BR-31: Privileged Inode Protection - This mechanism is applicable because if DEMODEX modifies privileged files (SUID/SGID binaries) on the vendor system to facilitate pivoting or maintain access, this mechanism detects unauthorized modifications to the inode's security fields.

​

F6: Campaign Alpha operation involving an open directory C&C server used for staging tools and potentially linked to other APT tools.

• Attacker sets up a C&C server (e.g., 23.81.41[.]166) with an open directory listing enabled on port 80. (Cited from: "While investigating the download site (23.81.41[.]166), we found more interesting samples on the C&C server which had an open directory on port 80.")
• Attacker uses this server to host malicious tools and configuration files for download during attacks (e.g., targeting Taiwanese government and a chemical company). (Cited from: "In the attacks we observed last October targeting the Taiwanese government and a chemical company, we found that the attackers downloaded malicious tools from their C&C server (23.81.41[.]166).", Table 2 listing tools)
  • BR-80: Tainted File Download Protection - This mechanism is applicable because if a monitored process like wget or curl on a compromised host downloads executable files (binaries or scripts like ondrived.ps1) from this C&C server and then attempts to execute them, this mechanism would detect the download+execute pattern and block the execution.
• Tools staged include SNAPPYBEE backdoor samples, PowerShell scripts (ondrived.ps1), frpc configuration (sql.toml), and open-source hacktools (NeoReGeorg, fscan). (Cited from: Table 2)
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if these tools (SNAPPYBEE, frpc, NeoReGeorg, fscan, ondrived.ps1) are downloaded and executed within a container, and they were not part of the original image, their execution would be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if these tools are downloaded and executed on a Linux host post-boot without being installed via a package manager, their execution would be blocked.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if these tools are executed from a path not on the allowlist, they will be blocked.
  • BR-90: Process Exec Deny - This mechanism is applicable because if tools like frpc or fscan (or their path suffixes) are on the deny list, their execution will be blocked.
• The configuration file sql.toml points frpc to another C&C server (165.154.227[.]192). (Cited from: "sql.toml frpc config (C&C server: 165.154.227[.]192)")
• This secondary C&C IP (165.154.227[.]192) is linked via SSL certificate to ShadowPad activity and mentioned in reports related to Ivanti exploits. (Cited from: "The frpc C&C 165.154.227[.]192 could be linked to an SSL certificate... previously used by ShadowPad... In addition, the C&C IP address was also mentioned in a Fortinet report and indicators of compromise related to the Ivanti exploit.")
• The staged PowerShell script ondrived.ps1 shows TTP overlap with GhostEmperor's first-stage dropper, differing mainly by using base64 encoding. (Cited from: "We observed the TTPs used by onedrived.ps1 are similar to those of GhostEmperor’s first-stage PowerShell dropper. The only difference is that the strings are encoded using base64 algorithm in this new variant.")
  • BR-54: Container Drift Protection (Binaries & Scripts) - This mechanism is applicable because if ondrived.ps1 is executed within a container and wasn't part of the original image, it would be blocked.
  • BR-62: Linux/Host Drift Protection - This mechanism is applicable because if ondrived.ps1 is executed on a Linux host post-boot and wasn't installed via a package manager, it would be blocked.
  • BR-88: Process Path Exec Allow - This mechanism is applicable because if the script (or the powershell.exe interpreter running it) is executed from a disallowed path, it would be blocked.