By Asheer Malhotra.
- Cisco Talos has observed a malware campaign that utilizes military-themed malicious Microsoft Office documents (maldocs) to spread Cobalt Strike beacons containing full-fledged RAT capabilities.
- These maldocs use malicious macros to deliver a multistage and highly modular infection.
- This campaign appears to target military and government organizations in South Asia.
- Network-based detection, although important, should be combined with endpoint protections to combat this threat and provide multiple layers of security.
Cisco Talos has recently discovered a new campaign distributing a multistage attack used to infect target endpoints with customized Cobalt Strike beacons. Due to the theme of the malicious documents (maldocs) employed, it is highly likely that military and government organizations in South Asia were targeted by this attack.
How did it work?
The attack consists of a highly modular dropper executable we’re calling “IndigoDrop” dropped to a victim’s endpoint using maldocs. IndigoDrop is responsible for obtaining the final payload from a download URL for deployment. The final payloads currently observed by Talos are Cobalt Strike beacons.
In this post, we illustrate the core technical capabilities of the maldocs, IndigoDrop and the Cobalt strike beacons components including:
- The maldocs-based infection chain.
- IndigoDrop’s functionality.
- Communication mechanisms and infrastructure used to download infection artifacts.
- Detailed configurations of the Cobalt Strike beacons.
This attack demonstrates how the adversary operates a targeted attack that:
- Uses legitimate-looking lures to trick the target into infecting themselves.
- Employs a highly modular infection chain (implemented in the IndigoDrop) to instrument the final payload.
- Uses an existing offensive framework (Cobalt Strike) to establish control and persist in the target’s network without having to develop a bespoke remote access trojan (RAT).
Analysis of recently discovered attack-chain variations provides insights into the evolution of this threat. These evolutions indicate the changes in tactics and techniques of the attackers used to continue attacks while trying to bypass detections. This campaign also shows us that while network-based detection is important, it should be complemented with system behavior analysis and endpoint protections for additional layers of security.
Analysis of maldocs
This attack uses two techniques to deliver malicious macros to be executed on the target’s endpoint:
- Malicious macros already embedded, ready to execute.
- Malicious macro downloaded as part of an externally linked template that is then injected into the original lure maldoc.
This attack consisted of maldocs masquerading as internal government or military documents. For example, some of the maldocs discovered by Talos masquerade as Incident Action Plan (IAP) documents dictating safeguard procedures for the IT infrastructure of the Indian Air Force (IAF).
These documents are aptly named:
- IAP39003.doc - Contains embedded malicious macro.
- IAP39031.docx - Uses template injection.
Sample content of the maldoc lures:
Fake document or weaponized copy?
Many targeted attacks employing maldocs observed by Talos usually consist of utmost a couple of pages of decoy content to make them look legitimate. The documents used in this attack, however, contain legitimate content (~64 pages, ~15k words), making them seem even more bonafide. Talos also found a benign copy of one of the maldocs indicating that it is highly likely that the attackers weaponized and distributed it to targets
(Benign copy hash: 0d16b15972d3d0f8a1481db4e2413a2c519e8ac49cd2bf3fca02cfa3ff0be532).
Malicious VBA Analysis
This section consists of an analysis of malicious macros used to carry out the attacks using:
- Locally embedded malicious macros and
- Malicious macros embedded in the injected templates downloaded from a remote location.
The malicious macros carry out the following malicious activities:
- Parse a Windows executable’s hardcoded bytes into bytes that can be written to a file on disk.
- The parsed bytes are written to an EXE file in the currently logged in user’s Startup directory: E.g.
- Once the malicious EXE (second-stage payload — IndigoDrop ) has been written to the user’s Startup directory the macro quits execution without executing the actual second-stage payload.
- The attack relies on the user either logging in again or restarting the system to activate the second-stage payload on the infected endpoint.
- The second-stage payload in this attack is a custom dropper (IndigoDrop) that carries out a variety of tasks.
Malicious macro code:
One of the maldocs disclosed here was referred to by a Bit.ly-shortened URL (created Jan. 23, 2020) — hxxp://bit[.]ly/iaf-guidelines — which redirects to hxxp://tecbeck[.]com/IAP39031[.]docx.
It is highly likely that the attackers hosted the maldocs on a public server and distributed the direct or Bit.ly links to the targets in the form of spear-phishing emails. This may be done to bypass detection systems that scan email attachments for malware.
Stage 2: Dropper binary — IndigoDrop
The second-stage binary dropped to disk by the maldocs is a malicious dropper/loader we’re calling “IndigoDrop” designed to download and activate a customized Cobalt Strike beacon (final payload DLL) from another remote location.
Before we delve into a detailed analysis, some of the key operational features of IndigoDrop are:
- Highly modular in nature: IndigoDrop usually consists of three hardcoded locations that can be used to download and activate the next payload.
- In this attack, IndigoDrop utilizes both attacker-operated remote locations and public data hosting platforms such as pastebin[.]com to host the next stage payloads.It is highly likely that this dropper may download the final payload from these remote locations (likely done in other variants of the attack).
- However this instance of the attack downloads a Metasploit shellcode from the hardcoded remote locations. We will refer to this Metasploit shellcode as Stage 2A in this post (detailed later-on).The Metasploit shellcode (Stage 2A) is hosted in the form of a Base64 encoded string on the download locations. This shellcode is base64 decoded, unhexlified and executed on the endpoint as part of IndigoDrop’s execution.
Base64-encoded Metasploit shellcode:
Base64-decoded Metasploit shellcode:
This dropper performs the following actions on the endpoint:
- Establish persistence using the registry Run key for itself in location:
HKCU\Software\Microsoft\Windows\CurrentVersion\Run | iexplorer = cmd /c <file_path_of_Dropper> /onboot -hide
- Download and execute the Stage 2A Metasploit shellcode.
- Anti-Infection Checks: Check the current Username, Computername, parent folder name, MAC addresses, Public IP addresses against a list of blocked values. If any of the values match, IndigoDrop quits (Blocked values listed in the IOC section).
Stage 2A: Metasploit (MSF) downloader shellcode
The Metasploit shellcode is a modified reverse HTTP stager meant to download a malicious file from the specified download location. This shellcode (stage 2A) is usually hosted on a public hosting site such as pastebin[.]com.
The malicious file downloaded is usually a copy of a trojanized jquery[.]min.js file. The malicious jQuery file consists of:
- At a specific offset in the file is yet another shellcode (referred to as Stage 3A).
The Metasploit HTTP stager carries out the following actions in sequence:
- Connect to the malicious attacker-controlled IP address.
- Download the malicious jquery-3.3.0.min[.]js file to an executable memory location.
- Jump to the malicious shellcode embedded in the jquery file and start executing Stage 3A.
Malicious jquery file:
Stage 2A Metasploit shellcode downloading the jQuery file to executable memory and jumping to the specified offset:
Stage 3A: Decoder shellcode
The malicious jQuery file contains the decoder shellcode (Stage 3A) and the final Cobalt Strike beacon DLL. The beacon DLL is, however, XOR-encoded. It is the responsibility of the decoder shellcode to decode and activate this final payload in the dropper process’ memory.
Decoder shellcode decoding the final RAT payload:
Stage 3B: Cobalt Strike beacon
The final RAT payload is actually a Cobalt Strike beacon. Once the beacon DLL has been decoded, the decoder shellcode (Stage 3A) jumps to the beginning of the MZ in memory instead of going to the DllEntryPoint. This is done to calculate and jump to the address to the loader routine (usually also an exported subroutine) that will carry out reflective-DLL-loading of the Cobalt Strike beacon DLL in the dropper process’ memory.
Code beginning at the beacon’s base image calculating and jump to address of the reflective loader (via call ebx):
After the loader routine has completed setting up the DLL in memory (re-building Imports, base relocations, etc.) it will then jump to the DllEntryPoint (or DllMain) of the beacon to activate the final and most important stage of the infection — the actual RAT components of the beacon.
Cobalt Strike beacons use configurations specified via “.profile” files in the framework. These configurations describe various characteristics of the malicious payload (beacon binary) including:
- C2 configuration
- Communication protocols
- Process injection techniques, etc.
The profiles used in this attack by the beacon binaries attempt to mimic a legitimate jquery request. The most common configurations used in this attack were:
- Beacon type = HTTP
- CnC URL resource location = /jquery-3.3.1.min.js
- HTTP Post location = /jquery-3.3.2.min.js
- User Agent = Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.157 Safari/537.36
- HTTP Get Metadata =
Accept-Encoding: gzip, deflate
- HTTP Post Metadata =
Accept-Encoding: gzip, deflate
- Idle DNS IP = 74[.]125.196.113 (google[.]com)
- Spawn processes =
- Process injection configuration =
The Cobalt Strike beacons used in this attack support a wide variety of capabilities (also known as commands) including:
- Execution of arbitrary code in target processes via injection.
- Execution of arbitrary commands on the infected endpoint.
- Download and upload files.
- Impersonate users.
- Enumerate, copy, delete, timestomp files.
- Modify, query the Windows registry.
- Use of malleable jquery CnC profiles to impersonate legitimate traffic.
The overall infection chain is illustrated as follows:
This attack utilizes pastebin[.]com extensively to host the Metasploit downloader shellcode (Stage 2A). The shellcode hosted on pastebin is either created through a guest account or owned by five registered accounts, specifically:
Pastebin account operated by the attacker:
The base64-encoded Metasploit downloader shellcode (Stage 2A) hosted on Pastebin.
Talos also found Python-based modules related to this threat (pyinstaller EXEs). These modules may have been used in a different campaign or deployed by the Cobalt Strike beacons as part of this attack. Two python modules discovered served the following purposes:
- Gather initial system information and send it to the C2 server.
- Extract credentials from the infected system and print to console.
Sysinfo gathering capabilities of the Python modules:
Credentials stolen from the endpoint by the other python module were from:
- Google Chrome
- Microsoft Edge
- Mozilla Firefox
- WiFi credentials
Credential-stealing module of the attack (snip):
Evolution of attacks
Talos discovered multiple variants of the attack instrumenting the Metasploit shellcode and ultimately activating the final payload (Cobalt Strike beacons).
This section shows the evolution of the attack and the introduction/modification of its features at different stages of the engineering process.
Apr. 2018: No droppers
This is the earliest discovered variant of the attack. The threat also begins with a maldoc containing a malicious macro. The payload dropped to disk is a “.crt” file. This file is decoded by the malicious macro using ‘certutil’ to obtain the next stage payload binary (EXE) which is then executed on the target endpoint.
The payload activated by the macro is not a dropper. This early variant of the attack does not utilize an intermediate dropper to download and activate the final beacon on the endpoint.
Instead, the binary decoded and executed on the endpoint by the malicious macro is just an SMB-based Cobalt Strike beacon. This SMB beacon continues to appear in maldocs created as late as September 2019.
May 2019: Cobalt Strike Macros
Around May 2019, the attackers tested the use of VBA macro based stagers generated by Cobalt Strike. This attack-chain consists of a maldoc with an embedded macro. The macro consists of code that can inject the hardcoded MSF downloader shellcode (Stage 2A) into a benign 32-bit process.
The macro code used to inject shellcode into rundll32.exe contacts the local team server 192[.]168.146.137/eKYS for infection tests:
Sept 2019: Test samples and embedded MSF shellcode
The attackers started experimenting with and testing custom droppers in September 2019 to include a new module — the next stage (Stage 2A) Metasploit downloader shellcode. The Metasploit downloader shellcode was embedded in the test samples and connected to a local IP address to download the third-stage payloads (Stages 3x). The dropper seen here is the earliest discovered instance of IndigoDrop.
Metasploit downloader connecting to a local IP in the dropper:
Sept. 2019: Productionized samples and embedded MSF shellcode
The attackers finalized their attack structure in September 2019 and started distributing copies of IndigoDrop. These droppers were based on earlier test samples (also built in September 2019) and similarly contained embedded MSF downloader shellcode. These droppers now connected to public IPs operated by the attackers to download the third-stage payloads.
September 2019: Python Downloaders; No MSF shellcode
Around the end of September 2019, the attackers started utilizing another infection tactic: The use of Python plus EXE-based downloaders/droppers.
These droppers were multi-staged where:
- The actual dropper was a malicious EXE file.
- This dropper would extract an embedded DLL and drop it to disk.
- The dropper then activates the DLL using rundll32.exe.
- The DLL is responsible for downloading and executing the third-stage payload from an attacker operated server.
- The DLL does this by executing minimal python code using the python27.dll library.
These droppers did not utilize the embedded MSF shellcode like their predecessors. Instead, the shellcode was hosted on an attacker-controlled and operated server.
Python code executed by the Python library in the downloader:
Decoded base64 Python code:
Oct. 2019: //Pastebin usage begins here
The attackers started using pastebin[.]com to host their MSF downloader shellcode (Stage 2A) in October 2019. The IndigoDrop samples built during this time period now also included the capabilities to persist another component of the infection (usually located at “%userprofile%\AppData\Local\Microsoft\svchost.exe” ) via registry and the Windows Startup folder:
IndigoDrop downloading the MSF shellcode from Pastebin:
Late October 2019 - Present: Multiple Pastebins and anti-Infection checks
Having realized the utility of Pastebin, the attackers upgraded their IndigoDrop implementations to use multiple Pastebins to download the MSF shellcode. The multiple pastes were meant to be backups of each other if any of them were removed. The attackers used a combination of Pastebins and attacker-operated download servers, as backups if the pastes were removed.
These IndigoDrop instances also introduced the Anti-Infection checks (detailed earlier) to the infection chain.
Base64-encoded Pastebin and attacker-downloaded URL in an IndigoDrop sample:
The evolution of attacks is illustrated here:
This investigation illustrates an attacker using multiple tools and techniques to implement their full attack chain. A variety of infection artifacts are utilized ranging from bespoke tools (IndigoDrop) to customizable adversarial tools (Cobalt Strike beacons). The attackers also use a combination of public and private servers to host their malicious payloads with a growing trend towards the sole usage of public servers.
The use of military-themed maldocs (lures) indicates that government and military organizations in South Asia may be the targets of this threat actor. The maldocs contain bonafide content and are most likely weaponized copies of benign documents known to peek the interests of their targets.
The attack variants discovered over time show us that the threat actor can evolve their TTPs in a short period of time. The earliest observable campaigns of this actor date back to April 2018 and continue to operate today along with the most recent evolutions of the attacks. Evidence of rapid ideation, testing and production of new and diversified modules and IndigoDrop iterations indicates highly motivated and agile adversaries. The use of adversarial frameworks like Cobalt Strike suggests that the attackers are looking to expand their malicious arsenal at a significant rate with self-authored and customizable artifacts.
Modern-day malware attack chains consist of multiple stages and operational entities. These artifacts and entities may be hosted locally or on remote servers. For example, this attack consists of multiple shellcodes hosted on remote locations downloaded by a local component (IndigoDrop) during runtime to instrument the attack chain. Thus, while network-based detection is important, it should be complemented with system behavior analysis and endpoint protections.
Ways our customers can detect and block this threat are listed below.
Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware detailed in this post. Below is a screenshot showing how AMP can protect customers from this threat. Try AMP for free here.
Cisco Cloud Web Security (CWS) or Web Security Appliance (WSA) web scanning prevents access to malicious websites and detects malware used in these attacks.
Email Security can block malicious emails sent by threat actors as part of their campaign.
Network Security appliances such as Next-Generation Firewall (NGFW), Next-Generation Intrusion Prevention System (NGIPS), and Meraki MX can detect malicious activity associated with this threat.
Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.
Umbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network.
Additional protections with context to your specific environment and threat data are available from the Firepower Management Center.
Open Source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.
Cisco AMP users can use Orbital Advanced Search to run complex OSqueries to see if their endpoints are infected with this specific threat. For specific OSqueries on this threat, click below:
Indicators Of Compromise (IOCs)
The following IOCs are related to this threat.
Python module EXEs
Cobalt Strike Beacon Hashes
Malicious JQuery Files containing the beacons
Maldoc distribution URLs
Cobalt Strike beacon CnC URLs
MSF shellcode URLs
jQuery/Decoder shellcode URLs
MSF shellcode Pastebin URLs
IndigoDrop’s anti-infection checks
Computer names blocked
Immediate parent folder names blocked
MAC addresses blocked
IP Addresses blocked