# The XCSSET Malware: Inserts Malicious Code Into Xcode Projects, Performs UXSS Backdoor Planting in Safari, and Leverages Two Zero-day Exploits
#### Appendix


-----

## Introduction

We have discovered an unusual infection related to Xcode developer projects. Upon further investigation,
we learned that a developer’s Xcode project at large contained the source malware — which leads to a
rabbit hole of malicious payloads. Most notably, we found two zero-day exploits: one is used to steal
[cookies via a flaw in the behavior of Data Vaults; another is used to abuse the development version of](https://support.apple.com/en-ph/guide/security/sece3bee0835/web)
Safari. The malware has the capability to hijack Safari and inject various Javascript payloads.

This scenario is quite unusual; in this case, malicious code is injected into local Xcode projects so that
when the project is built, the malicious code is run. This poses a risk for Xcode developers in particular.
The threat escalates when affected developers share their projects via platforms such as GitHub, leading
to a supply-chain-like attack for users who rely on these repositories as dependencies in their own
projects. We have also identified this threat in other sources including VirusTotal and Github, which
indicates this threat is at large.

In this technical brief, we will discuss our investigation into this attack which includes the hidden Mach-o
executable, its Applescript payload functions along with the three zero-day exploits we discovered, and
the JS payloads it injects to exfiltrate and manipulate data from browsers.

## Initial Entry

Xcode is an integrated development environment (IDE) used in macOS for developing Apple-related
software and is available for free from the Mac AppStore. Since its release, plenty of developers have
used Xcode for their Apple software needs.

Figure 1. A sample Xcode project and its contents


-----

When creating a project in Xcode, a project file (.xcodeproj) is generated that contains the code and
resources to be built together. Inside the project, schema files that contain how each part is mapped are
also generated.

For this incident, we initially traced an infected project’s Xcode work data files and found that a reference
to another folder was listed instead of to the main folder this workspace has.

Figure 2. Modified workdata string

We were able to identify a hidden folder located in one of the .xcodeproj files for the project. The hidden
folder contains the following:

##### 1. xcassets – Mach-O file malware 2. Assets.xcassets – shell script to call the Mach-O malware

Figure 3. Hidden contents of project

In one of the project files (.pbxproj), a reference to Assets.xcassets was found. Once the project is built
and compiled, we suspect that the malicious code is executed.

Figure 4. Reference to hidden contents

In our testing, executing the Mach-O xcassets shows that it drops the following files in the folder
~/Library/Caches/GameKit/. Note that the symbol ~ indicates the current user.

##### • .domain – refers to the file containing the target command and control (C&C) server address
 • .report – refers to the file containing the file path and app bundle dropped; its use will be discussed in the next section
 • <number>.jpg – refers to the screenshot of the current desktop; a new screenshot is taken approximately every minute and the filename for the screenshot changed in increments of one. Once a new screenshot is taken, the previous one is deleted.
 • Pods – is a copy of the Mach-O xcasset


-----

Figure 5. List of initial dropped files using a file event monitor tool

Figure 6. Contents of hidden files .report and .domain

Figure 7. Contents of the GameKit folder containing the visible dropped files (screenshot and Pods)

It also drops several application bundles containing a suspicious main.scpt in the current user’s
Application Scripts folder, including xcode.app:


-----

Figure 8. Dropped app bundles and the malicious AppleScript file

These dropped app bundles make use of a Mach-O wrapper (applet) to execute the main payload
main.scpt. As we can see from the screenshot above, the malware also drops a bundle that masquerades
as the legitimate Xcode.app but runs the malicious payload in the same way instead.

By delving deeper into the xcassets Mach-O file, we found that its main purpose is to communicate with
the server in order to download and run its main payload, main.scpt. All malicious fake apps are
generated by main.scpt. More details on how this payload works shall be discussed in the following
sections.


-----

Figure 9. TCP stream contents

The above is the TCP stream output for communication with the IP address 46.101.126.33, which
contains its assigned domain, adobestats.com. It is encrypted using RC4 as traced while debugging.


-----

## Main Payload

Figure 10. Contents of dropped app bundle Xcode.app found in the Application Scripts folder

Further checks on main.scpt show that it is compiled as a run-only binary script and can't be decompiled
with static methods. After investigating the C&C server, we were able to obtain a plaintext AppleScript
version.

Checking this reveals that it holds a lot of functions and calls that are responsible for the observed
infection behavior:

Figure 11. List of names for dropped app bundles

A hardcoded list of names to assign dropped app bundles containing the same payload main.scpt is
present, which matches dropped bundles found in our testing. The domains adobestats[.]com and
flixprice[.]com are also listed for use for C&C communication.


-----

Figure 12. Code snippet for checking system information

This code first pings to check if connection is established, then sends the following basic system
information of the infected user:

##### 1. MacOS Version 2. System Language 3. IOPlatformSerialNumber 4. Firewall States 5. SIP Enabled Status

It then proceeds to kill the running processes listed:

##### 1. com.apple.core 2. com.oracle.java 3. agentd 4. operad 5. edged 6. firefoxd 7. yandexd 8. avatard 9. braved

A majority of these processes are for installed browsers, and their significance is related to the data
exfiltration features that will be discussed in the next sections.


-----

Figure 13. Screenshot of browser-related functions in main.scpt

As observed in this figure showing the browser-related code, the payload AppleScript file contains various
calls to different modules by calling the executor function boot (moduleName, background). This function
downloads the module’s AppleScript code from the following to-be-constructed URL:

##### • https://" & domain & "/agent/scripts/" & moduleName & ".applescript  

This is compiled into a Mac app package through the command osacompile, similarly constructed as:

_osacompile -x -o xcode.app main.applescript_

The osacompile command is powerful. The parameterized command “osacompile -x -o test
main.applescript” will only generate a binary AppleScript file, while “osacompile -x -o xcode.app
main.applescript” will generate a completed app folder.

The package name is based on the input module name and mapping to an installed well-known
application name. Furthermore, it replaces the app’s corresponding icon file and "Info.plist" to make the


-----

fake app look like a real, normal app, and thereby making it hard to distinguish without further
investigation.

Figure 14. Screenshot of a newly generated app by the malware

Figure 15. Code snippet for loading


-----

If the creation of the fake app package is successful, it will then execute the fake app package.

In the main call stack, the following functions/modules will be called:

Figure 16. Screenshot of calls for the identified payload applescript modules

Finally, it uses the creation timestamp of ~/Library/Caches.GameKit/.report as a reference point to check
if it should execute its more notable modules, replicator and pods_infect, for injecting the malicious code
into local and Cocoapods-packaged Xcode projects respectively.

The timestamp from .report is compared to the current time taken on the machine. The replicator and
pods_infect functions will be executed 12 hours (43,200 seconds) after the Applescript execution.


-----

Figure 17. Code for delay of running replicator and pods_infect

### Payload Modules

Below is a summary list of the modules identified that we obtained by tracing downloads for each module
before they were compiled:

|Module|Feature|
|---|---|
|payloader|Checks last installed module and re-installs entry Mach-O malware (originally called Pods), C&C communication|
|replicator|Injects local Xcode projects with malicious code|
|pods_infect|Injects local repository of Xcode Cocoapods projects source-controlled by git|
|safari_remote|Uses exploit to create fake version from server|
|safari_update|Updates safari to version 13|
|safari_cookie|Uses exploit to read Safari cookie data|
|safari_killer|Checks if safari_remote is already executed, kills running safari process|
|safari_recover|Checks SIP, replaces safari with malicious one in dock using dockutil|
|chrome_remote|Downloads backdoor masquerading as browser from server; uses exploit to hijack actual browser|
|chrome_data|Downloads python script from server; collects credit card and user login data|
|firefox_remote|Downloads backdoor masquerading as browser from server; uses exploit to hijack actual browser|
|opera_remote|Downloads backdoor masquerading as browser from server; uses exploit to hijack actual browser|
|opera_data|Downloads python script from server; collects credit card and user login data|
|yandex_remote|Downloads backdoor masquerading as browser from server; uses exploit to hijack actual browser|
|brave_remote|Downloads backdoor masquerading as browser from server; uses exploit to hijack actual browser|
|edge_remote|Downloads backdoor masquerading as browser from server; uses exploit to hijack actual browser|


-----

|360_remote|Downloads backdoor masquerading as browser from server; uses exploit to hijack actual browser|
|---|---|
|notes|Collects saved data from notes.app|
|evernote|Obtains saved accounts from user's Evernote|
|contacts|Obtains saved contacts from user's QQ/WeChat)/Telegram/Skype|
|telegram|Obtains local app directory data from user's Telegram|
|telegram_lite|Obtains local app directory from user's Telegram Lite|
|skype_session|Collects saved local source Skype directory and Skype session data and sends to server|
|force_allow_screen_skype|Opens dialog to prompt user to enable security and privacy system preferences|
|wechat_files|Collects local app directory data from user's WeChat|
|force_allow_screen_wechat|Displays prompt to make request permission for WeChat screen recording|
|firewall_off|Turns off firewall via user input|
|updates_off|Turns off system updates via user input|
|screen|Re-downloads entry Mach-O Pods, takes a screenshot of current desktop using chkdsk.app/copy of screen.applescript posing as donor app every ~2 minutes (if Catalina) or takes a screenshot via screen capture shell command every ~30 seconds (if Mojave or lower)|
|encrypter|Performs AES CBC encrypting on files under ~/Documents, ~/Downloads, and ~/Desktop with fixed key and renames to <filename>.enc. Only files with sizes less than 500MB are encrypted.|
|decrypter|The opposite of encrypter module; finds all *.enc files under ~/Documents, ~/Downloads, and ~/Desktop folder, then performs AES CBC decryption with the same fixed key used in encrypter module|
|ransom_block|Gets active process list and kills certain critical processes in an infinite loop|
|ransom_ui|Sends request to server to get ransom note, then shows the ransom note to victim user|
|exec|(old/commented out) Executes command from server and sends logged files under /Library/Containers, /Library/Group Containers, /Library/Application Support (new) Executes command from server then searches for directories with name containing substring "evernote", uploads result to server|
|finder|Searches for files in Desktop, Documents, Downloads, Dropbox, and WeChat source directory based on server query (including Xcode projects); uploads folders excluding git files to server|
|finder_app|Executes module payload as Finder app; enumerates all hidden directories in system except inside Pictures and Applications folders|
|remove_old|Removes ~/Library/Frameworks.app, ~/Library/CoreFramework, and ~/Library/LaunchAgents/com.apple.core.launchd.plist|
|uploader|In ~/Documents, ~/Desktop, ~/Downloads folder, searches all Xcode project source code folder, compresses them to zip package, and uploads to server. Zip files containing Xcode project source code are uploaded to server as well.|
|uploader_folder|Compresses whole ~/Desktop folder excluding all .git folders to zip file and uploads to server. If total data size in ~/Desktop folder excluding .git folders is greater than 200MB, then the module will do nothing.|
|cleaner|Removes ~/Library/LaunchAgents/com.apple.core.accountsd.plist and /Library/Application Support/com.apple.frameworks|


-----

|reboot|Shows fake message to user saying that a system update requires a reboot of the operating system|
|---|---|
|remote.ssh|Checks if remote login via Secure Socket Shell (SSH) is enabled on the victim’s machine; if not, it will enable remote login by calling command 'do shell script "sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist" with administrator privileges', which needs user authentication. After that, it tries to find or generate SSH key and upload private key file to server, so the attacker can remotely connect via SSH to the victim machine at any time with the private SSH key without inputting username and password.|
|rnd|Calls ransom_ui.applescript, ransom_block.applescript; before the calling of these two modules, the calling to encryptor module and sleep 600 seconds was being commented now|
|test|Incomplete script file for testing purpose|
|bootstrap|original/plaintext version of main.scpt; already discussed as main.scpt|
|demo|Kills malicious planted Safari dev version (Safari for WebKit development) and relaunches malicious Safari|
|demo1|Shows a dialog as a blackmail/ransom note to let user contact specified QQ ID, then launches QQ|
|demo2|Shows dialog containing only string "demo2"|


We will now discuss the more notable modules that we believe makes this malware distinct from the rest.

### replicator

The "replicator" module will first download the latest shell script "Assets.xcassets" and Mach-O file
"xcassets" from server as preparation for Xcode project infection.

Figure 18. Code for downloading latest copy of module

After, it sets the home folder of current login as top folder for searching Xcode projects. If the username is
"vladbookpro", the top folder will be set as ~/Downloads/infect, which suggests that "vladbookpro" is the
username of the malware author and this logic is to control the infection scope on their own machine.


-----

Figure 19. Code mentioning vladbookpro username

It enumerates all .xcodeproj folders under the top target folder except Pods.xcodeproj, which might be the
project name developed by the malware author. If keyword "3F708E50247A0EB6004066FD" or
"162E3FD122D63A22006D904C" can be found in project file, the infection process will be skipped to
avoid multiple infections. According to the FORCED_STRATEGY value, it decides whether to infect
during the build phase part or build rule part. In the script we have, FORCED_STRATEGY is initialized
with empty string, so the script will decide by getting a random number.

Figure 20. Code for strategy selection


-----

Figure 21. Payload for build phase infection

Figure 22. Payload for build rule infection

Besides infection on Xcode project directory, it also finds and infects any Xcode projects compressed in
zip files. To handle zip files, it also downloads a 7za binary from server.

Figure 23. Code for downloading 7za binary


-----

### pods_infect

The pods_infect module is for infecting iOS Xcode projects using CocoaPods packages. It starts by
enumerating the CocoaPods "target_integrator.rb" file under "/Library/Ruby/Gems" folder.

Figure 24. Code for enumerating file

To avoid multiple infections, it checks if the target ruby script file contains the two server domain names.
As a matter of fact, however, in following infection logic, none of these two keywords are added to the
script file.

Figure 25. Code to avoid multiple infections

As infection logic, for the current target Xcode project which uses CocoaPods, the code gets
target.user_project_path. It downloads a shell script file "build.sh" and Mach-O file "project.xworkspace"
from a malicious server and puts these files in a hidden folder .git under the target Xcode project folder.

Figure 26. Code for infection

The downloaded Mach-O file is exactly the same one downloaded by the replicator module, while the
shell script file is also quite similar with the one used in the replicator module.


-----

Figure 27. Code for added files

### safari_update

This module downloads a Safari update package from the server, which is named either
Safari131Mojave.pkg or Safari1304Mojave.pkg. The version chosen is based on the currently installed
Safari version. The two packages are update packages from Apple with valid code signatures. After it is
downloaded, it proceeds to install the Safari update package.

## Data Vault vulnerability used for Safari cookie theft

macOS protects the Safari cookie file ~/Library/Cookies/Cookies.binarycookies with the System Integrity
Protection (SIP) feature.

Figure 28. Protection of the Safari cookie file

However, we found a bypass method when analyzing the malware’s safari_cookie module. It is a zeroday vulnerability exploitation that is at large. Based on our analysis, the malware tries to steal the safari
cookie file by using this vulnerability.

Figure 29. Code to acquire Safari cookie file

[This vulnerability is related to how the operating system handles Data Vaults. The behavior is similar to](https://support.apple.com/en-ph/guide/security/sece3bee0835/web)
what would happen if Full Disk Access was granted. Also, the malware checks if TCP port 22 is open on
the victim’s system. If not, it will execute the following AppleScript:


-----

Figure 30. AppleScript code

Regarding the root cause, we think the SSHD process must have the privilege to read all disks. It will then
spawn another SCP process to read the restricted file successfully. Both the SSHD and SCP processes
are running with the common user ID 501. Since the use of port 22 is required for the SSHD and SCP
processes, another way might be implemented in the future to leverage the same exploit if this port is not
available.

Figure 31. Relevant code of safari_cookie module

Note that for this vulnerability to be exploited, the user must have administrator privileges or a separate
sandbox escape vulnerability would be needed. Alternately, the SSHD process can be opened by the
user themselves for ease of use.


-----

## Safari for WebKit Development zero-day (safari_remote)

### Creating a Fake Safari app

The purpose of the safari_remote module is to download safari.zip and run-safari-dev.py from the C&C
server. It then compiles a fake Safari app with the safari-dev.py and changes all the references from the
normal safari.app to the fakeSafari.app — such as the icon, info.plist, item in the dock, and its respective
item in the system Launchpad. Functionally, this means that the fake Safari browser runs instead of the
legitimate version of Safari.

In this module's script, the following lines exist:

Figure 32. Safari version-checking code

We believe that this is the reason that the safari_remote module has a separate module for updating
Safari to version 13: that is, it needs to leverage the Safari WebKit.

Figure 33. Code for downloading malicious Safari frameworks

Notably, the downloaded safari.zip contains frameworks for Safari.


-----

Figure 34. Contents of downloaded file

This is done so that when the infected user wants to open the normal Safari browser, the fake one will get
executed instead. The downloaded safari.zip also tries to kill instances of the normal Safari browser, and
then launch the fake one.

In the file named WebCore in the zip, a string related to the malware server can be found.

Figure 35. Code related to malware server

The content of the fake Safari.app is the run-safari-dev.py file, which launches the system process
/Applications/Safari.app/Contents/MacOS/SafariForWebKitDevelopment after setting the necessary
environment variables.

When a developer opens the process
/Applications/Safari.app/Contents/MacOS/SafariForWebKitDevelopment, a dialog like the following
appears:


-----

Figure 36. Access request dialog box

Only when the user enters the correct password would the SafariForWebKitDevelopment then be
launched.

However, we found a bypass method when analyzing this, which we believe is a zero-day exploit in use
at large. The malware tries to use the un-sandboxed Safari to perform malicious operations without user
approval. Below is our proof of concept:

Figure 37. Proof of concept for malicious code

### Dylib Hijacking

The environment variables set in the run-safari-dev.py are DYLD_FRAMEWORK_PATH and
DYLD_LIBRARY_PATH, which point to the Release folder inside the downloaded safari.zip. The
safari.zip contains the fake WebCore.framework. Therefore, when the SafariForWebkitDevelopment is
launched, the crafted frameworks will be loaded.


-----

Figure 38. Code for loading malicious framework

## JavaScript Payload Injection in Browser Webpages

We can get the code snippet from the WebCore binary by searching the following string:

Figure 39. Code for loading Javascript

The code reference to the string is inside the function:

_WebCore::Document::dispatchWindowLoadEvent(WebCore::Document *this)_

This means that it will request a malicious Javascript from the malicious server with the following
parameters:


-----

##### • user: current username (base64 encoded)
 • url: current page URL that the user is accessing (base64 encoded) 
 • title: current page title that the user is accessing 

After, it will inject the malicious JavaScript code into the current Safari page. Note that the
SafariForWebkitDevelopment is not sandboxed for developer usage. This means that the JS payload can
do anything without the browser sandbox restriction.

After further investigation on the C&C server that relays this JS payload for injecting as Universal CrossSite Scripting (UXSS), we can say that it also injects this on other popular browsers that the infected user
has installed. We were able to both uncover the rest of the files stored here and identify its browser
hijacking capabilities. Below is a summary of the routines we have identified:

##### • Manipulates browser results
 • Manipulates and replace found bitcoin and other cryptocurrency addresses
 • Replaces the Chrome download link with a link to an old version package
 • Steals Google, Yandex, Amocrm, SIPmarket, Paypal, and Apple ID credentials
 • Steals credit card data linked in the Apple Store
 • Prevents the user from changing password but can also record the new password if it is changed

  - Takes screenshots of certain accessed sites


-----

Figure 40. Screenshot of agentd.php found in the server, including descriptions of the various JS

payloads for browser injection

Here the payload is used to steal the AppleID account and password. When trying to sign in with an
Apple ID, the following can be seen:

Figure 41. URL of AppleID login site

We obtained the payload from the C&C server as follows:


-----

Figures 42 and 43. Downloaded payload from malicious server


-----

Figures 44 and 45. JavaScript to decode payload

The initial payload contains an encoding routine. By reversing this for decoding, we were able to identify
three different kinds of code to inject, depending on the sites that the user accesses. Since these are
quite long, we will only be highlighting notable sections for each part.


-----

Decoded payload part 1:

Figure 46. Decoded Javascript payload, part 1

This decoded Javascript payload sends user agent and cookie information along with a specified base64
URL.

Aside from this part containing a similar code as part 1, this second part primarily focuses on exfiltrating
cryptocurrency and other payment-related accounts by tracing transactions.


-----

Figures 47 and 48. Decoded Javascript payload, part 2

It also collects security credentials from the App store:


-----

Figures 49-51. Decoded Javascript payload, part 2

Below are sections of the code related to cryptocurrency:


-----

-----

Figures 52-55. Cryptocurrency-related code snippets

Injected code for taking other credentials for certain sites are also present. Meanwhile, certain sites, if
matched on access, will cause the payload to not perform anything at all:


-----

Figures 56-58. Code for information theft

Meanwhile, for the third part it attempts to obtain AppleID credentials.


-----

-----

Figures 59-61. Code to steal AppleID


-----

## Impact and Evidence of Compromised Projects and Users

[We have found two Xcode projects infected by the malware from researching online. One happened on](https://github.com/ragulSimpragma/twitterTask/commit/7afdcd360d3547be6027fd9b0fdc40e28bbe8cfc)
[July 13](https://github.com/ragulSimpragma/twitterTask/commit/7afdcd360d3547be6027fd9b0fdc40e28bbe8cfc) [and the other on July 31. Fortunately, these projects are not too relevant for other users to](https://github.com/yimao009/MVC-MVP-MVVM/commit/2cace311311b52d3113a198ad235de073d2fc22a)
download and integrate these into their own projects. Still, this proves how dangerous the XCSSET
malware could be for developers.

Figure 62. Added malware to the compromised project in the latest commit

From our investigation of the C&C server, we were able to obtain the list of victim IP addresses that were
collected by the malware authors. Out of the 380 entries, users from China are the highest with 152,
followed by users from India with 103.


-----

## Conclusion

With the OS X development landscape rapidly growing and improving – as proven by news on the latest
Big Sur update, for instance – it’s no surprise that malware actors now also leverage both aspiring and
seasoned developers alike for their own benefit. Project owners should continue to triple-check the
integrity of their projects in order to definitely nip unwarranted problems such as a malware infection in
the future.

### MITRE TTP Matrix

Mapped MITRE Matrix for XCSSET using the MITRE ATT&CK® Navigator. Tactics, techniques, and
procedures (TTPs) highlighted in red are observed behaviors while those in orange are behaviors that

might happen based on its capabilities.


-----

|Indicators of Compromise|Col2|Col3|
|---|---|---|
|SHA256|Filenam e|Detection|
|6fa938770e83ef2e177e8adf4a2ea3d2d5b26107c30f9d85c3d1a55 7db2aed41|main.sc pt|TrojanSpy.MacOS.XCSS ET.A|
|7e5343362fceeae3f44c7ca640571a1b148364c4ba296ab6f8d264f c2c62cb61|main.sc pt|TrojanSpy.MacOS.XCSS ET.A|
|857dc86528d0ec8f5938680e6f89d846541a41d62f71d003b74b0c5 5d645cda7|main.sc pt|TrojanSpy.MacOS.XCSS ET.A|
|6614978ab256f922d7b6dbd7cc15c6136819f4bcfb5a0fead480561f 0df54ca6|xcasset s|TrojanSpy.MacOS.XCSS ET.A|
|ac3467a04eeb552d92651af1187bdc795100ea77a7a1ac755b4681 c654b54692|xcasset s|TrojanSpy.MacOS.XCSS ET.a|
|d11a549e6bc913c78673f4e142e577f372311404766be8a3153792 de9f00f6c1|xcasset s|TrojanSpy.MacOS.XCSS ET.A|
|532837d19b6446a64cb8b199c9406fd46aa94c3fe41111a373426b9ce59f 56f9|speedd|Backdoor.MacOS.XCSSET.A|
|4f78afd616bfefaa780771e69a71915e67ee6dbcdc1bc98587e219e120f3e a0d|firefoxd|Backdoor.MacOS.XCSSET.A|
|819ba3c3ef77d00eae1afa8d2db055813190c3d133de2c2c837699a0988 d6493|operad|Backdoor.MacOS.XCSSET.A|
|73f203b5e37cf34e51f7bf457b0db8e4d2524f81e41102da7a26f5590ab3 2cd9|yandexd|Backdoor.MacOS.XCSSET.A|
|ccc2e6de03c0f3315b9e8e05967fcc791d063a392277f063980d3a1b39db 2079|edged|Backdoor.MacOS.XCSSET.A|
|6622887a849b503b120cfef8cd76cd2631a5d0978116444a9cb92b1493e 42c29|braved|Backdoor.MacOS.XCSSET.A|
|32fa0cdb46f204fc370c86c3e93fa01e5f5cb5a460407333c24dc79953206 443|agentd|Backdoor.MacOS.XCSSET.A|
|924a89866ea55ee932dabb304f851187d97806ab60865a04ccd91a0d1b9 92246|agentd- kill|Backdoor.MacOS.XCSSET.A|
|af3a2c0d14cc51cc8615da4d99f33110f95b7091111d20bdba40c91ef759 b4d7|agentd- log|Backdoor.MacOS.XCSSET.A|
|534f453238cfc4bb13fda70ed2cda701f3fb52b5d81de9d8d00da74bc97ec 7f6|dskwalp|Trojan.MacOS.XCSSET.A|
|172eb05a2f72cb89e38be3ac91fd13929ee536073d1fe576bc8b8d8d6ec6 c262|chkdsk|Trojan.MacOS.XCSSET.A|
|a238ed8a801e48300169afae7d27b5e49a946661ed91fab4f792e99243fb c28d|Pods_sh ad|Trojan.MacOS.XCSSET.A|


**IP/Domain** **WRS Action**

|IP/Domain|WRS Action|
|---|---|
|https://adobestats.com/|Block and Categorized as C&C Server|
|https://flixprice.com/|Block and Categorized as C&C Server|
|46.101.126.33|Block and Categorized as C&C Server|


-----

**TREND MICRO[TM] 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, and
supporting efforts to stop cybercriminals. Our global team helps identify millions of threats daily, leads the industry in
vulnerability disclosures, and publishes innovative research on new threats techniques. We continually work to anticipate new
threats and deliver thought-provoking research.

**www.trendmicro.com**


-----