Android Malware Impersonates ChatGPT-Themed Applications

Posted on by Yang Ji

Executive Summary

Unit 42 researchers have observed a surge of malware written for the Android platform that is attempting to impersonate the popular ChatGPT application. These malware variants emerged along with the release by OpenAI of GPT-3.5, followed by GPT-4, infecting victims interested in using the ChatGPT tool.

Here, we provide an in-depth analysis of two types of currently active malware clusters. The first cluster is a Meterpreter Trojan disguised as a "SuperGPT" app. The second is a "ChatGPT" app that sends short-text messages to premium-rate numbers in Thailand, resulting in charges for the victim that are pocketed by the threat actor.

Android users can download applications written for the Android platform from a variety of places. The Google Play store is the official source, but users are also free to obtain applications from other sources such as websites or links in emails. This means there is potential for users to obtain applications that have not been vetted by Google.

The files described here have been sent to Google and will be blocked from the Google Play store. Google Play Protect also protects users from apps known to contain this malware on Android devices with Google Play Services, even when those apps come from other sources. This underscores the need for users to be aware of the risks when obtaining applications for mobile devices outside of official channels. It is still possible that users could encounter malicious applications for download elsewhere on the internet.

Palo Alto Networks customers with Cortex XDR, the Next-Generation Firewall and Advanced URL Filtering benefit from protections against the ChatGPT-themed attacks discussed in this article. Additionally, the malicious indicators (domains, URLs and hashes) can be prevented with our DNS Security and WildFire services.

Related Unit 42 Topics ChatGPT, Meterpreter, Scams

Introduction

OpenAI created a tool known as Chat "Generative Pre-trained Transformer," or ChatGPT for short. This tool is powered by a large language model (LLM) and is currently in its fourth version.

ChatGPT first became publicly available on Nov. 30, 2022. It quickly went viral, since it demonstrated remarkable question-answering ability, though not necessarily in an accurate manner.

Threat actors are always seeking to distribute their wares via effective attack vectors, and impersonating prevalent applications according to the current global trend is among the most effective means to accomplish this objective. For instance, attackers commonly leveraged the COVID-19 pandemic to spread their own malicious versions of “Health and Wellness” category applications written for the Android platform.

Past reports on malware masquerading as a ChatGPT-related tool, as well as our earlier publication "ChatGPT-Themed Scam Attacks on the Rise," found that scammers were taking advantage of ChatGPT's popularity to launch attacks. Threat actors are using similarly worded domain names to trick victims into giving away personal information or downloading malware.

Here, we continue to report on this trend, sharing our findings on some malicious Android applications we've recently discovered in our telemetry. Specifically, we found two types of active malware. One is a Meterpreter Trojan disguised as a "SuperGPT" app, and the other is a "ChatGPT" app that sends messages to premium-rate numbers in Thailand.

Meterpreter Trojan

Our team uncovered a malicious Android Package Kit (APK) sample, which turned out to be a Trojanized version of a legitimate application. The legitimate application is an AI assistant based on the latest version of ChatGPT. The malicious version of this application enables the actor to establish remote access to an Android device if exploitation is successful.

Table 1 describes the legitimate application and Table 2 shows the malicious application.

Application name SuperGPT - AI with GPT-4
Description (summarized from the official listing) A GPT-4 powered AI assistant, able to perform tasks such as:

  • writing emails,
  • answering questions,
  • and writing articles

Also comes equipped with the following capabilities:

  • speech recognition
  • language translation
Package name com.dominapp.supergpt
Version name (code) 1.2 (8)
SHA-256 hash d7ef8929b236a43917f351c39963916c1dd3a9c0580499443322750435245f9f
File size 10.85 MB (11,378,336 bytes)

Table 1. Metadata of the legitimate application.

The MainActivity class of the malware sample contains a String variable reference to the official ChatGPT URL https://chat.openai.com/chat. Package-Class named v3.v is a custom WebViewClient class implementation (WebView is Android's built-in implementation to embed web browser functionality in apps made for its operating system). As such, this Java class is able to extend or override the default functionality. It does so by adding the following redirect rules:

  1. Redirect to https://chat.openai.com/chat, if URL contains https://openai.com/blog/chatgpt/
  2. Redirect to https://chat.openai.com/chat after a 1,000 millisecond delay, if URL contains beta.openai.com/
Application icon Screenshot

Image 1 is the application icon for SuperGPT. It is the head of a blue robot using headphones attached to a voice mic.
ic_launcher.png (app icon)

Image 2 is a screenshot of the SuperGPT app. The SuperGPT logo appears on top with the header “Talk with AI” followed by the text, “You can ask any question in your language and receive a response with a human-like voice powered by GPT-3.” At the bottom there is a button that says get started.
App screenshot
Application name SuperGPT
SHA-256 hash af19ca9213a20263c30584a2bf260dcdb3b4eafa4f43af10824af781573a2314
File size 12.39 MB (12,994,395 bytes)
Programming language Kotlin
Version name (code) 1.2 (8)
Package name com.dominapp.supergpt
Main activity com.dominapp.supergpt.activities.MainActivity
Android version Minimum: API level 23 (Android 6)
Target: API level 32 (Android 12L)

Table 2. Metadata of the malicious APK sample.

According to VirusTotal (VT), this sample was first submitted through VT's web interface from Nicaragua (NI), on 2023-03-16 02:06:04 UTC, as filename 2021id.apk.

Payload Implantation

Comparing the differences between the legitimate and malicious APK samples, it is clear that the critical Trojanizing addition to the file is the following line of Smali language code (shown in Figure 1).

Image 3 is a screenshot of Smali code. The added, malicious line of code is bolded.
Figure 1. Added line of malicious Smali language code.

The core threat in this malware sample is known as "Meterpreter." It is created using the Metasploit framework.

The source code of the initial Java-based Android Meterpreter stager can be found on Rapid7's GitHub repository. The main functionality is implemented within the Payload class. The Payload class' start method is invoked by the MainService class. The MainService class, in turn, can be either:

  • Started by the MainActivity class
  • Started by the MainBroadcastReceiver class automatically upon completion of the device boot sequence

The Payload class' main method is responsible for performing the following sequence of actions:

  1. Parse the hard-coded exploit configuration stored in the configBytes byte array (shown in Figure 2).
    • Note: This is not obfuscated in any way (e.g., the TCP or HTTP remote host address and port are clearly visible)
  2. Ensure the Android device's central processing unit (CPU) remains on via the Power Manager system service's partial wake lock functionality.
  3. Hide the icon’s application if requested.
  4. Establish a socket connection to the author-managed remote host.
  5. Download a secondary payload upon successful connection, implementing the full range of capabilities (e.g., the dump_sms command).

In the case of the APK malware sample in question, the following sequence of operations triggers this Meterpreter payload:

  1. The service named com.dominapp.supergpt.eluad.Vojnd starts upon the BOOT_COMPLETED action, as declared in the AndroidManifest.xml file.
  2. The thread named com.dominapp.supergpt.eluad.C2094e spawns and runs.
  3. The main method of the package class named com.dominapp.supergpt.eluad.Dapjs is invoked.
Image 4 is a screenshot of a configuration byte array that is characteristic of a Meterpreter payload.
Figure 2. Configuration byte array, characteristic of a Meterpreter payload.

