Today, Talos is publishing a glimpse into the most prevalent threats we've observed between May 19 and May 26. As with previous roundups, this post isn't meant to be an in-depth analysis. Instead, this post will summarize the threats we've observed by highlighting key behavioral characteristics, indicators of compromise, and discussing how our customers are automatically protected from these threats.
As a reminder, the information provided for the following threats in this post is non-exhaustive and current as of the date of publication. Additionally, please keep in mind that IOC searching is only one part of threat hunting. Spotting a single IOC does not necessarily indicate maliciousness. Detection and coverage for the following threats is subject to updates, pending additional threat or vulnerability analysis. For the most current information, please refer to your Firepower Management Center, Snort.org, or ClamAV.net.
For each threat described below, this blog post only lists 25 of the associated file hashes and up to 25 IOCs for each category. An accompanying JSON file can be found here that includes the complete list of file hashes, as well as all other IOCs from this post. A visual depiction of the MITRE ATT&CK techniques associated with each threat is also shown. In these images, the brightness of the technique indicates how prevalent it is across all threat files where dynamic analysis was conducted. There are five distinct shades that are used, with the darkest indicating that no files exhibited technique behavior and the brightest indicating that technique behavior was observed from 75 percent or more of the files.
The most prevalent threats highlighted in this roundup are:
Threat Name
Type
Description
Win.Ransomware.Djvu-10002408-1
Ransomware
The Djvu ransomware encrypts victim's files with Salsa20 and is known for changing its payloads, ransom notes and the file extensions appended to encrypted files. It spreads via cracked or faked applications or updates, keygens or activators. The main payload uses a wide variety of anti-debugging and anti-emulation techniques, which includes checking the location of the system via the keyboard layout or websites.
Win.Virus.Ramnit-10002385-0
Virus
Ramnit is a banking trojan that monitors web browser activity on an infected machine and collects login information from financial websites. It also steals browser cookies and attempts to hide from popular anti-virus software.
Win.Trojan.Qakbot-10002083-1
Trojan
Qakbot, aka Qbot, has been around since at least 2008. Qbot primarily targets sensitive information like banking credentials but can also steal FTP credentials and spread across a network using SMB.
Win.Dropper.Tofsee-10002081-0
Dropper
Tofsee is multi-purpose malware that features a number of modules used to carry out various activities such as sending spam messages, conducting click fraud, mining cryptocurrency, and more. Infected systems become part of the Tofsee spam botnet and send large volumes of spam messages to infect additional systems and increase the size of the botnet under the operator's control
Xls.Malware.Valyria-10002078-0
Malware
Valyria is a malicious Microsoft Word document family that is used to distribute other malware, such as Emotet.
Win.Dropper.Zeus-10002075-0
Dropper
Zeus is a trojan that steals information such as banking credentials using methods such as key-logging and form-grabbing.
Win.Packed.njRAT-10002074-1
Packed
njRAT, also known as Bladabindi, is a remote access trojan (RAT) that allows attackers to execute commands on the infected host, log keystrokes and remotely turn on the victim's webcam and microphone. The Sparclyheason group originally developed njrAT. Some of the largest attacks using this malware date back to 2014.
Win.Ransomware.TeslaCrypt-10002553-0
Ransomware
TeslaCrypt is a well-known ransomware family that encrypts a user's files and demands Bitcoin in exchange for a decryptor service. A flaw in the encryption algorithm was discovered that allowed files to be decrypted without paying the ransomware, and eventually, the malware developers released the master key allowing all encrypted files to be recovered easily.
Threat Breakdown
Win.Ransomware.Djvu-10002408-1
Indicators of Compromise
IOCs collected from dynamic analysis of 19 samples
Registry Keys
Occurrences
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION Value Name: SysHelper
19
<HKCU>\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\RUN Value Name: SysHelper
19
Mutexes
Occurrences
{1D6FC66E-D1F3-422C-8A53-C0BBCF3D900D}
19
M5/610HP/STAGE2
17
IP Addresses contacted by malware. Does not indicate maliciousness
Occurrences
162[.]0[.]217[.]254
19
149[.]154[.]167[.]99
18
116[.]202[.]7[.]239
17
211[.]40[.]39[.]251
5
210[.]182[.]29[.]70
4
201[.]124[.]33[.]177
4
175[.]126[.]109[.]15
3
211[.]171[.]233[.]129
3
211[.]59[.]14[.]90
2
175[.]119[.]10[.]231
2
175[.]120[.]254[.]9
2
123[.]140[.]161[.]243
2
190[.]141[.]35[.]3
2
2[.]180[.]10[.]7
2
95[.]158[.]162[.]200
2
190[.]219[.]153[.]101
2
211[.]119[.]84[.]112
1
186[.]182[.]55[.]44
1
58[.]235[.]189[.]192
1
190[.]229[.]19[.]7
1
49[.]12[.]115[.]154
1
187[.]156[.]85[.]108
1
Domain Names contacted by malware. Does not indicate maliciousness
Cisco Talos recently discovered a memory corruption vulnerability in the Mitsubishi MELSEC iQ-F FX5U programmable logic controller that is caused by a buffer overflow condition.
The iQ-F FX5U is one offering in Mitsubishi’s MELSEC PLC line of hardware that comes with a built-in processor, power supply, Ethernet and 16 I/O points. Users can configure this PLC to host multiple network services, such as an HTTP Server, FTP Server, FTP Client, MODBUS/TCP interface and other Mitsubishi-specific protocols.
A vulnerability, TALOS-2023-1727 (CVE-2023-1424), exists in the device’s MELSOFT Direct functionality that is triggered if an adversary sends the targeted device a specially crafted network packet.
This buffer overflow condition could lead to a denial-of-service condition within the RTOS task responsible for parsing the MELSOFT Direct protocol, and potentially give the adversary the ability to execute remote code on the targeted device.
Cisco Talos worked with Mitsubishi to ensure this vulnerability is resolved and an update is available for affected customers, all in adherence to Cisco’s vulnerability disclosure policy.
Users are encouraged to update these affected products as soon as possible: Mitsubishi Electric Corp. MELSEC iQ-F FX5U, versions 1.240 and 1.260. Talos tested and confirmed these versions of the controller could be exploited by this vulnerability, however, Mitsubishi also stated in its advisory that versions 1.220 and later are affected.
The following Snort rules will detect exploitation attempts against these vulnerabilities: 61432 and 61433. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Cisco Secure Firewall Management Center or Snort.org.
Editor's note: The Need to Know is a new series from Talos, which focuses on cybersecurity terms, threats, tools and tactics that are discussed in our broader threat research. Think of this as a living encyclopedia of security terms and trends.
In fact, not only were web shells the most observed threat overall, but they also appeared in almost a quarter of all incidents. That’s a marked increased from our previous trends report (the usage growing from 6% to 25%).
You may be wondering, why is that? Or maybe, what are web shells? And why do attackers use them in their campaigns? Let’s break it down:
The complexity of modern systems, especially websites that may include third-party software or libraries (that, in turn, make many outbound connections), means that malicious scripts that threat actors use for initial access, are easily missed.
After that initial access, malicious web scripts can leverage exploitation techniques, or are used to carry out further attacks.
How are web shells typically used in attacks?
Attackers will look for vulnerabilities within a system to find the best place (as far as they are concerned) to drop a web shell (or in many cases, multiple shells). Those vulnerabilities might be in a website content management system or an unpatched web server, for example.
The point of this is to establish a foothold to gain persistent access to a system. Imagine you’ve built a secret door that no one else knows about – you have the key, so you can return as often as you like.
Adversaries then have several options in front of them, depending on their ultimate motivation. We’ve seen them remotely execute arbitrary code or commands, as well as move laterally within the network, or deliver additional malicious payloads.
As noted in the Talos Q1 2023 Incident Response report, exploitation of public-facing applications was the top observed initial access technique, with the increased web shell activity likely contributing to this significant observation.
Notable example: China Chopper
China Chopper is a web shell that allows attackers to retain access to an infected system using a client side application, which contains all the information required to control the target.
In 2019, due to its significant use over the previous two years (including espionage campaigns), two Talos researchers took a closer look at the China Chopper web shell. They explored several cases studies where China Chopper was used.
How can you detect web shells?
A web shell will often leave sticky fingerprints at the scene. An intrusion prevention system such as Snort can help detect if an attacker has used a tool like a web shell to gain remote access.
Organizations should deploy endpoint detection and response tools such as Cisco Secure Endpoint, which gives users the ability to track process invocation and inspect processes.
Prevention recommendations
The increase in web shell engagements highlights the need for more awareness and protections in helping to prevent web shells. Talos provides the following recommendations:
· Routinely update and patch all software and operating systems to identify and remediate vulnerabilities or misconfigurations in web applications and web servers.
· In addition to patching, perform general system hardening, including removing services or protocols where they are unnecessary and being aware of all systems exposed directly to the internet.
· Disable unnecessary php functions in your “php.ini”, such as eval(), exec(), peopen(), proc_open() and passthru().
· Frequently audit and review logs from web servers for unusual or anomalous activity.
Code Query is a new, open source universal code security scanning tool.
CQ scans code for security vulnerabilities and other items of interest to security-focussed code reviewers. It outputs text files containing references to issues found, into an output directory. These output files can then be reviewed, filtered by unix command line tools such as grep, or used as a means to ‘jump’ into the codebase at the specified file:line reference.
One popular mode of use is to consider the output files as a ‘todo’ list, deleting references as they are reviewed and either considered false positives, or copying the references into some report file to either review in detail or provide the basis for a bug report.
The tool is extremely basic, largely manual, and assumes deep knowledge of application security vulnerabilities and code review. It does, however, have the advantages of being relatively fast and reliable, and working even when only partial code is available.
CQ is intended to be used in a security code review context by human experts. It is not intended for use in automated scenarios, although it might be applied in that context.
A common challenge technical teams (e.g. penetration testers) face is centralized deployment and pipelining execution of security tools. It is possible that at some point you have thought about customising several tools, buying their commercial licenses, and allowing a number of people to run the tools from AWS.
The problem is that this means you also have to deal with a bunch of tedious tasks like giving your team access to the EC2 instances, managing the IAM users, updating the OS to protect against privilege escalation, protecting tool licenses, powering the EC2 instances on and off as required.
Let’s imagine that we want to define a pipeline that we want to execute it continuously (e.g. a CI/CD pipeline). When given a range of IP addresses, it scans the UDP ports with Nmap, launches Nessus PRO to analyse the available ports for vulnerabilities and also runs ScoutSuite to evaluate an AWS account. Let’s further imagine that we want all this traffic to originate from a specific pool of AWS IP addresses, that the pipeline tools should be executed in a distributed manner and, while we’re at it, offer the user a web interface so as to abstract them from all the infrastructure that runs underneath.
CowCloud is a serverless solution to distribute workloads in AWS that can execute these pipelines. To get started, spin up an EC2 instance, access it, install Nmap, Nessus and register your Nessus pro license. Then download the ec2py/template.py file from the CowCloud repository and customise it to run both tools against one target and saves the output in the temporal folder `tmp_folder`.
Once you confirm that the template.py works, create a snapshot of the EC2 instance and save the AMI ID of the snapshot.
Next, clone the repository locally, open the Terraform/variables.tf file, and update the AMI variable with your AMI ID, and then simply follow the rest of the installation steps in the repository’s Readme.md.
At the end of the CowCloud deployment, access the URL shown in the Terraform output, log into the website, and queue a new task. Subsequently, the tasks will be consumed by the ec2py tool, which runs on an EC2 instance using your AMI as the base image. And the output/result/reports will be compressed, encrypted and uploaded to an S3 bucket so that the user can download the result of the Nmap and Nessus scans.
That’s all there is to it!
This solution is ideal for cases where you want to maintain an AMI with up-to-date commercial and open source tools and custom configurations for your pentests. With CowCloud, you can abstract users from the hurdles of maintaining and managing the infrastructure so that they only have to worry about the target. All they have to do is send a small amount of required information to the tools that run on the EC2 instances.
CowCloud can be used for a whole range of purposes – you may already have thought of some use cases yourself – but some of the more common ones are detailed below:
Baselining security testing. Use CowCloud to launch a series of tools that you consider as a baseline every time you do an external pentest (or participate in a bug bounty) and from a pool of EIPs from which the client expects to receive attacks
Centralized Tool Access and Management. Add API keys and commercial licenses to your AMI so you can provide your teams with the best and most relevant capability, while responsibly managing your licenses.
Distributed password cracking in AWS. Update the `instance_type` in the variables.tf file with one suitable for cracking passwords
EntropyReducer: Reduce The Entropy Of Youre Payload And Obfuscate It With Serialized Linked Lists
How Does It Work
EntropyReducer algorithm is determined by BUFF_SIZE and NULL_BYTES values. The following is how would EntropyReducer organize your payload if BUFF_SIZE was set to 4, and NULL_BYTES to 2.
Obfuscation Algorithm
EntropyReducer first checks if the input raw payload is of a size that's multiple of BUFF_SIZE, if not, it pads it to be as so.
It then takes every BUFF_SIZE chunk from the payload, and makes a linked list node for it, using the InitializePayloadList function, initializing the payload as a linked list.
The created node will have an empty buffer of size NULL_BYTES, that will be used to lower the entropy
At this point, although EntropyReducer completed its task by lowering the entropy of the payload, it doesn't stop here. It then continues to randomize the order of each node in the linked list, breaking down the raw payload's order. This step is done via a Merge Sort Algorithm that is implemented through the MergeSort function.
The sorted linked list is in random order because the value in which the linked list is sorted is the XOR value of the first three bytes of the raw payload, this value determines its position in the re-organized linked list, this step can be shown here
Since saving a linked list to a file is impossible due to the fact that it's linked together by pointers. We are forced to serialize it.
Serialization of the generated linked list is done via the Obfuscate function here.
After that, the serialized data is ready to be written to the output file.
Deobfuscation Algorithm
Since the last step in the Obfuscation Algorithm was serializing the linked list, the first thing that must be done here is to deserialize the obfuscated payload, generating a linked list from it, this step is done here in the Deobfuscate function.
Next step is to sort the linked list using the node's Id, which is done using the same Merge Sort Algorithm used before.
Now, the linked list is in the right order to re-construct the payload's bytes as they should. So we simply strip the payload's original bytes from each node, as done here.
Last step is to free the allocated nodes, which is done here.
Usage
EntropyReducer simply read the raw payload file from the command line, and writes the obfuscated version to the same file's name prefixed with ".ER".
The size of the final obfuscated payload varies depending on the values of both BUFF_SIZE and NULL_BYTES. However, it can be determined using the following equation
During Pwn2Own Toronto 2022, three different teams successfully exploited the Sonos One Speaker. In total, $105,000 was awarded to the three teams, with the team of Toan Pham and Tri Dang from Qrious Secure winning $60,000 since their entry was first on the schedule. Part of Pwn2Own competitions involves a random drawing for order. Not only does the team selected first get the full award if they are successful, but the subsequent entries are also more likely to have bug collisions. That means if three teams show up with the same exploit, only the first one randomly selected will get full credit. That’s not exactly what happened during the event, but some bug collisions did occur. In fact, there were four unique bugs used by the three different teams. Let’s take a look at the vulnerabilities used during the contest and see which team used which bug.
CVE-2023-27354 – The Unique libsmb2 Info Leak
With three different teams targeting the Sonos speaker, it’s obviously a huge advantage to go first. The team from Qrious Secure was randomly selected to go first, and they successfully exploited the speaker using a two-bug chain. This first bug used was this info leak, and they ended up being the only team to use this particular bug during the contest.
On the speaker, there exists a daemon named anacapad that handles all Sonos-specific functions, including accessing music services, LED control, and audio playback. The vulnerability exists in the way anacapad handles SMBv2 replies from a server, specifically in the smb2_process_query_directory_fixed() function that processes query directory reply data. It does this by allocating an smb2_query_directory_reply struct and storing the result in the Protocol Data Unit (PDU) pdu->payload field. The function then extracts the output buffer offset and length from the query directory reply from the server:
The speaker then checks that the output buffer does not overlap with the query directory reply header. The offset here will later be used to calculate the IOV_OFFSET:
This will also be used at:
The output_buffer here will later be used to decode file information from that directory PDU response from the server in the smb2_decode_fileidfulldirectoryinformation field. However, it never checks if the offset is within the len of a PDU packet. This can be leveraged to perform an information leak by acting as a SMB server and sending a malformed PDU query directory response with a large offset. The client will decode the file information from an out-of-bounds (OOB) memory region and send that information back to the malicious SMB server as part of a filename. By manipulating the offset, the SMB server can determine libc and heap addresses on the client, which are useful for the next step of the exploit chain.
CVE-2023-27353 – The Other Infoleak
The libsmb2 bug wasn’t the only infoleak we saw during the contest. Two of the teams used CVE-2023-27533/ZDI-23-448 to kick off their exploit. This vulnerability resides in the /msprox endpoint, which serves as a proxy for Sonos Speaker array communication. It forwards the user-supplied SOAP request to other registered speakers. When a user sends a request to this endpoint, the request is handled by function sub_15DFA0(), which in turn calls sub_1C86C0(). The following code snippet is from sub_1C86C0 in the anacapad binary, corresponding to assembly code from address 0x1C876C:
The code fails to check the return value of snprintf() at [1], and later uses this value as the size of an outgoing HTTP header buffer at [2]. The team from STAR Labs used this bug by sending a crafted request that provides overly long parameters to the snprintf() function at [1]. In this way, the return value from snprintf() (request_len) exceeds the size of the request buffer, which is 0x1000 bytes. At [2], it calls ana_server_send_request() to send the contents of the request buffer, using request_len as the length. STAR Labs used this out-of-bounds read (OOBR) vulnerability to leak the address of the .text segment.
The DEVCORE Team took a slightly different route to achieve the same effect. Their exploit relied on acting like a rogue Sonos Speaker adjacent on the network to the target. This allowed them to reach the following code, which contains an out-of-bounds read vulnerability analogous to the one discussed above. The result is leakage of stack data right after the request_body buffer.
From address location 0x1C889C:
While they took different approaches, both teams arrived at the same vulnerable code and leaked the data needed to continue their exploit.
CVE-2023-27352 – Remote Code Execution Through libsmb2
Now that we have our info leaks established, let’s take a look at how two teams leveraged that information for code execution. Both the Qrious Secure and STAR Labs teams leveraged a use-after-free (UAF) bug in the libsmb2 library. Again, since Qrious Securewas randomly chosen to go first, they won the full $60,000 while the bug collision resulted in STAR Labs earning $22,500.
Sonos provides SMB functionality by incorporating the open-source libsmb2 library with a few modifications. It runs within the anacapad daemon and can be reached by unauthenticated users to play music via the smb2 shared directory.
smb2_closedir is implemented as below in libsmb2:
And smb2_lazy_readdir is implemented as follows:
The main function handling data returned from an SMB server is as follows:
The control flow proceeds as follows:
(1) smb2_lazy_readdir -> smb2_fetchfiles_async -> smb2_cmd_query_directory_async -> create pdu (PDU) with internal message_id (MID) -> add to wait_queue (3)
When the client receives data from a server (4), it will decode the header (5) and find the PDU via its message_id (6). The interesting thing is that smb2_fetchfiles_async() function adds the PDU to wait_queue, which then holds a callback to fetchfiles_cb() at (7). This callback keeps the dir structure within its private data (8). Before it finishes, it invokes dir->cb callback at (9).
Back to (6), in a normal scenario, the SMB server will return the data with the valid message_id as MID, and the callback will be triggered before dir is freed in close_dir at (2). However, if the server sends an invalid message_id (different from MID), the PDU will not be found and will still be alive in wait_queue. Should this occur, the PDU will keep holding on to the dir struct pointer. When (2) finishes, the dir pointer will be freed, and the PDU will be left holding a dangling pointer.
The next time the client tries to read data from the server, if we reply with a previously valid message_id of MID, the client will decode the data and find the corresponding PDU via that MID. This time the PDU’s callback fetchfiles_cb will be called, and at (4) it will access the dangling pointer. By reallocating the freed dir structure before fetchfiles_cb is called, we can control the value cb and thereby gain control of $PC by pointing cb to maliciously crafted data.
Combined with the memory address leak from CVE-2023-27354, this vulnerability can be used to achieve remote code execution.
The STAR Labs team took a different approach to hit the same vulnerability. As stated above, the speaker allows us to play media files remotely using SMB using libsmb2. One of the added functions to this library is smb2_lazy_readdir(). Here is how they triggered the bug.
-- smb2_opendir() is called, which will return an smbdir (smb2dir structure).
-- smbdir is later passed into smb2_lazy_readdir() together with a custom callback function.
smb2_cmd_query_directory_async() receives a callback function with the following prototype and any user-defined structure (in this case smb2dir):
This function will then insert a pdu (smb2_pdu) into a request queue waiting to be handled. After a reply is received, the callback will be invoked with the received data. The Sonos device passes the smbdir structure as cb_data, then populates it inside the callback. This code snippet is in sub_109C0() function of the libsmb2.so.1 binary, corresponding to assembly code from address 0x10A04:
If wait_for_reply fails, meaning smb2_cmd_query_directory_async did not receive any valid response for its pdu, smb2_closedir is invoked to free thesmbdir object. Then smb2_disconnect_share function is called. However, during this process, a dangling pointer to smbdir is left in the request queue.
In smb2_disconnect_share, it calls wait_for_reply->smb2_service->smb2_service_fd->smb2_read_from_socket->smb2_read_data. In smb2_read_data, it uses smb2_find_pdu to retrieve the pdu based on the message_id of the response packet, which is controllable by the attacker. If our response specifies the message_id of the Query Directory pdu, smb2_find_pdu will return the smb2_cmd_query_directory_async’s pdu. Finally, when pdu->cb is invoked from z_query_directory_cb_109C0, the dangling pointer leads to $PC control.
Reclaiming the freed smb2dir object is accomplished by appending extra data onto the response packet from server. The client will allocate a buffer to store this extra padding data.
The exploit uses a modified impacket to implement a malicious smb server.
The exploit proceeds as follows.
Send a command to the target device to add a new SMB share.
Using a modified smb2QueryDirectory() function in the exploit’s impacket SMB server, return a malformed response to the client’s smb2_cmd_query_directory request, producing a dangling pointer.
When the client calls smb2_disconnect_share function, it sends a disconnect tree request to server. Using a modified smb2TreeDisconnect function in the impacket SMB server, the exploit returns a Query Directory response with the message_id from step 2. Additionally, the exploit appends data to this response to reclaim the smb2dir object in the client.
The exploit gains control of $PC via the overwritten smb2dir->cb pointer and uses ROP to get shell.
CVE-2023-27355 – Remote Code Execution via the MPEG-TS Parser
This remote code execution bug was used only by the DEVCORE team. Due to the random draw, this was the third attempt on the Sonos, which left them at a disadvantage as they were more likely to run into a bug collision. They did collide regarding their info leak, which we have already discussed above. However, the remote code execution portion of their exploit chain was unique and earned its own CVE.
While parsing a .ts audio file, the Sonos speaker does not check the length of the Adaptation field, which leads to a stack buffer overflow. The bug results from the ability to specify an arbitrary value to the afelen field. The speaker will then read the specified number of bytes into the payload buffer, smashing the stack.
From address: 0x406604
Since Sonos enables exploit mitigations, the attacker needs to leak some information first. During the contest, the DEVCORE entry first leaked the stack canary, stack address and program base address using the previously described CVE-2023-27353. Once they obtained those values, exploitation is straightforward. They used the MPEG-TS parser vulnerability to overwrite the return address and jump to the exec() wrapper.
As the #x19 and #x22 registers are also controllable by the exploit, the attacker can set these registers to a controllable stack buffer and execute arbitrary commands.
The end result was a successful demonstration during the contest, but due to the collision of CVE-2023-27353, the DEVCORE team didn’t win the full amount. Still, they earned $22,500 for being the third team to exploit the Sonos speaker during the event.
Wrapping Things Up
It’s always interesting to see different teams reach similar conclusions when targeting a piece of software. It’s equally as interesting when they take completely different paths but still end up with the same result. In this example, we had three different teams use a various combination of three different bugs to get code execution on a Sonos speaker. In the end, we awarded these teams a total of $105,000 for their efforts. Situations like this also highlight how bug collisions can encourage more thorough and innovative research to avoid duplicate entries in the future. All three of these teams had participated in Pwn2Own before, and we certainly hope they return for future events.
Now that many of the bugs disclosed during Pwn2Own Toronto are patched, we’ll continue to disclose some of those details on this blog. Until then, follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.
Welcome to this week’s edition of the Threat Source newsletter.
As a longtime macOS user, I must admit I’m behind the times when it comes to Microsoft Windows. Since buying a Steam Deck, I’ve actually come to learn more about Linux and the Proton compatibility layer than I ever did about Windows.
But it still came as a shock to me this week when I uncovered a weird trend on social media: People bragging about still using Windows 7.
Microsoft stopped putting out free security updates for Windows 7 in January 2020 and only more recently stopped offering its paid Extended Security Updates (ESU). The company explicitly told users at the beginning of this year that it was unsafe to continue to keep using Windows 7 and that users should upgrade to Windows 10 or use a new machine that can run Windows 11.
I’m sure there are other examples of this among other types of software, but video games are the most specific corner of the internet I’m in, so that’s my frame of reference.
The moral of the story here is that using Windows 7 to do anything, but especially connecting to the internet (which is required to download and play video games) is a terrible idea. Attackers are always targeting outdated operating systems because they’re the most likely to be unpatched and vulnerable.
Running an operating system that is no longer receiving any type of security updates is extremely dangerous. If infected, that single machine could also be used as a springboard for the attacker to target and infect other machines on your network.
Just because something is old, doesn’t mean that attackers aren’t paying attention anymore. Without official support or security updates for Windows 7, Microsoft is no longer compelled to disclose formal vulnerabilities with CVEs attached to inform users about any security holes in the operating system.
Upgrading a PC or buying a new one is expensive, I get it. But Windows 7 isn’t a novelty anymore, it’s a security risk. If you feel like you absolutely have to keep Windows 7 running on a machine for some reason, make sure it is isolated from your network or just doesn’t connect to the internet at all.
But more preferably, upgrade to Windows 10. If you’re already using Windows 7, it’s free, and likely whatever hardware you’re using can support Windows 10. If you’re starting from scratch, many online stores have deeply discounted product keys for Windows 10 or 11 for $20 or less — just make sure to download the ISO directly from Microsoft still.
The one big thing
Montana recently became the first state in the U.S. to ban the app TikTok, though the law still has a long way to go before it can be enforced. The state’s governor signed a bill last week that prohibits mobile application stores from offering the app in the state by the start of 2024, or else they’ll face fines. However, it’s currently unclear if it’s even feasible for Montana to enforce this ban, as app stores don’t geofence certain applications on its stores, and internet service providers are exempt from having to enforce these rules. TikTok has recently become a target for Republican lawmakers over concerns that its Chinese-backed parent company is collecting and using Americans’ data. TikTok and popular TikTok creators in Montana have already sued the state to stop the law.
Why do I care?
Even if you are not an active TikTok user, the ban is noteworthy because it has major implications for American law and the enforcement of the First Amendment in the U.S. Opponents of Montana’s bill say it's a clear violation of the First Amendment. The various legal challenges are likely going to shift through the legal system for months, but any eventual decisions could influence how states view banning certain technology or even books and movies.
So now what?
There are many questions still unanswered about how this ban will work or whether it will stand. So for now, interested parties can’t do much but sit back and wait for the legal proceedings to play out.
Top security headlines of the week
Apple released a security update for many of its devices last week that fixed three zero-day vulnerabilities in the WebKit browser engine. A few days after the patches initially dropped, security researchers also discovered the updates addressed a different vulnerability known as “ColdInvite” (CVE-2023-27930). An attacker could exploit ColdInvite to attack a co-processor chip on iPhones and escape its isolation environment, eventually accessing the iPhone’s kernel. The three WebKit vulnerabilities affect some iPhones and iPads. CVE-2023-28204, CVE-2023-32373 and CVE-2023-32409 could be exploited to escape the Web Content sandbox. Google’s Threat Analysis Group and Amnesty International co-reported CVE-2023-32409, which led many security experts to speculate means attackers exploited this issue to spread spyware. (SecurityWeek, Forbes)
Two popular Android set-top TV boxes sold on Amazon are preloaded with malware that quietly generates revenue for the manufacturers in the background. The devices click on ads while running without the user knowing and connect to a global botnet of other infected Android devices around the globe. Despite the reported security issues, the devices were still for sale on Amazon as of earlier this week. However, the security researcher who discovered this botnet worked with the internet company hosting the command and control servers that sent directions to devices part of the botnet to take those servers down. However, that doesn’t mean the botnet or ad-click malware could never come back — the easiest solution for users is to replace the devices immediately. (TechCrunch, ArsTechnica)
Security researchers are concerned that two new top-level domains from Google — .zip and .mov — will cause confusion among users and potentially open the door for scammers. Because these new TLDs (like .com, .gov, .uk, etc.) are the same as popular file extensions, adversaries could disguise legitimate-looking file names and actually send people to a malicious web address without the user knowing that it could even be a web page. They could also be used to create legitimate-looking URLs that match that of a real website but just add one character in a long string, eventually pointing people to a malicious file or site. However, Google says it's actively monitoring for domain abuse. (Wired, Ars Technica)
We would like to thank The Citizen Lab for their cooperation, support and inputs into this research.
Commercial spyware use is on the rise, with actors leveraging these sophisticated tools to conduct surveillance operations against a growing number of targets. Cisco Talos has new details of a commercial spyware product sold by the spyware firm Intellexa (formerly known as Cytrox).
Our research specifically looks at two components of this mobile spyware suite known as “ALIEN” and “PREDATOR,” which compose the backbone of the spyware implant. Our findings include an in-depth walkthrough of the infection chain, including the implants’ various information-stealing capabilities.
A deep dive into both spyware components indicates that ALIEN is more than just a loader for PREDATOR and actively sets up the low-level capabilities needed for PREDATOR to spy on its victims.
We assess with high confidence that the spyware has two additional components — tcore (main component) and kmem (privilege escalation mechanic) — but we were unable to obtain and analyze these modules.
If readers suspect their system(s) may have been compromised by commercial spyware, please consider notifying Talos’ research team at [email protected] to assist in furthering the community’s knowledge of these threats.
ALIEN and PREDATOR part of growing rise in spyware use
Threat actors’ use of commercial spyware has been on the rise, and the number of companies supplying these products and services seems to keep growing. Most commercial spyware is intended for government use, with firms like NSO Group advertising their products as technology that helps prevent terrorism, investigate crime, and enhance national security. However, in recent years, ethical and legal questions have swirled around the use of these surveillance tools, which have become known in the security community as “mercenary spyware.” As a response to the rapid proliferation and growing concern over the misuse of these products, on March 27, 2023, the Biden-Harris administration signed an Executive Order prohibiting the U.S. government from using commercial spyware that poses national security risks or has been misused by foreign actors to enable human rights abuses.
Spyware suppliers take great care to make the final payloads difficult to detect, obtain, analyze and protect against by creating deployment sequences that often require little or no user interaction. The delivery mechanism is usually an exploit chain that can start a zero-click exploit, like FORCEDENTRY, which is produced by Israeli spyware firm NSO Group, or with a link that the victim is tricked into clicking (i.e., a “one-click” exploit), like the one created by the surveillance company Cytrox to deploy their own spyware known as “PREDATOR.” (Note: Cytrox is owned by Intellexa, which sells the PREDATOR spyware.)
PREDATOR is an interesting piece of mercenary spyware that has been around since at least 2019, designed to be flexible so that new Python-based modules can be delivered without the need for repeated exploitation, thus making it especially versatile and dangerous.
New analysis from Talos uncovered the inner workings of PREDATOR and the mechanisms it uses to communicate with the other spyware component deployed along with it known as “ALIEN.” Both components work together to bypass traditional security features on the Android operating system. Our findings reveal the extent of the interweaving of capabilities between PREDATOR and ALIEN, providing proof that ALIEN is much more than just a loader for PREDATOR as previously thought to be.
Intellexa spyware framework
Intellexa’s spyware products, like most recently exposed spyware tools, have multiple components that can be grouped into three major buckets aligned with consecutive stages of the attack:
The first two — exploitation and privilege escalation — are often grouped in exploit chains, which start by exploiting a remote vulnerability to obtain remote code execution (RCE) privileges, followed by mitigation circumvention and privilege escalation, since the vulnerable processes are often less privileged.
An example of the initial chain is covered in detail in this 2021 blog post from Google TAG. The report describes how adversaries exploited five different zero-day vulnerabilities to deliver ALIEN, the implant in charge of loading the PREDATOR spyware. The vulnerabilities, which were discovered in 2021, are CVE-2021-37973, CVE-2021-37976, CVE-2021-38000, CVE-2021-38003 — all of which affect Google Chrome, and CVE-2021-1048 in Linux and Android.
While ALIEN and PREDATOR can be used against Android and iOS mobile devices, the samples we analyzed were specifically designed for Android. For privilege escalation, the spyware is configured to use a method called QUAILEGGS, or, if QUAILEGGS is not present, it will use a different method called “kmem.” The samples we analyzed were running QUAILEGGS.
There is no way to know for sure what vulnerability QUAILEGGS exploits without having access to the code itself. Nevertheless, we decided to share our assessment in hopes that other researchers might be able to add to it.
We assess that QUAILEGGS likely exploits the aforementioned zero-day vulnerability CVE-2021-1048. Based on Google’s root cause analysis, this vulnerability allows code injection into privileged processes, which is exactly what happens with ALIEN when QUAILEGGS is used. According to the Linux kernel development git logs, the vulnerability was public since August 2020 and patched in September. However, some Google Pixel phones remained vulnerable until March 2021 and Samsung devices until at least October 2021.
From the PREDATOR components Cisco Talos had access to, we assess that there are at least two more components that we have not been able to analyze: “tcore” and "kmem.”
The tcore Python module is loaded by loader.py, the key instrumentor module, after all initializations are completed.
Loader module importing tcore.
If tcore fails to load, the loader deletes the downloaded encrypted SQLite3 file. It first tries to delete the file, and if that fails, attempts to open the file for write operations and write zero bytes to it to wipe it clean, effectively eradicating the file contents without deleting the file itself.
We assess that the tcore Python module contains the core spyware functionality. Analysis of the native code inside ALIEN and PREDATOR indicates that the spyware can record audio from phone calls and VOIP-based applications. It can also collect information from some of the most popular applications, including Signal, WhatsApp and Telegram. Peripheral functionalities include the ability to hide applications and prevent applications from being executed upon device reboot.
The second component we are missing is the artifact that implements the KMEM module. Based on our analysis of the “_km” python module, we assess that KMEM provides arbitrary read and write access into the kernel address space.
Access gained by exploiting CVE-2021-1048 would allow the spyware to execute most of its capabilities, including loading and executing additional payloads at SYSTEM level. Eventually, this could lead to the user gaining kernel access and making configuration setting changes to kmem.
Spyware implant architecture and overview
ALIEN/PREDATOR teamwork
The spyware implant runs a variety of processes to bypass the inherent restrictions of Android’s security model. The spyware takes the “__progname” of the process that is currently running and then uses it to decide what set of functions to call. The processes looked for are: zygote64, system_server, installd, audioserver (alien_voip) and a second version of audioserver (alien_recorder).
The zygote64 and system_server call chains are the ones that do the most work while the installd call chain sets up the file structures for the other portions of the spyware. Each of these call chains set up a process structure used to intercept specific ioctl commands, where the spyware uses the functionality of that process to abuse the SELinux context to grant different functionality to the other processes.
The image below shows an example in which the SELinux policy-applied zygote process prevents all kinds of access to sockets, except for Unix-type local ones.
However, by storing the recorded audio in a shared memory area using ALIEN, then saving it to disk and exfiltrating it with PREDATOR, this restriction can be bypassed. This is a simplified view of the process — keep in mind that ALIEN is injected into the zygote address space to pivot into specialized privileged processes inside the Android permission model. Since zygote is the parent process of most of the Android processes, it can change to most UIDs and transition into other SELinux contexts that possess different privileges. Therefore, this makes zygote a great target to begin operations that require multiple sets of permissions.
The ALIEN component configuration contains the URL to download the PREDATOR component. During the initialization, it starts the download and calls its main_exec() function by importing it using dlsym(), thus initializing the main component of the spyware. It is unclear how ALIEN is initially started, but it is highly likely that it is loaded from the shellcode executed by the exploits used in the initial stage.
Download URL for PREDATOR in ALIEN.
ALIEN is also responsible for updating PREDATOR after, for instance, secondary exploitation.
If the configuration contains the string “_refresh”, the file downloaded will be stored as fs.db that will be processed by the sqlimper.py module residing inside PREDATOR and not ALIEN, thus strengthening our findings that these two modules are highly dependent on each other. It is worth noting that fs.db is an SQLite3-encrypted database that may contain new configuration settings or serialized Python code, thus making it extremely modular and adaptable spyware.
ALIEN and PREDATOR also communicate via binder transactions. During its initialization routines, ALIEN hooks ioctl() to catch binder transactions arriving at its host process. A detailed example of this method of communication can be seen in the audio recording feature description ahead.
ALIEN overview
ALIEN is the primary worker component for the spyware. Once deployed, downloads and activates the remaining components according to the configuration that has been hardcoded into its own binary. We assess with high confidence that ALIEN is injected into a privileged process address space and is then launched in an independent thread.
Initially, ALIEN checks if it has been loaded into zygote64. If this check is positive, it will go ahead and perform its activities. If needed, it will download the PREDATOR component from a hosting site defined in the configuration. Optionally, this can be a refresh, in which case the already existing PREDATOR will be replaced by a new version, meaning a second exploitation of the target device was performed and a new version of tcore is installed. Keep in mind that this is tcore and not the entire PREDATOR payload. ALIEN’s configuration also includes the location for its working directory which is actively utilized for carrying out tasks such as data exfiltration etc.
An example of one such working directory is “/data/local/tmp/wd/”. Spyware artifacts such as PREDATOR and SQLite3-encrypted database files can be found on it.
Path
Purpose
/data/local/tmp/wd/pred[.]so
PREDATOR spyware shared library
/data/local/tmp/wd/fs[.]db
SQLITE3 file containing additional payloads
ALIEN is not just a loader but also an executor — its multiple threads will keep reading commands coming from PREDATOR and executing them, providing the spyware with the means to bypass some of the Android framework security features. Before launching PREDATOR, there are several steps that need to be performed:
Hooking the ioctl() API in the libbinder.so using an open-source library called xHook is one of the means it uses to communicate with PREDATOR. The distributed nature of the spyware requires component communication and synchronization to work properly. The spyware framework has several means of achieving this communication and synchronization.
ALIEN hooks the ioctl() function in libbinder.so, which is responsible for inter-process communication (IPC) in the Android framework. The ioctl hooks are structured to allow the implant to communicate with itself (on forked processes) and with other implant components.
Hooking ioctl.
When the implant begins executing, it selects which application context it’s running within. After this activity starts, it will record the thread ID that it is running inside, then register a hook on the ioctl activity in that process. This ioctl hook manages a variety of different binder commands, inside of the BINDER_WRITE_READ IOCTL command. This hook filters all the BINDER_WRITE_READ functions to ALIEN’s own handler commands.
The commands that are redirected include BC_TRANSACTION, BR_TRANSACTION, BR_REPLY, BC_REPLY. This allows the control of information into and out of the target process. Within each of the selected processes mentioned above, there are different actions a malicious module could then take on the system.
This creates an effective way to communicate within the implant while also allowing the implant to hide within other legitimate system processes. The implant communicates discreetly with itself, without network-based indicators and avoiding SELinux restrictions.
On the instalID process, the implant hooks BR_TRANSACTION and BC_REPLY. Each of the commands takes the same action. It then spawns a thread and moves toward recursively changing the permissions of 26 directories belonging to applications and users’ media. Each application has a list of flags associated with it referencing what vendor will likely possess the application and whether to apply the new permissions to said app. In this sample, each application is given the permissions of 777, although the spyware supports an extension of any value. ALIEN also gives them an SELinux context consistent with the configuration of the spyware “u:object_r:shell_data_file:s0” using the function setfilecon. These files (applications) are copied into the configuration directory where the spyware resides, likely to be extracted later.
PREDATOR overview
PREDATOR is a pyfrozen ELF file that contains serialized Python modules and native code used by either of the built-in modules or downloaded modules. ALIEN launches PREDATOR, calling the main_exec() exported function with a parameter that contains two file descriptors. These are shared memory area file descriptors created by ALIEN to be used as a medium for communication between the two components.
The PREDATOR main_exec() function is a simple function that will duplicate the file handles and launch PREDATOR’s real main function on a native thread, thus ensuring it can run without being blocked by ALIEN processes or the main process execution.
Initialization process for PREDATOR.
This threat will call the startPy() function which prepares the Python runtime environment to be used by the spyware. Like any other pyfrozen binary, it starts by importing the usual “__main__” module. Then, it defines the following attributes to the “__main__”:
Name
Usage
SHMEMFD_PC2
Shared memory handle for communication with ALIEN
SHMEMFD_VSS
Shared memory handle for communication with ALIEN
DEV
Defines if the current PREDATOR implant is a development version or not. This will have impact in the amount of logging performed
installID
An installation ID that can be related to the victim, device or campaign. The value is hardcoded in the initialization time.
The final activities are the import of another module called loader whose main subroutine, a Python function called “mainExec” will be called. It is interesting to note that the installation ID is hardcoded in the native code with a specific value but, in the Python module loader.py, the value is initialized with a placeholder value. Once the Python runtime is properly initialized, PREDATOR will proceed to initialize and start the spyware tcore component.
Spyware capabilities
When used together, these components provide a variety of information stealing, surveillance and remote-access capabilities. The functionalities described here are just a subset of the comprehensive capabilities of the spyware. At this time, Talos does not have access to all components of the spyware; therefore, this capability list should not be considered exhaustive. We believe that capabilities like geolocation tracking, camera access or the ability to make it appear as if the phone is powering off may have been implemented in the tcore module.
Arbitrary code execution
ALIEN also can read and execute code from specified locations on the filesystem. For example, the implant can inject code that was read earlier from “/system/fonts/NotoColorEmoji.ttf” into the system_server process memory for execution.
Inject and wait for the result.
The spyware architecture is highly reliable on process-based parallelism. The shell code is injected after a fork() call, the child process will inject the shell code, execute it and exit. Meanwhile, the parent process will wait for the execution of the shell code for five seconds before returning. Given the code flow, we assess with medium confidence that the injected shell code takes the content of “/data/system/.0” as a parameter.
The overall injection process is achieved using ptrace() and mmap() to inject the code into the target process.
Overall injection flow.
Audio recording
This spyware can record audio from different sources by several means. It can record from microphone, earpiece- and VOIP-based calls, using deep-level techniques like memcpy hooking inside audio-related processes, or more simply, creating a RECORD interface using the OpenSLES native library. This capability is spread across the two components and just like any other component it can be started from the Python environment loaded by PREDATOR.
Audio recorder command codes.
This capability's internal name is pc2. The screenshot above shows the preparation of the Python environment with the constants that will be used as commands between the ALIEN and PREDATOR modules. PREDATOR implements the native code that will be responsible for the communication with ALIEN, on one side, and exposes that code to the Python interpreter so it can be called from the tcore module.
ALIEN attempts to hook the following APIs in the audio libraries being used by a process. The APIs are hooked using the xhook framework. These hooks are established to copy the source data served to the legitimate APIs into a buffer allocated and specified by the spyware.
Lib name
Function to be hooked
libaudioutils.so
memcpy_by_audio_format
.*\\libaudiohal.*.so$
memcpy
.*\\libaudioflinger.so$
memcpy
Hooks created in audio libraries using xhook.
Another set of interception measures deployed by ALIEN includes the setting up of ioctl hooks and a recorder interface. These hooks intercept and identify the operations being carried out/requested by the recorder to copy data into locations defined by the spyware.
These mechanisms target the audioserver process on the device and are meant to essentially record audio from the VOIP and voice recording interfaces. Although the whole infrastructure to enable voice recording is set up by ALIEN, it is primarily operated by PREDATOR, which is responsible for issuing commands to either start or stop recording. This is yet another example of the close relationship between ALIEN and PREDATOR to carry out essential malicious activities on the infected devices.
Adding certificates to the store
The spyware can also add certificates to the current user-trusted certificate authorities by writing the certificate authority’s (CA) public certificate to the path “/data/misc/user/0/cacerts-added”, as shown below.
Even though the spyware has high privileges, it doesn't attempt to add the certificates at the system level. That kind of operation could interfere with the normal functioning of the device. Some versions of Android would even require the remount of the filesystem with read-write permissions. If anything was to go wrong during TLS decryption at the system level, the device may become unstable, likely tipping off the victims. From an attacker’s perspective, the risks outweigh the reward, since with user-level certificates, the spyware can still perform TLS decryption on any communication within the browser.
Application hiding and preventing execution on reboot
Read the contents in “/data/system/.0” and use that as an input for establishing hooks in Android runtime (ART) using a custom version of the YAHFA framework. The way that the hooking works is that ALIEN contains an embedded DEX file which is loaded using the InMemoryClassLoader() method.
Embedded DEX in ALIEN
The customized version inside the DEX contains, what seems to be a plugin, called “com.jnative.pluginshideapp”, which implements the methods mentioned below.
getInstalledApplications
getInstalledPackages
queryIntentActivitiesInternal
queryIntentReceiversInternal
Malicious plugins with Hooks defined for Package Manager APIs.
The DEX file thus uses these hooks for two key purposes:
Hiding Applications/packages: The plugin in the DEX can hook and filter out a specific package/application name from the list of installed packages and applications.
Prevent execution on Reboot: The plugin can also hook and be used for filtering out specific names from the list of packages/applications to be run when the BOOT_COMPLETED intent is received via broadcast.
Filtering of applications and packages based on their “packageName” field.
To filter the application/package lists for hiding or disabling them on reboot, the DEX file hooks the original API calls, replacing them with its own custom code. Every time a call is made to the hooked method, the custom code will check the destination list against its own list, removing any matches of application and package names it intends to hide. Filtering of the list is followed by the call to the original API with the filtered list now being used as its argument.
The code we analyzed only implements the BOOT_COMPLETED broadcast, which prevents an application from starting after reboot. This same method could be implemented for other broadcasts, modeling the behavior of other applications in the process. For example, it could do the same for the SMS_RECEIVED broadcast notification, preventing SMSs from reaching the user. This can be considered a more aggressive method of interception use instead of the more commonly used technique of installing an application that receives SMS_RECEIVED broadcasts with higher priority.
Get system information
The spyware uses a variety of sources to gather information about the system. It will enumerate various directories on the file system and read multiple files to extract as much statically available data from the infected device.
Enumerating directories
The ALIEN implant will first get the device manufacturer name from the system property “ro.product.manufacturer”. It checks for specific manufacturers from a hardcoded list:
Samsung
Huawei
Oppo
Xiaomi
If any of these manufacturers' names match, it will recursively enumerate the contents of the following directories on disk:
/data/local/tmp/wd - This is the directory used by ALIEN to store stolen data from the device.
Browser apps
/data/data/com.android.chrome
Getting Configuration Data
The implant gathers configuration information, but it will also collect contacts, calls and messaging information by copying the content of the files listed below.
The implant will again check for the manufacturer names and then read data from the following files:
The content obtained is then written to “/data/local/tmp/wd/”, before being exfiltrated. This can be considered a low-level method of collecting information. Spyware with fewer privileges on the system usually uses the Android framework API to collect such information. This method, however, requires user interaction to provide the necessary permissions.
Coverage
Cisco Secure Endpoint (formerly AMP for Endpoints) is ideally suited to prevent the execution of the malware detailed in this post. Try Secure Endpoint for free here.
Cisco Secure Web Appliance web scanning prevents access to malicious websites and detects malware used in these attacks.
Cisco Secure Email (formerly Cisco Email Security) can block malicious emails sent by threat actors as part of their campaign. You can try Secure Email for free here.
Cisco Secure Malware Analytics (Threat Grid) identifies malicious binaries and builds protection into all Cisco Secure products.
Umbrella, Cisco's secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network. Sign up for a free trial of Umbrella here.
Cisco Secure Web Appliance (formerly Web Security Appliance) automatically blocks potentially dangerous sites and tests suspicious sites before users access them.
Additional protections with context to your specific environment and threat data are available from the Firewall Management Center.
Cisco Duo provides multi-factor authentication for users to ensure only those authorized are accessing your network.
Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.
IOCs
Indicators of Compromise associated with this threat can be found here.
Login
