[Link].

com /blog/2024/08/02/stormbamboo-compromises-isp-to-abuse-insecure-software-update-mechanisms/
r7rXw1DKlo
StormBamboo Compromises ISP to Abuse Insecure
Software Update Mechanisms
⋮ 8/2/2024

August 2, 2024

by Ankur Saini, Paul Rascagneres, Steven Adair, Thomas Lancaster

KEY TAKEAWAYS

StormBamboo successfully compromised an internet service provider (ISP) in order to poison DNS
responses for target organizations.
Insecure software update mechanisms were targeted to surreptitiously install malware on victim
machines running macOS and Windows.
Malware deployed by StormBamboo includes new variants of the MACMA malware.
Analysis of the newest versions of MACMA shows converged development of the MACMA and
GIMMICK malware families.
Post-exploitation activity included deployment of the malicious browser extension RELOADEXT to
exfiltrate victim mail data.

In mid-2023, Volexity detected and responded to multiple incidents involving systems becoming infected
with malware linked to StormBamboo (aka Evasive Panda, and previously tracked by Volexity under
“StormCloud”). In those incidents, multiple malware families were found being deployed to macOS and
Windows systems across the victim organizations’ networks.

1/13
The infection vector for this malware was initially difficult to establish but later proved to be the result of a
DNS poisoning attack at the internet service provider (ISP) level. Volexity determined that StormBamboo
was altering DNS query responses for specific domains tied to automatic software update mechanisms.
PbofM6kuoL
StormBamboo appeared to target software that used insecure update mechanisms, such as HTTP, and
did not properly validate digital signatures of installers. Therefore, when these applications went to
retrieve their updates, instead of installing the intended update, they would install malware, including but
not limited to MACMA and POCOSTICK (aka MGBot). The overall workflow used by the attackers is
similar to a previous incident investigated by Volexity that was attributed to DriftingBamboo, a threat actor
which is possibly related to StormBamboo.

In April 2023, ESET published a blog post about a malware family that Volexity has tracked since 2018 as
POCOSTICK. ESET did not have direct evidence but proposed the most likely source of infection was an
adversary-in-the-middle (AiTM). Volexity can now confirm this scenario in a real-world case and prove the
attacker was able to control the target ISP’s DNS infrastructure in order to modify DNS responses in the
victim organization’s network.

This blog post explains the infection vector and gives an example of where an automatic update was
abused by StormBamboo. Note that this is just one example; the threat actor has modified installation
workflows for a range of applications whose update mechanisms are vulnerable to this type of attack.

Overview
During one incident investigated by Volexity, it was discovered that StormBamboo poisoned DNS
requests to deploy malware via an HTTP automatic update mechanism and poison responses for
legitimate hostnames that were used as second-stage, command-and-control (C2) servers.

The DNS records were poisoned to resolve to an attacker-controlled server in Hong Kong at IP address
103.96.130[.]107. Initially, Volexity suspected the initial victim organization’s firewall may have been
compromised. However, further investigation revealed the DNS poisoning was not performed within the
target infrastructure, but further upstream at the ISP level. Volexity notified and worked with the ISP, who
investigated various key devices providing traffic-routing services on their network. As the ISP rebooted
and took various components of the network offline, the DNS poisoning immediately stopped. During this
time, it was not possible to pinpoint a specific device that was compromised, but various components of
the infrastructure were updated or left offline and the activity ceased.

This is not the first case where Volexity has encountered an attacker utilizing DNS poisoning to facilitate
initial access to a target network. In the May 2023 Cyber Session, Volexity presented details of a malware
family it calls CATCHDNS, DNS poisoning malware used by DriftingBamboo that was deployed to a
network appliance (in that instance, a Sophos XG Firewall). Volexity cannot confirm what mechanism was
used by StormBamboo on the ISP’s routers to modify DNS responses; however, CATCHDNS would be a
well-designed tool to achieve this goal in an ISP environment. An analysis of CATCHDNS can be found in
the Appendix.

DNS Poisoning: Now with Abuse of Insecure Automatic Update

2/13
In the previously analyzed case where CATCHDNS was used to modify DNS responses, the end goal of
the attacks was to modify the content of pages users browsed. This resulted in a popup JavaScript alert
on the page asking the user to “update their browser”, which would download a malicious file from the
S6pm2GX0uo
attacker’s server. In this most recent case, the attacker’s method of delivering malware was more
sophisticated, abusing insecure automatic update mechanisms present in software in the victim’s
environment, thus requiring no user interaction.

The logic behind the abuse of automatic updates is the same for all the applications: the legitimate
application performs an HTTP request to retrieve a text-based file (the format varies) containing the latest
application version and a link to the installer. Since the attacker has control of the DNS responses for any
given DNS name, they abuse this design, redirecting the HTTP request to a C2 server they control
hosting a forged text file and a malicious installer. The AiTM workflow is shown below.

