XCSSET Update: Abuse of Browser Debug
Modes, Findings from the C2 Server, andan Inactive Ransomware Module
AppendixIntroduction
In our first blog post and technical brief for XCSSET, we discussed the depths of its dangers for Xcodedevelopers and the way it cleverly took advantage of two macOS vulnerabilities to maximize what it cantake from an infected machine. This update covers the third exploit found that takes advantage of otherpopular browsers on macOS to implant UXSS injection. It also details what we’ve discovered frominvestigating the command-and-control server’s source directory — notably, a ransomware feature thathas yet to be deployed.

Recap: Malware Capability List
Aside from its initial entry behavior (which has been discussed previously), here is a summarized list ofcapabilities based on the source files found in the server:
••
•

•
•
•
•
•
•
•
•

Repackages payload modules to masquerade as well-known mac apps
Infects local Xcode and CocoaPods projects and injects malware to execute when infected
project builds
Uses two zero-day exploits and trojanizes the Safari app to exfiltrate data•
Uses a Data Vault zero-day vulnerability to dump and steal Safari cookie data•
Abuses the Safari development version (SafariWebkitForDevelopment) to inject UXSS
backdoor JS payload
Injects malicious JS payload code to popular browsers via UXSS
• Exploits the browser debugging mode for affected Chrome-based and similar browsers
Collects QQ, WeChat, Telegram, and Skype user data in the infected machine (also forces theuser to allow Skype and WeChat access to security and privacy settings)
Collects Evernote and Notes.app data in infected machineCollects screenshots of the infected machine's current desktop
Collects target files and sends them to the server (Xcode projects, files based on server query)
Encrypts files under certain folders and displays a ransom note to possible targeted victims
Disables firewall and automatic updates on the infected machine
Sets up remote SSH for remotely accessing the victim machine

Abuse of the Remote Debug Mode in PopularBrowsers
While the malware authors have given specific attention to Safari, they have also created other modules
for downloading and executing malware masquerading as other browsers, which then launch thedebugger modes of legitimate browsers to hijack them and perform UXSS backdoor injection. These aredownloaded to ~Library/Containers/com.apple.Siri/Data/.
The following is a list of browsers aside from Safari that these modules affect:

••
•
•
•
•
•

Brave by Brave Software (brave_remote)
Google Chrome (chrome_remote, chrome_data)
Microsoft Edge (edge_remote)Mozilla Firefox (firefox_remote)Opera (opera_remote, opera_data)
Qihoo 360 Browser (360_remote)Yandex Browser (yandex_remote)In the “remote” modules, the script first kills the legitimate process of the browser.

Figure 1. Code killing legitimate browser process
It then downloads and executes a file from the server that poses as the affected browser.

Figure 2. Downloading and executing the fake browser
Below is an analysis of the downloaded browser file agentd (from chrome_remote):
It does not perform any operation on first execution. But on the second execution initiated by the userwhen accessing the URL appleid.apple.com, we can see the payload that it deploys:

Figure 3. The second execution of agentd

Here is how the file progresses during payload execution:

Figures 4. Progression of execution in agentd
What’s notable here is that the malware launches the normal browser in remote debugging mode so thatit can manipulate every page in the browser, which includes the JavaScript injection. It also uses thissame trick in other Chrome-based browsers with their respective remote binary module:•firefox_remote (firefoxd)

Figure 5. Reference code in firefoxd that indicates launching the browser in remotedebugging mode
Notably, there is a difference in the executed behavior compared to agentd — mainly
changing its default preferences regarding the debugger version of the software.

In the default config file prefs.js, it simply tells the user not to edit the file, yet themalware can edit this for its own gain.

Figure 6. Default preferences of firefoxd
By default, Firefox will attempt to deny the remote debugger execution:

Figure 7. Default Firefox configuration
It will also prompt the user when a new debugging client is attempting to connect:Figure 8. Firefox debug request

The malware looks for the default configuration file for browser preferences, thenmodifies certain default entries related to the features mentioned above:
1. Enable remote debugging
2. Enable chrome options
3. Disable GUI that prompts when the opened debugged browser tried to connect
4. Disable Content Security Policy (CSP) feature
5. Disable automatic updates

