mrmoor/cyber-threat-intelligence huggingface dataset:
In the event that the main C2 servers do not respond, the infected systems can retrieve backup domains encrypted in the latest transaction from the following bitcoin wallet addresses:  The following 32 byte AES keys for decryption are hard coded in the binaries:  The blockchain transaction’s OP_RETURN data can be decrypted using AES-256 GCM to provide a backup command and control domain name.
The first 12 bytes of the OP_RETURN contains the IV, the last 16 bytes the GCM tag, while the middle section is the AES-256 GCM encrypted domain
Full details of Glupteba’s network protocol can be found in this report from 2020, the following Python script illustrates how one can decrypt an encrypted domain name:
Recent domains used for command and control:
Recent sha256 hashes of malware samples:
This bulletin includes coordinated influence operation campaigns terminated on our platforms in Q4 2021.
It was last updated on February 7, 2022.
To protect our users, TAG routinely hunts for 0-day vulnerabilities exploited in-the-wild.
In late August 2021, TAG discovered watering hole attacks targeting visitors to Hong Kong websites for a media outlet and a prominent pro-democracy labor and political group.
The watering hole served an XNU privilege escalation vulnerability (CVE-2021-30869) unpatched in macOS Catalina, which led to the installation of a previously unreported backdoor.
As is our policy, we quickly reported this 0-day to the vendor (Apple) and a patch was released to protect users from these attacks.
Based on our findings, we believe this threat actor to be a well-resourced group, likely state backed, with access to their own software engineering team based on the quality of the payload code.
In this blog we analyze the technical details of the exploit chain and share IOCs to help teams defend against similar style attacks.
The websites leveraged for the attacks contained two iframes which served exploits from an attacker-controlled server—one for iOS and the other for macOS.
iOS Exploits
The iOS exploit chain used a framework based on Ironsquirrel to encrypt exploits delivered to the victim's browser.
We did not manage to get a complete iOS chain this time, just a partial one where CVE-2019-8506 was used to get code execution in Safari.
macOS Exploits
The macOS exploits did not use the same framework as iOS ones.
The landing page contained a simple HTML page loading two scripts—one for Capstone.js and another for the exploit chain.
The parameter rid is a global counter which records the number of exploitation attempts.
This number was in the 200s when we obtained the exploit chain.
While the javascript starting the exploit chain checks whether visitors were running macOS Mojave (10.14) or Catalina (10.15) before proceeding to run the exploits, we only observed remnants of an exploit when visiting the site with Mojave but received the full non-encrypted exploit chain when browsing the site with Catalina.
The exploit chain combined an RCE in WebKit exploiting CVE-2021-1789 which was patched on Jan 5, 2021 before discovery of this campaign and a 0-day local privilege escalation in XNU (CVE-2021-30869) patched on Sept 23, 2021.
Loading a page with the WebKit RCE on the latest version of Safari (14.1), we learned the RCE was an n-day since it did not successfully trigger the exploit.
To verify this hypothesis, we ran git bisect and determined it was fixed in this commit.
Capstone.js
It was interesting to see the use of Capstone.js, a port of the Capstone disassembly framework, in an exploit chain as Capstone is typically used for binary analysis.
The exploit authors primarily used it to search for the addresses of dlopen and dlsym in memory.
Once the embedded Mach-O is loaded, the dlopen and dlsym addresses found using Capstone.js are used to patch the Mach-O loaded in memory.
With the Capstone.js configured for X86-64 and not ARM, we can also derive the target hardware is Intel-based Macs.
Embedded Mach-O
After the WebKit RCE succeeds, an embedded Mach-O binary is loaded into memory, patched, and run.
Upon analysis, we realized this binary contained code which could escape the Safari sandbox, elevate privileges, and download a second stage from the C2.
Analyzing the Mach-O was reminiscent of a CTF reverse engineering challenge.
It had to be extracted and converted into binary from a Uint32Array.
Then the extracted binary was heavily obfuscated with a relatively tedious encoding mechanism--each string is XOR encoded with a different key.
Fully decoding the Mach-O was necessary to obtain all the strings representing the dynamically loaded functions used in the binary.
There were a lot of strings and decoding them manually would have taken a long time so we wrote a short Python script to make quick work of the obfuscation.
The script parsed the Mach-O at each section where the strings were located, then decoded the strings with their respective XOR keys, and patched the binary with the resulting strings.
Once we had all of the strings decoded, it was time to figure out what capabilities the binary had.
There was code to download a file from a C2 but we did not come across any URL strings in the Mach-O so we checked the javascript and saw there were two arguments passed when the binary is run–the url for the payload and its size
After downloading the payload, it removes the quarantine attribute of the file to bypass Gatekeeper.
It then elevated privileges to install the payload.
day or 0-day?
Before further analyzing how the exploit elevated privileges, we needed to figure out if we were dealing with an N-day or a 0-day vulnerability.
An N-day is a known vulnerability with a publicly available patch.
Threat actors have used N-days shortly after a patch is released to capitalize on the patching delay of their targets.
In contrast, a 0-day is a vulnerability with no available patch which makes it harder to defend against.
Despite the exploit being an executable instead of shellcode, it was not a standalone binary we could run in our virtual environment.
It needed the address of dlopen and dlsym patched after the binary was loaded into memory.
These two functions are used in conjunction to dynamically load a shared object into memory and retrieve the address of a symbol from it.
They are the equivalent of LoadLibrary and GetProcAddress in Windows.
To run the exploit in our virtual environment, we decided to write a loader in Python which did the following:  For our payload, we wrote a simple bash script which runs id and pipes the result to a file in /tmp.
The result of the id command would tell us whether our script was run as a regular user or as root.
Having a loader and a payload ready, we set out to test the exploit on a fresh install of Catalina (10.15) since it was the version in which we were served the full exploit chain.
The exploit worked and ran our bash script as root.
We updated our operating system with the latest patch at the time (2021-004) and tried the exploit again.
It still worked.
We then decided to try it on Big Sur (11.4) where it crashed and gave us the following exception.
The exception indicates that Apple added generic protections in Big Sur which rendered this exploit useless.
Since Apple still supports Catalina and pushes security updates for it, we decided to take a deeper look into this exploit.
Elevating Privileges to Root The Mach-O was calling a lot of undocumented functions as well as XPC calls to mach_msg with a MACH_SEND_SYNC_OVERRIDE flag.
This looked similar to an earlier in-the-wild iOS vulnerability analyzed by Ian Beer of Google Project Zero.
Beer was able to quickly recognize this exploit as a variant of an earlier port type confusion vulnerability he analyzed in the XNU kernel (CVE-2020-27932).
Furthermore, it seems this exact exploit was presented by Pangu Lab in a public talk at zer0con21 in April 2021 and Mobile Security Conference (MOSEC) in July 2021.
In exploiting this port type confusion vulnerability, the exploit authors were able to change the mach port type from IKOT_NAMED_ENTRY to a more privileged port type like IKOT_HOST_SECURITY allowing them to forge their own sec_token and audit_token, and IKOT_HOST_PRIV enabling them to spoof messages to kuncd.  After gaining root, the downloaded payload is loaded and run in the background on the victim's machine via launchtl.
The payload seems to be a product of extensive software engineering.
It uses a publish-subscribe model via a Data Distribution Service (DDS) framework for communicating with the C2.
It also has several components, some of which appear to be configured as modules.
For example, the payload we obtained contained a kernel module for capturing keystrokes.
There are also other functionalities built-in to the components which were not directly accessed from the binaries included in the payload but may be used by additional stages which can be downloaded onto the victim's machine.
Notable features for this backdoor include:  Our team is constantly working to secure our users and keep them safe from targeted attacks like this one.
We continue to collaborate with internal teams like Google Safe Browsing to block domains and IPs used for exploit delivery and industry partners like Apple to mitigate vulnerabilities.
We are appreciative of Apple’s quick response and patching of this critical vulnerability.
For those interested in following our in-the-wild work, we will soon publish details surrounding another, unrelated campaign we discovered using two Chrome 0-days (CVE-2021-37973 and CVE-2021-37976).
That campaign is not connected to the one described in today’s post.
Delivery URLs Javascript Sandbox escape / LPE Backdoor C2
We have uncovered a cyberespionage campaign being perpetrated by Earth Baku, an advanced persistent threat (APT) group with a known history of carrying out cyberattacks under the alias APT41.
This is not the group’s first foray into cyberespionage, and its long list of past cybercrimes also includes ransomware and cryptocurrency mining attacks.
Earth Baku deploys its ongoing campaign, which can be traced to as far back as July 2020, through multiple attack vectors that are designed based on different exploits or the infrastructure of its targeted victim's environment:  • SQL injection to upload a malicious file • Installment through InstallUtil.exe in a scheduled task • Possibly a malicious link (LNK) file sent as an email attachment • Exploitation of the ProxyLogon vulnerability CVE-2021-26855 to upload a China Chopper web shell  This campaign uses previously unidentified shellcode loaders, which we have named StealthVector and StealthMutant, and a backdoor, which we have dubbed ScrambleCross.
Earth Baku has developed these new malware tools to facilitate targeted attacks on public and private entities alike in specific industries that are located in the Indo-Pacific region.
Countries affected by Earth Baku’s new campaign Source: Trend Micro™ Smart Protection Network™ infrastructure StealthVector
We initially observed StealthVector, a shellcode loader written in C/C++, in October 2020.
StealthVector is designed with various configurable features that make it easy for malicious actors to modify and tailor it to their needs, including a feature that disables Event Tracing for Windows (ETW), allowing the malware to run in stealth mode.
This loader can stealthily run its payload in various ways, such as using the CreateThread function, bypassing Microsoft’s Control Flow Guard (CFG), module stomping, and phantom dynamic link library (DLL) hollowing.
StealthMutant Like StealthVector, StealthMutant, which supports both 32-bit and 64-bit operating systems, can disable ETW.
This loader, written in C#, has been used by malicious actors since July 2020.
Many of the StealthMutant samples we have analyzed use AES-256-ECB for decryption; alternatively, an earlier variant of the loader uses XOR.
After its payload is decrypted, StealthMutant performs process hollowing to execute its payload in a remote process.
ScrambleCross
Both StealthMutant and StealthVector contain a payload of either the Cobalt Strike beacon or ScrambleCross, a newly discovered backdoor.
ScrambleCross receives instructions from its command-and-control (C&C) server that allow it to receive and manipulate plug-ins.
However, we have yet to retrieve and study one of these plug-ins.
It has many of the same capabilities as another backdoor, Crosswalk, which has also been used by Earth Baku.
For example, both calculate the hash of the code section as an anti-bugging technique, both are designed as fully position-independent code, and both support various kinds of network communication protocols.
Connections to other campaigns Earth Baku’s recent activities are related to another campaign that has been active since at least November 2018, as reported by FireEye and Positive Technologies.
While the older campaign uses a different shellcode loader, which we have named LavagokLdr, we have observed similar code and procedures between LavagokLdr and StealthVector.
In the same vein, we have observed that LavagokLdr’s payload, Crosswalk, and one of StealthVector’s payloads, ScrambleCross, perform similar techniques for decryption and signature checking.
But because Earth Baku has updated its toolset with StealthVector, StealthMutant, and ScrambleCross for this new campaign, we have identified it as its own separate operation.
A timeline of Earth Baku’s previous campaign as APT41 and its new campaign How Earth Baku creates its malware tools Earth Baku is known for its use of self-developed tools.
To continue doing so, it appears to be filling its ranks with malicious actors who are pooling their diverse skills.
Interestingly, the new malware tools involved in Earth Baku’s new campaign indicates that the APT group has likely recruited members who specialize in low-level programming, software development, and red-team techniques.
For more details about Earth Baku’s new campaign, read our research paper "Earth Baku: An APT Group Targeting Indo-Pacific Countries With New Stealth Loaders and Backdoor."        Tags  Articles, News, Reports | APT & Targeted Attacks | Research
This post is also available in:      日本語 (Japanese)  Recently, two vulnerabilities were announced within the Spring Framework, an open-source framework for building enterprise Java applications.
On March 29, 2022, the Spring Cloud Expression Resource Access Vulnerability tracked in CVE-2022-22963 was patched with the release of Spring Cloud Function 3.1.7 and 3.2.3.
Two days later on March 31, 2022, Spring released version 5.3.18 and 5.2.20 of Spring Framework to patch another more severe vulnerability tracked in CVE-2022-22965.
The CVE-2022-22965 vulnerability allows an attacker unauthenticated remote code execution (RCE), which Unit 42 has observed being exploited in the wild.
The exploitation of this vulnerability could result in a webshell being installed onto the compromised server that allows further command execution.
Because the Spring Framework is widely used for web system development and the severity of the vulnerability is critical (CVSS score of 9.8), CVE-2022-22965 is given the name SpringShell (and/or Spring4Shell) by the infosec community.
To understand the impact of this vulnerability, we analyzed all the available information and located the issue in the source code.
On April 8, we updated this blog to include statistics on SpringShell exploitation attempts that we identified by analyzing hits on the Spring Core Remote Code Execution Vulnerability threat prevention signature for the Palo Alto Networks Next-Generation Firewall, as well as alerts triggered in Cortex XDR.
We also added a section on indicators.
Palo Alto Networks customers receive protections against CVE-2022-22965 and CVE-2022-22963 via products and services including Cortex XDR Prevent and Pro, a Threat Prevention subscription for the Next-Generation Firewall, and Prisma Cloud Compute.
Affected Software and Versions Background on the Spring Framework Root Cause Analysis for CVE-2022-22965
Background on Exploitation of the Class Loader Establishing a Reverse Shell Connection to a Remote Server on the Compromised Server SpringShell Exploit Observed in the Wild Conclusion
Additional Resources Indicators   Existing proofs of concept (PoCs) for exploitation work under the following conditions:  Any Java application using Spring Beans packet (spring-beans-*.jar) and using Spring parameters binding could be affected by this vulnerability.
The Spring Framework is an open-source application framework and inversion of the control container for the Java platform.
It is widely used in the industry by various programs and systems due to its powerful features and ease of use.
Some well-known products such as Spring Boot and Spring Cloud are developed with the Spring Framework.
The Spring Core (spring-core) is the core of the framework that provides powerful features such as inversion of control and dependency injection.
It contains the core, beans, context and Spring Expression Language (SpEL) modules.
The vulnerability is caused by the getCachedIntrospectionResults method of the Spring framework wrongly exposing the class object when binding the parameters.
The default Spring data binding mechanism allows developers to bind HTTP request details to application-specific objects.
For example, there is a simple classical application scenario in which the developer creates a trade object to capture request parameters as shown in Figure 1.
Then the developer creates a controller to use the object trade as shown in Figure 2.  After that, the developer usually creates a request builder for the trade controller, which allows the web user to access the trade object remotely as shown in Figure 3.
When web users access trade object properties, the binding process (bindRequestParameters) in the Spring framework implementation will call the getCachedIntrospectionResults method to get and set the object property in the cache.
However, the return object of the getCachedIntrospectionResults method includes a class object.
This means that web users can get a class object remotely by simply submitting a URL as shown in Figure 4.
Exposing the class object to web users is very dangerous and can lead to RCE in many ways.
The class loader is often used by exploiting payloads to load some sensitive classes dynamically for object modification and code execution.
One easy way to get RCE is using the exposed class loader to modify the Tomcat log configuration and remotely upload a JSP web shell after changing the Tomcat log configuration.
One example of changing the Tomcat log configuration by simply submitting a URL is shown in Figure 5.
This is the exploit method used in the public PoC for the SpringShell vulnerability.
Early in 2010, CVE-2010-1622 was assigned to a remote code execution vulnerability in the Spring Framework.
This vulnerability was due to the lack of proper check on the provided PropertyDescriptor in CachedIntrospectionResults() so that class.classLoader is allowed to be utilized to modify the search path of the system's class loader and cause the program to invoke remote Java code.
For this vulnerability, the class loader plays a vital role in the exploitation.
In the Spring Framework version 2.5.6.SEC02, the vulnerability was fixed.
However, while the original way of obtaining the class loader and exploiting it no longer works, a new feature of JDK was introduced in version 9, providing another way to obtain the class loader and making the exploit possible again.
The code snippet seen in Figure 6 shows the fix to CVE-2010-1622.
The fix is to use a block list to exclude two methods: Class.getClassLoader() and getProtectionDomain() as highlighted in Figure 6.
But using a block list runs the risk of being bypassed by the cases not on the list.
And the Java 9 Platform Module System (JPMS) provides a way to bypass this block list.
The newly added module property makes it possible to modify the logging configuration so that a JSP webshell can be written into the web host folder via the logging function as shown in Figure 7.
Figure 8 shows the payload drops a password-protected webshell in the Tomcat ROOT directory called shell7.jsp.
Attackers can then invoke any command through the JSP webshell.
Figure 9 shows the example of executing Netcat to establish a reverse shell to a remote server on the compromised server.
Exploit code for this remote code execution vulnerability has been made publicly available.
Unit 42 first observed scanning traffic early on March 30, 2022 with HTTP requests to servers that included the test strings within the URL.
Figure 10 shows an example of the early scanning activity.
While testing our Threat Prevention signatures, we observed additional scanning activity that included the exploit code within the data section of the HTTP POST request, as seen in Figure 11.
Once we deployed the Threat Prevention signatures, we analyzed the packet captures associated with our "Spring Core Remote Code Execution Vulnerability" signature and found that a majority of the activity was likely generated by variations of the publicly available PoC tools.
Our analysis shows that the following filenames would store the webshell contents on the server in the event of successful exploitation:  0xd0m7.jsp myshell.jsp shell.jsp tomcatwar.jsp wpz.jsp  The webshell contents written to these files are very similar to the code included in the publicly available PoC as well.
There are two variants of the webshell.
One was included in the PoC and uses the pwd parameter for authentication (password is always j) and the cmd parameter for the command to execute.
The second variant does not use a parameter for authentication and uses id for the command to execute.
Table 1 shows the parameters that the webshell saved to the server would use for authentication and command and how many times we saw them.
Table 1. Parameters used by webshells seen in hits on "Spring Core Remote Code Execution Vulnerability" signature.
We searched our telemetry for activity to webshells using the file names associated with the SpringShell activity, with the noted exception of shell.jsp, which is far too general.
We have seen the unique commands listed below submitted to webshells.
Of these, only the two commands involving /etc/passwd would possibly suggest malicious intent for exploitation – the rest of the commands suggest general scanning activity.
ls nslookup%20[redacted].test6.ggdd[.]co[.]uk nslookup+[redacted].test6.ggdd[.]co[.]uk ping%20[redacted].test6.ggdd[.]co[.]uk ping+[redacted].test6.ggdd[.]co[.]uk whoami cat%20/etc/passwd cat+/etc/passwd id ifconfig ipconfig ping%20[redacted].burpcollaborator[.]net
Our Spring Core Remote Code Execution Vulnerability signature was released in the early hours of March 31.
On April 7, we collected the seven days’ worth of activity since the signature release and found that the signature had triggered 43,092 times.
Figure 12 shows the steady increase of total hits from March 31 until April 3, a fairly significant decrease on April 4, followed by an incline in activity on April 5 and 6.
At this time, we have yet to confirm any successful exploitation attempts that led to a webshell installed onto the server outside of testing activity using purposefully vulnerable applications.
We observed a large amount of unique IP addresses during our analysis – with 2,056 addresses triggering the Spring Core Remote Code Execution Vulnerability signature.
Table 2 shows the top 15 IP addresses seen as the source that triggered our signature, which accounts for just over 50% of all of the activity we observed.
Table 2. Top 15 source IPs triggering the Spring Core Remote Code Execution Vulnerability signature.
We were able to analyze 31,953 packet captures that triggered the Spring Core Remote Code Execution Vulnerability signature to determine the webshell filenames and the webshell contents that would be saved to the server in the event of successful exploitation.
In many cases, the webshell file names had .jsp extensions, which would allow for a successful exploitation to install a working webshell.