Volexity observed StormBamboo targeting multiple software vendors, who use insecure update
workflows, using varying levels of complexity in their steps for pushing malware. For example, 5KPlayer
uses a workflow that, for each time the application is started, the binary automatically checks if a new
version of “YoutubeDL” is available. The image below shows the HTTP request to upgrade
[Link].

And the following image shows the contents of upgrade [Link].

3/13
 hC8oisDTFA

If a new version is available, it is downloaded from the specified URL and executed by the legitimate
application. StormBamboo used DNS poisoning to host a modified config file indicating a new update was
available. This resulted in the YoutubeDL software downloading an upgrade package from
StormBamboo’s server.

As one might expect, the YoutubeDL package had been backdoored through the insertion of malicious
code into the middle of the [Link] file that is used as part of the upgrade process. The image
below shows inserted malicious code, starting at line 164.

4/13
 6jrKb1BhLf

Its purpose is to download the next stage, a PNG file containing MACMA (macOS) or POCOSTICK
(Windows) depending on the operating system.

MACMA was first publicly documented in 2021 by Google TAG. In the three years since, MACMA has
changed, with more features added for the convenience of the operator and some of its architecture
overhauled. For example, the network protocol has been completely changed. The original version used
a Data Distribution Server (DDS) implemented in a series of custom classes prefixed by the string
“CDDS”. Now, MACMA appears to use the kNET protocol UDP for network communications. During
Volexity’s analysis, Volexity noticed significant code similarities between the latest MACMA version and
the GIMMICK malware family previously described by Volexity.

Follow-on Activity
In one case, following successful compromise of a victim’s macOS device, Volexity observed
StormBamboo deploying a Google Chrome extension to the victim’s device. Volexity tracks this malicious
extension under the name RELOADEXT. The extension was installed using a custom binary
(ee28b3137d65d74c0234eea35fa536af) developed by the attacker. The installer supports the
following parameters:

5/13
Parameter Description
-p / --
plugin Path of the plugins (must be a ZIP archive)
qYSNqGOfDq
-f / --force Kill Chrome and install the plugin

The browser extension is deployed by modifying the Secure Preferences file to include the new
extension. The installer also correctly fixes the [Link] and protections.super_mac
values in the newly modified SecurePreferences. These values are designed to prevent tampering
with a user’s browser settings, but they can be forged. If they do not contain the expected values,
Chrome will overwrite the SecurePreferences file.

The plugin passed to this tool is stored in the following location:

$HOME/Library/Application
Support/Google/Chrome/Default/Default/CustomPlug1n/Reload/

Once configured, it can be seen in the user’s SecurePreferences file, as shown below.

6/13
 dbOBZI5vlO

Finally, the plugin (6abf9a7926415dc00bcb482456cc9467) is activated by the installer running the

osascript -e tell application “Google Chrome” to activate

The extension portrays itself as an extension that loads a page in compatibility mode with Internet
Explorer:

7/13
 ijDFt46mNO

The main JavaScript logic used by the extension is obfuscated using [Link]. The purpose of the
extension is to exfiltrate browser cookies to a Google Drive account controlled by the attacker. The
attacker’s Google Drive client_id, client_secret, and refresh_token are all contained in the

8/13
extension. They are encrypted beyond the default encryption afforded by [Link] using AES with
the key chrome extension.
Cu8QhDyqDi
The exfiltrated data sent to Google Drive is also encrypted using AES, using the key
opizmxn!@309asdf and encoded with base64 prior to exfiltration.

Conclusion
StormBamboo is a highly skilled and aggressive threat actor who compromises third parties (in this case,
an ISP) to breach intended targets. The variety of malware employed in various campaigns by this threat
actor indicates significant effort is invested, with actively supported payloads for not only macOS and
Windows, but also network appliances.

The incident described in this blog post confirms the supposition made by ESET concerning the infection
vector for the POCOSTICK malware. The attacker can intercept DNS requests and poison them with
malicious IP addresses, and then use this technique to abuse automatic update mechanisms that use
HTTP rather than HTTPS. This method is similar to the attack vector Volexity previously observed being
used by DriftingBamboo following the 0-day exploitation of Sophos Firewalls.

To detect the malware used in this specific attack, Volexity recommends the following:

Use the rules provided here to detect related activity.

Volexity's Threat Intelligence research, such as the content from this blog, is published to
customers via its Threat Intelligence Service. The content of this blog post is a summary of
posts published in 2022–2024. Volexity Network Security Monitoring customers are also
automatically covered through signatures and deployed detections from the threats and IOCs
described in this post.

If you are interested in learning more about these products and services, please do not
hesitate to contact us.

Appendix
CATCHDNS Analysis

CATCHDNS is a 32-bit ELF malware that targets Linux systems which was discovered in a case
investigated by Volexity which Volexity attributes to StormBamboo. CatchDNS is designed to be deployed
on systems through which most of the network traffic passes. In the specific case investigated by Volexity,
this malware was discovered on a perimeter firewall device. However, CATCHDNS could be deployed on
any Linux device that supports the use of libpcap.