Figure 9. Executed commands by firefoxd
By doing so, it sets up the browser so it won’t notify the victim user when the debugger
version of the browser runs and performs the malware’s tasks.
•edge_remote (edged)

Figure 10. Reference code in edged that indicates launching the browser in remotedebugging mode•

opera_remote (operad)

Figure 11. Reference code in operad that indicates launching the browser in remotedebugging mode
Opera has implemented an additional safeguard in their browser to warn users, whichtakes effect in this attack as well:Figure 12. Page warning in Opera when operad is executed, and the user accesses asite that has been hijacked to steal credentials
By giving the users the ability to cancel unwarranted access to the hijacked site, thismakes it difficult for the malware to steal user credentials in the Opera browser. We
hope other browser vendors implement the same feature in the future.
•360_remote (speedd)

Figure 13. Reference code in speedd that indicates launching the browser in remotedebugging mode•yandex_remote (yandexd)•Figure 14. Reference code in yandexd that indicates launching the browser in remotedebugging mode
brave_remote (braved)

Figure 15. Reference code in braved that indicates launching the browser in remotedebugging mode
The browser debugging mode feature is not just used in macOS, but on Windows as well — we tested
this on Windows and confirmed that it works.
Given that the normal and debugger modes of these browsers barely exhibit any UI difference in the eyesof a regular user, the malicious browser files can launch their legitimate counterparts to make themappear to behave as normal, while the malicious JavaScript payload executed steals user tokens andpasswords without the user realizing it.
We believe the key to protecting users is to have web browsers implement a password authentication oralert mechanism for the user when accessing the debugging mode. While Opera has a feature forwarning users about suspicious connections, only Firefox has an alert in its default configuration,although malware can still bypass this feature.

Server Backend Files
Here are some notable backend scripts to which other installed payload modules also connect to send
and receive information from the server.

Agentd.php
The file agentd.php is the main code responsible for the browser backdoor UXSS injection, which has
been discussed previously. The planted Safari and other affected browser executables connect to this fileon the server to perform the backdoor payload:
••
•
•
•

Manipulate browser results
Manipulate and replace found bitcoin and other cryptocurrency addresses
Replace Chrome download link with a link to an old version package
Steal Google, Yandex, Amocrm, SIPmarket, Paypal, Apple ID credentials
Steal credit card data linked to the Apple Store••Prevent the user from changing passwords but can also record new passwords if changed
Take screenshots of certain accessed sites

Upload.php
This PHP script is responsible for uploading files from the victim machine to the server. It has special logic
in its code for handling uploads from the “screen” payload module. It uses a module named
SpacesConnect to upload screenshots taken by the screen module.

Figure 16. Special logic for uploading files from screen module
According to the SpacesConnect module’s readme file, it is an API module for accessing a 3rd party
online storage provider, DigitalOcean.

Figure 17. The SpacesConnect module’s readme fileIts code reveals that finally, all the screenshots are stored in AWS S3 storage.

Figure 18. Data is stored in AWS S3
We can see that for a single victim, the screenshots were taken in approximately 30-second intervals,
which is why they need to use AWS S3 to store all the files.

Figure 19. screenshot file logs

Translate.php and GoogleTranslateForFree.php
translate.php is a simple wrapper for GoogleTranslateForFree.php. These two modules are used totranslate certain messages from English to the victim’s local language in real time, before these areshown to the victim.

Cron_comeback.php
The cron_comeback PHP script first defines a dictionary to store certain victim information, whichcontains the user name and related contract search condition. The script we found only contains a short,hardcoded list of targets; these seem to be either the initial targets of the attack or it’s a list that will
eventually be populated with more relevant victims.

Figure 20. Screenshot of target list in cron_comeback.php
It then searches for all of the victims’ files with the defined search condition in the upload folder. If found,then it compares the contract file hash with the old hash; if the hash has been changed, then it calls
sendMessage() to alter for a returning user.

Figure 21. Code block of collecting files

Common.php
The common PHP script defines some command data and functions to be used in other modules. In thesendMessage() function, it leverages Telegram to send messages back.