The Meterpreter payload is configured to connect to the remote endpoint tcp[://]Gwdidkfkf-47070[.]portmap[.]io:47070. Portmap.io is a service that performs port forwarding free of charge.

Certificate Attribution

The digital code-signing certificate used to sign this sample belongs to the attacker with the following characteristics:

  • Email address – lkpandey950@gmail[.]com
  • Organization Common Name (CN) – Hax4Us
  • Located in Shahdara, Delhi, India
  • The certificate is valid from 2020-07-17 11:08:41 UTC to 2047-12-02 11:08:41 UTC
  • Serial number – 1a505d53b1c75046a81acb021fdb5f99936b75db
  • SHA-1 thumbprint – 65094A64233F818AEF5A4EDE90AC1D0C5A569A8B

This certificate is attached to over a hundred other publicly shared malware samples on VT (as shown in Figure 3).

Image 5 is a screenshot of a VirusTotal search query. The columns include detections, size, and when the samples were first seen. The samples also include tags, such as android, obfuscated, reflection, telephony, and so on.
Figure 3. Snapshot of partial results for VT search query androguard:"C:IN, CN:hax4us, L:shahdara, O:hax4us, ST:delhi, email:lkpandey950@gmail[.]com."
In contrast, the legitimate application is digitally signed with a generic certificate.

SMS to Premium-Rate Numbers

We've also uncovered another cluster of APK malware samples. On the surface, the malware seems to be presenting the following webpage (shown in Figure 4) containing a description of ChatGPT. But in fact, this threat conceals a sinister intent underneath.

Image 6 as a screenshot of an article about ChatGPT on a webpage, titled ChatGPT: optimizing language models for dialogue. There is an image of a robot head with the words, ChatGPT on it, and then the article goes into details about what ChatGPT is.
Figure 4. ChatGPT: Optimizing Language Models for Dialogue. hxxps[://]apkafe[.]com/what-is-chatgpt.
Image 7 is the OpenAI logo and logotype.
Figure 5. OpenAI logo and logotype.

Moreover, all these APK samples share the OpenAI logo often associated with ChatGPT (shown in Figure 5) as their application icon, adding to the deceptive narrative that this application is related to the ChatGPT AI tool.

These APK malware samples are capable of sending SMS messages to premium-rate numbers in Thailand (TH). Premium-rate numbers cost more than calls to normal phone numbers, in exchange for rendering some sort of service (e.g., users providing information). The business behind it collects the earnings, but this can also be abused to conduct scams and fraudulent activity. For reference, the official Android Open Source Project (AOSP) codebase contains a list of premium-rate numbers by country.

The Android permission to send SMS text messages, android.permission.SEND_SMS, is requested by the application, and a reference to the "country":"thailand" is passed as a ContentValue. The samples also make use of OneSignal, a service that enables apps to send messages via push notifications, including by email, SMS and within the app itself.

For instance, the configuration obtained from the URL hxxps[://]api[.]onesignal[.]com/apps/af63b434-ec50-46a0-9374-d57a383f2e03/android_params[.]js is reproduced below:

(The OneSignal app ID is af63b434-ec50-46a0-9374-d57a383f2e03)

{
  "awl_list": {},
  "android_sender_id": "660194064544",
  "chnl_lst": [],
  "outcomes": {
    "direct": {
      "enabled": false
    },
    "indirect": {
      "notification_attribution": {
        "minutes_since_displayed": 60,
        "limit": 10
      },
      "enabled": false
    },
    "unattributed": {
      "enabled": false
    }
  },
  "receive_receipts_enable": false
}

The formatted phone number in the android_sender_id field value is +661-9406-4544.

These APK samples are digitally signed with a generic certificate. As for other key attributes, their values are depicted in Table 3 below.

Validity From 2008-02-29 01:33:46 UTC

  To 2035-07-17 01:33:46 UTC
Serial number 936eacbe07f201df
Thumbprint (SHA-1) 61ED377E85D386A8DFEE6B864BD85B0BFAA5AF81

Table 3. Code-signing certificate attributes for Type II APK samples.

This cluster of samples can be subdivided into two smaller batches, each sharing some common characteristics. APK samples in the first batch send an SMS text message to one hard-coded, premium-rate Thai number and make use of the OneSignal service. APK samples in the second batch send different SMS text messages to two other hard-coded, premium-rate Thai numbers, and they do not obtain configuration from an external OneSignal endpoint.

The APK samples belonging to the first batch have a lower version compared to those from the second. This suggests that the first batch could be an earlier iteration of malware development than the second. This theory is supported by the earlier "first submission" timestamp of these APK samples on VT: batch one (February 2023), followed by batch two (March 2023).

Batch One

These are the SHA-256 hashes of samples in this batch:

  • 2980329fa5eaed0f5625e961572f7ae8136ca7df30cca9e9c8783c827627b692
  • 391e8f394af425f1e7edff6aea1605aa89f2fb0233c44e70cff265fc60ec3b1b
  • d1844bf3865c7d2e4745baa2496297937821171d7a3ad4412b0a4e767bc32b5e
  • d1b1813f7975b7117931477571a2476decff41f124b84cc7a2074dd00b5eba7c

Table 4 below summarizes the static attributes of samples in this batch.

Package names
  • com.chatgpt.tl
  • com.gg.gptchatt
  • com.chatgpt.go
  • com.chatgpt.ogothai
Main activities
  • chatgpt.subth.MainActivity
  • tikitaka.sub.MainActivity
Version name (code) chatgpt (183)
Android version Minimum: API level 18 (Android 4.3)
Target: API level 30 (Android 11)
Tags
  • GTA_TT
  • ChatGPT
First submission timestamps on VT (UTC) Between 2023-02-02 08:37:23 and 2023-02-07 03:08:33

OneSignal configuration
App ID af63b434-ec50-46a0-9374-d57a383f2e03
Android sender ID +661-9406-4544

Table 4. Static attributes of batch one APK samples.

Batch Two

These are the SHA-256 hashes of samples in this batch:

  • b787d5ef4a0c350a9f62f55907c8ef6d92bf7699b8544fabff5a263e52a2d0d1
  • be757541584cc2dc2e7adacf7a5186be07d474f06c8698a938589f86ce56ea34
  • e9bb6d04d796eb147b9d73a7df91fb9e6a99e0be8a41a61329d600a9dfe8b1ae

Table 5 below summarizes the static attributes of samples in this batch.

File size 1.249 MB (1,309,619 bytes)
Package name com.chatgpt.ggmmtlan
Main activity ggtlan.sub.MainActivity
Version name (code) chatgpt (200)
Android version Minimum: API level 22 (Android 5.1)
Target: API level 30 (Android 11)
First submission timestamp on VT (UTC) SHA-256 hash
2023-03-08 22:16:21 be757541584cc2dc2e7adacf7a5186be07d474f06c8698a938589f86ce56ea34
2023-03-10 12:00:23 e9bb6d04d796eb147b9d73a7df91fb9e6a99e0be8a41a61329d600a9dfe8b1ae
2023-03-17 10:19:14 b787d5ef4a0c350a9f62f55907c8ef6d92bf7699b8544fabff5a263e52a2d0d1

Table 5. Static attributes of Batch 2 APK samples.

Conclusion

The emergence of ChatGPT-themed APK malware poses a severe threat to the security and privacy of mobile devices. These types of malware can potentially steal sensitive information, spy on user activities and cause significant financial losses for unsuspecting victims.

To protect themselves against this type of malware, mobile users should take proactive measures, such as installing reputable antivirus software, being cautious when downloading apps from third-party sources and keeping their devices up to date with the latest security patches.

Overall, the threat of mobile malware highlights the critical importance of mobile device security. By remaining vigilant and taking proactive steps to safeguard our devices, we can help prevent the spread of this dangerous malware and protect ourselves from potential harm.

Palo Alto Networks customers with Cortex XDR, the Next-Generation Firewall and WildFire benefit from protections against the attacks discussed in this article. Additionally, the malicious indicators (domains, URLs and hashes) can be prevented with our DNS Security and Advanced URL Filtering services.

If you think you might have been impacted or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America Toll-Free: +1.866.486.4842 (+1.866.4.UNIT42)
  • UK: +44.20.3743.3660
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Indicators of Compromise

Category SHA-256 hashes
APK malware samples Type I
  • af19ca9213a20263c30584a2bf260dcdb3b4eafa4f43af10824af781573a2314
APK malware samples Type II

Batch One

  • 2980329fa5eaed0f5625e961572f7ae8136ca7df30cca9e9c8783c827627b692
  • 391e8f394af425f1e7edff6aea1605aa89f2fb0233c44e70cff265fc60ec3b1b
  • d1844bf3865c7d2e4745baa2496297937821171d7a3ad4412b0a4e767bc32b5e
  • d1b1813f7975b7117931477571a2476decff41f124b84cc7a2074dd00b5eba7c

Batch Two

  • b787d5ef4a0c350a9f62f55907c8ef6d92bf7699b8544fabff5a263e52a2d0d1
  • be757541584cc2dc2e7adacf7a5186be07d474f06c8698a938589f86ce56ea34
  • e9bb6d04d796eb147b9d73a7df91fb9e6a99e0be8a41a61329d600a9dfe8b1ae
URL
  • hxxps[://]api[.]onesignal[.]com/apps/af63b434-ec50-46a0-9374-d57a383f2e03/android_params[.]js
  • tcp[://]Gwdidkfkf-47070[.]portmap[.]io
Certificate Thumbprint (SHA-1)
  • 65094A64233F818AEF5A4EDE90AC1D0C5A569A8B

MITRE ATT&CK TTPs

ID Technique Description
T1582 SMS Control APK malware samples are capable of sending SMS to Premium-rate Numbers in Thailand.
T1623 Command and Scripting Interpreter APK malware samples are capable of providing Meterpreter shell access.

Additional Resources

Inside Win32k Exploitation: Background on Implementations of Win32k and Exploitation Methodologies

Posted on by Samantha Stallings

Executive Summary

In late January 2022, several reports on social media indicated that a new Microsoft Windows privilege escalation vulnerability (CVE-2022-21882) was being exploited in the wild. These reports prompted us to do an analysis of CVE-2022-21882, which turned out to be a vulnerability in the Win32k.sys user-mode callback function xxxClientAllocWindowClassExtraBytes.

In 2021, a very similar vulnerability (CVE-2021-1732) was reported to – and patched by – Microsoft. We decided to take a closer look at both vulnerabilities to better understand the code involved in each. In our initial analysis we wanted to determine why the patch for CVE-2021-1732 was not sufficient to prevent CVE-2022-21882.

This is part one of a series that will cover Win32k internals and exploitation in general using these two vulnerabilities and their related proof-of-concept (PoC) exploits as examples.

Here, we cover a significant amount of background information, including years worth of background research, conducted by several excellent researchers, to get the reader up to date to the latest implementations of Win32k and its associated exploitation methodologies. For an even deeper understanding of the subject, we also recommend reading all of the linked references at the end of the post.

Both vulnerabilities discussed in this series are detected and blocked by the Cortex XDR Anti-LPE protection module. Both vulnerabilities are data-only exploits that copy the NT/Authority System privilege token to that of the current (exploit) process for privilege escalation. The XDR Anti-LPE modules monitor for this specific type of privilege escalation technique.

Related Unit 42 Topics Microsoft Windows, CVE-2021-1732, CVE-2022-21882

Table of Contents

Introduction to CVE-2022-1732 and CVE-2022-21882
Win32k – History and Background
Basic Windows GUI API Background
Creating a Window
Window Messages and Window Procedures
Window Structures
User-mode Callbacks
Conclusion
Additional Resources

Introduction to CVE-2022-1732 and CVE-2022-21882

Quite a lot has been written on Windows development via the Win32 API, and Windows internals. However, in our experience, very few security-related sources cover development via the graphical user interface (GUI) or its underlying internals. This interface is implemented within Win32k.sys, Win32kbase.sys and Win32kfull.sys.

Therefore, we decided to do some research to get better acquainted with the Windows GUI internals and associated APIs. We read a few whitepapers on Win32k exploitation written over the past 10 years or so, as well as the Microsoft Developer Network (MSDN) documentation on the Win32 API.

We don’t want to assume any level of expertise with the underlying code involved. Therefore, to ease the understanding of the two vulnerabilities being analyzed as well as other Win32k.sys vulnerabilities and exploits, in our first post we will cover some background on the relevant APIs, objects and data structures involved.

Because exploitation of these vulnerabilities and the patch bypass method was relatively easy to understand, we chose these two recent examples to walk through some of the Win32k internals to help people understand how they are commonly leveraged to obtain read/write primitives. It also provides us with a good opportunity to discuss common Win32k exploit targets (user-mode callbacks) within the Win32k.sys codebase.

Win32k – History and Background

Prior to Windows NT 4.0, Microsoft implemented the GUI functionalities of the Win32 API within a user-mode process called the Client-Server Runtime SubSystem (CSRSS.exe). However, context switches between user-mode and kernel-mode were computationally expensive and required large memory overhead.

To eliminate these issues and speed up the overall Windows operating system, Microsoft decided to move the Windows subsystem (Window Manager, GDI and graphics drivers) to the kernel. This transition started with Windows NT 4.0 in 1996.

This change was implemented through a kernel-mode driver called Win32k.sys, in what is now known as the kernel-mode Windows subsystem. The user-mode component of the Windows subsystem still resides within CSRSS.

Although the move to the kernel greatly reduced the overhead required, Microsoft had to resort to some old tricks, such as caching management data structures within the user-mode portion of the client’s address space. In fact, to further avoid context switches, some management structures have historically been stored exclusively in user-mode. However, in an effort to eliminate kernel address leaks, Microsoft has started to implement methods that use user-mode and kernel-mode copies of these structures to prevent kernel addresses from being stored in user-mode structures.

Additionally, because Win32k needed a way to access these user-mode structures and support some existing user-mode functionality such as window hooking, user-mode callbacks were implemented to facilitate these tasks.

“User-mode callbacks allow Win32k to make calls back into user-mode and perform tasks such as invoking application-defined hooks, providing event notifications, and copying data to/from user-mode,” Tarjei Mandt wrote in a detailed whitepaper. His research was also presented at Black Hat USA in 2011. In doing so, he demonstrated the challenges Microsoft faced in implementing user-mode callbacks and preserving data integrity.

Mandt demonstrated that many objects were not being properly locked before making user-mode callbacks, which allowed user-mode code to destroy these objects during the user-mode callback, resulting in Use-After-Free (UAF) vulnerabilities. Although Microsoft has addressed many of the issues Mandt pointed out in 2011, user-mode callbacks are still abused today.

Inspired by Mandt’s research, in 2019 Gil Dabah wrote a paper building upon Mandt’s research. He discovered that even if user-mode code destroys objects that are correctly locked during user-mode callbacks, the destroyed objects can have secondary effects on other objects that are not locked correctly. This activity resulted in secondary object destruction and further UAF vulnerabilities.

Basic Windows GUI API Background

Before we discuss Win32k internals, we will briefly cover a simple C program that creates and destroys a window using the Win32 API. This will allow us to begin to understand how graphics windows are programmatically created and manipulated. It will also allow us to examine the underlying structures that define each window and their menus.

We’ll be referring to the sample code in Figures 1-3 below to discuss the basics of window creation and the underlying structures used to define windows and menus. Comments have been added to the sample code to make it as understandable as possible.

As shown in Figure 1, the sample program starts off by defining a window class. A process must register a window class before it can create a window of the type defined within the WNDCLASSEX structure. First a window class object is declared WNDCLASSEX wcx = { }, then the window class structure is filled in.

Image 1 is many lines of code that define the window class. The object is declared, and then the structure follows.
Figure 1. Defining the window class.

The elements of the window class are as follows:

  • cbSize: The size, in bytes, of this structure. Set this member to sizeof(WNDCLASSEX).
  • style: The window class styles. This member can be any combination of the Class Styles.
  • lpfnWndProc: Pointer to the function that processes all messages sent to windows in the class and defines the behavior of the window. Typically, the default window procedure is used for at least some messages. However, custom window procedures are often used to create unique window experiences. For more information, see WindowProc.
  • cbClsExtra: The number of extra bytes to allocate following the window-class structure. The system initializes the bytes to zero.
  • cbWndExtra: The number of extra bytes to allocate following the window instance. The system initializes the bytes to zero. Do not confuse this with cbClsExtra, which is common to all windows of this window class. This is often 0, but when it’s not, the memory is typically used to store data that is not constant across windows. We’ll see this used in the PoC later.
  • hInstance: A handle to the instance that contains the window procedure for the class. Identifies the application or .DLL that registered the class. Assigned the hinstance argument to WinMain here.
  • hIcon: A handle to the class. LoadIcon(NULL, IDI_APPLICATION) loads the default icon.
  • hCursor: A handle to the class cursor. LoadCursor(NULL, IDC_ARROW) loads the default cursor.
  • hbrBackground: A handle to the class background brush. GetStockObject (WHITE_BRUSH) returns a handle to a white brush. The return value must be cast because GetStockObject returns a generic object.
  • lpszMenuName: Pointer to a null-terminated character string that specifies the resource name of the class menu, as the name appears in the resource file. If no menu bar is needed, this field can be NULL.
  • lpszClassName: The class name that identifies this window class structure.
  • hIconSm: A handle to the small class icon.

Now that the attributes of the window class have been defined, we need to register it with the application using RegisterClassEx(), shown in Figure 2 below. On failure, RegisterClassEX() returns 0. Otherwise, it returns a class atom that uniquely identifies the class being registered. Registering the window class defines the class and its associated structure members to Windows.

Image 2 is a few lines of code showing the registration of the window class.
Figure 2. Registering a window class.

Creating a Window

Once the window has been registered, we can create an instance of the window class by calling CreateWindowExA(), shown in Figure 3 below.

Image 3 is the many lines of code that create the main window.
Figure 3. Code for creating a window.

The arguments of CreateWindowEX are as shown in Figure 4.

Image 4 shows the arguments making up the CreateWindowExA function prototype.
Figure 4. CreateWindowExA function prototype.

A brief description of each argument is listed below:

  • dwExStyle: The extended window style of the window being created. In this case, we have set it to the default window constant of WS_EX_LEFT, which gives the window generic left-aligned properties.
  • lpClassName: The class name. Taken from wcx.lpszClassName that was declared in the call to RegisterClassEX.
  • lpWindowName: The window name.
  • dwStyle: The style of the window being created. In this case, we used WS_OVERLAPPEDWINDOW, which creates a top-level (parent) window.
  • X: The initial horizontal position of the window. For an overlapped or pop-up window, the x parameter is the initial x-coordinate of the window's upper-left corner, in screen coordinates. For a child window, x is the x-coordinate of the upper-left corner of the window relative to the upper-left corner of the parent window's client area. If x is set to CW_USEDEFAULT, the system selects the default position for the window's upper-left corner and ignores the y-parameter.
  • Y: Same as above but for the y-coordinate.
  • nWidth: The width of the window.
  • nHeight: The height of the window.
  • hWndParent: A handle to the parent or owner window of the window being created.
  • hMenu: A handle to a menu, or specifies a child-window identifier, depending on the window style. For an overlapped or pop-up window, hMenu identifies the menu to be used with the window; it can be NULL if the class menu is to be used.
  • hInstance: A handle to the instance of the module to be associated with the window.
  • lpParam: The extra information that is passed to the window's window procedure. If no extra information is to be transmitted, pass NULL.

Once the window has been created with the call to CreateWindowEx(), the window has been created internally – which is to say, memory has been allocated and its structures populated – but not shown. To display the window, we call the ShowWindow() function.

ShowWindow() takes the handle obtained from the call to CreateWindowEXW() and the state variable nCmdShow, obtained from WinMain(). The nCmdShow variable determines how the window will be displayed on screen, whether it’s normal, maximized or minimized, for example.

ShowWindow() only controls how the application window is displayed. This includes elements such as a title bar, a menu bar, the window menu, the minimize button, etc. The client area is the area where the application displays data, such as where you type text in a text editor. The client area is painted by calling the UpdateWindow() function.

If you specify the WS_VISIBLE window style as the dwStyle parameter to the CreateWindowEXW() function, you do not need to call the ShowWindow() function. This is implied, and Windows will take care of invoking this for you. On a similar note, if you do not specify the WS_VISIBLE style and you also do not call the ShowWindow() function, the window will remain hidden from view.

Window Messages and Window Procedures

After the call to UpdateWindow(), the window is fully visible and ready for use. When writing a simpler console application for Windows, the application makes explicit function calls in response to user input from the console.

In a windowed application, a user can typically interact with the application by entering text, clicking through buttons and menus, or just by moving the mouse. Each of these actions have their own special functionality. To make this work, Microsoft implemented an event driven system that relays messages from user input (e.g., keyboard, mouse or touch) to the various windows in each application. These messages are handled by a function within each window, known as the window procedure.

Windows maintains a message queue for each thread, which will relay any user input event that affects the state of the window. Windows then translates these events into messages and places them into the message queue. The application processes these messages by executing the code similar to that in Figure 5 below.

Image 5 is the window message queue loop, starting with “while”.
Figure 5. Window message queue loop.

The GetMessage() function retrieves the next message from the message queue. The MSG parameter is a structure that contains the message information required for the assigned window procedure to properly handle the message.

Among the members of the MSG structure are a handle (hwnd) to the window whose window procedure receives the message, and a message that contains an identifier that determines what request is being asked of the window procedure. For example, if the message contains a WM_PAINT message, it tells the window procedure that the window’s client area has changed and must be repainted.

The TranslateMessage() function translates virtual-key messages into character messages, but this is not important for the current discussion. The DispatchMessage() sends the message to the window, identified by the window handle in the msg structure, to be handled by the window procedure defined by that window class.

Up to this point, the example code has accomplished the overhead of defining the window class by performing the following actions:

  • Registering the window
  • Creating an instance of a window defined by the window class
  • Displaying the window on the screen
  • Entering the message loop

It’s the window procedure that determines what is displayed and how it responds to user input. Windows provides a default window procedure to handle any window messages that an application does not process, and it provides the minimal functionality for any window to function properly.

The window procedure is where all the functionality of the window is defined and, as one might guess, they can be quite involved. For our purposes we are currently only interested in Microsoft’s default window procedure, DefWindowProc().

Window Structures

As mentioned earlier, Windows now manages GUI objects such as menus, windows, etc., in the kernel via Win32k.sys. When a window object is created, its properties are tracked within a data structure known as tagWND.

Unfortunately, Microsoft removed many of the Win32k debugging symbols, making it much more difficult to gain transparency into these structures. Based on some reverse engineering, Figure 6 shows what the structure looks like in Windows 10 version 21H1.

Image 6 is many lines of code — it is the TagWND parent structure.
Figure 6. TagWND parent structure.

This is not a comprehensive list of members, but only those important to this discussion. Looking at HMAllocObject during a call to xxxCreateWindowEx, where the allocation of the structure occurs, we can confirm this structure is 0x150 (336) bytes in size.

The WinDbg output just prior to the call to HMAllocObject is shown in Figure 7. You can see the fourth argument, which represents the allocation size, is stored in the r9 register and is equal to 0x150.

Image 7 is the WinDbg output showing the input parameters to the HMAllocObject object. The fourth argument represents the allocation size and is stored in the r9 register.
Figure 7. WinDbg output showing input parameters to HMAllocObject.

The tagWND structure, shown in Figure 6, used to be referenced within the Win32ClientInfo entry of the Thread Environment Block (TEB). It has since been removed to prevent easy leaking of kernel-mode addresses.

The first entry in the kernel tagWND structure is the window handle. Each window will have a representative tagWND structure associated with it in the kernel.

During the analysis of CVE-2022-21882, this structure will be important, but for now, we’ll focus on offset 0x28. I’ve labeled it as *pWND because Microsoft no longer supplies symbols. Additionally, Microsoft no longer provides a name for this structure — however, in the past it has been referred to as state or WW. According to Microsoft, these names are deprecated and no longer used internally.

What is important to know about this pointer is that it’s a user-mode version of the tagWND data that does not include kernel addresses, and it is structured differently than its parent tagWND structure. This child structure exists both in the kernel as well as in user-mode. This is how Windows manages the data in an attempt to avoid leaking kernel addresses, because any user-mode application will work with the copy of the tagWND structure located on the user-mode desktop heap and hence will not be able to see any kernel-mode addresses.

I will continue to refer to the child structure as a tagWND structure. Be aware, it is structured differently (as shown in Figure 8, below) than the parent tagWND structure above, but is still commonly referred to as tagWND in other research blogs and papers.

The child tagWND structure is shown in Figure 8, and the elements and their offsets were confirmed through reverse engineering. The gaps were not analyzed and are not important for this discussion.

Many of the elements of the WNDCLASSEX structure discussed in the section about creating a window can be seen within the tagWND structure. Therefore, it’s pretty clear that when a window is created, the properties assigned via the WNDCLASSEX structure are passed to the kernel and stored within the tagWND structures. The properties are then propagated to the user copies in both the kernel and user-mode desktop heaps.

Image 8 is many lines of code — the child tagWND structure. The BYTE gaps were not analyzed as they are not relevant.
Figure 8. User-mode safe copy of the tagWND structure.

Figures 9 and 10 show both the parent tagWND and the kernel copy of the user-mode safe tagWND structures respectively.

Image 9 is the WinDbg memory dump of the parent tagWND structure. ff.ff8e82 ffff8e82 ff.ff8e82 ffff8e82 ff.ff8e82 ffff8e82 ff.ff8e82 ffff8e82 ffff8e82 ffff8e82 ffff8e82 kd> dq exffff8e82ee8437ee Lye eeeøøeee• eee5033e eeeoøeeøs 00038390 oeeeeeee• eeeeøeeø eøeøøeee• eøeeoøee eeeøeøøe• eeeøøeeø eeeeøeee• eeøeeeee oeeeeeøe• eeeeeeeø eøeoøeee• eoøeeeee oeeeeøøe• eeeeøeee eeeoeeees oooeeøee eeeøe15b• a4b69d8ø eø8437eø 008437fø 00843800 00843810 00843820 00843830 00843840 00843850 00843860 00843870 00843880 eeeøeøøe• eeeeøees ffffd40fS f34ea4bø eøeøøeeø eeeoøeeøs e2cceme 008437ee 0083354e 82 ffff8e82 ffff8e82 ffff8e82 01038390 ee844e70 ee83ø93e ee81887ø
Figure 9. WinDbg memory dump of the parent tagWND structure.

The Figure above is the parent tagWND, and you can see that the handle (offset 0x00) is the same as that of the copy tagWND below. You can also see that the parent structure has kernel addresses, while the user-mode safe copy only has user-mode addresses. Lastly, notice the parent tagWND+0x28 is a pointer to the child tagWND copy’s address.

Image 10 is a screenshot of the WinDbg memory dump of the child tagWND structure. ffff8e82 ffff8e82 ffff8e82 ffff8e82 ffff8e82 ffff8e82 ffff8e82 ffff8e82 ffff8e82 ffff8e82 ffff8e82 dq poi(exffff8e82ee8437eo + ox28) eøeeeeee• 0005033e eeeeeøøø• eee3839ø gøeømeø• 40020019 ecceeøøe• egeømeø eøøe7ff7& ed32eeee eeeøeøøe• eeeøøeeø eqeeøeec oeøe10de eeeøeeee• øeeeeeeø eéeoøeee• ooeeeeee eeeøeøøø• eee384eø eeeeøeeø• eeø2ad3e eeeøeeee• øeeeeeeø oøeoøe27& ooøeoe88 eeeøeel€ eeeøøee8 eeeeeel€ eeøeee8e eeeø7ffT ed321edø oeeeeøøe• eeeeøeeø eeeoøeeø• eeø38fee eeeeeeeø• eeøeeeee eeeøe15b• a4b69d8Ø eeoeeeoe- oeeeoeoo eeeeoeee- eooeooee 01e3839ø 01083aø 01e383bø 010383cø 010383dø 010383eø 01e383fø 01038400 01e3841ø 01e3842ø 01038430
Figure 10. WinDbg memory dump of the child tagWND structure.

Historically, there have been a few methods to leak the kernel mode addresses of window objects. All objects within Win32k that store properties set by user-mode code (e.g., windows, menus) are commonly referred to as user objects.

All user objects, the user-mode copy of the tagWND structure being one of many, are indexed within a per-session handle table commonly known as the UserHandleTable. (Though the tagWND structure wasn’t always a user-mode safe copy and did once contain kernel addresses.)

It used to be possible to locate tagWND objects via the UserHandleTable through an exportable structure within User32.dll, called gSharedInfo. This is no longer possible as of Windows 10 version 1703. Due to Microsoft’s continued efforts to eliminate kernel address leaks, they have removed the kernel addresses of objects within the desktop heap from the UserHandleTable.

The Window Manager validates handles with an non-exported function, HMValidateHandle, which is located in User32.dll. Prior to Windows 10 version 1803, the Window Manager returned the kernel-mode pointer to the object whose handle was to be validated and it was commonly used to leak this address. Even though the kernel address leak has been fixed, this method will be important when we look at the two vulnerabilities later.

The reason exploit writers are so interested in locating tagWND structures is because, historically, you can modify tagWND.cbExtra with a large value to allow for an arbitrary write into an adjacent tagWND structure using the SetWindowLong function. However, as of Windows 10 version 1703, any bytes written by SetWindowLong are no longer written to the kernel. That is except under a specific condition, which will be discussed later during the analysis of the exploit. This fix has effectively killed this technique for creating an arbitrary write.

User objects are stored in one of three types of memory within the kernel: the desktop heap, the shared heap or the session pool. For the purposes of this discussion, we are interested in the desktop heap because the objects we’ll be working with are stored here.

Each desktop gets its own desktop heap. Since Windows stores management structures in the desktop heap, which resides in the kernel, there needs to be a way for user-mode applications to access these structures.

Historically, Windows created a user-mode mapped copy of the desktop heap that contained kernel-mode pointers to relevant structures. Today, these pointers have been replaced with user-mode pointers, indicating that Windows has begun to create an isolated copy of the desktop heap in user-mode to eliminate the disclosure of kernel-mode pointer addresses.

Typically when you are trying to exploit a kernel vulnerability, you need a few things to enable exploitation from user-mode. One of these is a way to determine where objects of interest are located within the kernel in order to get around kernel address space layout randomization (KASLR). Therefore, knowing where the desktop heap is located, as well as the ability to find specific objects of interest within the desktop heap is highly desirable.

In fact, since Windows 10 version 1607, Microsoft started adding mitigations in an attempt to prevent exploit writers from locating the desktop heap and its associated objects in the kernel. These mitigations include removal of kernel addresses from the UserHandleTable, as discussed above, as well as removal of kernel pointer references to the desktop heap within the Win32ClientInfo structure located in each process’ Thread Environment Block (TEB). Additionally, HMValidateHandle now returns user-mode (versus kernel-mode) pointers for any object handles passed to it.

For more information on the history of Microsoft’s Win32k kernel mitigation history, see Morten Schenk’s 2017 Black Hat USA presentation.

We should note that there is an assumption that we are operating under a low-integrity process. If the process is medium-integrity or higher, it is trivial to use API functions such as EnumDeviceDrivers and NtQuerySystemInformation to obtain kernel pointers of interest.

User-mode Callbacks

The final thing that needs to be discussed in this first post discussing the background of these PoCs are user-mode callbacks.

Because the windows subsystem is primarily located within the Windows kernel, while the windows themselves operate in user-mode, Win32k must make frequent calls from the kernel into user-mode. User-mode callbacks provide a mechanism to implement items such as application defined hooks, event notifications and copying data to/from the kernel from/to user-mode.

Win32k calls KeUserModeCallback, with the associated ApiNumber of the user-mode function it wants to call, when making a user-mode callback. The ApiNumber is an index into a function table, located within User32.dll (USER32!apfnDispatch). The address of this table is copied to the process environment block (PEB) (PEB.KernelCallbackTable) during initialization of User32.dll within each process.

In the analysis of the exploits, we show how user-mode callbacks are hooked via the KernelCallback table and show what the table looks like in WinDbg (shown in Figure 21 and Figure 22). The function prototype of KeUserModeCallback and its associated parameters are shown in Figure 11 below.

Image 11 is a screenshot of the KeUserModeCallback function and its associated parameters.
Figure 11. KeUserModeCallback function prototype.

The user-mode callback input parameters are passed via the InputBuffer, while the output from the callback function is returned within the OutputBuffer. Upon invoking a system call, ntdll!KiSystemService or ntdll!KiFastCallEntry stores a trap frame (TRAP_FRAME) on the kernel thread stack to save the current thread context and enable the restoration of registers upon returning to user-mode.

To make the transition back to user-mode in a user-mode callback, KeUserModeCallback first copies the InputBuffer to the user-mode stack using the trap frame information held by the thread object. It then creates a new trap frame with EIP set to ntdll!KiUserCallbackDispatcher, replaces the thread object's TrapFrame pointer, and finally calls ntdll!KiServiceExit to return execution to the user-mode callback dispatcher.

Image 12 is a screenshot of the KiUserCallbackDispatcher function prototype.
Figure 12. KiUserCallbackDispatcher function prototype.

Once the user-mode callback has completed, NtCallbackReturn is called to resume execution in the kernel. This function copies the result of the callback back to the original kernel stack and restores the saved trap frame (PreviousTrapFrame) and kernel stack stored in the KERNEL_STACK_CONTROL structure. Before jumping to the location where it previously left off (in ntdll!KiCallUserMode), the kernel callback stack is deleted.

Image 13 is a screenshot of the NtCallbackReturn function prototype.
Figure 13. NtCallbackReturn function prototype.

The Window Manager uses the Executive Resource (ERESOURCE) synchronization primitive, as opposed to exclusive locks, when operating on Win32k management structures. The ERESOURCE primitive allows multiple threads to access a shared resource in the cases where each thread is only attempting to read the resource in question. The ERESOURCE primitive is also known as a single writer, multiple readers primitive. Once the ERESOURCE is initialized, threads can acquire an exclusive lock (for writes) using ExAcquireResourceExclusiveLite, or a shared lock (for reads) by calling ExAcquireResourceSharedLite. The thread then releases the resource by calling ExReleaseResourceLite. There is a requirement for normal kernel APCs to be disabled to use the acquire APIs discussed here, and this is done by calling KeEnterCriticalRegion, prior to the acquire call, and KeLeaveCriticalRegion after the release call.

If Win32k didn’t release the resource upon calling a user-mode callback, and that user-mode callback allowed an application to freeze the GUI subsystem, Win32k would not be able to perform other tasks while the GUI subsystem was frozen. Therefore, Win32k always releases the resource upon calling a user-mode callback. The code in Figure 14 below demonstrates how this occurs.

Image 14 is a screenshot of pseudo code. It shows how Windows enters and leaves a critical region before calling to KeUserModeCallback.
Figure 14. Pseudo code showing how Windows enters and leaves a critical region before calls to KeUserModeCallback.

This practice creates a dilemma. Because user-mode code is free to do things like modify the properties of objects and reallocate arrays, upon returning from a user-mode callback, Win32k must ensure that referenced objects are still in an untrusted state. Operating on such objects without performing the proper checks or object locking can and does create security vulnerabilities.

In fact, Tarjei Mandt’s 2011 paper, "Kernel Attacks Through User-Mode Callbacks," identified multiple instances of these types of vulnerabilities, and was the basis for research on Win32k exploitation for many years. Microsoft subsequently reviewed the Windows user-mode callback functions to ensure proper verification or locking of objects, making it significantly more difficult to exploit this class of bugs.

In 2019, Gil Dabah demonstrated that, although Microsoft had effectively eliminated Win32k bugs through operations on objects modified through direct calls to user-mode callbacks, it was still possible to create kernel-mode to user-mode states that indirectly modified objects (e.g. destroying a parent window while performing operations on a child window) in order to leverage similar bugs. The vulnerabilities identified were much more complex, making them harder to identify and likely much smaller in number.

User-mode callbacks were deemed important enough to track by Microsoft that they were given special prefixes. User-mode callback function names are preceded with either a xxx or zzz. Those preceded by an xxx leave the critical region and call the user-mode callback, just like we described above. Those that are preceded by a zzz invoke asynchronous or deferred callbacks. We’ll only be concerned with xxx type callbacks for this discussion.

Conclusion

In our first installment of this series, we’ve covered using the Win32 API to create GUI objects such as windows and menus. We covered the user-mode and kernel-mode data structures that are used to manage these objects and how they have changed over the years to help optimize and secure the transition between user-mode and kernel-mode.

In our next post, we’ll walk through a PoC for CVE-2022-21882 and explain what the code is doing. Finally, we’ll discuss the vulnerability, how it’s used to elevate privileges, and why the patch for CVE-2021-1732 wasn’t sufficient to prevent CVE-2022021882.

Both vulnerabilities discussed in this series are detected and blocked by the Cortex XDR Anti-LPE protection module. The XDR Anti-LPE modules monitor for techniques such as these that are data-only exploits, which copy the NT/Authority System privilege token to that of the current process for privilege escalation.

Additional Resources

Analyzing Web Application and API Attacks: The Cloud as a Target and a Launch Pad

Posted on by Aviv Sasson

Executive Summary

Unit 42 researchers have identified a growing trend of cyberattacks targeting web applications and application programming interfaces (APIs) hosted by cloud service providers. Based on the data from our research, 14.9% of attacks in late 2022 on web applications and APIs targeted cloud-hosted deployments.

Attackers are also operating in the cloud and using it to launch their attacks on applications and APIs, as 5.1% of the attacks originated from cloud service providers' addresses. We will discuss what web and API attacks are and why attackers are exploiting them in the cloud. We will also review possible reasons for attacks originating from the cloud, as well as the potential impact on businesses and individuals.

Palo Alto Networks customers using Prisma Cloud are protected from these threats through the WAAS module, which is designed to protect web applications and APIs in cloud environments.

Related Unit 42 Topics Cloud, API

Understanding Web Applications and APIs

APIs and web applications play a pivotal role in today's digital landscape. Web applications are software programs accessed through web browsers, providing interactive and engaging user experiences. Meanwhile, APIs act as intermediaries that facilitate communication between different software applications.

By enabling seamless interaction between applications, APIs simplify complex processes and promote a more connected digital ecosystem. Generally, both web applications and APIs are served on the HTTP protocol.

The widespread use of web applications and APIs has made them an integral part of the modern online world. Businesses, organizations and developers are increasingly adopting them to create user-friendly interfaces and automate processes, boosting efficiency and productivity.

The growing reliance on these technologies has also led to an increased focus on ensuring their security and reliability. As a result, it is essential to keep up with best practices and stay informed about potential vulnerabilities to protect valuable data and to maintain users' trust.

Web Applications and APIs on the Cloud

There has been a significant surge of organizations moving web applications and APIs to the cloud in recent years. Recognition among businesses and organizations of the numerous benefits offered by cloud solutions is driving this transformation.

Cloud applications are mainly based on microservices architecture, which is why the shift to the cloud is encouraging an evolution in software architecture. This difference is driving these organizations to embrace microservices architecture.

There are also many advantages of employing a microservices architecture, which is an approach to software development where an application is divided into small, independent services that communicate with each other through APIs.

A recent survey of nearly 400 organizations by TechTarget's Enterprise Strategy Group (ESG) Research Team, published in April 2023 and co-sponsored by Palo Alto Networks, revealed that organizations plan to double down on microservices architecture for their applications and move their production workloads into cloud providers.

Image 1 is a column graph of the percentage of public-facing web applications based on microservices for cloud native architecture. The percentage of the columns in blue is the percentage as of May 2023. The percentages in teal are what is predicted from 24 months from May 2023.
Figure 1. Public-facing web applications based on microservices. "Today” and "from now" date from the April 2023 survey. Source: "Securing the API Attack Surface," ESG and Palo Alto Networks.
Image 2 is five pie charts of the production workloads that are run on public cloud infrastructure. The percentages in blue are the percentage of production workloads run on public cloud infrastructure services today in 2023. The percentages in teal are the production workloads run on public cloud infrastructure services 24 months from May 2023. From left to right, the pie charts are: 10% to 20% of workloads, 21 to 30% of workloads, 31% to 40% of workloads, 41% to 50% of workloads, and lastly, more than 50% of workloads.
Figure 2. Production workloads run on public cloud infrastructure. “Today” and "from now" date from the April 2023 survey. Source: "Securing the API Attack Surface," ESG and Palo Alto Networks.

A wide variety of organizations are increasingly deploying their web applications and APIs in the cloud due to its compelling advantages. Cloud-based infrastructure offers scalability, flexibility and cost-effectiveness, allowing businesses to adapt to changing demands quickly and only pay for the resources they use. Moreover, the cloud enables faster development and deployment cycles, promoting innovation and agility.

Attacks on Web Applications and APIs in the Cloud

Unit 42 researchers conducted research on roughly 12 billion attacks targeting web applications and APIs to determine if attackers are targeting such instances on the cloud. Their findings revealed that attackers indeed place increased emphasis on targeting cloud-hosted web applications and APIs.

Through the analysis of this data, we discovered that 14.9% of attacks on web applications and APIs were directed at workloads hosted by the top three cloud vendors. This indicates that the cloud is not only a critical component for businesses but also an increasingly attractive target for cybercriminals.

Image 3 is a pie chart of the destination of attacks. 85.1% are from others, and 14.9% are from the cloud.
Figure 3. Destination of the attacks.

We believe attackers are increasingly targeting web applications and APIs in the cloud for several reasons.

  • Growing adoption of cloud services:
    • As more businesses and individuals migrate their workloads to the cloud for scalability, cost-effectiveness and convenience, the attack surface for cybercriminals expands, providing more opportunities.
  • Complex security landscape:
    • Cloud environments often have complex architectures and multitenant setups, leading to increased security risks. Attackers can take advantage of misconfigurations, unsecured data storage or vulnerable APIs to exploit systems.
  • Abundant resources:
    • Cloud environments offer abundant computing resources, making them attractive targets for resource-intensive attacks such as distributed denial-of-service (DDoS) attacks or cryptojacking.
  • Value and Impact:
    • Web applications and APIs often handle valuable data or provide critical services. Attackers target these systems in the cloud to gain unauthorized access to sensitive information, disrupt services or leverage compromised resources for further attacks.

Origination of Web Application and API Attacks

In the course of analyzing attacks on web applications and APIs, Unit 42 researchers placed special emphasis on determining the origins of these attacks. We discovered that 5.1% of the attacks were initiated from deployments hosted by the top three cloud service providers.

One plausible explanation for this high percentage is that attackers compromise legitimate cloud-hosted workloads and then use them as launch pads for further attacks. This tactic enables threat actors to spread their reach to other cloud environments, expanding the scope of their malicious activities.

Another potential reason is that some attackers may pose as legitimate users to gain access to cloud infrastructure. In order to do so, they could use free tiers offered by cloud vendors or use stolen credit card information to pay for cloud services. Once inside the cloud environment, these attackers can launch their attacks directly from within the cloud.

Image 4 is a pie chart showing the origin of the attacks. 94.9% are others, and 5.1% are from the cloud.
Figure 4. Origin of web application and API attacks.


Conclusion

In light of this research, organizations must be vigilant in securing their cloud environments, ensuring proper configurations, and monitoring for potential threats. By understanding the risks and implementing robust security measures, businesses can better protect their web applications and APIs from cloud-based attacks.

As more businesses shift their web applications and APIs to the cloud, attackers might perceive these environments as attractive targets, offering a wealth of valuable data and resources. This trend underscores the importance of implementing robust security measures to safeguard cloud-hosted web applications and APIs.

Palo Alto Networks customers using Prisma Cloud are protected from these threats through the WAAS module, which is designed to protect web applications and APIs in cloud environments.

Cold as Ice: Answers to Unit 42 Wireshark Quiz for IcedID

Posted on by Brad Duncan

Executive Summary

Our introductory blog Cold as Ice: Unit 42 Wireshark Quiz for IcedID provides a packet capture (pcap) from an IcedID infection in April 2023. This blog provides the answers. Also known as Bokbot, IcedID is well-established Windows-based malware that can lead to ransomware. Reviewing the pcap provides an opportunity to analyze IcedID infection traffic.

If you would like to view this quiz without answers, please see our previous blog introducing the standalone quiz.

Palo Alto Networks customers are protected from IcedID and other malware through Cortex XDR and our Next-Generation Firewall with Cloud-Delivered Security Services that include WildFire, Advanced Threat Prevention and Advanced URL Filtering.

Related Unit 42 Topics pcap, Wireshark, Wireshark Tutorial, IcedID, BokBot

Scenario, Requirements and Quiz Material

Traffic for this quiz occurred in an Active Directory (AD) environment during April 2023. The infection is similar to previous IcedID activity tweeted by Unit 42 in March 2023. Details of the Local Area Network (LAN) environment for the pcap follow.

  • LAN segment range: 10.4.19[.]0/24 (10.4.19[.]1 through 10.4.19[.]255)
  • Domain: boogienights[.]live
  • Domain controller IP address: 10.4.19[.]19
  • Domain controller hostname: WIN-GP4JHCK2JMV
  • LAN segment gateway: 10.4.19[.]1
  • LAN segment broadcast address: 10.4.19[.]255

This quiz requires Wireshark, and we recommend using the latest version of Wireshark, since it has more features, capabilities and bug fixes over previous versions.

We also recommend readers customize their Wireshark display to better analyze web traffic. A list of tutorials and videos is available. As always, we recommend using Wireshark in a non-Windows environment like BSD, Linux or macOS when analyzing malicious Windows-based traffic.

To obtain the pcap, visit our GitHub repository, download the April 2023 ZIP archive and extract the pcap. Use infected as the password to unlock the ZIP archive.

Quiz Questions

For this IcedID infection, we ask participants to answer the following questions previously described in our standalone quiz post:

  • What is the date and time in UTC the infection started?
  • What is the IP address of the infected Windows client?
  • What is the MAC address of the infected Windows client?
  • What is the hostname of the infected Windows client?
  • What is the user account name from the infected Windows host?
  • Is there any follow-up activity from other malware?

Quiz Answers

The AD environment for this pcap contains three Windows clients, but only one was infected with IcedID.

Answers for this Wireshark quiz follow.

  • Malicious traffic for this infection started on April 19, 2023, at 15:31 UTC.
  • Infected Windows client IP address: 10.4.19[.]136
  • Infected Windows client MAC address: 14:58:d0:2e:c5:ae
  • Infected Windows client hostname: DESKTOP-SFF9LJF
  • Infected Windows client user account name: csilva
  • Follow-up activity: BackConnect traffic

Pcap Analysis: IcedID Chain of Events

To understand IcedID network traffic, you should understand the chain of events for an IcedID infection. A flow chart illustrating this chain of events is shown in Figure 1.

Image 1 is a flowchart of the chain of events in the April 2023 IcedID infection. It starts with email and or web-based delivery methods, continues to the IcedID installer, HTTP traffic for the gzip binary, malware created from that binary, and then command and control traffic from the IcedID infection. The initial follow-up activity can include Cobalt sStrike, VNC traffic, and BackConnect.
Figure 1. Flowchart for chain of events in the April 2023 IcedID infection.

Most IcedID infections use a standard variant of IcedID. These infections typically use an EXE or DLL that acts as an installer. This installer generates an unencrypted HTTP GET request that retrieves a gzip-compressed binary. The installer then converts this binary into malware used for a persistent IcedID infection.

The newly created, persistent IcedID generates HTTPS traffic to communicate with command and control (C2) servers. The C2 activity can lead to BackConnect traffic, Cobalt Strike and Virtual Network Computing (VNC) activity.

If the infected host is part of a high-value environment, an IcedID infection would likely lead to ransomware.

Pcap Analysis: Infection Vector

Using Wireshark customized from our tutorials, apply a basic web filter to see if anything stands out. Review the results in your column display. Look for unencrypted HTTP traffic over TCP port 80 directly to an IP address without an associated domain. This is a common characteristic in the chain of events for various malware infections.

At 15:31:08 UTC, the host at 10.4.19[.]136 generated an HTTP GET request to hxxp://80.77.25[.]175/main.php as shown below in Figure 2.

Image 2 is a screenshot of suspicious HTTP traffic in Wireshark that goes directly to an IP address, which is highlighted with an arrow.
Figure 2. Suspicious HTTP traffic directly to an IP address shown in Wireshark.

Follow the TCP stream for this HTTP GET request, as shown in Figure 3. This should generate a window for TCP stream 32, as shown in Figure 4.

Image 3 shows the menu selection to follow the TCP stream for the suspicious HTTP GET request.
Figure 3. Following TCP stream for suspicious HTTP GET request.
Image 4 is the TCP stream window in Wireshark. Indicated with two arrows is the first line of the HTTP GET request and highlighted by the black box is the location.
Figure 4. TCP stream for the suspicious HTTP GET request and response.

Figure 4 reveals HTTP request headers that contain a User-Agent string ending with Edg/112.0.1722.48. This string indicates the traffic was likely generated by the Microsoft Edge browser. However, web traffic generated by malware can spoof different User-Agent strings, and some browser extensions also have this ability, so we cannot be certain this was actually Microsoft Edge.

The HTTP response headers in Figure 4 show a 302 code, redirecting traffic to the following URL:

hxxps://firebasestorage.googleapis[.]com/v0/b/serene-cathode-377701.appspot.com/o/XSjwp6O0pq%2FScan_Inv.zip?alt=media&token=a716bdce-1373-44ed-ae89-fdabafa31c61

This Firebase Storage URL has been reported as malicious by at least seven security vendors on VirusTotal, and it appears in URLhaus tagged as IcedID. Fortunately, Google has taken the URL offline, and it is no longer active.

To further refine our search, add the client’s IP address 10.4.19[.]136 to the basic web filter as shown below in Figure 5. This reveals HTTPS traffic to firebasestorage.googleapis[.]com shortly after traffic to the initial URL at hxxp://80.77.25[.]175/main.php.

Image 5 is a screenshot of the HTTPS traffic to firebasestorage.googleapis[.]com after the initial suspicious URL. Highlighted in green in the screenshot is the command to insert into Wireshark. Two arrows indicate the request and the suspicious URLs.
Figure 5. HTTPS traffic to firebasestorage.googleapis[.]com after the initial suspicious URL.
Follow the TCP stream for the initial frame showing fire in the Wireshark column display. The TCP stream reveals 273 KB of data sent from the server to the Windows host, as shown below in Figure 6. This indicates a file might have been sent to the Windows host.

Image 6 is the TCP stream window showing the 275 kB of data sent from firebasestorage.googleapis[.]com to the Windows host. This is highlighted by an arrow in a menu that shows the entire conversation.
Figure 6. TCP stream showing 275 KB of data sent from firebasestorage.googleapis[.]com to the Windows host.
While the Firebase Storage URL is tagged as IcedID on URLhaus, this only indicates a distribution method for the IcedID installer. Based on this pcap, the victim opened a link that led to the Firebase Storage URL, and that URL delivered a file for an IcedID installer.

The URLhaus entry for this Firebase Storage URL reveals the ZIP archive it previously hosted, as shown in Figure 7.

Image 7 is a screenshot of the URLhaus entry for the firebasestorage URL. The screenshot shows the payload delivery, when it was first seen, the file name and file type, and the signature, which is IcedID.
Figure 7. URLhaus entry for our firebasestorage URL shows it delivered a zip archive.

The ZIP archive was submitted to Malware Bazaar. The archive is password-protected with the ASCII string 1235, and it contains a file named Scan_Inv.exe. This Windows executable file is an IcedID installer.

Pcap Analysis: IcedID Traffic

An IcedID loader first generates an unencrypted HTTP GET request over TCP port 80 to a domain using GET / without any further URL. This returns a gzip binary used by the installer to create the persistent malware on the victim’s host.

To find the gzip binary, use the same basic web filter with the victim’s IP address noted earlier in Figure 5. Scroll down to an HTTP GET request to skigimeetroc[.]com at 15:35:39 UTC and follow the TCP stream as shown below, in Figure 8.

Image 8 is a screenshot of the menu selection to follow the TCP stream for IcedID installers initial HTTP GET request. Highlighted in green is the filter to enter into Wireshark.
Figure 8. Following the TCP stream for IcedID installer’s initial HTTP GET request.

This is TCP stream 53 from the pcap, as shown below in Figure 9. The HTTP request headers for traffic generated by the IcedID installer have no User-Agent string. Note the cookie sent in the request headers in Figure 9.

Image 9 is the TCP stream window in Wireshark. Highlighted with a black box is the cookie data. Highlighted with an arrow is the gzip binary.
Figure 9. HTTP GET request generated by the IcedID installer.

The cookie line follows:

Cookie: __gads=422998217:1:1808:131; _gid=A0CA96894E9D; _u=4445534B544F502D534646394C4A46:6373696C7661:46353431423635424230383346354633; __io=21_1181811818_1193560798_2439418475; _ga=1.591597.1635208534.1022; _gat=10.0.22621.64

Cookie parameters for the HTTP GET request caused by this IcedID installer follow:

  • __gads= IcedID campaign identifier and information from the infected host.
  • _gid= Value calculated using MAC address of the infected host.
  • _u= ASCII text representing hex values of the victim’s hostname, Windows user account name and another undetermined value.
  • __io= Domain identifier from the infected host’s security identifier (SID).
  • _ga= Information based on the infected host’s CPU.
  • _gat= Windows version. For example, 10.0.22621.64 is an identifier for 64-bit Windows 11 version 22H2 and 10.0.19045.64 is an identifier for 64-bit Windows 10 version 22H2.

These cookie parameters are unique to IcedID infections. You can identify this traffic as IcedID without understanding the values. However, the _u= parameter reveals the victim’s hostname and Windows user account name. This information is very useful for our investigation. These hex values translate to a hostname of DESKTOP-SFF9LJF and a Windows user account name of csilva, as shown below in Figure 10.

Image 10 shows two hex value translations. The hex value highlighted in yellow translates to DESKTOP-SFF9LJF. The hex value highlighted in blue translates to csilva.
Figure 10. Using the _u= cookie parameter to determine the victim’s hostname and Windows user account name.

After retrieving the gzip binary, an IcedID installer creates persistent IcedID malware that takes over the infection. The infected Windows host then starts generating HTTPS traffic to IcedID C2 servers.

These C2 servers use different domain names and IP addresses than the initial domain contacted by the IcedID installer. IcedID’s HTTPS C2 traffic starts within a minute or two after the installer retrieves the gzip binary, and this activity uses at least two domains with random alphabetic names.

Our pcap reveals HTTPS traffic from the infected host to two domains after skigimeetroc[.]com at 15:35:39 UTC. These HTTPS C2 servers are askamoshopsi[.]com on 104.168.53[.]18 and skansnekssky[.]com on 217.199.121[.]56.

To find these servers, use the same basic web filter with the victim’s IP address noted earlier in Figure 5. HTTPS traffic starting at 15:36:41 UTC reveals these domains, as shown below in Figure 11.

Image 11 is a screenshot of the Wireshark traffic for the command and control IcedID servers. Highlighted with a black box is the IcedID installer that retrieve the gzip binary.
Figure 11. HTTPS C2 traffic after HTTP request by the IcedID installer.

Both C2 servers at askamoshopsi[.]com and skansnekssky[.]com use self-signed certificates for their HTTPS traffic. Self-signed certificates for HTTPS traffic will generate warnings about potential security risks when the site is viewed in any modern web browser.

Why do web browsers display warnings about websites that use self signed certificates? Because these are not validated by a Certificate Authority. Criminals can generate self-signed certificates that impersonate an existing company, or they can use generic values for the certificate issuer. Without a validated certificate, web browsers cannot be sure a website is what it says it is.

Figure 12 shows what the server at askamoshopsi[.]com looked like when we attempted to view it with the Firefox web browser. This warning allows users to view the server’s self-signed certificate.

Image 12 is two screenshots of Mozilla Firefox windows, showing a warning for the potential security risk of the invalid certificate. It also shows the certificate for the localhost.
Figure 12. Attempting to view the web server at askamoshopsi[.]com using Firefox.
As shown above in Figure 12, the certificate uses values like Internet Widgits Pty Ltd for the issuer’s Organization name and Some-State for the State/Province name. Values for self-signed certificates used by IcedID C2 servers are the same default values seen when using OpenSSL to create a certificate in Xubuntu as shown below in Figures 13 and 14.

Image 13 is the Xubuntu terminal x509 certificate creation for a web server using OpenSSL.
Figure 13. Creating an x509 certificate for a web server using OpenSSL in Xubuntu.
Image 14 is the Xubuntu terminal default values for the x509 certificate creation. Highlighted with arrows are the country name two letter code, which is Australia, the state, or province, name, and the organization name, which is Internet Widgets Pty Ltd.
Figure 14. Default values when creating an x509 certificate for a web server using OpenSSL in Xubuntu.

Since Internet Widgits Pty Ltd is a default value for a self-signed certificate in HTTPS traffic, and this value is sometimes seen in C2 traffic for malware. This should be more closely examined if it’s found when investigating a suspected malware infection. We can easily check any pcap for this value using the following Wireshark filter:

x509sat.uTF8String eq "Internet Widgits Pty Ltd"

The results from our pcap reveal the same IP addresses used by IcedID C2 servers for askamoshopsi[.]com at 104.168.53[.]18 and skansnekssky[.]com at 217.199.121[.]56. Expand the frame details for any of the results to find the same certificate issuer data, as shown in Figure 15.

Image 15 is a Wireshark screenshot. Highlighted in green is the command to put into the search bar. The results, highlighted by arrows, are the transport layer security, the certificate, including size, and the issuer of the certificate. Highlighted in a black box are the IDs that showed in the Xubuntu terminal.
Figure 15. Self-signed certificate by IcedID C2 servers using Internet Widgits Pty Ltd as the Organization name shown in Wireshark.

This certificate data is not unique to IcedID. The same values for self-signed certificates are also seen in HTTPS C2 traffic by other malware families like Bumblebee.

Pcap Analysis: BackConnect Traffic

Undetected IcedID infections lead to follow-up activity like BackConnect traffic.

For the past several months, BackConnect traffic caused by IcedID was easy to detect because it occurred over TCP port 8080. However, as early as April 11, 2023, BackConnect activity for IcedID changed to TCP port 443, making it harder to find.

This BackConnect activity from IcedID Unit 42 tweeted on April 11, 2023 used an IP address of 193.149.176[.]100 over TCP port 443. Filter for that IP address in Wireshark and combine it with tcp.flags eq 0x0002 as shown below, in Figure 16. This reveals the beginning of three streams.

Image 16 is a Wireshark command, highlighted in green, showing how to filter in Wireshark for the BackConnect traffic in the packet capture.
Figure 16. Filtering in Wireshark for BackConnect traffic in our pcap.

Follow the TCP stream for the first result, which is TCP stream 950. This stream reveals encoded or otherwise encrypted TCP traffic, as shown in Figure 17.

Image 17 is a TCP stream terminal window in Wireshark showing the BackConnect activity.
Figure 17. The first TCP stream for BackConnect activity.

Go back to the Wireshark filter used to reveal the TCP streams to 193.149.176[.]100. Follow the TCP stream for the second frame in the results, which is TCP stream 951. This reveals encoded or encrypted data followed by a command to reveal all hosts under the domain controller for boogienights[.]live as shown below, in Figure 18.

Image 18 is a TCP stream terminal window in Wireshark showing the BackConnect traffic with a command to and the results enumerating the Active Directory environment.
Figure 18. BackConnect traffic with a command to and results enumerating the victim’s AD environment.

The response to this command enumerates the victim’s AD environment, showing three clients logged in to the domain:

  • DESKTOP-JAL4D68
  • DESKTOP-RETP4BU
  • DESKTOP-SFF9LJF

Go back to the Wireshark filter used to reveal the TCP streams to 193.149.176[.]100. Follow the TCP stream for the last frame in the results, which is TCP stream 953. This lists disk drives on the victim client, and it provides a directory listing for each of these drives, as shown below in Figure 19.

The C:\ drive is the victim’s system drive. Z:\ is likely a mapped drive from a server’s shared directory that does not contain any files.

"Image 19 is a TCP stream terminal window in Wireshark showing the BackConnect traffic. A highlighted black box shows where the attacker sends a DISK command. The victim returns the disk drive list. The attacker then changes the directory to the Z:\ drive and lists its contents. This drive is empty. The second black box highlights where the attacker changes the directories to the C:\ drive and lists its contents. This is the victim’s system drive. It contains files and directories normally seen on a Windows host. This screenshot also shows the entire conversation size which is 796 bytes."
Figure 19. BackConnect traffic showing contents of the victim’s system drive and mapped drive.

Previous IcedID infections reveal this threat can use BackConnect traffic to load and run Cobalt Strike. We tweeted about one such case from March 24, 2023. However, this pcap does not contain any indicators of Cobalt Strike.

Previous IcedID infections also reveal this threat can generate VNC traffic over the same IP address used by BackConnect traffic. This happened during the same IcedID infection from March 24, 2023.

Pcap Analysis: Victim Details

The common internal IP address for the malicious traffic we have reviewed is 10.4.19[.]136. This is our victim’s IP address. To find the Windows user account name, filter on that IP address and kerberos.CNameString as shown in Figure 20.

Image 20 is a Wireshark screenshot highlighting the CNameString column, and the outcome of selecting “apply as column” from the menu. Highlighted in green is the command to filter to do this. Highlighted by arrows are the Windows account user name for the infected Windows host.
Figure 20. Finding the Windows user account name for our infected Windows host.

In some cases, lightweight directory access protocol (LDAP) might also provide the full name of the user. Use the following Wireshark filter:

ldap.AttributeDescription == "givenName"

This should provide four frames in our column display. Select any of them and expand the frame details until you find the user’s full name, Cornelius Silva, as shown below in Figure 21.

Image 21 is a Wireshark screenshot showing how to filter to find the victim’s full name from LDAP traffic. Highlighted by arrows are the names.
Figure 21. Finding the victim’s full name from LDAP traffic.

Perhaps the easiest way to find a victim’s hostname in Wireshark is to combine the victim’s IP address with a search for ip contains "DESKTOP-" as shown below, in Figure 22. Several results in the info column show Host Announcement DESKTOP-SFF9LJF sent by our infected Windows host at 10.4.19[.]136.

Image 22 is a Wireshark screenshot showing how to filter to find the Windows hostname in Wireshark. Highlighted in green is the filter to use.
Figure 22. Finding the Windows hostname in Wireshark.

To find the victim’s MAC address, just correlate the IP address to the host’s MAC address in any of the frame details windows, as shown below in Figure 23.

Image 23 is a screenshot where, highlighted, shows the victim’s MAC address with its associated IP address.
Figure 23. Correlating the victim’s MAC address with its associate IP address.

Conclusion

This blog provides answers and analysis for our Unit 42 Wireshark quiz featuring an IcedID infection from April 2023. IcedID is important to identify and stop, because it is a known vector for ransomware infections.

Many organizations lack access to full packet capture in their IT environment. As a result, security professionals might lack experience reviewing IcedID and other malware traffic. Training material like this Wireshark quiz can help. Pcap analysis is a useful skill that helps us better understand malicious activity.

You can also read the original post, without answers, from our standalone quiz post.

Palo Alto Networks customers are protected from IcedID and other malware through Cortex XDR and our Next-Generation Firewall with Cloud-Delivered Security Services that include WildFire, Advanced Threat Prevention and Advanced URL Filtering.

If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

Traffic from the pcap related to the IcedID infection:

  • hxxp://80.77.24[.]175/main.php
  • hxxps://firebasestorage.googleapis[.]com/v0/b/serene-cathode-377701.appspot.com/o/XSjwp6O0pq%2FScan_Inv.zip?alt=media&token=a716bdce-1373-44ed-ae89-fdabafa31c61
  • 192.153.57[.]223:80 - hxxp://skigimeetroc[.]com/
  • 104.168.53[.]18:443 - askamoshopsi[.]com - HTTPS traffic
  • 217.199.121[.]56:443 - skansnekssky[.]com - HTTPS traffic
  • 193.149.176[.]100:443 - BackConnect traffic

Files associated with traffic from this IcedID infection:

  • SHA256 hash: fc96c893a462660e2342febab2ad125ce1ec9a90fdf7473040b3aeb814ba7901
  • File size: 262,343 bytes
  • Filename: Scan_Inv.zip
  • File description: Password-protected ZIP archive hosted on Firebase Storage URL
  • Password: 1235
  • MalwareBazaar Database sample
  • SHA256 hash: bd24b6344dcde0c84726e620818cb5795c472d9def04b259bf9bff1538e5a759
  • File size: 333,408 bytes
  • Filename: Scan_Inv.exe
  • File description: Windows executable file for IcedID installer
  • MalwareBazaar Database sample

Additional Resources

Cold as Ice: Unit 42 Wireshark Quiz for IcedID

Posted on by Brad Duncan

Executive Summary

So far in 2023, IcedID has been a relatively constant presence in our threat landscape. Also known as BokBot, IcedID is Windows-based malware that can lead to ransomware. This Wireshark quiz presents a packet capture (pcap) from an IcedID infection that occurred in April 2023, and it provides experience analyzing traffic generated by this malware.

Anyone can participate in this quiz. However, participants should have some familiarity with Wireshark. Participants should also have a basic knowledge of IPv4 traffic. Palo Alto Networks has published a series of Wireshark tutorials to help people gain knowledge helpful for these quizzes.

Palo Alto Networks customers are protected from IcedID and other malware through Cortex XDR and our Next-Generation Firewall with Cloud-Delivered Security Services that include WildFire and Advanced Threat Prevention.

Related Unit 42 Topics pcap, Wireshark, Wireshark Tutorial, IcedID, BokBot

Scenario

Traffic for the IcedID infection occurred in an Active Directory (AD) environment during April 2023. This infection is similar to previous IcedID activity from March 24, 2023, which was tweeted by Unit 42.

Details of the network and questions for the quiz follow.

Local Area Network (LAN) Details

  • LAN segment range: 10.4.19[.]0/24 (10.4.19[.]1 through 10.4.19[.]255)
  • Domain: boogienights[.]live
  • Domain controller IP address: 10.4.19[.]19
  • Domain controller hostname: WIN-GP4JHCK2JMV
  • LAN segment gateway: 10.4.19[.]1
  • LAN segment broadcast address: 10.4.19[.]255

Quiz Questions

  • What is the date and time in UTC the infection started?
  • What is the IP address of the infected Windows client?
  • What is the MAC address of the infected Windows client?
  • What is the hostname of the infected Windows client?
  • What is the user account name from the infected Windows host?
  • Is there any follow-up activity from other malware?

Requirements

Since this is a Wireshark quiz, participants should use Wireshark to review the pcap. We encourage participants to customize Wireshark when reviewing malware traffic. Participants can customize Wireshark as demonstrated in the Unit 42 series of tutorials and videos.

We recommend using the latest version of Wireshark, since it has more features, capabilities and bug fixes over previous versions. Older Wireshark versions like 1.x and 2.x are not recommended for our Wireshark quizzes.

Infection traffic often contains malicious code targeting Microsoft Windows, so we recommend using a non-Windows environment to review the pcap for this quiz. Operating systems like BSD, Linux or macOS provide an ideal environment for Wireshark when reviewing traffic from Windows-based malware like IcedID.

Accessing the Pcap

To obtain the pcap, visit our GitHub repository as shown in Figure 1 and download the ZIP archive named 2023-04-Unit42-Wireshark-quiz.pcap.zip as shown in Figure 2. Use infected as the password to unlock the ZIP archive as shown in Figure 3.

Image 1 is a screenshot of Wireshark software showing where to click to download the ZIP archive from GitHub.
Figure 1. Selecting the pcap for this quiz from our GitHub repository.
Image 2 shows how to download the .zip archive.
Figure 2. Downloading the pcap.
Image 3 shows how to enter the password and how to extract the password-protected .zip archive from the download folder.
Figure 3. Extracting the pcap from the downloaded ZIP archive.

Conclusion

IcedID is a prominent part of our current threat landscape. This Wireshark quiz can help participants better understand network traffic associated with an IcedID infection.

The answers to the Unit 42 Wireshark quiz for IcedID are published in a separate blog post.

Palo Alto Networks customers are protected from IcedID and other malware through Cortex XDR and our Next-Generation Firewall with Cloud-Delivered Security Services that include WildFire and Advanced Threat Prevention.

If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Additional Resources

Updated May 30, 2023, at 6:40 a.m. PT.

Old Wine in the New Bottle: Mirai Variant Targets Multiple IoT Devices

Posted on by Zhibin Zhang

Executive Summary

On April 10, Unit 42 researchers observed a Mirai variant called IZ1H9, which used several vulnerabilities to spread itself. The threat actors use the following vulnerabilities to target exposed servers and networking devices running Linux:

Compromised devices can be fully controlled by attackers and become a part of the botnet. Those devices can be used to conduct further attacks, such as distributed denial-of-service (DDoS) attacks.

Palo Alto Networks Next Generation Firewall customers receive protections through Cloud-Delivered Security Services such as IoT Security, Advanced Threat Prevention, WildFire and Advanced URL Filtering, which can help detect and block the exploit traffic and malware.

Related Unit 42 Topics Mirai variant, IoT

Campaign Overview

Since November 2021, Unit 42 researchers have observed multiple campaigns using the Mirai IZ1H9 variant. Based on our analysis, we believe that these campaigns were operated by the same threat actor for the following reasons:

  • The malware shell script downloaders used in both campaigns are almost identical.
  • The botnet samples use the same XOR decryption key: 0xBAADF00D
  • The botnet client samples use almost identical functions.
  • Botnet client samples among those campaigns share the same infrastructure.

On April 10, 2023, Unit 42 researchers observed some abnormal traffic from our threat hunting system. This threat group tried to download and execute a shell script downloader lb.sh from IP 163.123.143[.]126.

If executed, the shell script downloader would first delete logs to hide its tracks. Then the following bot clients would be downloaded and executed, to accommodate different Linux architectures:

  • hxxp://163.123.143[.]126/bins/dark.x86
  • hxxp://163.123.143[.]126/bins/dark.mips
  • hxxp://163.123.143[.]126/bins/dark.mpsl
  • hxxp://163.123.143[.]126/bins/dark.arm4
  • hxxp://163.123.143[.]126/bins/dark.arm5
  • hxxp://163.123.143[.]126/bins/dark.arm6
  • hxxp://163.123.143[.]126/bins/dark.arm7
  • hxxp://163.123.143[.]126/bins/dark.ppc
  • hxxp://163.123.143[.]126/bins/dark.m68k
  • hxxp://163.123.143[.]126/bins/dark.sh4
  • hxxp://163.123.143[.]126/bins/dark.86_64

In the last step, the shell script downloader would block network connection from several ports including SSH, telnet and HTTP. It did so by modifying the device’s iptable rules, so that the victim wouldn’t be able to connect and recover the compromised device remotely, as depicted in Figure 1.

Figure one is a screenshot of the modified iptable rules.
Figure 1. Iptable modification.

Threat Group Analysis

Unit 42 researchers conducted analysis on the downloaded botnet client samples and found two URLs hosting more shell script downloaders:

  • hxxp://2.56.59[.]215/i.sh
  • hxxp://212.192.241[.]72/lolol.sh

Figure 2 is a diagram illustrating the campaign overview.

Figure 2 is a campaign overview diagram. It starts with the first IP address from April 10, 2023, and leads through the hosts, Mirai samples, the hosts, a shell script, and continues through the different downloaders.
Figure 2. Campaign overview diagram.

The shell script downloader from 2.56.59[.]215 would download botnet clients from hxxp://2.56.59[.]215/bins/. Those botnet client samples would contact a command and control (C2) server at 195.133.40[.]141 where there were URLs in the malware samples that hosted two shell scripts:

  • hxxp://31.210.20[.]100/lolol[.]sh
  • hxxp://212.192.241[.]72/lolol[.]sh

The shell script downloader from 212.192.241[.]72 would download botnet clients from hxxp://212.192.241[.]87/bins/, and those botnet client samples would contact the C2 domain dotheneedfull[.]club.

Malware Analysis

Based on behavior and patterns Unit 42 researchers observed during the analysis of the downloaded samples, we believe that they are a variant of the Mirai botnet called IZ1H9.

Discovered in August 2018, IZ1H9 is one of the most active Mirai variants. Just like the original Mirai, the IZ1H9 botnet client first checks the network portion of the infected device’s IP address. The client avoids execution for a list of IP blocks, including government networks, internet providers and large tech companies.

The botnet client makes its presence visible by printing the word “Darknet” to the console. The malware also contains a function that ensures the device is running only one instance of this malware. If a botnet process already exists, the botnet client will terminate the current process and start a new one, as depicted in Figure 3.

Figure 3 is a screenshot demonstrating how the botnet client terminates a current process, and then starts a new one. Included in the code is “instance already exists, overriding current process.”
Figure 3. IZ1H9 ensures there is only a single instance of execution.

The botnet client also contains a list of process names belonging to other Mirai variants and other botnet malware families. The malware checks the running process names on the infected host to terminate them.

The IZ1H9 variant tries to connect to a hard-coded C2 address: 193.47.61[.]75, as shown in Figure 4.

Figure 4 is a screenshot of the malware variant trying to connect to the hardcoded command and control (C2) IP address.
Figure 4. IZ1H9 malware C2 address.

Botnet Client Configuration String Decryption

For botnet client configuration strings, the IZ1H9 variant will first initialize an encrypted string table. It will then retrieve the encrypted strings through an index (as shown in Figures 5 and 6).

Figure 5 is a screenshot of the encrypted string table. Highlighted in red is table_init().
Figure 5. Initializing the encrypted string table.
Figure 6 is a screenshot of the malware variant retrieving strings. Highlighted within a red box is the code val = table retrieve val (84, 0). This is Mirai retrieving strings by index.
Figure 6. IZ1H9 retrieving strings.

The IZ1H9 variant uses a table key during the string decryption process: 0xBAADF00D. For each encrypted character, the malware performs XOR decryption with the following bytewise operations:

cipher_char ^ 0xBA ^ 0xAD ^ 0xF0 ^ 0x0D = plain_char

According to the logic behind XOR operation, the configuration string key equals to

0xBA ^ 0xAD ^ 0xF0 ^ 0x0D = 0xEA

IZ1H9 Sample Spreading Through HTTP, SSH and Telnet Protocol

For SSH and telnet channels, IZ1H9 inherits the most significant feature from the original Mirai source code: a data section with embedded default login credentials for scanner and brute-force purposes.

The original Mirai and IZ1H9 also both encrypt their login credentials with a 1 byte XOR key. The keys vary in different versions, but this variant uses 0x54, as shown in Figure 7.

Figure 6. IZ1H9 retrieving strings.
Figure 7. IZ1H9 variant credentials XOR decryption.

This IZ1H9 variant initializes the table of nearly 100 pairs of telnet/SSH login credentials in the scanner function. It then spreads through brute forcing network devices’ weak username and password combinations.

For the HTTP channel, IZ1H9 uses four remote code execution vulnerabilities to get access to the vulnerable devices, and it executes the shellcode script downloader shown in Figure 8.

Figure 8 is a screenshot of the exploit scanner function. It shows the Zyxlel RCE, Blink, RCE, Netlog RCE, and the Tense RCE.
Figure 8. Exploit scanner function.

Notice that in the Tenda vulnerability exploit function, the payload downloads tenda.sh from the malware host server but executes netlog.sh, as shown in Figure 9. In this case, the exploit will not work.

Figure 9 is a screenshot of the source code for Mirai. Highlighted in red boxes is tenda.sh, which downloads, and netlog.sh, which executes.
Figure 9: Malware executes wrong downloader.

The malware will initialize all DDoS attack functions before the botnet client establishes a connection with the C2 server. According to the Mirai source code, the malware developer will define the attack method and assign a command code to represent the attack method, as depicted in Figure 10.

Figure 10 is a screenshot of the Mirai source code, with the definitions for all of the attack methods.
Figure 10. Mirai attack method definition.

In this IZ1H9 sample, the threat actor defines a set of attack methods, shown in Table 1.

Command  Attack Method Description
0 attack_method_tcpsyn TCP SYN flooding attack
1 attack_method_tcpack TCP ACK flooding attack
2 attack_method_tcpusyn TCP URG-SYN flooding attack
3 attack_method_tcpall TCP DDoS with all options set
4 attack_method_tcpfrag TCP fragmentation attack
5 attack_method_asyn TCP SYN-ACK flooding attack
6 attack_method_udpgame UDP attack targets online gaming servers
7 attack_method_udpplain UDP flooding with fewer options
8 attack_method_greip GRE IP flooding attack
9 attack_method_std STD flooding attack
10 attack_method_udpdns DNS flooding attack
11 attack_method_udpgeneric UDP flooding attack
12 attack_app_http HTTP flooding attack
13 attack_method_dnsamp DNS amplification attack

Table 1. IZ1H9 attack method.

Conclusion

IoT devices have always been a lucrative target for threat actors, and remote code execution attacks continue to be the most common and most concerning threats affecting IoT devices and linux servers. Exposed vulnerable devices could lead to serious threats.

The vulnerabilities used by this threat are less complex, but this does not decrease their impact, since they could still lead to remote code execution. Once the attacker gains control of a vulnerable device, they can include the newly compromised devices in their botnet. This allows them to conduct further attacks such as DDoS.

To combat this threat, it is highly recommended that patches and updates are applied when possible.

Palo Alto Networks customers receive protection from the vulnerabilities and malware discussed above through the following products and services:

  • Next Generation Firewall with a Threat Prevention security subscription can help block the attacks with Best Practices via Threat Prevention signatures: 93386, 93718, 93721, 93722.
  • Advanced Threat Prevention provides inline machine learning that can detect vulnerability exploits in real time.
  • WildFire can help stop the malware with static signature detections.
  • Advanced URL Filtering and DNS Security are able to block the C2 domain and malware-hosting URLs.
  • The Palo Alto Networks IoT Security platform can leverage network traffic information to identify the vendor, model and firmware version of a device, and it can identify specific devices that are vulnerable to particular CVEs.
  • In addition, IoT Security has inbuilt machine learning-based anomaly detection that can alert the customer if a device exhibits nontypical behavior such as the sudden appearance of traffic from a new source, an unusually high number of connections, or an inexplicable surge of certain attributes typically appearing in IoT application payloads.

Indicators of Compromise

Artifacts

Shell Script Downloader

  • 692a5d099e37cd94923ea2b2014d79e6e613fb061a985069736dd3d55d4330c4
  • e0b1c324298eeccd54ffc2ff48288ec51fbec44f5f82229537508785a9bda6de
  • 931800d4f84bda7c0368c915dfd27721d63ed0ce6a9bc9f13e1417d4c2fe88f3
  • 64a350a33757f6631dc375632de191967ae59c876b4718a087e299bd54f23844

Mirai Variant Sample

  • 23190d722ba3fe97d859bd9b086ff33a14ae9aecfc8a2c3427623f93de3d3b14
  • 00b151ff78a492b5eae0c8d3c769857f171f8424cf36c3b2505f7d7889109599
  • 212b1af9fd1142d86b61956ac1198623f9017153153cfc20bfeab6a9fd44004a
  • 38406b2effd9fc37ce41ee914fda798de9c9b0e239a0cc94b1464dc2a9984fe9
  • 21185d9b7344edcd8d9c4af174e468c38cb3b061e6bd6bd64a4be9bd3fa27ff5
  • 65a46cd29dad935d067a4289445d2efb2710d44d789bf1bf0efb29f94d20e531
  • 06ef6c76e481d25aa09b3b15959d702be29c22d63bd35524766397e3d36d0d2e
  • 7bfb02c563ae266e81ba94a745ea7017f12010d5491708d748296332f26f04f5
  • 1e29f364f502b313f01f28f1ae85bf27114fae5eede6550809fe5bca58f59174

Infrastructure

Malware C2

  • 193.47.61[.]75
  • 195.133.40[.]141
  • dotheneedfull[.]club

Malware Host

  • 163.123.143[.]126
  • 2.56.59[.]215
  • 212.192.241[.]72
  • 212.192.241[.]87
  • 31.210.20[.]100

Additional Resources

Appendix

Campaign-related vulnerability information is listed below:

CVE-2023-27076: Tenda G103 Command Injection Vulnerability

This malicious traffic was first detected as a part of the IZ1H9 campaign on April 10, 2023. The command injection vulnerability is due to the failure to sanitize the value of the language parameter in the cgi-bin/luci interface of Tenda G103.

Figure 11 is a screenshot of the Tenda G103 command injection vulnerability. It shows the cgi-bin.
Figure 11. CVE-2023-27076 exploit in the wild.

CVE-2023-26801: LB-Link Command Injection Vulnerability

We captured this exploit traffic on April 10, 2023. The exploit targets a command injection vulnerability in the LB-Link wireless router’s /goform/set_LimitClinet_cfg component, which does not successfully sanitize the user input in the time1, time2 and mac parameters. This leads to arbitrary command execution.

Figure 12 is a screenshot of the LB-Link command injection vulnerability, including the component that is exploited.
Figure 12. CVE-2023-26801 exploit in the wild.

CVE-2023-26802: DCN DCBI-Netlog-LAB Remote Code Execution Vulnerability

The exploit was detected on April 10, 2023. The exploit works due to the Digital China Network DCBI-Netlog-LAB nsg_masq.cgi component failing to adequately sanitize the user-supplied input data, which leads to remote command execution.

Figure 13 is a screenshot of the DCN DCBI-Netlog-LAB Remote Code execution vulnerability. It shows the nsg_masq.cgi component in the first line of a screenshot.
Figure 13. CVE-2023-26802 exploit in the wild.

Zyxel Remote Code Execution Vulnerability

We observed this exploit traffic on Dec. 16, 2022. The exploit targets the Zyxel router’s /bin/zhttpd/ component. If insufficient input validation is found, the attacker can exploit the vulnerability to launch a remote code execution attack.

Figure 14 is a screenshot of the Zyxel remote code execution vulnerability. Included is the line that is exploited in the router, /b/zhttpd/.
Figure 14. Zyxel router exploit in the wild.

Updated May 26, 2023, at 3:30 p.m. PT.

It’s All in the Name: How Unit 42 Defines and Tracks Threat Adversaries

Posted on by Unit 42

Executive Summary

Within Unit 42 Threat Intelligence, we are often asked, “How does Unit 42 define and track actor activity?” To answer this question, we’ll give you a glimpse into our day-to-day activities, specifically focusing on how Unit 42 Threat Intelligence tracks behavior-based activity clusters.

The convention that Unit 42 Threat Intelligence uses for naming formal threat actor groups has been discussed in a previous blog. In this post, we’ll step back to give you a broader view, covering how the Unit 42 team builds and tracks activity clusters, and then associates this behavior with temporary threat actor groups. We’ll also discuss how we decide when to enact our formal actor naming and definition processes.

Related Unit 42 Topics nomenclature, threat actors, threat intelligence

Threat Tracking Overview

Defining a cluster of activity or a temporary actor group is a complex and often ambiguous process that typically takes a lot of time, effort and coordination. Formal actor naming begins when our team analyzes artifacts and TTPs from a single intrusion. It then evolves when we build and track additional activity into what we call an activity cluster.

Activity clusters consist of observed threat actor behavior that we have identified and use as a basis for tracking. These behaviors are clustered into groups of tactics, techniques and procedures (TTPs). We continually review and push these TTPs through our analysis process such that the clusters grow over time, potentially becoming a temporary threat actor group.

Figure 1 is a flow chart of how a threat actor gets named. It starts with threat actor, activity mapping mapping, where a temporary actor group is monitored. Finally, the threat actor gets a formal name.
Figure 1. Logical flow of tracked activity cluster to a formal actor name.

To achieve Unit 42’s mission of protecting the digital world against cyberattacks, we need to consistently track and monitor activity clusters and temporary threat actor groups.

Activity Clusters

An activity cluster is a grouping of related threat activity that includes observable artifacts like adversary tools, infrastructure or trade craft. The intention of defining an activity cluster is to build out a corpus of knowledge on a cluster of activity over time before “graduating” that cluster to a temporarily tracked threat group.

These clusters start with data collected in a single incident or investigation, and they grow by piecing together additional data from other incidents and collection sources. While running investigations, Unit 42 researchers often discover new artifacts associated with their investigations that can grow, merge or break off clusters of activity.

The Unit 42 team defines activity clusters based on our hypothesis of the actor’s motivation, where it is possible to establish. We name clusters using the following shorthand notation:

  • CL - short for cluster
  • CRI - short for criminal motivation
  • STA - short for state-backed motivation
  • MIX - short for mixed motivation
  • UNK - short for unknown motivation

Using this shorthand, Unit 42 names clusters of activity as follows:

CL-{CRI | STA | MIX | UNK} - ####

The number assigned to the activity cluster is in consecutive order, incrementing by one from the previously classified activity cluster.

Let’s examine how this looks with an example.

Unit 42 researchers are often involved in the research of multiple incidents targeting medical facilities throughout the United States. While working on each of the incidents, we find that the different adversary tools, infrastructure and trade craft are sometimes related. This helps us form an activity cluster.

We will often find the adversary exploiting the same vulnerabilities to gain initial access, applying the same lateral movement and exfiltration tactics, and using the same infrastructure for command and control (C2) across varying medical organizations. However, in many cases, we might not know the motivation of the adversary. Based on this, Unit 42 could track this as an activity cluster named CL-UNK-0042.

Now that we’ve examined some of the core tenants of tracking activity clusters, let’s examine the next step of our definition process: creating temporary actor groups.

Temporary Actor Groups

The concept of creating temporary actor groups is a way for the Unit 42 team to graduate activity clusters to a more solidified categorization. This graduation means the researcher feels confident that a single actor is participating in the threat activity.

It is important to note that within Unit 42 Threat Intelligence, we prevent direct migration of activity clusters to formally named actor groups. The activity clusters must first go through graduation to a temporary threat actor group.

This graduation is done after establishing several correlation points over time and across activity clusters, and after mapping those overlaps to the Diamond Model of Intrusion Analysis. This model focuses on core features of intrusions such as adversary, capability, victim and infrastructure, which Unit 42 researchers leverage and examine to correlate related clusters of activity.

For temporary actor groups, we opted to keep the same naming convention, with the addition of TGR, which is short for “threat group.”

We name temporary group names as follows:

TGR-{CRI | STA | MIX | UNK} - ####

Like the numbering for activity clusters, the number assigned at the end of the name for a threat group is in consecutive order, incrementing by one from the previously classified threat group.

Let’s look at an example of how we name a temporary actor group using our defined convention, continuing with tracking CL-UNK-0042. Further tracking and analysis revealed shared usage of phishing and C2 infrastructure in addition to overlaps with another activity cluster: CL-STA-0073.

During tracking, researchers also determined that threat actors were sharing tooling and malware throughout both clusters of activity, some of which were custom created. Based on these and previous investigative findings, Unit 42 could now start tracking clusters CL-STA-0042 and CL-STA-0073 as TGR-STA-0051.

Consistent tracking and analysis over time of TGR-STA-0051 could ultimately lead to a formal Unit 42 threat actor name, after we establish higher confidence in the relationship between the temporary group and the formal group.

Final Thoughts

In this blog, we wanted to give a glimpse into a day in the life of a researcher who’s identifying, defining and tracking activity clusters and temporary threat actor groups. We hope this insight provides clarity into how some of the more nebulous aspects of threat research are performed. You can now be better informed about the meaning of these two groupings, as Unit 42 starts to leverage activity clusters and temporary actor groups in our forthcoming publications.

Threat Assessment: Royal Ransomware

Posted on by Doel Santos

Executive Summary

Royal ransomware has been involved in high-profile attacks against critical infrastructure, especially healthcare, since it was first observed in September 2022. Bucking the popular trend of hiring affiliates to promote their threat as a service, Royal ransomware operates as a private group made up of former members of Conti.

The Unit 42 team has observed this group compromising victims through a BATLOADER infection, which threat actors usually spread through search engine optimization (SEO) poisoning. This infection involves dropping a Cobalt Strike Beacon as a precursor to the ransomware execution. Unit 42 incident responders have participated in 15 cases involving Royal ransomware in the last 9 months.

Royal ransomware also expanded their arsenal by developing an ELF variant to impact Linux and ESXi environments. The ELF variant is quite similar to the Windows variant, and the sample does not contain any obfuscation. All strings, including the RSA public key and ransom note, are stored as plaintext.

Palo Alto Networks customers receive protections against ransomware used by the Royal ransomware group from Cortex XDR, as well as from the WildFire Cloud-Delivered Security Service for the Next-Generation Firewall. The Unit 42 Incident Response team can also be engaged to help with a compromise or to provide a proactive assessment to lower your risk.

Related Unit 42 Topics Ransomware

Overview

The Royal ransomware group was first observed in September 2022, compromising victims and using multi-extortion to pressure victims to pay their fee. Before their first appearance, this group had been linked to a previous ransomware family named Zeon, starting in January of the same year.

Unlike major ransomware groups like LockBit 3.0, which typically operate as a ransomware-as-a-service (RaaS) by hiring affiliates and promoting their RaaS model, we have not observed this particular group using a similar approach. It is suspected that this group is made up mainly of former members of the Conti ransomware group, who operate covertly and behind closed doors. The ex-members that formed this group are known as Team One.

Because some of the people behind this threat were part of the development of Ryuk (discovered in 2018), which is the predecessor of Conti, they have many years of experience. This means they have a solid base for carrying out attacks and know what works when extorting victims. Perhaps due to this experience, the group has already impacted numerous organizations across the globe. We’ve observed them making demands up to $25 million dollars in BTC.

Royal also has frequently threatened certain critical infrastructure sectors, such as manufacturing and healthcare. In a few months in 2022, the group impacted 14 manufacturing organizations, according to their leak site, and then followed up by publicizing claims of attacking 26 additional manufacturing organizations in 2023. They have also impacted eight healthcare organizations since their inception. The U.S. Department of Health and Human Services issued a warning about the threat Royal ransomware poses to the healthcare sector in January 2023.

Royal also has been one of the ransomware groups disrupting the education industry. We observed that they impacted 14 organizations in the education sector, including school districts and universities. In fact, in just the first few days of May 2023, the group had already impacted four educational institutions.

This group has leveraged their leak site to publicly extort victims into paying the ransom, as shown in Figure 1. The Royal group will harass victims until the payment is secured, using techniques such as emailing victims and mass-printing ransom notes.

Figure 1 is a screenshot of the royal ransomware leak site. It includes a contact form as well as a revenue counter, and a link to their website.
Figure 1. Royal ransomware leak site.

The Royal ransomware threat actor has an active Twitter account that was created in October 2022, called “LockerRoyal.” Most of the account content is announcements of compromised victims, tagging the victim’s Twitter account. In some cases, the threat actor will also reply to those same announcements.

It’s not unusual to see threat actor groups create social media accounts to keep spreading their brand and announcements. It’s clear that this group is trying to get attention from multiple organizations through any means necessary.

Figure 2 is two screenshots of the royal ransomware Twitter account. The left screenshot is the account profile.There are 29 tweets total, and the username is LockerRoyal. The right screenshot is a response. The right screenshot is the account responding to a tweet with OMG! The original tweet is by FalconFeedio, and says that the royal ransomware group has added a brewery based in Germany to their victim list.
Figure 2. Royal Twitter account replying to an alert.

This particular ransomware group has been observed using multiple initial access vectors to secure access into vulnerable systems, such as the following:

Once access is secured, this group uses multiple tools to support the intrusion operation, like the TCP/UDP tunnel Chisel and the Active Directory query tool AdFind, among others.

Victimology

Royal ransomware has impacted a variety of industries, including small businesses and large corporations alike. Based on information from their leak site and public reporting outlets, we can see that Royal ransomware has impacted industries such as manufacturing, as well as wholesale and retail. Since 2022, Royal ransomware has claimed responsibility for impacting 157 organizations on their leak site.

It's important to note that the impact of Royal ransomware extends beyond just financial losses. There have been instances where the group has targeted critical infrastructure, such as healthcare organizations and agricultural facilities. Since 2022, we have observed this group impacting seven local government entities – like the recent attack on the city of Dallas – in the United States and Europe.

Unit 42 incident responders have participated in 15 cases involving Royal ransomware.

This demonstrates the potential for broader and more severe consequences, as shown in Figure 3.

Figure 3 is a column chart showing the industries distribution per Royal leak site post. The vast majority is manufacturing, followed by wholesale and retail, and then professional and legal services.
Figure 3. Industries distribution per Royal leak site post.

Most of the organizations impacted by this ransomware are located in the United States, comprising 64% of the impacted organizations. Canada is the country second most impacted by this ransomware family, making the total for North America 73.2%. The next most impacted countries include Germany, the United Kingdom, Brazil, Italy and others (shown in Figure 4).

Figure 4 is a graph of countries impacted by Royal Ransomware by number of cases, with 155 total. The United States was impacted the most at 100 cases, followed by Canada with 13, and Germany with 11. The lowest case count is Mexico and Portugal at two cases each.
Figure 4. Countries impacted distribution per Royal leak site post.

Infection Chain

There are several different infection chains that lead to Royal ransomware. In some cases, we have observed instances where SEO poisoning and malvertising were used as initial access vectors. The goal of these two methods is to trick a victim into downloading and executing a malicious file that masquerades as legitimate software.

This kicks off a complex infection chain with multiple stages, including PowerShell scripts and MSI files. In certain cases, this leads to infection with BATLOADER.

BATLOADER will then attempt to download further payloads to the infected machine, such as VidarStealer, Ursnif/ISFB and Redline Stealer, as well as legitimate tooling such as the system management tool NSudo and the Syncro remote monitoring and management (RMM) tool. Most importantly, BATLOADER has been seen loading Cobalt Strike, which is often a precursor to ransomware distribution.

In one particular case where we saw Royal ransomware deployed, a snippet of C# code was identified that was originally pulled down from Pastebin. This code, when compiled, would decrypt and load shellcode. The shellcode appeared to be a simple Meterpreter stager that would reach out to an IP address and execute the final Meterpreter beacon. The IP address also hosted a Cobalt Strike server, from which we were able to retrieve the Cobalt Strike configuration.

The configuration contained fairly standard values, although the watermark appeared to be somewhat unique and not randomly generated: 12345. Querying for live Cobalt Strike servers on Shodan with the same watermark returned just over 50 results.

While this unique watermark could indicate a cracked version of Cobalt Strike, examining the domain names for these C2s revealed commonalities across the board. Almost every domain was named to resemble a security company.

For example, the following servers hosted Cobalt Strike beacons with the watermark 12345:

  • altocloudzone[.]live
  • cloudmane[.]online
  • palaltocloud[.]online
  • kasperslkyupdate[.]com
  • palalto[.]live
  • altocdn[.]online
  • paloaltokey[.]store
  • kasperskyupdates[.]com
  • Rapidfinact[.]com

Note that the names above are the work of a threat actor attempting to impersonate legitimate organizations and do not represent actual affiliations with that organization. The threat actor’s impersonation does not imply a vulnerability in the legitimate organizations’ products or services.

Defense Evasion

Unit 42 researchers observed Royal ransomware operators using PowerTool. This is a piece of software that has access to the kernel and is ideal for removing endpoint security software. They also executed batch scripts to disable security-related services, and deleted shadow file copies and logs after successful exfiltration.

Lateral Movement

Unit 42 researchers observed Royal threat actors using the network discovery software NetScan to identify and map out various connected computer resources such as other user targets and shares. In addition to using NetScan, we also observed them using PsExec for conducting lateral movement within the infected environments.

Command and Control (C2)

Unit 42 researchers observed threat actors using various popular legitimate remote management software also used heavily by other ransomware operations to maintain access to the infected environment. The use of Cobalt Strike and related beacons were also observed for C2. An interesting observation of a tool used for maintaining access was the use of Chisel, a TCP/UDP tunneling tool written in Golang.

Exfiltration

Unit 42 researchers observed Royal threat actors using Rclone, a legitimate tool to manage files between two systems, for exfiltrating stolen data before the deployment of ransomware. We found Rclone deployed in folders such as ProgramData, or renamed and masquerading in other folders. One popular filename used was svchost.exe.

Ransomware Functionality

Windows Variant

It is important to note that, while many ransomware families employ various forms of anti-analysis, as of late April, Royal ransomware does not employ anti-analysis tricks or string encryption.

There are five possible arguments for the Windows variant of Royal ransomware:

Argument Purpose
-path Path to be used for targeting encryption
-id 32-character ID for running sample
-ep Encryption percentage - indicates the percentage of each file to be encrypted
-localonly Encrypt only the local system
-networkonly Encrypt file shares connected to system

In Figure 5 below, the decompiled view contains the various command-line arguments to be evaluated at the start of the binary being executed.

Figure 5 is a screenshot of many lines of code. Five areas highlighted in red are the command line arguments that royal Ransomeware excepts as inputs. They are L-path, id, ep, localonly, and networkonly.
Figure 5. Command-line arguments Royal accepts as inputs.

Upon evaluating the command-line arguments provided, the ransomware then will create a cmd.exe process with the parameter to execute vssadmin delete shadows /all /quiet. The command is part of the standard ransomware playbook for impacting restoration services.

For the encryption process, Royal ransomware has a hard-coded RSA public key within the binary and uses AES for encryption. The AES encryption is set up using a 32-byte key and a 16-byte initialization vector (IV). The encrypted files are encrypted with the extension .royal_w.

During file enumeration and encryption, the sample avoids files with the following extensions and filenames (also shown in Figure 6):

Extensions:

  • .exe
  • .dll
  • .bat
  • .lnk
  • .royal_w
  • .royal_u

Files and folders:

  • README.TXT
  • Windows
  • Royal
  • Recycle.bin
  • Google
  • Perflogs
  • Mozilla
  • Tor browser
  • Boot
  • $Windows.~ws
  • $Windows.~bt
  • Windows.old

During the encryption process, if a file is encountered which is actively being used by the computer system, the ransomware can use the RestartManager API functionality to close a file. As shown in Figure 6, the strings related to skipped extensions and folder paths are shown in the .rdata section of the binary.

Figure 6 is a screenshot of the extensions and folders that are excluded in the .rdata section of the binary.
Figure 6. Extensions and folders excluded.

The ransom note dropped as a README.txt is shown in Figure 7 below.

Figure 7 is a screenshot of a royal ransomware ransom note. It is a read me a text and gives an exclamation explanation of what you expect, and how to contact the group.
Figure 7. Royal ransomware ransom note.

Royal also contains functionality to encrypt network shares connected to the victim machine. The decompiled view of the code path responsible for enumerating shares is shown in Figure 8 below.

Figure 8 is a screenshot of many lines of code. It is the decompiled view of the code path responsible for enumerating shares.
Figure 8. Enumerates network shares and excludes ADMIN and IPC shares.

For supporting cryptographic operations used in the ransomware, the code is statically compiled with OpenSSL. The cryptographic references can be seen in Figure 9 below and can be cross-referenced by examining the library on GitHub.

Figure 9 is a screenshot of the open SSLibrary statically compiled with the ransomware binary. Highlighted in the string column is the word crypto.
Figure 9. OpenSSL library statically compiled with ransomware binary.

Linux Variant

During development of this post, a Linux variant of Royal ransomware was identified by @BushidoToken on Feb. 1, 2023. This is the first known version not targeting Windows systems. However, considering many ransomware families have an ESXi/Linux focused variant, this isn’t unusual. It only makes sense that this group would expand their arsenal to impact other environments.

There are minimal differences between the Linux and Windows variants in terms of encryption. AES-256 is used for symmetric encryption, while RSA-4096 is used for asymmetric encryption within the sample.

Additionally, there is a lack of obfuscation within the Linux sample. All strings are stored as plaintext, including the RSA public key and the ransom note.

There are five possible arguments for the Linux variant of Royal ransomware:

Argument Purpose
-id 32-character ID for running sample
-ep Encryption percentage – indicates the percentage of each file that will be encrypted
-stopv Indicates to the sample whether to stop VM-linked processes or not
-fork Forks the current process for encryption
-logs Informs the sample to log information to a file

During file enumeration and encryption, the sample avoids files with the following extensions and filenames:

Extensions:

  • .v00
  • .b00
  • .sf
  • .royal_u
  • .royal_w
  • .royal_log_
  • .readme

The variant is also compiled with the OpenSSL library, resulting in a large number of unreferenced crypto-linked strings.

Figure 10 is a screenshot of the open SSL string was seen within the Linux ransomeware binary.
Figure 10. OpenSSL strings seen within Linux ransomware binary.

Conclusion

Royal ransomware has been more active this year, using a wide variety of tools and more aggressively targeting critical infrastructure organizations. Organizations should implement security best practices and be wary of the ongoing threat of ransomware. This is true not only for Royal ransomware but for other opportunistic criminal groups as well.

The Unit 42 team recommends that defenders have advanced logging capabilities deployed and configured properly. This includes tools such as Sysmon, Windows command-line logging and PowerShell logging.

Ideally, you should be forwarding these logs to a security information and event management tool (SIEM) to create queries and detection opportunities. Keep computer systems patched and up to date wherever possible to reduce the attack surface related to exploitation techniques.

Deploy an XDR/EDR solution to perform in-memory inspection and detect process injection techniques. Perform threat hunting looking for signs of unusual behavior related to security product defense evasion, service accounts for lateral movement and domain administrator-related user behavior.

Protections and Mitigations

Palo Alto Networks customers receive protections from the threats discussed above through the following products.

  • WildFire: All known samples are identified as malware.
  • Cortex XDR with:
    • Indicators for Royal
    • Anti-Ransomware module to detect Royal encryption behaviors on Windows
    • Local Analysis detection for Royal binaries on Windows
  • Behavioral Threat Protection (BTP) rule helps prevent ransomware activity on Linux
  • Next-Generation Firewalls (NGFW): DNS signatures detect the known command and control (C2) domains, which are also categorized as malware in URL Filtering.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

Hashes

595c869f8ec7eaf71fef44bad331d81bb934c886cdff99e1f013eec7acdaf8c9 Royal Windows Variant
b57e5f0c857e807a03770feb4d3aa254d2c4c8c8d9e08687796be30e2093286c Royal Linux Variant
b64acb7dcc968b9a3a4909e3fddc2e116408c50079bba7678e85fee82995b0f4 Royal Linux Variant
b64acb7dcc968b9a3a4909e3fddc2e116408c50079bba7678e85fee82995b0f4 Royal Linux Variant
12a6d61b309171b41347d6795002247c8e2137522a756d35bb8ece5a82fc3774 Royal Linux Variant

Infrastructure

  • royal2xthig3ou5hd7zsliqagy6yygk2cdelaxtni2fyad6dpmpxedid[.]onion

Additional Resources

Teasing the Secrets From Threat Actors: Malware Configuration Parsing at Scale

Posted on by Mark Lim

Executive Summary

Configuration data that changes across each instance of deployed malware can be a gold mine of information about what the bad guys are up to. The problem is that configuration data in malware is usually difficult to parse statically from the file, by design. Malware authors know the intelligence value as they provide directives for how the malware should behave.

Malware is like most complex software systems in that there are many advantages for code reuse and abstraction. Therefore, it is not surprising to see that the concept of software configuration is pervasive across the various malware families we analyze. After all, it’s pretty hard to imagine a stereotypical cybercriminal wanting to bother with recompiling their code to change an IP address or whatever else, when going after different targets.

But the good news is that statically armored configuration data can often easily be found and parsed directly from memory. We will cover a nice example of an IcedID (information stealer) configuration, how it was obfuscated and how we’ve extracted it.

Palo Alto Networks customers receive improved detection for the evasions discussed in this blog through Advanced WildFire. As we continue to parse and extract this information from malware families at scale, we hope to build out a pool of threat intelligence that will better help us understand the campaigns and tactics of the various threat actors who are targeting various organizations.

Related Unit 42 Topics Memory Detection

What Are Malware Configurations?

So what exactly do we mean by the term “configuration” when talking about malware? Outside the context of malware, we think of configuration in terms of defining how systems should behave. For example, we would consider the rules used to define which networking routes for a firewall are allowed, or which font size your web browser uses while you read this, as configurable information.

For malware, this is no different. Malware configurations are just collections of elements that define how a malware operates, such as the following:

  • Command-and-control (C2) network addresses
  • Passwords for remote administrators
  • File paths in which to drop persistent payloads

The way these elements are embedded in malware components tends to be specific to each malware family. Also, they might evolve over time as malware undergoes development, or when malware authors change their build process.

Generally speaking, malware configuration elements tend to be the properties of malware that the authors want to make easily editable between campaigns and deployments without requiring manual code edits for each one. Malware configuration elements can also expose latent behaviors and malware infrastructure that are not typically observable under routine dynamic analysis.

Malware configurations have intelligence value for security practitioners because they provide insights into campaigns over time. In some cases, defenders could use them as actionable artifacts for network detection, or for identifying infected hosts. The successful extraction and validation of a malware configuration can also be used to reinforce our confidence when identifying a file as malicious.

Because malware configurations have value to security systems and defenders alike, it is state-of-practice for modern malware authors to protect their configuration elements using different techniques. These protections often include a blend of encryption, obfuscation and compression. They might also be layered with evasive techniques.

This protection poses a significant challenge for malware configuration extractors that operate solely by using static analysis, because all of these protections must be detected and bypassed before extraction can be performed. Using an advanced dynamic analysis sandbox combined with intelligent runtime memory analysis makes it possible to bypass many of these protections and pinpoint the best opportunities to perform extraction.

When we represent and store these configurations using standardized schemas, it enables us to extract maximum value through automation, machine learning and interactive analysis. The DC3-MWCP library defines a schema for many of the most common configuration element types, and it provides a simple library for serialization to JSON.

The MITRE MAEC and STIX projects also provide us with a more general vocabulary for representing malware configuration elements. This also allows us to correlate the elements with observable objects collected during dynamic analysis.

IcedID Analysis

Let’s look at one IcedID binary and how its configurations are encrypted.

Hash 05a3a84096bcdc2a5cf87d07ede96aff7fd5037679f9585fee9a227c0d9cbf51

This particular attack chain, shown in Figure 1, was discovered in early November 2022. It delivered IcedID, an information stealer also known as Bokbot, as the final payload. This threat is well-known malware that has been attacking people since 2019.

The following diagram shows the infection chain.

Image 1 is a graphic showing the IcedID infection chain. It starts with malicious spam executed by the user, and it ends with a scheduled task created to persist IcedID stage two.
Figure 1. IcedID infection chain.

Authors of IcedID took pains to hide their configurations. Recent samples of IcedID stage two would only be downloaded if the victim’s machine matched the requirements of the threat actor.

The configurations of IcedID consisted of C2 URLs and their campaign IDs. The C2 URLs included some that might not be revealed during the execution of the IcedID binaries. The campaign ID links IcedID samples back to specific threat actors.

We will go through the following steps to extract the configurations found in the IcedID stage one and two binaries:

  1. Unpack the IcedID binary
  2. Locate the encrypted configuration data blob
  3. Extract the encryption key
  4. Decrypt the configuration data blob with the encryption key

Unpacking IcedID Stage One

IcedID stage one unpacks itself by first allocating memory using the VirtualAlloc function. This is followed by erasing the allocated memory using the Memset function, as shown in Figure 2. Finally, it copies the unpacked data to the allocated memory using the Memmove function.

To dump the unpacked data, we set a breakpoint at Memmove. The second argument of Memmove contains the address of the unpacked data. Figure 2 also shows the DOS MZ header of the unpacked IcedID stage one in the right-hand side of the hex dump.

Image 2 is a screenshot of iced ID stage one as it is unpacked image two is a screenshot of unpacking iced ID, stage one. This is done by using the VirtualAlloc function.
Figure 2. Unpacking IcedID stage one.

Locating the Encrypted Configuration Data Blob

Next, we located the encrypted configuration data blob using the unpacked stage one IcedID. While debugging the unpacked IcedID stage one file, we set a breakpoint at the address that called WinHttpConnect, as shown in Figure 3. The address pointed to by register RDI contains the string of the C2 URL.

Image 3 is a screenshot of IcedID stage one being debugged.
Figure 3. Debugging IcedID stage one.

By backtracing the code, we located a function that used the decrypted configuration as shown in Figure 4.

Image 4 is a screenshot of IcedID stage one code being backtraced.
Figure 4. Tracing code in IcedID stage one.

Tracing the code flow back, we found the loop that decrypted the configuration, as shown in Figure 5.

Image 5 is a screenshot of the configuration decryption loop for IcedID stage one.
Figure 5. Configuration decryption loop for IcedID stage one.

The instruction at 0x7FEF33339CD loaded the address of the encrypted configuration data blob (Encrypted_Config) into register RDX.

Extracting the Encryption Key

The instruction at 0x7FEF33339D4 reads the encryption key. The key is 0x40 bytes offset from the address of Encrypted_Config. We also learned the configuration is 0x20 bytes long. An XOR loop was used to decrypt the configuration.

Decrypting the Configuration Data Blob With the Encryption Key

After gathering the encryption key, the encrypted data blob and the decryption routine, we can now decrypt the configuration using the following script shown in Figure 6.

Image 6 is a screenshot of the configuration decryption script for IcedID stage one.
Figure 6. Configuration decryption script for IcedID stage one.

The decrypted IcedID stage 1 configuration has the following format, as shown in Figure 7.

Image 7 is a screenshot of the IcedID stage one configuration format.
Figure 7. IcedID stage one configuration format.

From the decrypted configuration, we can extract the following IoCs:

C2 URL bayernbadabum[.]com
Campaign ID 1139942657

Now, we will decrypt the configuration for the IcedID stage two binary.

Unpacking the IcedID Stage Two Binary

As the IcedID stage two binary uses the same packer as stage one, we will not repeat the unpacking steps here.

Locating the Encrypted Configuration Data Blob

We set a breakpoint at the address that calls Winhttpconnect, as shown in Figure 8.

Image 8 is a screenshot of IcedID stage two being debugged. Highlighted is row 14, were the breakpoint is set.
Figure 8. Debugging IcedID stage two.

After tracing the code, we located the function that used the decrypted configuration, as shown in Figure 9.

Image 9 is a screenshot of the traced code of IcedID stage two, showing the location of the function that used the description configuration.
Figure 9. Tracing code in IcedID stage two.

Extracting the Encryption Key

Tracing the code flow even further back, we found the function that decrypts the configuration. The first few instructions located the encrypted configuration blob. The encrypted blob is 0x25c bytes long. The encryption key is the last 0x10 bytes of the encrypted configuration blob, as shown in Figure 10.

Image 10 is a screenshot of the encryption key for IcedID stage two. Highlighted is the address of the encryption key, which is below the line offset to encryption key.
Figure 10. Loading the encryption key for IcedID stage two.

After retrieving the encryption key, the next step is the loop to decrypt the encrypted blob, as shown in Figure 11.

Image 11 is a screenshot of the configuration decryption loop for IcedID stage two. This is the next step after retrieving the encryption key.
Figure 11. Configuration decryption loop for IcedID stage two.

Decrypting the Configuration Data Blob With the Encryption Key

We replicated the instructions in the decryption loop using Python. After gathering the encryption key, encrypted data blob and the decryption routine, we can now decrypt the configuration using the following script (shown in Figure 12).

Image 12 is a screenshot of the configuration decryption script for IcedID stage two.
Figure 12. Configuration decryption script for IcedID stage two. Note: Jquinn147 and myrtus0x0 published a similar configuration decryption script for IcedID in May 2021, called IcedDecrypt (GitHub).

The decrypted IcedID stage two configuration has the following format, shown in Figure 13.

Image 13 is a screenshot that shows the configuration format for the decrypted IcedID stage two.
Figure 13. Configuration format for IcedID stage two.

From the decrypted configuration, we can extract the following indicators of compromise (IoCs):

C2 URLs newscommercde[.]com

spkdeutshnewsupp[.]com

germanysupportspk[.]com

nrwmarkettoys[.]com
C2 URI news
Campaign ID 1139942657

We have manually decrypted the configuration for both the IcedID stage one and two binaries.

Scaling Up

Now that we’ve discussed the work of figuring out how to target the configuration data in memory, the next challenge is to figure out how to perform this at scale. The massive scale of most malware processing systems means that most practitioners looking to build out a configuration extraction system will need to be careful about adding additional overhead. This means that we will need a mechanism to intelligently identify only the samples of interest for each parser, so we’re not unnecessarily running dozens of parsers across millions of samples.

We think a reasonable approach to this problem involves using intelligent runtime memory analysis, as it provides us with excellent visibility into the secrets malware authors want to protect. A typical workflow for our malware configuration extractors includes the following activities:

  • Scanning memory and/or other dynamic analysis artifacts
  • Applying a noise filter on the results to identify the best candidates for extraction
  • Performing extraction using the best fitting module and storing the results for reporting and indexing

Generalizing this common workflow presented us with the opportunity to make the following improvements:

  • Optimizing the search phase by only scanning analysis data once in most cases
  • Applying abstractions and reusable code for many common tasks
  • Limiting the impact of modules with problematic inputs or other bugs
  • Giving our security researchers visibility into the performance of their modules

The following example shows some of the IoCs from a recent IcedID extractor after being deployed at scale. Having a nice framework for deploying configuration extractors means that once you are finished crafting a configuration extraction script, it’s time to kick your feet up and relax while hundreds of configurations flow into your malware configuration database.

Image 14 is a screenshot of IoCs from IcedID samples. It starts at line 34 and continues to line 59.
Figure 14. IoCs from IcedID samples.

Conclusion

Thank you for joining us in this overview of malware configurations and why we are working hard to parse this information at scale in Advanced WildFire. Reverse engineering variants of each malware family allow us to build out parsers to extract meaningful and relevant data for all of them at scale.

There is a staggering amount of diversity among payloads in the malware landscape, which makes the task of supporting them all more or less impossible. Where possible, we use metrics-based approaches to prioritize focus on the malware families and variants most relevant to our customers. In this ongoing area of research, our team will continue to expand support for new malware families and variants.

Palo Alto Networks customers receive protections from threats such as those discussed in this post with Advanced WildFire.

Indicators of Compromise

05a3a84096bcdc2a5cf87d07ede96aff7fd5037679f9585fee9a227c0d9cbf51

Additional Resources

Updated May 17, 2023, at 6:00 a.m. PT.

Network Security Trends: November 2022-January 2023

Posted on by Samantha Stallings

Executive Summary

Recent observations of exploits used in the wild November 2022-January 2023 reveal that attackers have been using newly published remote code execution vulnerabilities in the following three products:

  • Roxy-WI, a web interface for managing and monitoring RoxyDNS
  • CWP, a free web hosting control panel (aka Control Web Panel or CentOS Web Panel)
  • Cacti, an open-source network monitoring and graphing tool used to track the performance of various network devices, servers and applications

Additionally, attackers have also been taking advantage of a traversal and information disclosure vulnerability in ThoughtWorks GoCD to read sensitive files stored on servers.

In our observations of network security trends, Unit 42 researchers have pinpointed several attacks based on proof-of-concept (PoC) availability and impact. We have detailed below which of these we believe should be on the defender’s radar.

Other insights that could assist defenders include the following:

  • Rankings of the most commonly used attack techniques and the types of vulnerabilities that attackers have recently favored. For example, among 6,169 newly published vulnerabilities, a large portion (almost 11%) involves cross-site scripting.
  • Lists of major vulnerabilities identified by evaluating more than 276 million attack sessions including code execution, traversal and information disclosure.
  • Insight into how these vulnerabilities are exploited in the wild based on real-world data collected from our Next-Generation Firewalls.
  • Summaries of key trends from November 2022-January 2023.
  • Analysis of the most recently published vulnerabilities, including the severity and attack origin distribution.
  • Classification of these vulnerabilities to provide a clear view of the prevalence of the different types, such as cross-site scripting or denial-of-service.
  • Lists of the most commonly exploited vulnerabilities attackers are using, as well as the severity, category and origin of each attack.

Palo Alto Networks customers receive protections from the vulnerabilities discussed here through the Next-Generation Firewall, Cloud-Delivered Security Services and Prisma Cloud WAAS, including Threat Prevention, WildFire, Advanced URL Filtering and Cortex XDR.

CVEs Discussed CVE-2022-27924, CVE-2022-31137, CVE-2022-44877, CVE-2022-46169, CVE-2021-43287, CVE-2021-31602, CVE-2021-22005, CVE-2021-33035, CVE-2022-30136. CVE-2022-1118
Types of Attacks and Vulnerabilities Covered Cross-site scripting, information disclosure, buffer overflow, code execution, SQL injection, traversal, command injection, improper authentication, security feature bypass
Related Unit 42 Topics Network Security Trends, exploits in the wild, attack analysis

Analysis of Published Vulnerabilities, November 2022-January 2023

From November 2022-January 2023, a total of 6,169 new Common Vulnerabilities and Exposures (CVE) numbers were registered. To better understand the potential impact these newly published vulnerabilities could have on network security, we provide our observations based on the severity, availability of working proof-of-concept (PoC) code, and vulnerability categories.

How Severe Are the Latest Vulnerabilities?

To estimate the potential impact of vulnerabilities, we consider their severity and examine any reliable PoCs available that attackers could easily launch. Some of the public sources we use to find PoCs are Exploit-DB, GitHub and Metasploit. Distribution of the CVEs that have an assigned severity score of Medium or higher can be seen in the following table:

Severity Count Ratio Ratio Change From Last Quarter % PoC Availability Change in PoC Availability
Critical 1,100 17.8% -1.1% 3% +0.1%
High 2,339 37.9% -4.2% 3.1% +0.9%
Medium 2,730 44.3% +5.3% 2.2% -0.1%

Table 1. Severity distribution for CVEs registered November 2022-January 2023, including only those rated Medium-Critical.

Image 1 is a pie chart measuring the distribution of critical, high, and medium CVEs registered through August and September of 2022. The largest percent is “high” at 37.9%.
Figure 1. Severity distribution for CVEs registered November 2022-January 2023, including only those rated Medium-Critical.

Our classification of vulnerabilities is based on CVSS v3 scores. Many conditions must be met to rate a vulnerability as Critical, so there are very few at this level. One of the common factors for rating a vulnerability at this level is having a working PoC available. To be considered Critical, vulnerabilities generally have low attack complexity, and it is often easy to create a PoC to exploit them.

Vulnerability Category Distribution

It is crucial to understand each type of vulnerability and its consequences. Out of the newly published CVEs that were analyzed, 22.6% are classified as local vulnerabilities, requiring prior access to compromised systems, while the remaining 77.4% are remote vulnerabilities, which can be exploited over a network. This means that most newly published vulnerabilities introduce potential opportunities for threat actors to attack vulnerable organizations from anywhere in the world.

In Figure 2, the most common vulnerability types are ranked by how prevalent they were among the most recent set of published vulnerabilities.

Image 2 is a stacked bar chart showing the vulnerability category distribution for CVEs registered through November 2022 to January 2023. Medium has the largest portion in yellow for cross-site scripting.
Figure 2. Vulnerability category distribution for CVEs registered November 2022-January 2023.

Cross-site scripting remains the most reported vulnerability from November 2022-January 2023. We also saw that the prevalence of cross-site scripting vulnerabilities increased during this time, and the majority of the vulnerabilities in this category are ranked Medium. Code execution and information disclosure vulnerabilities decreased. Most of the recently published cross-site scripting and information disclosure vulnerabilities are at Medium severity (rather than Critical).

Figure 3. Vulnerability category distribution compared with the previous quarter.

This quarter, we have observed an increase in cross-site scripting vulnerabilities compared to last quarter. Cross-site scripting is a classic attack vector that is still very popular today. We have also observed a slight increase in denial-of-service vulnerabilities, while code execution vulnerabilities have decreased slightly.

Network Security Trends: Analysis of Exploits in the Wild, November 2022-January 2023

Data Collection

By leveraging Palo Alto Networks Next-Generation Firewalls as sensors on the perimeter, Unit 42 researchers observed malicious activities from November 2022-January 2023. The malicious traffic we identified is further processed and based on metrics such as IP addresses, port numbers and timestamps. This ensures the uniqueness of each attack session and thus eliminates potential data skews. We analyzed 276 million valid malicious sessions and then correlated the refined data with other attributes to infer attack trends over time to get a picture of the threat landscape.

How Severe Were the Attacks Exploited in the Wild?

To arrive at 276 million valid malicious sessions, we excluded the original set of low-severity signature triggers used to detect scanning and brute-force attacks, as well as internal triggers used for research purposes. Therefore, we consider exploitable vulnerabilities with a Medium and higher severity ranking (based on the CVSS v3 Score) as a verified attack.

Image 4 is a pie chart measuring attack severity distribution of critical, high, and medium CVEs registered through November 2022 to January 2023. The largest percent is “Critical” at 42.5%.
Figure 4. Attack severity distribution, November 2022-January 2023, including only Medium through Critical vulnerabilities.

Figure 4 shows the session count and ratio of attacks grouped by the severity of each vulnerability. Compared with the previous quarters' severity distribution, this quarter shows a decrease in Critical attacks, because attacks against CVE-2021-35394 decreased.

We focus more on Critical-severity attacks because of their greater potential impact. Although there has been a decline, the vulnerabilities rated as Critical are still exploited the most, because attackers typically leverage more severe vulnerabilities for exploits. Defenders should prioritize preventing and mitigating High-severity and Critical-severity network attacks.

Image 5 is a column chart showing the vulnerability severity distribution for CVEs registered through November 2022 to January 2023 compared to the previous quarter, showing a decrease in Critical and a rise in High and Medium.
Figure 5. Vulnerability severity distribution compared with the previous quarter.

When Did the Network Attacks Occur?

Image 6 is a column chart comparing the net work attacks occurred across critical hot, high, medium, and then showing the total, by week.
Figure 6. Severity of exploits in the wild measured weekly from November 2022-January 2023.

During November 2022-January 2023, attackers increased their exploitation of Critical-severity vulnerabilities starting in January, and the number of attacks against High-severity and Medium-severity vulnerabilities gradually increased. Note, the last set of data records eight days of attack volume instead of seven days.

As we’ve seen in the past, attackers frequently use recently disclosed vulnerabilities, especially those from 2021-2022. This shows the importance of updating security products and applying software patches as soon as they become available to protect against the most recently discovered vulnerabilities.

Image 7 is a bar chart showing by month and week the observed attacks in which the exploited CVE was disclosed. Included CVEs are CVEs from 2021 to 2022, yellow, 2019 to 2020, solid red, 2016 to 2018, dashed blue, 2010 to 2016, dotted green and before 2010, orange.
Figure 7. Observed attacks broken down by the year in which the exploited CVE was disclosed, measured weekly from November 2022-January 2023.

Exploits in the Wild, November 2022-January 2023: A Detailed View

Among the latest published attacks, the following exploits stood out due to their PoC availability, severity and ease of exploitation. We have provided snippets showing how attackers used open-source tools to compromise the different targets, allowing defenders to better understand how the exploit operates.

CVE-2022-27924

This is a vulnerability that allows attackers to inject malicious commands and sniff sensitive information. This is accomplished by poisoning the IMAP route cache entries in the memcached server. This server is used to query Zimbra users and push their HTTP requests to the appropriate backend service.

Figure 8 is a screenshot of a code snippet detailing the Zimbra remote code execution. I
Figure 8. CVE-2022-27924.

CVE-2022-31137

Roxy-WI is a web interface used to manage HAProxy, NGINX and Keepalived servers. This vulnerability allows attackers to construct malicious requests, execute arbitrary commands without logging in and control the server.

Figure 9 is a screenshot of a code snippet detailing the Roxy-WI web interface vulnerability.
Figure 9. CVE-2022-31137.

CVE-2022-44877

Control Web Panel (CWP) is a popular web hosting platform. This vulnerability exists in the /login/index.php component, allowing an unauthenticated attacker to execute arbitrary system commands through crafted HTTP requests.

Figure 10 is a screenshot of a code snippet detailing the Control Web Panel web who platform vulnerability. The vulnerability is part of the login index.php component.
Figure 10. CVE-2022-44877.

CVE-2022-46169

Cacti is an open-source platform for operational monitoring and a fault management framework. Due to a verification flaw in the remote_agent.php file, an unauthenticated attacker can bypass authentication by setting the variable at the beginning of HTTP_ to the host name of the Cacti server, to achieve command execution.

Figure 11 is a screenshot of vulnerability in Cacti, an open source platform. There is a verification flaw in the remote_agent.php file.
Figure 11. CVE-2022-46169.

CVE-2021-43287

ThoughtWorks GoCD is an open source build and release tool. An unauthenticated attacker could exploit this vulnerability to obtain all secrets known to the GoCD server.

Figure 13 is a screenshot of a code snippet detailing the ThoughtWorks GoCD vulnerability.
Figure 13. CVE-2021-43287.

CVE-2021-31602

Pentaho is business intelligence software that provides data-related services. An attacker could exploit a vulnerability where the default configuration allows them to extract pieces of information without valid credentials.

Figure 14 is a screenshot of a code snippet detailing the Pentaho vulnerability of of the default configuration.
Figure 14. CVE-2021-31602.

CVE-2021-22005

vCenter is virtual server management software by VMware. An unauthenticated remote attacker could exploit this vulnerability by uploading a crafted forged file to an affected vCenter Server deployment to transform commands and software. The whole attack process is very simple and does not require any user interaction.

Figure 15 is a screenshot of a code snippet detailing the vCenter exploit.
Figure 15. CVE-2021-22005.

CVE-2021-33035

This is a vulnerability in Apache OpenOffice, an open-source office software suite. The vulnerability opens dBase/DBF documents and displays the contents as a spreadsheet. When the DBF (a database file where data is organized by fields) data is read, the size of some fields is not checked. The data is copied into local variables. This vulnerability could be exploited by a malicious file opened by the software, executing malware on the machine.

Figure 16 is a screenshot of a code snippet detailing the Apache OpenOffice code.
Figure 16. CVE-2021-33035.

CVE-2022-30136

This is a remote code execution vulnerability in Windows Network File System due to improper handling of NFSv4 requests. An unauthenticated attacker could exploit this bug to execute arbitrary code in the context of SYSTEM1.

Figure 17 is a screenshot of a code snippet detailing the Windows Network File System remote code execution vulnerability.
Figure 17. CVE-2022-30136.

CVE-2022-1118

This vulnerability exists in Connected Components Workbench, ISaGRAF Workbench, and Safety Instrumented System Workstation because there is no restriction on the objects that can be deserialized.

Figure 18 is a screenshot of a code snippet detailing the vulnerability in Connected Components Workbench, ISaGRAF Workbench, and Safety Instrumented System Workstation.
Figure 18. CVE-2022-1118.

Attack Category Distribution

We classified each network attack by category and organized them in terms of prevalence. In the period discussed, remote code execution ranks highest. Traversal and information disclosure vulnerabilities were the second and third most popular attacks of the quarter. Both of these types of vulnerabilities can be exploited by attackers to obtain sensitive information. Attackers typically aim to gain maximum information from and control over the systems they target.

Figure 19 a stacked bar chart showing the attack category and severity of critical, high, and medium CVEs from November 2022 to January 2023. Remote code execution far outranks any other at 127 million.
Figure 19. Attack category and severity, November 2022-January 2023.

Compared with the previous quarter, most categories of attacks have increased. The number of remote code execution attacks has decreased, possibly due to a decrease in attacks against CVE-2021-35394. However, we have observed an increase in traversal, information disclosure and SQL injection vulnerabilities. These four types of vulnerabilities are frequently exploited by attackers.

We have also observed an increase in the use of hack tools, especially FFuF (often used for identifying security vulnerabilities in web applications by fuzzing them with a large number of test cases) and Nmap (often used for network exploration and discovery by scanning hosts and services on a network and creating a map of the network topology).

Where Did the Attacks Originate?

After identifying the region from which each network attack originated, we discovered that the majority of them seem to originate from the United States, followed by France and then Germany. Attacks from Vietnam decreased significantly this quarter. That may be because almost all attacks from Vietnam last quarter were against CVE-2021-35394, and the attacker stopped or changed attack source location this quarter.

We recognize that attackers might leverage proxy servers and VPNs located in those countries to hide their actual physical locations.

Figure 20 is a chart showing the percentage by country of attack origins from November 2022 to January 2023. The highest is the United States at 74.4%. The second highest is others at 8.9%.
Figure 20. Locations ranked in terms of how frequently they were the origin of observed attacks from November 2022-January 2023.
Figure 21 is a column chart showing the CVE attack origin distribution compared to the previous quarter, where the United States has increased by 22.66%.
Figure 21. Attack origination comparison between August 2022-October 2022 and November 2022-January 2023.

It is worth noting that Luxembourg and Switzerland, where there were not many attacks last quarter, saw a lot of attacks in this quarter. Let’s look more closely at the attacks from these two places.

There were about 31,000 attacks originating from Luxembourg in November 2022, which is a relatively high level. From December 2022-January 2023, the number of attacks from Luxembourg rose from about 2.2 million to 5.8 million, showing a rapid growth rate.

Unlike Luxembourg, attacks originating from Switzerland were at about 2.1 million and 1.2 million in November and December 2022, respectively, and then they dropped sharply to about 730,000 in January 2023.

We also observed that in this quarter, among all the attacks from Luxembourg, the number of attacks targeting CVE-2021-35394 reached 7.77 million. This accounted for 96% of the total number of attacks from Luxembourg.

About 1.9 million attacks from Switzerland were aimed at the Code Execution of Netis/Netcore Router vulnerability. This accounted for 45% of their total attacks.

From this evidence, we can conclude that the current attacks on hardware devices, especially network devices, are very active.

Figure 22 is a heat map of the attack geolocation distraction from November 2022 to January 2023. The darkest area of the map is the United States.
Figure 22. Attack geolocation distribution from November 2022-January 2023.

Conclusion

The vulnerabilities disclosed from November 2022-January 2023 indicate that web applications remain popular targets for attackers, and that Critical vulnerabilities are more likely to have PoCs publicly available.

In the meantime, we continue to capture newly published vulnerabilities that are exploited in the wild. This emphasizes the need for organizations to promptly patch their systems and implement security best practices. Attackers continue to make a concerted effort to expand their tool kit of exploits whenever possible.

While cybercriminals will never cease their malicious activities, Palo Alto Networks customers receive protections from the attacks discussed in this blog through the Next-Generation Firewall and Cloud-Delivered Security Services, including Threat Prevention, WildFire and Advanced URL Filtering, as well as through Cortex XDR. Prisma Cloud customers using WAAS are protected from such threats through the App Firewall feature, which detects attacks such as cross-site scripting, SQL injection, directory traversals and more.

To further mitigate any risks to your network:

  • Run a Best Practice Assessment to identify where your configuration could be altered to improve your security posture.
  • Run a Security Lifecycle Review to get a consolidated view of your largest threats and if you have coverage to prevent them.
  • Continuously update your Next-Generation Firewalls with the latest Palo Alto Networks Threat Prevention content (e.g., versions 8686 and above).

Additional Resources

 

Recent Trends in Internet Threats: Common Industries Impersonated in Phishing Attacks, Web Skimmer Analysis and More

Posted on by Cecilia Hu

Executive Summary

From July-December 2022, Unit 42 researchers have observed and analyzed over 67 million unique malicious URLs, domains and IPs, which we use to block associated malicious network traffic. We will cover the trends we have observed during the second half of 2022 based on our detections of malicious URLs, domains and IPs.

We present our analysis and findings of these internet threat trends, including the following information:

  • A view of the internet threat landscape
    • This includes malicious URL distribution, geolocation, category analysis and statistics describing attempted malware attacks that we observe
  • A spotlight on internet threats of particular interest
    • This includes industry sectors being targeted for spoofing in phishing pages, as well as downloaded malware statistics, injected JavaScript (JS) malware analysis and malicious DNS analysis
  • A case study of a classic web skimmer that infected a Tranco top 1 million-rated website

Palo Alto Networks customers receive protections from the web and DNS threats discussed here via the Advanced URL Filtering, DNS Security and Advanced Threat Prevention Cloud-Delivered Security Services.

Related Unit 42 Topics Web threats, Phishing, Cryptomining

Internet Threat Landscape

During the second half of 2022 (H2), we amassed over 67 million malicious domains and URLs, an increase of over 52% over the first half of 2022 (H1). These malicious domains and URLs have a broad impact on their victims. We observed over 12 million HTTP requests to some of these malicious URLs and over 60 million DNS requests to these domains every day. These malicious URLs are collected from third-party feeds as well as our own internal analyzers. These analyzers include a variety of types including web crawlers, malware traffic analyzers and deep learning models.

Looking more closely at malicious JavaScript samples as an example, during the second half of 2022, we detected over 4 million malicious JS samples hosted on 4.8 million malicious URLs and 1.6 million hostnames. Compared to the first half of the year, the total number of URLs containing malicious JavaScripts increased by 99.3%.

Image 1 is a column graph, showing the percentage of URLs compared to host names, in millions, for the first half to the second half of 2022. There is a much larger number of unique URLs in the second half of 2022 compared to the first half. In the second half of 2022, the first half and second half measurements are more equal.
Figure 1. The number of malicious JS and their hosting URLs and hostnames.

Malicious URL and Domain Distribution

Figure 2 shows the number of newly observed malicious URLs each quarter. Compared to H1 2022, the number of malicious URLs in H2 increased by 52%. For the grayware and command-and-control (C2) categories, even though the number of observed URLs dropped in Q4, the total increase in H2 is still 80% and 165%, respectively, when compared to H1.

Image 2 is a column chart showing the amount (in log scale) of newly observed malicious URLs from quarter 1 to quarter 4 in 2022. It compares malware, phishing, grayware, and command and control over these four quarters. The largest numbers are malware and the smallest are C2.
Figure 2. Number of newly observed malicious URLs from Q1 to Q4 2022.

Figure 3 shows the number of new malicious domains in each month from July-December 2022. Note that for the monthly numbers for the grayware and C2 categories, the number of detections are distributed less evenly than the other categories, mainly because they are more related to specific attack campaigns.

For example, one of the main sources of URLs in the grayware category is from detected clusters of malicious domains belonging to the same campaign at their registration time. More details of this detection logic are presented in Detecting and Preventing Malicious Domains Proactively with DNS Security.

Image 3 is a column chart comparing the number of malicious domains observed from July to December 2022. Like figure 2, the largest percentage is malware, and the smallest is C2.
Figure 3. The number of malicious domains observed from July-December 2022.

Geolocation Analysis of Malicious URLs

By looking at passive DNS data and an IP to location database, we can retrieve the IPs where the domains hosting the malicious URLs are located. Figures 4 and 5 below show the geolocation distribution of the domains hosting malicious URLs worldwide.

A heatmap showing the distribution of
Figure 4. Geolocation distribution of domains (in millions) hosting malicious URLs during July-December 2022.

Although malicious websites are hosted in more than 150 countries and regions, over 85% are hosted in the top eight countries, as shown in Figure 5.

Similar to what we observed in Q1 2022 and Q2 2022, the majority of all malicious URLs and domains continue to be hosted in the United States. During the second half of 2022, the next most common hosting locations were Brazil and China.

Image 5 is a pie chart of the top eight countries for malicious URLs hosted during July to December 2022. The largest percentage is the United States at 51.8%, followed by Brazil, China, and Germany.
Figure 5. Top eight countries hosting malicious URLs during July-December 2022.

Category Analysis

We also analyzed the distribution of the original content categories of the malicious URLs and domains we amassed. In other words, we determined what they were intended for before they were used for malicious purposes or were otherwise detected as malicious. This analysis aims to find the common targets for these cyberattacks and how they might be trying to fool people.

Figure 6 shows the distribution of the original categories for the malicious URLs in Advanced URL Filtering. Unsurprisingly, URLs with the original categories Insufficient Content and Newly Registered Domains make up over 30% of all malicious URLs. We classify a URL as Insufficient Content when it does not host enough content for classification. In both cases, this result makes sense as, after an attacker registers a domain, it will likely fall into these two categories before the URL starts serving content for malicious purposes.

Image 6 is a pie chart of the categories of the URLs before they were identified as malicious during July through December 2022. The largest percentage is “others,” at 28.5%, followed by insufficient content, at 23.6%, and then newly registered domains, at 17.1%. The fourth largest was computer/Internet, at 12.2%.
Figure 6. Categories of the URLs before they are identified as malicious during July-December 2022.

Impact of Malicious URLs and Domains

Not all the malicious domains and URLs we detected and collected were actively resolved or visited by victims, as threat actors can make them short-lived by design, or they can be blocked by other security products. Figures 7 and 8 below present the number of URLs and domains visited or resolved during the last three months of 2022.

Unique domains/URLs indicate the number of malicious domains and URLs visited at least once. Sessions indicate the number of DNS and HTTP sessions to these blocked malicious domains and URLs.

These statistics represent the impact of all the malicious URLs and domains. We calculated these numbers based on lookups from the Palo Alto Networks firewall to the Advanced URL Filtering and DNS cloud. Due to the cache on the firewall, the absolute number could be higher. All these domains and URLs were blocked when visited by Palo Alto Networks customers.

Figure 7 below shows the number of malicious URLs visited and how many times these malicious URLs were visited in total. From October-December 2022, the number of malicious URLs visited at least once increased 8.7% monthly. In total, the number of times victims visited these URLs increased 11.5% each month.

Image 7 is a column chart, comparing malicious HTTP and HTTPS URL sessions from October through December 2022. The number of sessions is much higher than that of unique URLs in each month. The largest number of sessions is in December 2022 at 407 million.
Figure 7. Malicious HTTP/HTTPs URL sessions during October-December 2022.

Figure 8 shows the number of malicious domains resolved and how many times these malicious domains were resolved. From October to December 2022, we saw the number of malicious domains that were resolved at least once increased 4.5% monthly. In total, the number of times potential victims resolved these domains increased 4.4% each month.

On average, users visited each malicious URL ten times, while each domain was resolved 28 times. We would expect a domain to be resolved more frequently than a URL visited by potential victims. This could be because an attacker launched a campaign with different URL parameters for different targets, even though the domains are the same.

Image 8 is a column chart comparing malicious DNS sessions from October through December 2022. Sessions are the largest amount, in the billions for each month, compared to the unique domains, which are only in the tens of millions each month.
Figure 8. Malicious DNS sessions October-December 2022.

Internet Threats Highlights

Phishing Attacks

In Figure 9 below, we present the changes in industry sectors impersonated in phishing attacks between Q2, Q3 and Q4. In general, the following types of sites were the most popular sectors to target for spoofing, across all three quarters:

  • Online document and storage
  • Internet portals and web mail
  • Financial services sites

Compared to Q2, during Q3 and Q4 we observed an increase of phishing attacks disguising themselves as online document and storage platforms, from 27.8% to over 38.1%. During the same time period, fake online shopping and marketplace sites became more popular as sources of phishing campaigns.

Image 9 shows the changes in the distribution of phishing masquerading as target sectors in quarters 2, 3 and 4 of 2022. The largest sector is online document and storage, as well as financial services for quarter 2. The three least affected sectors are streaming on the Internet services, insurance, and payroll and taxes.
Figure 9. Changes in the distribution of phishing target sectors in Q2, as well as Q3 and Q4 2022.

During the second half of 2022, phishing attacks used more advanced techniques to bypass the detection of crawlers or to bypass advanced authentications. For example, we observed increased abuse of legitimate SaaS platforms to host phishing pages. There was also an increasing trend of CAPTCHA-protected phishing pages. Meddler-in-the-middle phishing attacks were also used to bypass two-factor authentication.

Detected Malicious Files

During the second half of 2022, we detected 2.7 million URLs that distributed 1.9 million malicious files. Among those malware-downloading URLs, we found malicious campaigns that distributed a large number of malicious PDF files. Among all the detected file types, PDF was by far the most common (96.0%), followed by Windows PE – including both EXE and DLL files – (1.8%) and archive files (1.6%).

Figure 10 reports the top five most common VirusTotal family names for downloaded malicious PDF files. These families, with names such as PDF.Spam.Heur.1 and Trojan.PDF.Phishing, are heuristic or generic detection names associated with the distribution of malicious content through deceptive strategies.

Image 10 is a column chart showing the distribution of the top VirusTotal family names of PDF files that were dowloaded.
Figure 10. Distribution of the top families that download malicious PDFs.

For instance, one of these PDF files uses a deceptive CAPTCHA button to convince the user to click it. Upon clicking, the user could be redirected through random websites before reaching the final destination page that hosts malicious content (such as fake browser extensions and fake antivirus).

Injected JS Malware Analysis

Malware Class Analysis

The top five injected JS malware classes in the last half of 2022 are downloaders, web skimmers, cryptominers, redirectors and web scams. For the definition of these classes, please refer to our analysis blog, The Year in Web Threats: Web Skimmers Take Advantage of Cloud Hosting and More.

As shown in Figure 11, JS downloader threats showed the most activity, followed by web skimmers and web miners (aka cryptominers).

Image 11 is a column chart comparing the top five web threat categories from July to December 2022. JS_downloader is the largest at over 2.2 million. All hits is much larger number than unique hits in each instance.
Figure 11: Top five web threats category distribution during July-December 2022.

Malware Family Analysis

Based on our classification of injected JS malware explained in the previous section, we further organized our set by malware family.

The malware family classification is important to understand how the malware works. Injected JS malware in the same family share similar code even if the HTML landing pages where they appear have different layouts and styles.

As we did in our analysis blog mentioned above, we identified pieces of malware as part of a family by checking for certain characteristics: similar code patterns or behaviors, or having originated from the same attacker.

Figure 12 shows the number of similar snippets observed for the top 10 injected JS malware families we identified. As we’ve seen previously, there were fewer families of redirectors, web scams and downloaders, while web skimmers show more diversity in code and behavior.

Image 12 is a column chart comparing the web threat malware family distribution from July through December 2022. All hits is the greatest amount compared to unique hits in each instance.
Figure 12. Web threat malware family distribution July-December 2022.

Malicious DNS Analysis

While attackers still prefer registering their own domains for malicious activities, we observe that a nontrivial number of malicious domains (4.8%) are the subdomains of well-known web hosting services. These malicious subdomains inherit the reputation of the web hosting services and thus make it more difficult for both victims and security analysts to determine their true intentions. Among all the web hosting services that attackers abused, two popular web hosting services account for around 70% of all the malicious web hosting subdomains.

Internet Threats Case Study

We discovered a web skimmer that infected an active motor retail website, ranking in the Tranco 1 million, which is a research-oriented top sites ranking list. On this motor retail website, we can see the malicious JS code (motor.js) injected in almost every page that contains sensitive information (e.g., login page, shopping cart page). The objective is to steal the customer’s information. This information includes username, login password and payment information, as shown in Figures 13 and 14.

Image 13 is a screenshot of malicious JavaScript code, motor.js, of the infected login page. It shows a username, login, password, and payment information. It contains identifying information that has been redacted.
Figure 13. Screenshot of the infected login page.
Image 14 is a screenshot of malicious JavaScript code of the infected shopping cart page. It shows the author, region, and description. It contains identifying information that has been redacted.
Figure 14. Screenshot of the infected shopping cart page.

We can see all those pages contain the same JS file named motor.js located in a malicious domain that delivered malware before, as shown in Figure 15.

Image 15 is a screenshot of VirusTotal of personallydelivered.com. It shows that three security vendors flagged the URL as malicious. There are tabs for detection, details, relations, telemetry, and community. The URL is categorized as shopping.
Figure 15. VirusTotal screenshot of personallydeliver[.]com.
The original web skimmer in motor.js is not straightforward, as shown in Figure 16.

Image 16 is a screenshot of many lines of code. It is the source code of motor.js
Figure 16. A screenshot of the source code of personallydeliver.com/motor[.]js.
After deobfuscating the JS code in motor.js and taking a closer look at this skimmer, we can see the code uses

var1 == var2 ? statement1: statement2

This structure is meant as a trick to slow analysis by researchers, combined with obfuscation in the code itself. Let’s look at this code logic in more detail.

As shown in Figure 17, we can see there are two main functions. One is function HraHMoYftE() and the other one is function XGSsWznnKh(). For function HraHMoYftE(), it tries to get the victim’s input from the website page through fields including input, select and textarea.

After they collect this kind of sensitive information, the function HraHMoYftE() will pass the sensitive information to the function XGSsWznnKh(). This latter function mainly stores the sensitive information in an array and sends information transformed into a string to the malicious server hosted by attackers, with the img.src method shown in Figure 17.

Image 17 is a screenshot of the deobfuscated motor.js JavaScript code. It shows the two main functions. The first passes along sensitive information, and the second sends the stored information to a malicious server hosted by the attackers.
Figure 17. Two main functions of the deobfuscated code of personallydeliver.com/motor[.]js.

Conclusion

We have tracked and presented the internet security trends for H2 of 2022, including malicious URL category analysis and geolocation analysis.

In particular, we found that in the second half of 2022, attackers more commonly impersonated the following types of businesses and services:

  • Cloud-based documents
  • Cloud storage services
  • Online shopping websites

For malicious websites, malicious PDFs are still the predominant type of downloaded malicious files. JS downloaders and web skimmers are the most popular injected malicious JS.

We also observed that a nontrivial number of malicious domains are subdomains of well-known web hosting services. In addition, we shared the case study of a web skimmer that infected a retail website in Tranco’s top 1 million.

To protect your systems against the threats discussed in this post, we recommend the following actions:

Indicators of Compromise

  • motor[.]js
  • eaadde9a724180a0318c13a9399ec30bda7a3ec6399ff43b8b7207bf0e74332b

URL hosting the malicious javascript

  • personallydeliver[.]com/motor[.]js

Collection server

  • personallydeliver[.]com/gatemotor[.]php

 

Chinese Alloy Taurus Updates PingPull Malware

Posted on by Unit 42

Executive Summary

Unit 42 researchers recently identified a new variant of PingPull malware used by Alloy Taurus actors designed to target Linux systems. While following the infrastructure leveraged by the actor for this PingPull variant, we also identified their use of another backdoor we track as Sword2033.

The first samples of PingPull malware date back to September 2021. Monitoring its use across several campaigns, in June 2022 Unit 42 published research outlining the functionality of PingPull and attributed the use of the tool to Alloy Taurus.

Operating since at least 2012, Alloy Taurus (aka GALLIUM, Softcell) is assessed to be a Chinese advanced persistent threat (APT) group that routinely conducts cyberespionage campaigns. This group has historically targeted telecommunications companies operating across Asia, Europe and Africa. In recent years we have also observed the group expand their targeting to include financial institutions and government entities.

We provide a detailed breakdown of the following:

  • A new variant of PingPull
  • Sword2033 samples linked to the same command and control (C2) infrastructure
  • Recent activity by Alloy Taurus in South Africa and Nepal

Palo Alto Networks customers receive protections from the threats described in this blog through Cortex XDR and WildFire malware analysis. The Advanced URL Filtering and DNS Security Cloud-Delivered Security Services can help protect against C2 infrastructure.

Related Unit 42 Topics Alloy Taurus, PingPull

PingPull Linux Variant

On March 7, 2023, the following sample was uploaded to VirusTotal.

Filename nztloader
Filetype ELF
SHA256 cb0922d8b130504bf9a3078743294791201789c5a3d7bc0369afd096ea15f0ae

Table 1. PingPull sample file details.

At the time of writing, three out of 62 vendors found the sample to be malicious. Despite a largely benign verdict, additional analysis has determined that this sample is a Linux variant of PingPull malware. This determination was made based on matching HTTP communication structure, POST parameters, AES key, and C2 commands, which are outlined below.

Upon execution, this sample is configured to communicate with the domain yrhsywu2009.zapto[.]org over port 8443 for C2. It uses a statically linked OpenSSL (OpenSSL 0.9.8e) library to interact with the domain over HTTPS via the following HTTP POST request:

Image 1 is the HTTP post request for the PingPull Linux variant. It includes the content type, user agent, host, content, length, and cache control.
Figure 1. PingPull Linux variant POST request.

The payload then expects the C2 server to respond with data that is Base64 encoded ciphertext, encrypted with AES using P29456789A1234sS as the key. This is the same key that we previously observed in the original Windows PE variant of PingPull.

Once decoded, the cleartext resembles HTTP parameters and the payload will parse the cleartext for & and = with the following parameters:

Image 2 a screenshot of the PingPull HTTP parameters.
Figure 2. PingPull HTTP parameters.

The value in the P29456789A1234sS parameter will contain a single upper case character between A and K, as well as M, which the payload will use as the command value. The values in the z0, z1 and z2 parameters are used for the arguments passed to the command.

After running the command, the payload will send the results back to the C2 server via an HTTPS request that resembles the beacon request, but contains Base64 encoded ciphertext. The command handler supports the following functionality that aligns with both China Chopper capabilities and those observed in the PingPull Windows PE variant:

Cmd Description
A Get the current directory
B List folder
C Read text file
D Write text file
E Delete file or folder
F Read binary file, convert to hex
G Write binary file, convert to hex
H Copy file or folder
I Rename file
J Create Directory
K Timestomp file with specified timestamp in "%04d-%d-%d %d:%d:%d" format
M Run command

Table 2. PingPull command handler functionality.

Of note, the HTTP parameters z0, z1 and z2 and command handlers A-K, M also align to commands A-K, M observed in the web shell China Chopper. This suggests that Alloy Taurus is using code they might be familiar with, and they are integrating it into the development of custom tooling.

Sword2033 Backdoor

Pivoting on the C2 domain, we identified one additional sample that also communicated with yrhsywu2009.zapto[.]org:

Sword2033 Sample 1
Filename zimbra
Filetype ELF
SHA256 5ba043c074818fdd06ae1d3939ddfe7d3d35bab5d53445bc1f2f689859a87507

Table 3. Related Sword2033 sample file details.

Similar to the PingPull variant above, this sample was designed to connect to port 8443 over HTTPS. However, analysis of the sample revealed that it’s a simple backdoor that we track as Sword2033. This backdoor supports three basic functions:

Cmd Description
#up Uploads a file to the system
#dn Downloads a file from the system
exc /c: Executes a command, but appends ;echo <random number>\n before running it

Table 4. Sword2033 command handler functionality.

These three commands map to commands in a second command handler that uses A, C, D and M commands, which are identical in value and functionality with the PingPull commands identified in Table 2 above.

Searching for other recent samples of Sword2033, we identified a second sample:

Sword2033 Sample 2
Filename Hopke
Filetype ELF
SHA256 e39b5c32ab255ad284ae6d4dae8b4888300d4b5df23157404d9c8be3f95b3253

Table 5. Additional Sword2033 sample file details.

This sample was seen in July 2022. Analysis of this sample revealed that it’s configured to connect to 196.216.136[.]139, located in South Africa, for C2.

Infrastructure Analysis

Analysis of the C2 domain yrhsywu2009.zapto[.]org found in the PingPull Linux variant and the first Sword2033 sample shows it was most recently hosted on 5.181.25[.]99 until early February 2023. However, a historical review of its hosting revealed that this domain resolved to 45.251.241[.]82 for a single day in April 2022. This IP was outlined as an active indicator of compromise (IoC) in our June 2022 report, thereby drawing a clear link to Alloy Taurus activities.

Analysis of the C2 for the second Sword2033 sample (Hopke, referenced in Table 5) found that the domain *.saspecialforces.co[.]za resolved to 196.216.136[.]139. This domain has been hosted on eight other IPs throughout its history with various mail-related subdomains.

None of these IPs appear to have any affiliation with the South African government, but the domain name gives the impression of a connection to the South African military. The establishment of a C2 server that appears to impersonate the South African military is uniquely notable when analyzed in the context of recent events. In February 2023, South Africa joined Russia and China to participate in combined naval exercises.

Additionally, 196.216.136[.]139 resolved to vpn729380678.softether[.]net from late December 2022 through mid-February 2023. Alloy Taurus is known for leveraging the SoftEther VPN service in their operations to facilitate access and maintain persistence to their targeted network.

Threat actors often abuse, take advantage of or subvert legitimate products like SoftEther VPN for malicious purposes. This does not necessarily imply a flaw or malicious quality to the legitimate product being abused.

Image 3 is a diagram of the infrastructure of PingPull/Sword2033 including samples 1 and 2 of Sword2033.
Figure 3. PingPull/Sword2033 infrastructure visualization.

Reviewing traffic to the Sword2033 C2 server 196.216.136[.]139, we identified sustained connections originating from an IP that hosts several subdomains for an organization that finances long-term urban infrastructure development projects in Nepal.

Conclusion

Alloy Taurus remains an active threat to telecommunications, finance and government organizations across Southeast Asia, Europe and Africa. The identification of a Linux variant of PingPull malware, as well as recent use of the Sword2033 backdoor, suggests that the group continues to evolve their operations in support of their espionage activities. We encourage all organizations to leverage our findings to inform the deployment of protective measures to defend against this threat group.

Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Protections and Mitigations

In order to defend against the threats described in this blog, Palo Alto Networks recommends organizations employ the following capabilities:

  • Network Security: Delivered through a Next-Generation Firewall (NGFW) configured with machine learning enabled, and best-in-class, cloud-delivered security services. This includes, for example, threat prevention, URL filtering, DNS security and a malware prevention engine capable of identifying and blocking malicious samples and infrastructure.
  • Endpoint Security: Delivered through an XDR solution that is capable of identifying malicious code through the use of advanced machine learning and behavioral analytics. This solution should be configured to act on and block threats in real time as they are identified.
  • Security Automation: Delivered through an XSOAR or XSIAM solution capable of providing SOC analysts with a comprehensive understanding of the threat derived by stitching together data obtained from endpoints, network, cloud and identity systems.

Specific Product Protections and Mitigations

For Palo Alto Networks customers, our products and services provide the following coverage associated with this group:

  • WildFire cloud-based threat analysis service accurately identifies the malware described in this blog as malicious.
  • Advanced URL Filtering and DNS Security identify domains associated with Alloy Taurus as malicious.
  • Cortex XDR prevents the execution of known malware samples as malicious. Behavioral threat protection covers this activity starting from content version 930.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Indicators of Compromise

PingPull Linux Variant

  • cb0922d8b130504bf9a3078743294791201789c5a3d7bc0369afd096ea15f0ae

Sword2033

  • 5ba043c074818fdd06ae1d3939ddfe7d3d35bab5d53445bc1f2f689859a87507
  • e39b5c32ab255ad284ae6d4dae8b4888300d4b5df23157404d9c8be3f95b3253

Alloy Taurus Infrastructure

  • yrhsywu2009.zapto[.]org
  • *.saspecialforces.co[.]za
  • vpn729380678.softether[.]net
  • 5.181.25[.]99
  • 196.216.136[.]139

Additional Resources

Updated May 10, 2023, at 12:02 p.m. PT to expand on Cortex XDR protections. 

ChatGPT-Themed Scam Attacks Are on the Rise

Posted on by Zhanhao Chen

Executive Summary

Unit 42 researchers are monitoring the trending topics, newly registered domains and squatting domains related to ChatGPT, as it is one of the fastest-growing consumer applications in history. The dark side of this popularity is that ChatGPT is also attracting the attention of scammers seeking to benefit from using wording and domain names that appear related to the site.

Between November 2022 through early April 2023, we noticed a 910% increase in monthly registrations for domains related to ChatGPT. In this same time frame, we observed a 17,818% growth of related squatting domains from DNS Security logs. We also saw up to 118 daily detections of ChatGPT-related malicious URLs captured from the traffic seen in our Advanced URL Filtering system.

We now present several case studies to illustrate the various methods scammers use to entice users into downloading malware or sharing sensitive information. As OpenAI released its official API for ChatGPT on March 1, 2023, we’ve seen an increasing number of suspicious products using it. Thus, we highlight the potential dangers of using copycat chatbots, in order to encourage ChatGPT users to approach such chatbots with a defensive mindset.

Palo Alto Networks Next-Generation Firewall and Prisma Access customers with Advanced URL Filtering, DNS Security and WildFire subscriptions receive protections against ChatGPT-related scams. All mentioned malicious indicators (domains, IPs, URLs and hashes) are covered by these security services.

Related Unit 42 Topics Phishing, Cybersquatting

Trends in ChatGPT-Themed Suspicious Activities

While OpenAI was beginning its rapid rise to become one of the most famous brands in the field of artificial intelligence, we observed several instances of threat actors registering and using squatting domains in the wild that use “openai” and “chatgpt” as their domain name (e.g., openai[.]us, openai[.]xyz and chatgpt[.]jobs). Most of these domains are not hosting anything malicious as of early April 2023, but it is concerning that they are not controlled by OpenAI, or other authentic domain management companies. They could be abused to cause damage at any time.

Figure 1 shows the trend of squatting domain registration related to ChatGPT, after its release. We noticed a significant increase in the volume of daily domain registrations during our research period. Shortly after Microsoft announced their new Bing version on Feb. 7, 2023, more than 300 domains related to ChatGPT were registered.

Image 1 is a chart showing the amount of ChatGPT domain squatting over time. It starts 1 December 2022, and extends through 1 April 2023. The sharpest increase was over 300 with the new Bing release in February 2023.
Figure 1. Trend of ChatGPT squatting domain registration.

Figure 2 shows a similar pattern where the recognition and popularity of ChatGPT have resulted in a significant rise in logs from the DNS Security product.

Image 2 is a chart of the number of DNS requests of ChatGPT domain squatting over time. It starts December 1, 2022 and continues until April 1, 2023. There is a sharp increase in March 2023 with the public API release, and then another bump of activity with the ChatGPT 4 release.
Figure 2. DNS traffic trend of ChatGPT squatting domains.

We also did a keyword search in the traffic of the Advanced URL Filtering system. Figure 3 shows two large spikes on the day when OpenAI released the ChatGPT official API and GPT-4.

Image 3 is a chart of the number of detections of ChatGPT as a keyword. There are two large spikes in March 2023, and another later in March for the ChatGPT 4 release.
Figure 3. Trend of malicious detections with “ChatGPT” keyword.

Case Studies of ChatGPT Scams

While conducting our research, we observed multiple phishing URLs attempting to impersonate official OpenAI sites. Typically, scammers create a fake website that closely mimics the appearance of the ChatGPT official website, then trick users into downloading malware or sharing sensitive information.

For example, Figure 4 shows a common technique that scammers use to deliver malware. It presents users with a “DOWNLOAD FOR WINDOWS” button that, once clicked, downloads the Trojan malware (SHA256: ab68a3d42cb0f6f93f14e2551cac7fb1451a49bc876d3c1204ad53357ebf745f) to their devices without the victims realizing the risk.

Image 4 is a screenshot of a website mimicking the official ChatGPT website. This website will deliver malware to the enduser.
Figure 4. Malware delivery: chat-gpt-online-pc[.]com.
Additionally, scammers might use ChatGPT-related social engineering for identity theft or financial fraud. Despite OpenAI giving users a free version of ChatGPT, scammers lead victims to fraudulent websites, claiming they need to pay for these services. For instance, as shown in Figure 5, the fake ChatGPT site tries to lure victims into providing their confidential information, such as credit card details and email address.

Image 5 is a screenshot of an example of cryptocurrency fraud, where a threat actor is attempting to collect confidential information through an online payment form. The screenshot shows the online payment form as well as a URL that mimics ChatGPT.
Figure 5. Financial fraud: pay[.]chatgpt-oracle[.]com.
We also noticed some scammers are exploiting the growing popularity of OpenAI for crypto frauds. Figure 6 shows an example of a scammer abusing the OpenAI logo and Elon Musk’s name to attract victims to this fraudulent crypto giveaway event.

Image 6 is a screenshot of a cryptocurrency scam that mimics the OpenAI website. It has a picture of Elon Musk with the title “biggest giveaway crypto of $100 million.” There's a button for endusers to participate as well as instructions for participation.
Figure 6. Crypto scam: x2chatgpt[.]org.

The Risks of Copycat Chatbots

While ChatGPT has become one of the most popular applications this year, an increasing number of copycat AI chatbot applications have also appeared on the market. Some of these applications offer their own large language models, and others claim that they offer ChatGPT services through the public API that was announced on March 1. However, the use of copycat chat bots could increase security risks.

Before the release of the ChatGPT API, there were several open-source projects that allowed users to connect to ChatGPT via various automation tools. Given the fact that ChatGPT is not accessible in certain countries or regions, websites created with these automation tools or the API could attract a considerable number of users from these areas. This also provides threat actors the opportunity to monetize ChatGPT by proxying their service. For example, Figures 7a and 7b below show a Chinese website providing paid chatbot service.

Image 7a is a screenshot of a chatbot service. It is in Chinese.
Figure 7a. Paid chatbot service (in Chinese): chatgpt[.]appleshop[.]top.
Image 7b is a screenshot of a chatbot service. It has been translated from Chinese to English.
Figure 7b. Paid chatbot service (translated from Chinese to English): chatgpt[.]appleshop[.]top.
Whether or not they’re offered free of charge, these copycat chatbots are not trustworthy. Many of them are actually based on GPT-3 (released June 2020), which is less powerful than the recent GPT-4 and GPT-3.5.

Moreover, there is another significant risk of using these chatbots. They might collect and steal the input you provide. In other words, providing anything sensitive or confidential could put you in danger. The chatbot’s responses could also be manipulated to give you incorrect answers or misleading information.

For example, as shown in Figure 8, the squatting domain chatgptforchrome[.]com hosts an introduction page for the ChatGPT Chrome Extension. It uses the information and video from the official OpenAI extension.

The “Add to Chrome” link leads to a different extension URL chrome[.]google[.]com/webstore/detail/ai-chatgpt/boofekcjiojcpcehaldjhjfhcienopme, while the authentic URL should be chrome[.]google[.]com/webstore/detail/chatgpt-chrome-extension/cdjifpfganmhoojfclednjdnnpooaojb.

We downloaded the “AI ChatGPT” extension shown in Figure 8 (SHA256: 94a064bf46e26aafe2accb2bf490916a27eba5ba49e253d1afd1257188b05600) and found that it adds a background script to the victims’ browser, which contains a highly obfuscated JavaScript. Our analysis of this JavaScript shows that it calls the Facebook Graph API to steal a victim's account details, and it might get further access to their Facebook account. Other researchers have also reported similar campaigns involving malicious browser extensions.

Image 8 as a screenshot of a ChatGPT extension for Google. This browser extension is meant to steal account details. It says that ChatGPT will “response alongside search engine results,” list, the browsers that it works with, gives star ratings and says that it's trusted by 600,000+ users. There is a button to add it to Google Chrome. There's also a screenshot of a YouTube video.
Figure 8. ChatGPT extension: chatgptforchrome[.]com.

Conclusion

The growing popularity of ChatGPT worldwide has made it a target for scammers. We have noticed a significant increase in the number of newly registered domains and squatting domains related to ChatGPT, which could potentially be exploited by scammers for malicious purposes.

To stay safe, ChatGPT users should exercise caution with suspicious emails or links related to ChatGPT. Moreover, the usage of copycat chatbots will bring extra security risks. Users should always access ChatGPT through the official OpenAI website.

Palo Alto Networks Next-Generation Firewall and Prisma Access customers with Advanced URL Filtering, DNS Security and WildFire subscriptions are protected against ChatGPT-related scams. All the mentioned malicious indicators (domains, IPs, URLs and hashes) are covered by these security services.

Acknowledgments

The authors would like to thank Nabeel Mohamed, Shehroze Farooqi and Shresta Bellary Seetharam for providing data sources and examples used in this blog. We would also like to thank Jun Javier Wang, Alex Starov, Harsha Srinath, Laura Novak, Daniel Prizmant and Erica Naone for their advice and help with improving the blog.

Indicators of Compromise

Squatting Domains

  • openai[.]us
  • openai[.]xyz
  • chatgpt[.]jobs

ChatGPT Scams

  • chat-gpt-online-pc[.]com
  • ab68a3d42cb0f6f93f14e2551cac7fb1451a49bc876d3c1204ad53357ebf745f
  • pay[.]chatgpt-oracle[.]com
  • x2chatgpt[.]org

ChatBot

  • chatgpt[.]appleshop[.]top

Chrome Extensions

  • chatgptforchrome[.]com
  • chrome[.]google[.]com/webstore/detail/ai-chatgpt/boofekcjiojcpcehaldjhjfhcienopme
  • 94a064bf46e26aafe2accb2bf490916a27eba5ba49e253d1afd1257188b05600

Threat Actors Rapidly Adopt Web3 IPFS Technology

Posted on by Samantha Stallings

Executive Summary

During 2022, analysts from Unit 42 observed the rampant adoption of the InterPlanetary File System (aka IPFS) being used as a vehicle for malicious intent. IPFS is a Web3 technology that decentralizes and distributes the storage of files and other data into a peer-to-peer network.

Like any technology, IPFS can be abused by malicious threat actors. However, because the hosted content on IPFS is decentralized and distributed, there are challenges in locating and removing malicious content from the ecosystem, making it akin to bullet-proof hosting.

From the last quarter of 2021 through the end of the last quarter of 2022, Palo Alto Networks detected an 893% increase in IPFS-related traffic. Our calculations also show that VirusTotal reported over 27,000% increase during the same period.

This increase in IPFS-related traffic is rife with notable increases in malicious activity, as can be expected. Analysts from Unit 42 observed numerous threat campaigns in 2022 that covered the gamut of phishing, credential theft, malicious payload distribution and general adoption by threat actors.

Some of the key takeaways from our analysis include the following:

  • There was a significant jump in IPFS-related traffic at the beginning of 2022. Palo Alto Networks detected a 178% increase in IPFS-related traffic from the last quarter of 2021 to the first quarter of 2022, while VirusTotal reported more than 6,500% increase during that same reporting period.
  • We have identified threat actors discussing the adoption of the technology on forums in the dark web as well as threat actors selling services hosted on IPFS.
  • We have seen several types of cyberthreats using IPFS, including phishing, credential theft, command and control (C2) communications, and malicious payload distribution.

Palo Alto Networks customers receive protections from the malware families discussed as well as their malicious components in the following ways:

Related Unit 42 Topics Phishing

What Are Web3 and IPFS?

Before we delve into our observations around threat actor behavior associated with IPFS, it is important to have a general understanding of Web3 and also IPFS. IPFS is one of the technologies that supports Web3 infrastructures.

Web3 – or the third iteration of the web – is a new version of the internet that prioritizes decentralization using blockchain technology and tokens. With Web3, users can safeguard their data against censorship and manipulation without the need for a central authority.

This decentralization allows individuals to have ownership and control over their own content, which can be posted without fear of governments or tech companies removing it. However, cybercriminals can also exploit these same benefits to further their malicious activities.

IPFS is a distributed file sharing system that was released in 2015. It is open source and uses a peer-to-peer (P2P) hypermedia protocol, making the internet faster, safer and more open.

Unlike the traditional web, IPFS is content-oriented and searches for content identifiers in the form of hashes through a decentralized network, rather than specific locations. Content on IPFS can be accessed by establishing your own node on the IPFS network or using IPFS gateways, which are third-party web-based interfaces between the web and the IPFS network. IPFS is available through any IPFS gateway, and is not gateway-specific. These gateways allow users to view and pull content through HTTP requests, but they cannot alter or add to the content.

More information about Web3 and IPFS can be found at the following sites:

Increase in Overall Traffic

Despite its relative obscurity, we observed a notable increase in IPFS traffic across Palo Alto Networks starting the first quarter of 2022, as seen in Figure 1. In the first quarter of 2022, our products detected a 178% increase in IPFS traffic as compared to what we logged at the end of the last quarter of 2021.

This traffic continued to increase following this initial observation:

  • An increase of 85% in the second quarter
  • A 62% increase in the third quarter
  • A 19% increase in the last quarter of 2022

This equated to an overall increase of 893%.

Image 1 is a graph of Palo Alto Networks’ observed IPFS traffic. It shows an increase of almost 900% between quarter four of 2021 to quarter four of 2022.
Figure 1. Palo Alto Networks IPFS traffic.

We had also identified that IPFS-related traffic saw a similar increase on VirusTotal for the first quarter of 2022, with an increase of 6,503% when compared to the last quarter of 2021.

Similar to what was seen across Palo Alto Networks, VirusTotal continued to see the following increases quarter over quarter (as shown in Figure 2):

  • A 68% increase in the second quarter
  • A 69% increase in the third quarter
  • A 48% increase in the last quarter of 2022
Image 2 is a graph showing the increase of VirusTotal IPFS submissions from quarter four of 2021 to quarter four of 2022. There is a large increase over time from 149 to almost 41,500.
Figure 2. VirusTotal IPFS submissions.

As shown in the observed traffic for IPFS represented in Figures 1 and 2, this increase can be directly attributed to the adoption of IPFS as a technology. Unfortunately, with the adoption of any new technology, there are always people who aim to use it with malicious intent. The notable increase in IPFS traffic we observed in Palo Alto Networks and VirusTotal submissions also includes substantial increases in malicious activity using IPFS.

Analysts from Unit 42 have observed adoption of IPFS for the following types of malicious activities over the past year:

  • Adoption by threat actors
  • Utilization for phishing and account credential theft
  • Utilization by several malware intrusion sets for malicious payload distribution
  • C2 communication

Observations of Threat Actors Adopting IPFS

Unit 42 researchers have observed threat actors discussing their use of IPFS, or their customers’ adoption of this technology, particularly as it pertains to phishing and similar types of cybercrime. Threat actors often advertise their scam services, citing a variety of selling points including that sites were “not suspended online for a long time” and that their “link has no downtime.” This is to say that IPFS has provided them with protection and longevity to their campaigns due to the nature of IPFS’ distributed file system. These discussions are shown in Figures 3, 4, 5 and 6.

Image 3 is a screenshot of threat actors advertising scam services using IPFS links. The threat actor is part of the HappyBrotherGroup. The message consists of a list of the different ways in the message consists of not only their services, but their skill sets.
Figure 3. Threat actor selling scam services using customer IPFS links.
Image 4 is a screenshot of an advertisement by a threat actor selling an IPFS phishing page. It also includes contact info.
Figure 4. Threat actor selling IPFS phishing page.
Image 5 as a screenshot of a threat actor, selling an IPFS phishing page and asking for any potential buyers to DM them.
Figure 5. Threat actor selling IPFS phishing page.
Image 6 is a screenshot of an advertisement by a threat actor selling an IPFS phishing page. It includes the price and contact information as well as services offered.
Figure 6. Threat actor selling IPFS phishing page.

Threat actors are using public IPFS gateways as a means to deliver their malicious content. Without these internet accessible gateways, threat actors would not be able to reach their targets successfully at the scale necessary when using the IPFS network as part of their threat campaigns. This trend is seen in the use of internet accessible IPFS links found in numerous phishing and cybercrime campaigns where initial attack vectors are often email lures.

In the following sections, we will detail some of the threat campaigns we have seen during our analysis of malicious use of IPFS technology.

Phishing

Figure 7 shows that IPFS saw exponential growth in phishing-related network traffic, particularly in the last quarter of the year. Unlike traditional phishing pages hosted on the web, a hosting provider or moderating organization cannot easily remove IPFS phishing content.

Once published to the IPFS network, anyone can obtain and republish content on their own node. Phishing content can be hosted on multiple nodes and requests would have to be made to each host for content removal. Should any one host not agree to the removal, the content would be virtually impossible to remove.

Phishing campaigns typically have shorter times to live (TTL) than other types of cybercrime due to content removal or suspension by site owners, hosting providers or moderators. The structure of IPFS allows criminals to prolong their campaign by making it more resilient to takedowns.

Image 7 is a graph of the increase of Palo Alto Networks IPFS phishing URLs change over time. It starts with quarter four of 2021 and goes to quarter four of 2022. There is an enormous increase, especially from quarter three to quarter four of 2022.
Figure 7. Palo Alto Networks IPFS phishing URLs.

IPFS phishing campaigns are similar to those of traditional phishing, where attackers mimic legitimate services and software (such as DHL, DocuSign and Adobe) to increase the potential of landing in someone’s inbox. The ability to block these lures depends on what email security the receiving organization has in place. While some organizations set very strict rules within their secure email gateway and other security products, others do not out of fear that legitimate emails will be affected.

Note that the names and logos shown below are the work of a threat actor attempting to impersonate a legitimate organization and do not represent an actual affiliation with that organization. The threat actor’s impersonation does not imply a vulnerability in the legitimate organization’s products or services.

In the example below, an email lure mimicking the DHL brand contains an attachment. Within that attachment, there is an IPFS link to the actual phishing page.

Image 8 is a screenshot of an email phishing lure. It is disguised to resemble a DHL shipping invoice.
Figure 8. DHL-themed email lure with attachment submitted to VirusTotal.

Once the user clicks the attachment shown in Figure 8, a fake invoice mimicking Adobe PDF branding is previewed, as shown in Figure 9. Instead of opening a PDF, the “Open” button is actually an IPFS link that redirects the user to the actual phishing page. This page can be accessed via the internet through an IPFS gateway (also highlighted in Figure 9).

Image 9 is a screenshot of the attachment seen in the previous image of the DHL phishing lure. It shows a PDF as well as a red button saying open.
Figure 9. Attachment with link from the DHL lure.

The IPFS URL takes the user to an Adobe phishing page (shown in Figure 10) via the ipfs[.]io gateway, which then attempts to steal the user’s login credentials.

Image 10 is a screenshot of an IPFS phishing link. This is also from the same attachment as the DHL themed phishing lure. A pop-up shows a broken image as well as a form field for email and password, and a confirmation button.
Figure 10. IPFS phishing link found in the attachment from the DHL-themed lure.

As in other Web3 technologies, typical data exfiltration methods are not possible on the IPFS network. There is no way for the threat actor to receive the data the victim inputs into the form meant to steal their credentials.

Standard web forms use HTML frontends to display content for presentation and backend form processors to collect, process and send the data to a web server. IPFS does not contain the same or similar technology to handle these dynamic functions.

People using IPFS are simply pulling or retrieving a read-only copy of the data, not interacting with it. Phishing pages hosted behind IPFS gateways rely on a number of other techniques instead.

For example, attackers can use embedded script code in webpages that collect account credentials. They can also use headless forms, which are static user forms that can be filled out and collected. The form fields are mapped to a JSON model to facilitate API-driven theft by sending to a backend system via an API. The information is gathered via HTTP POST requests, which are sent to the attacker, where it can be used for additional nefarious purposes.

Let’s examine the use of both of these credential theft techniques.

Unescaped Script in Nillis.html

Figure 10 shows an example of a phish mimicking Microsoft that is hosted as an HTML page. The IPFS URL to contact this page is

hxxps[://]bafybeicw4jjag57bk3czji7wjznkkpbocg27qk3fjvqh5krbrfiqbksr2a[.]ipfs[.]w3s[.]link/Nills[.]html.

Image 11 is a screenshot of a phishing page that mimics a Microsoft login page. It shows what appears to be a regular Microsoft login form field, asking the user to sign in.
Figure 11. Phishing page for Nills.html.

To understand how the credentials will be exfiltrated, let’s review the source content of the webpage.

Figure 12 shows a function named WriteHTMLtoJS. The purpose of this function is to write HTML to JavaScript (JS), and to also unescape the contents. The unescape JS function is responsible for decoding hexadecimal sequences with their actual ASCII character values. This representation can be seen on lines 3 and 4 of Figure 12.

Image 12 is a screenshot of the source code of the phishing webpage. An red arrow in a box highlights the content to be decoded.
Figure 12. Source view of Nills.html webpage.

Decoding and analyzing the unescaped content (shown in Figure 13) reveals a pair of script tags and an observed URL, which is app[.]headlessforms[.]cloud. The phishing page appears to contact this URL.

A review of the headless forms indicates this phishing page is using a method for managing user forms where data can be captured on a third-party backend without having to design and/or develop a frontend web application.

Image 13 is a screenshot of a few lines of code. It is the decoded Nills.html file that contains the location of credential exfiltration. Highlighted with a red arrow and box is the headless form phishing.
Figure 13. Decoded view of Nills.html containing the location of credential exfiltration.

After a victim enters an account username and password credential, it will be sent via an HTTP POST request (shown in Figure 14). The string of characters at the end of the URI (GjCP9S9nke) is a unique identifying token associated with the actor on the headless forms platform.

Image 14 is a screenshot of many lines of code. It shows the HTTP POST and captured credentials. These are highlighted with a red arrows and boxes around the relevant content. The HTTP POST is at the top with the credential theft at the bottom.
Figure 14. HTTP POST and captured credentials.

Let’s move on to examining another phishing campaign using another collection technique.

HTTP POST in new.html

Another phishing page (shown in Figure 15) that we discovered mimicking the Microsoft brand, which was also hosted on IPFS, is called new.html. The associated IPFS phishing URL is:

hxxp[://]bafybeifm5vcoj35hhuxf7ha3gg6asrrlrwu3bvcysgmrvygnm3qjmugwxq[.]ipfs[.]w3s[.]link/new[.]html?email=

 

Image 15 is a screenshot of a phishing page that mimics a Microsoft account login page. It includes a form field to sign in.
Figure 15. Phishing page for new.html.

Review of the webpage source indicates a similar JS function to the one referenced previously, where it unescapes the contents, decoding them to the ASCII values. The unescape function can be seen in Figure 16.

Image 16 is a screenshot of the source code for news.html
Figure 16. Source view of new.html.

Decoding the content reveals a snippet of interest that is located near the bottom of a sizable amount of code, as shown in Figure 17.

Image 17 is a screenshot of many lines of code. Highlighted inside of a red box is a URL.
Figure 17. new.html URL where data is POSTed.

The snippet in Figure 17 shows the external URL (fairpartner[.]ru) registered to a click function event for the submit button. This URL will be contacted with the data provided by an HTTP POST request, as shown in Figure 18.

Image 18 is a screenshot of Wireshark showing the DNS request for fairpartner.ru.
Figure 18. DNS request for fairpartner.ru.

At the time this research was compiled, we were unable to capture the credential theft as the domain was no longer reachable. This highlights the resiliency of using a third-party service such as headless forms versus the traditional hosting used by this campaign for capturing credentials.

IPFS is not only used by threat actors for phishing. It is also used for malware intrusion sets and ransomware.

Ransomware-as-a-service (RaaS) operators such as RansomEXX are known to use the IPFS network to release the stolen data of their victims. Malware families such as Smoke Loader, XLoader, XMRig and OriginLogger often use IPFS links for malicious payload delivery. IPStorm and Dark Utilities use the IPFS network for infrastructure and staging.

Let’s review how each of these groups uses IPFS.

Malware and Red Team Tools

Threat actors use IPFS gateways in a couple different ways. These can be categorized as either delivery methods or for use as infrastructure for hosting or staging payloads, or for acting as a decentralized C2 channel.

The following malware families have been using IPFS throughout 2022. The malware family Dark Utilities has been using IPFS gateways for staging malicious payloads. IPStorm uses IPFS gateways as a C2 channel for P2P communications.

Attackers have also used IPFS gateways to deliver various red team tools and malware such as the following:

  • OriginLogger
  • XLoader
  • XMRig
  • Metasploit

We’ll describe how these threats operate at a high level, including how IPFS was used to facilitate malicious operations.

OriginLogger

The OriginLogger malware family has been around since 2019. It is the continuation of the Agent Tesla remote access Trojan. It is written in .NET and functions as a highly evasive information stealer. This threat typically targets keystrokes and clipboard data, which is communicated back to an actor-controlled server through a C2 channel.

Unit 42 researchers discovered an email lure masquerading as an overdue invoice, with an XLL attachment (as shown in Figure 19). Upon opening the XLL file, an HTTP GET request is sent to the IPFS URL:

hxxps[://]ipfs[.]io/ipfs/QmXtVwamvHvXZzuEZcMn2xDsPRKN8uS17YCUzTiGx1rYnv?filename=file-05-2022.exe

This URL is used for downloading the OriginLogger payload via IPFS gateway.

Image 19 is a screenshot of an email. The email text is requesting for overdue invoices to be paid. Highlighted in red is the attachment, which is a .XLL file.
Figure 19. Attachment - 30-MAY-22.xll.

Figure 20 shows the second delivery example of OriginLogger. This email lure also masquerades as an overdue invoice statement, with the subject line “Overdue Invoice Statement.”

This email lure also has an XLL file attachment. Upon opening, this will also send a GET request to the IPFS URL:

hxxps[://]ipfs[.]io/ipfs/QmXtVwamvHvXZzuEZcMn2xDsPRKN8uS17YCUzTiGx1rYnv?filename=file-05-2022.exe

Clicking this URL downloads an OriginLogger payload via an IPFS gateway.

Image 20 is a screenshot of an email. The email text is requesting for overdue invoices to be paid. Highlighted in red is the attachment, which is a .XLL file. It contains an OriginLogger payload.
Figure 20. Email pushing an attachment containing an OriginLogger payload.

Some additional OriginLogger payloads hosted on IPFS are listed below, from a campaign that occurred during May-June 2022:

hxxps[://]ipfs[.]io/ipfs/QmQBPuPxy3nZjK2yVspsUJVhutajAfRQpnjc58RAcUJFrh?filename=INV-SCL0093-05-22pdf.exe

hxxps[://]ipfs[.]io/ipfs/QmY4kDbUk8VYM8Zzn1rVgfa3c4ybma4evMBfyWwyieaZxW?filename=Sign-Reurn-pdf.exe

hxxps[://]ipfs[.]io/ipfs/QmczJ1MxQ2SH8deXBTJfFgsrApM5BShgLSh1MQry4Vxc4c?filename=REF

XLoader

The XLoader malware family has been around since 2020, as a rebrand of FormBook. XLoader has been advertised as a malware-as-a-service (MaaS) offering that can run on Windows as well as macOS. XLoader functions as a stealer that targets browser and login credentials, and it’s also capable of keylogging and capturing screenshots.

Unit 42 researchers observed the following in the wild (ITW) URLs related to the hosting of XLoader payloads:

hxxp[://]bafybeiafb63z73aoz3d4jdpve2rhlwo6ujlzjyri26z63flqnara2dqwoa[.]ipfs[.]dweb[.]link/order.exe

bafybeicokadgkcohrqslwdnmtu5mcc2zmo2hveiw2bh5j5z35onsxe3cy4[.]ipfs[.]dweb[.]link

XMRig

XMRig is a cryptomining malware family that has been around since 2017. XMRig is an open-source utility that various threat groups have adapted to be delivered either in malspam or in campaigns that exploit vulnerable public facing applications, leading to XMRig being deployed.

Figure 21 shows an ITW IPFS domain that was serving an XMRig payload in late March 2023. Unit 42 researchers also observed threat actors abusing Cloudflare’s IPFS gateway to host XMRig.

Image 21 is a screenshot of the ITW domain that downloads the XMRig payload. Highlighted in red are two sections.
Figure 21. ITW domain downloading XMRig payload.

Unit 42 researchers observed the following URLs related to the hosting of XMRig:

hxxps[://]bafybeibgc3snqi6qesnhskujhjcbduu7lfhju7eppumuqhymapuwvln6tq[.]ipfs[.]nftstorage[.]link

hxxps[://]cloudflareipfs[.]com/ipns/12D3KooWDdu1TTG9JRzFisv8HBXE2Zi2qpqs1r2vb88vEE1ws5mc/phpupdate.exe

Figure 22 shows the attributes of the executable PE file properties for XMRig.

Image 22 is a screenshot of the file property is for the XMRig PE file.
Figure 22. View of XMRig PE file information.

Metasploit

The Metasploit Framework is a penetration testing toolkit that has been around since the early 2000s. Metasploit contains exploits, modules, payloads and auxiliary capabilities. The primary use case for this toolkit is to generate payloads and achieve code execution to set up a communication channel with a victim machine. This allows someone using the toolkit to gain access to and control of an environment or user.

In late March 2023, Unit 42 researchers observed an ITW IPFS domain:

hxxps[://]bafybeihtuhj7ezvjbtig75qpv43t7eh6dmcnarlm454fx5yjb4uzqbidpy[.]ipfs[.]infura-ipfs[.]io

This domain has been serving a Metasploit shellcode payload since May 26, 2022. The shellcode connects back to the IP address 51.254.127[.]82 as shown in Figures 23 and 24.

Image 23 is a screenshot showing what it looks like when the Metasploit payload is downloaded. Highlighted in red is the payload in the file name.
Figure 23. Downloading Metasploit payload from IPFS domain.
Image 24 is a screenshot of a few lines of code. Highlighted within the code is the IP connection.
Figure 24. Metasploit shellcode reverse shell IP connection.

An additional ITW domain was also observed associated with the same Metasploit payload:

hxxps[://]ipfs.infura[.]io/ipfs/QmejguEysvXLMaAYmXe3EXmjfnoAqMdVfn4ojto1yLTGhK

IPStorm

The IPStorm malware family has been around since 2019, as reported by researchers at Anomali. IPStorm is a notable botnet as it uses IPFS as a C2 channel.

IPStorm uses the open-source library libp2p for its networking stack and P2P communication over the IPFS network. The executable is written in Golang and contains multiple notable package names that can be used to identify the malware family. This threat uses the folder name /storm before the module name, as shown in Figure 25.

Image 25 is the screenshot of the GO libraries. The included columns show the address, length, type, and finally the string. Highlighted in yellow are the source storm parts of the path.
Figure 25. Screenshot of GO libraries used in b8ee3897aff6c6660557a4c73b243870020705df6c87287040bfcd68b7c8b100.

Dark Utilities

The Dark Utilities malware family was initially identified in 2022 by Cisco Talos. Dark Utilities is a C2-as-a-service product offering that uses IPFS as its delivery channel of choice.

This threat can be compiled for Windows, macOS, Linux or various embedded systems. The product offers cryptomining and DDoS capabilities, as well as typical remote access functionality.

Unit 42 researchers found numerous ITW domains still serving Dark Utilities payloads in late March 2023. Figures 26 and 27 show the ITW domain and associated SHA256 hash.

Image 26 is a screenshot showing the download of an ITW domain. Highlighted in red is the URL.
Figure 26. ITW domain downloading Dark Utilities payload.
Image 27 is a screenshot of the SHA256 of Dark Utilities payload.
Figure 27. SHA256 of Dark Utilities payload.

bafybeidravcab5p3acvthxtwosm4rfpl4yypwwm52s7sazgxaezfzn5xn4[.]ipfs.infura-ipfs.io

bafybeibmryvvmv6vzdsewqw63j46k72pm4lqkb37hnc757qa3jyqktscxy[.]ipfs.infura-ipfs.io

bafybeiehf33obq42jx73m3nfilstzgk52wuvwmoechf4wmbt652p36jsia[.]ipfs.nftstorage.link

bafybeidqh7dk3sse4u5d66web5v446nnygtw5jeav5vunueyonjx5wp6gm[.]ipfs.nftstorage.link

Figure 28 shows the decompiled view of the Python source code used to build the Dark Utilities executables, which is hosted on the IPFS network. The main function in the source code shown determines whether a system is Windows or Linux-based. Upon determining what operating system is running, the code continues by setting up persistence, among other tasks.

Image 28 is a screenshot of many lines of code. It is the decompile view of the Dark Utilities Python code.
Figure 28. Decompiled view of Dark Utilities Python code.

Conclusion

Threat actors increasing their adoption of IPFS is a growing concern because, as a decentralized and distributed storage technology, IPFS poses unique challenges in locating and removing malicious content from the ecosystem. It is important to note that there is no single solution for removing malicious content from the IPFS networks. Different approaches might be more or less effective depending on the specific circumstances and the participation of the owners of the decentralized networks in which the content is ultimately hosted.

The significant increase in IPFS-related traffic we observed during 2022 at Palo Alto Networks and VirusTotal data highlights the growing popularity of this technology among threat actors. The threat campaigns observed by analysts from Unit 42 demonstrate the versatility of IPFS for carrying out a variety of malicious activities, including phishing, credential theft, C2 communications and payload distribution.

Threat actors’ adoption of IPFS, as well as the sale of services hosted on IPFS, underscores the need for continued vigilance and proactive measures to detect and mitigate threats on this platform. It is imperative that the cybersecurity community remains vigilant and takes proactive steps to stay ahead of evolving threats on IPFS and other emerging technologies.

Product Protections

Palo Alto Networks customers receive protections from the threats discussed above through the following products:

If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America Toll-Free: 866.486.4842 (866.4.UNIT42)
  • EMEA: +31.20.299.3130
  • APAC: +65.6983.8730
  • Japan: +81.50.1790.0200

Palo Alto Networks has shared these findings, including file samples and indicators of compromise, with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

MalwareBazaar References

Malware Family Malware Bazaar Report Link
Phishing hxxps[://]bazaar[.]abuse[.]ch/sample/460a3720734df53891c36340dc037122d73103517fe57b7c36480dfae3c0f4d7
Phishing hxxps://bazaar[.]abuse[.]ch/sample/2a060e0db155844605077e78270b45b8627c2aedef503b26fc6ecaf2f6742023
OriginLogger hxxps://bazaar[.]abuse[.]ch/sample/edfc3c3090eba1aba9c9960d68a1464bcf668773a1eec38ec8c54c357dca0c61
OriginLogger hxxps://bazaar[.]abuse[.]ch/sample/3b9ef32ea71c375cd63e599a54ca3f5b58ac8b6e589c3036a3a0d4886c730ddd
OriginLogger hxxps://bazaar[.]abuse[.]ch/sample/3072a7ec1f71a9adc7a714092172e4b763a9f7128ead2ae67e72663863b1143b
OriginLogger hxxps://bazaar[.]abuse[.]ch/sample/b6f8699b55c9e9ca2d84c18c689eff12be9b7bd849a527a44d39e2aaa4dbf3a0
OriginLogger hxxps://bazaar[.]abuse[.]ch/sample/c7ceafc46a828d2ccca49936ddc8d5da666e885455ecd6ad6bd77aa23c284fe6
XLoader hxxps://bazaar[.]abuse[.]ch/sample/a12635fd762876c38da85b88adf42141beb117cc12464c3e0d122c9395bd2a4b
XLoader hxxps://bazaar[.]abuse[.]ch/sample/1a41a5bf751fd2deb7cf46b231e45843adc5f036149979de847c053177be2eb8
XMRig hxxps://bazaar[.]abuse[.]ch/sample/d1ea28dee35382c510a49e4304ed7cead25bcee5cc869c73c9c53f333139e060
XMRig hxxps://bazaar[.]abuse[.]ch/sample/a372e07a691f8759e482615fd7624bfca2a2bc2cd8652a47ff9951ff035759a5
Metasploit hxxps://bazaar[.]abuse[.]ch/sample/894b5e81fe56418b8df30639fd8b8c484c934aba8a121397b592039e07f766ee
IPStorm hxxps://bazaar[.]abuse[.]ch/sample/b8ee3897aff6c6660557a4c73b243870020705df6c87287040bfcd68b7c8b100
IPStorm hxxps://bazaar[.]abuse[.]ch/sample/765a4d57b2db92c2fd904b11a3e2dd26cdaa38843cc1760ae84e3334822bf4c4
IPStorm hxxps://bazaar[.]abuse[.]ch/sample/cdddd240d432b084b2c5cbe6b4a89b39a33d97840630210772b7758ec87dcacd
Dark Utilities hxxps://bazaar[.]abuse[.]ch/sample/65a1b3fb9430c7342d13f79b460b2cc7d9f9ddced2aeecd37f2862a67083e68c
Dark Utilities hxxps://bazaar[.]abuse[.]ch/sample/c9deeda7cd7adb4ff584d13ea64cdb50c9e8b5c616f1dff476f372e86c9b9be6
Dark Utilities hxxps://bazaar[.]abuse[.]ch/sample/554f955a405be9393eb2e9af182029029d562d79d23a6a8663704b1c00abfb56
Dark Utilities hxxps://bazaar[.]abuse[.]ch/sample/583d96d55608ab7079b7867c34c195766699a711ef3aa9df826ac3c5bc5c3232
Dark Utilities hxxps://bazaar[.]abuse[.]ch/sample/e1512098be4bd1a8b67839b077a58451941a87407257beb05752155ef5e04d40
Dark Utilities hxxps://bazaar[.]abuse[.]ch/sample/ba81c3a82a01fcd2f4c24904e4dc0b7ca26f472e50db9056af6e2217f925e9f5

Indicators of Compromise

Hashes

Family SHA256
Phishing 460a3720734df53891c36340dc037122d73103517fe57b7c36480dfae3c0f4d7
Phishing 2a060e0db155844605077e78270b45b8627c2aedef503b26fc6ecaf2f6742023
OriginLogger edfc3c3090eba1aba9c9960d68a1464bcf668773a1eec38ec8c54c357dca0c61
OriginLogger 3b9ef32ea71c375cd63e599a54ca3f5b58ac8b6e589c3036a3a0d4886c730ddd
OriginLogger cfa0a616bb5e61e215e915a3d7942094db58b8c3f8a613d9410a807df4837d5a
OriginLogger 3072a7ec1f71a9adc7a714092172e4b763a9f7128ead2ae67e72663863b1143b
OriginLogger b6f8699b55c9e9ca2d84c18c689eff12be9b7bd849a527a44d39e2aaa4dbf3a0
OriginLogger c7ceafc46a828d2ccca49936ddc8d5da666e885455ecd6ad6bd77aa23c284fe6
XLoader a12635fd762876c38da85b88adf42141beb117cc12464c3e0d122c9395bd2a4b
XLoader 1a41a5bf751fd2deb7cf46b231e45843adc5f036149979de847c053177be2eb8
XMRig a372e07a691f8759e482615fd7624bfca2a2bc2cd8652a47ff9951ff035759a5
XMRig d1ea28dee35382c510a49e4304ed7cead25bcee5cc869c73c9c53f333139e060
Metasploit 894b5e81fe56418b8df30639fd8b8c484c934aba8a121397b592039e07f766ee
IPStorm b8ee3897aff6c6660557a4c73b243870020705df6c87287040bfcd68b7c8b100
IPStorm 765a4d57b2db92c2fd904b11a3e2dd26cdaa38843cc1760ae84e3334822bf4c4
IPStorm cdddd240d432b084b2c5cbe6b4a89b39a33d97840630210772b7758ec87dcacd
Dark Utilities 65a1b3fb9430c7342d13f79b460b2cc7d9f9ddced2aeecd37f2862a67083e68c
Dark Utilities c9deeda7cd7adb4ff584d13ea64cdb50c9e8b5c616f1dff476f372e86c9b9be6
Dark Utilities 554f955a405be9393eb2e9af182029029d562d79d23a6a8663704b1c00abfb56
Dark Utilities 583d96d55608ab7079b7867c34c195766699a711ef3aa9df826ac3c5bc5c3232
Dark Utilities e1512098be4bd1a8b67839b077a58451941a87407257beb05752155ef5e04d40
Dark Utilities ba81c3a82a01fcd2f4c24904e4dc0b7ca26f472e50db9056af6e2217f925e9f5

Acknowledgments

Special thanks to Lucas Hu for his contributions on the curation of some of the IPFS-related URLs and data sources used in this blog.

Additional Resources

Updated April 24, 2023, at 1:08 p.m. PT.

Unit 42 Unveils Most ‘Expansive’ Cloud Threat Research Yet: Cloud Threat Report Volume 7 Examines the Expanding Attack Surface

Posted on by Unit 42

Executive Summary

The cloud attack surface is as dynamic as the cloud itself. As organizations around the globe increasingly share, store and manage data in the cloud, this expands organizations’ attack surface exponentially. This expansion often happens in ways that are unknown, overlooked or improperly secured. For threat actors, each workload in the cloud presents an opportunity, and without proper management, organizations are exposed to risk in countless ways.

Where previous reports zoomed in on a single threat (e.g., identity access management, supply chain attacks and container security), the “Unit 42 Cloud Threat Report, Volume 7” zooms out to look at a bigger, more expansive problem: Threat actors have become adept at exploiting common, everyday issues in the cloud. These issues include misconfigurations, weak credentials, lack of authentication, unpatched vulnerabilities and malicious open source software (OSS) packages.

The report includes a breakdown of two separate real-world cloud breach incident response cases we observed in 2022. Anonymizing and de-identifying the victims, we illustrate how attackers took advantage of sensitive data leaked on the dark web and the business disruption caused by ransomware.

Below, we’ll present a sampling of the highlights of the research and recommendations in the “Unit 42 Cloud Threat Report, Volume 7: Navigating the Expanding Attack Surface.”

What we learned:

  • On average, security teams take 145 hours (approximately six days) to resolve a security alert. 60% of organizations take longer than four days to resolve security issues.
  • In most organizations' cloud environments, 80% of the alerts are triggered by just 5% of security rules.
  • 63% of the codebases in production have unpatched vulnerabilities rated high or critical (CVSS >= 7.0)
  • 76% of organizations don’t enforce MFA for console users, while 58% of organizations don’t enforce MFA for root/admin users.

Common Oversights in the Cloud

Using large-scale data collected in 2022, the report examines real breaches that impacted medium- and large-size companies, details the issues observed in thousands of multicloud environments, and analyzes the impact of OSS vulnerabilities on the cloud. In particular, we analyzed the workloads in 210,000 cloud accounts across 1,300 different organizations. With many organizations now having multiple cloud deployments, the gaps in security are getting more attention from threat actors.

A graph showing how quickly organizations resolve security alerts measured in days. Less than fifty percent resolve alerts within four days.
Figure 1. The range of time, in days, organizations take to resolve security alerts. Forty percent of organizations resolve their security alerts within four days.

While user errors, such as insecure configurations, are still the primary concern, Unit 42 researchers also noticed issues stemming from the ready-to-use templates and default configurations provided by cloud service providers (CSPs). These settings and features are convenient, making the adoption of new technologies frictionless, but they don’t position users in the most secure initial state.

Sample Findings:

  • 76% of organizations don’t enforce MFA for console users.
  • Sensitive data was found in 63% of publicly exposed storage buckets.

Impacts and Risks of Open Source Software (OSS) in the Cloud

Open source software has been one of the driving forces behind the cloud revolution. However, the increased use of OSS in the cloud also increases complexity—increasing the likelihood of depreciated or abandoned software, malicious content and slower patching cycles. This puts the onus on end users to scrutinize the OSS before integrating it into applications. This task is particularly challenging when organizations need to manage scores of projects that are all dependent on potentially thousands of OSS.

A graph showing the number of vulnerabilities in CNCF projects categorized by language with Golang as the majority, followed by C++ and Python.
Figure 2. The number of vulnerabilities in CNCF projects categorized by language.

Recommendations: Making It Harder for the Threat Actors

Organizations should expect the attack surface of cloud-native applications to continue to grow as threat actors find increasingly creative ways to target the misconfiguration of cloud infrastructure, APIs and the software supply chain itself.

To guard against these threats, our report includes practical guidance for closing the gaps in your cloud security, such as the following:

Tip: There should be an automated backup process for any cloud workload that would interrupt business operations if it were to go down. Backups should be stored in protected locations isolated from the production environment across multiple geographic locations to prevent a single point of failure. All organizations should have business continuity and disaster recovery (BC/DR) plans that incorporate the process of recovering backups.

In addition, we predict the industry will see a shift away from point security solutions toward cloud-native application protection platforms (CNAPPs), which offer a full spectrum of capabilities across the application development lifecycle. Gartner echoes this assertion that there will be a significant uptick in CNAPP adoption, having reported a 70% jump in client inquiries regarding CNAPPs from 2021-2022.

As the report makes clear, the only way to defend against the changing scope and severity of today’s security threats is to always stay one step ahead of the attackers who are perpetrating them.

Download your copy of the “Unit 42 Cloud Threat Report, Volume 7.”

Additional Resources

Get the latest news, invites to events, and threat alerts

Default Heading

Read the article Right Arrow