After initial analysis, Volexity found that the malware is fully stripped, and the library functions are
statically linked thus making further analysis more difficult. CATCHDNS stores its configuration within
itself as an encrypted archive. The malware decrypts the archive and drops it on disk at runtime with the

9/13
name [binary_name].tty. This archive is then decompressed in memory, and the copy on disk is
deleted. In the example analyzed, the configuration file was in a file named [Link]. The configuration
follows the INI file format, which consists of various sections containing key-value pairs.
SHyLb4Srxs

CATCHDNS configurations can have following sections:

Section Description
[LISTEN_DEV] The listen device and send device sections have a “dev” key under them whose
value refers to the interface on which the malware intercepts the packets and
[SEND_DEV] sends fake packets.
This section contains the “dns” key whose value represents the domain whose
[DNSDomain]
DNS is to be hijacked.
This section contains the “ip” key whose value is the IP address to which the
[SERVER_IP] hijacked domain will resolve once the malware has successfully performed
hijacking.
This section contains a key named “ip”. When this is defined, the malware only
[IPLimit] hijacks requests originating from this IP address. This option only applies to
HTTP requests.
This section is interesting, as it is the only one with multiple keys. It defines
[HTTPConfig]
various values that are used when the malware intercepts HTTP requests.

Packet Interception

Packet Interception is a key component of CATCHDNS. To intercept packets, it makes use of libpcap, a
common library for packet monitoring on Linux. The device/interface on which the malware intercepts the
packets is specified in the configuration. It uses the pcap_open_live library function to open the device
for capturing packets. It installs a BPF filter on the device, and the filter program is compiled using the
pcap_compile function by passing the filter string “(udp and dst port 53 ) or (tcp and dst
port 80 or 8080)”. The filter only captures UDP packets on port 53 and TCP packets on ports 80 or
8080. To actually install this filter, it uses the pcap_setfilter call.

Once everything is set up, CATCHDNS calls pcap_loop with a handler function as an argument. For
every packet that passes the filter, the handler function is called with the packet data as an argument.
This handler function is responsible for processing every filtered packet, as shown below.

10/13
 kHlpNJnoty

The packet processing function checks the Ethernet and IPv4 headers to determine if it is a UDP or TCP
packet. Depending on the IPv4 protocol of the packet, either process_udp_packet or
process_tcp_packet is called.

DNS Hijacking

After analyzing the process_udp_packet function, it is clear the function specifically processes DNS
packets. While dealing with network packets, it a good idea to create the packet structures in IDA and
apply them while analyzing. This makes it easy to understand the whole logic. A DNS packet consists of
the Ethernet header, IP header, and UDP header, followed by the DNS header and DNS data. Using this
knowledge, these structures are applied to the processing functions to reveal the function parsing the
DNS header and to perform basic sanity checks, as shown below.

Each DNS packet contains queries that appear after the DNS header in the packet. The queries contain
information about the domain for which the DNS information is requested by the client. The malware
parses the DNS queries and retrieves the domain name for which the DNS request is being made. Once
it has the domain name, it is compared to the DNS domain(s) present in the malware’s configuration. If
there is match, the DNS request is hijacked and the malware builds a fake DNS response packet. It then
sends the packet back to the client, responding with the attacker-controlled (C2) IP address instead of the
legitimate IP address. The following function is used to build the fake DNS packet and send it to the
client:

11/13
 aDM1KyUqnh

HTTP Interception and Mock Response

The process_tcp_packet function is used to intercept HTTP requests. An attacker can tune the
interception using various configuration options. Both GET and POST requests can be intercepted by the
malware. As previously mentioned, HTTP interception can also be limited to a given IP address using
IPLimit. HTTP interception works similarly to DNS interception. If a request meets the conditions
specified, the malware builds an HTTP mock response and sends it back to the client. The response can
be configured via the malware configuration, where the attacker can configure a hardcoded page to
return in response to specific requests.

To successfully respond with a fake HTTP response, all conditions specified in the configuration must be
satisfied. The following keys can be specified in HTTPConfig:

url
host
ua (user-agent)
content-type
otherhead_%s
sendlimit
configfile

12/13
Other headers to be parsed and checked can be specified using the otherhead_%s key, where %s
denotes the header name. The sendlimit key defines how many times the malware will respond to
requests satisfying the configuration. Once this limit is exceeded, the malware will no longer modify
q7RsGHIHNI
responses to requests matching the pattern. The configfile key contains the path to the web page to
be served if all conditions are met.

Configuration Example

Volexity was able to extract all configurations from the CATCHDNS samples encountered during the
intrusion by intercepting them before they were deleted from the disk. The image below shows one
example of an extracted configuration.

The above configuration intercepts all DNS (53) and HTTP (80 and 8080) packets on the Port1 device.
It hijacks the [Link][.]com domain and responds with IP address 122.10.90[.]20
for this domain. In HttpConfig , the “host” key is absent, meaning the malware would intercept an
HTTP request to any host if it satisfied the other conditions. This was only one of several configurations
observed; the attacker has been observed using a variety of options offered by the malware to achieve
various objectives.

13/13