Inactive Ransomware Modules
We discovered a critical set of modules that exhibit ransomware capabilities, but they have not been
deployed to any of the victims so far. We believe it may be possible that this module isn’t part of thedefault modules to execute automatically because the actors will first need to evaluate if the victims are
reputable enough to be exorted:

Rnd
The rnd.applescript module first calls the modules ransom_ui and ransom_block. However, in the code
before these two modules, the encryptor module and a 600 sleep are present but currently commented
out.

Figure 22. Screenshot calling other ransomware modules

Encrypter
The encrypter module performs AES CBC encryption on files under ~/Documents, ~/Downloads, and~/Desktop with a fixed key. Only files with a size lower than 500MB were encrypted.

Figure 23. Screenshot of the search and encrypt logic

Ransom_ui
The ransom_ui module sends a request to a server to get the ransom note, which will then be displayed
to the victim.

Figure 24. Screenshot of code block preparing the ransom noteRansom_block
The ransom_block module gets the active process list and kills certain critical processes in an infiniteloop.

Figure 25. Kills listed processes before displaying the ransom note

Figure 26 shows what the ransom note should look like:Figure 26. Ransom note content from module code

Collected User Data
Our investigation on the C&C server allowed us to obtain the list of victim IP addresses already collectedby the malware authors. Out of the 380 entries, users from China are the highest with 152, followed byusers from India with 103. Based on what we have obtained, many other countries have also been
affected, including the United States, Ukraine, Pakistan, and the Philippines.
Tracing the collected usernames and their respective IP addresses revealed that software development
companies might have been part of the initial targets. However, due to the Xcode project infection natureof the malware, the actors may intend to target developers indiscriminately.
Unlike screenshots of the victim desktops, screen captured windows of the hijacked browsers were also
found in the server. These screenshots we encountered were mostly from Google Sheets and the AppleApp Store. However, the launched hijacked browser also had a hardcoded list of websites to monitor for
screen capture:

Figure 27. Screenshot of website list in targets.php, which is called by agentd.php
Entries related to the exact URLs for the captured sites are listed in the sessions.sqlite database present
in the server source directory. These screenshots are located in the server directory/agent/secure/sessions/images.
While there seem to be multiple individuals involved in this malware, we have yet to find any links to aknown threat actor group.

New Mach-O File Pods_shat Found in the Server
On Aug. 6, 2020, we found a newly added file named Pods_shat on the malicious server(a238ed8a801e48300169afae7d27b5e49a946661ed91fab4f792e99243fbc28d). Its file size is the sameas that of the previous version Pods file(d11a549e6bc913c78673f4e142e577f372311404766be8a3153792de9f00f6c1), and all functions code
logics is quite similar to the ones in the previous version. The obvious changes are found in the encrypted
data block.

Figure 28. Old encrypted data block

Figure 29. New encrypted data block
Dynamic testing revealed that all the behaviors remain the same, except for a small change in thecommand line.
Old command line for downloading the main entry Apple Script:

New command line for downloading the main entry Apple Script:

A branch for buildVendor == “shat” already existed before in com.php, and has the same actions as thedefault one.

Figure 30. Snippet showing that the newer Pods_shat will perform the same as its originalAt the same time, the fake Xcode.app's location is changed from~/Library/Containers/com.apple.routerd/Xcode.app
to~/Library/Application Support/iCloud/Xcode.app

Conclusion
Given the potentially destructive coverage of the browser abuse and the way the server’s backend
system has been made to accommodate new features, we expect new payloads to be added, and moredamaging payloads will be distributed soon.
Users can defend against these types of attacks by familiarizing themselves with the features of theirinstalled utilities. Doing this helps users become more aware of the possible ways these utilities can beexploited. Users must also be aware of where and how files are obtained and stay updated on security
measures that can protect their systems.

TREND MICROTM RESEARCH
Trend Micro, a global leader in cybersecurity, helps to make the world safe for exchanging digital information.
Trend Micro Research is powered by experts who are passionate about discovering new threats, sharing key insights, andsupporting efforts to stop cybercriminals. Our global team helps identify millions of threats daily, leads the industry invulnerability disclosures, and publishes innovative research on new threats techniques. We continually work to anticipate newthreats and deliver thought-provoking research.
www.trendmicro.com