Analysis of PureLand Info Stealer

Summary

#

In this blog, we will be investigating an information stealer designed for macOS systems called ‘PureLand’. This information stealer targets cryptocurrency wallets and sensitive password/username information stored within the Chrome browser. It masquerades as a pay-to-win video game, under the subsection of blockchain specific gaming. This particular campaign by the threat actors was distributed initially via Twitter (now X), asking users whether they would be amenable to testing their new pay-to-win video game. Test participants were informed that if they took part in testing, they would be compensated for their time and feedback. You can find the rebranded PureLand campaign here if you’re interested.

When the application is opened, the user is prompted to enter their password for “Chrome Safe Storage”. Once this has been granted, the stealer will then cycle through the contents of Chrome, searching for internet cookies and saved log on credentials. The malware then goes on to search for its primary points of interest, cryptocurrency wallets.

This sample was the first iOS application that I have reversed and served as wonderful learning regarding the structure of these applications. As such, this analysis will also describe components of iOS applications to serve as a reference point for future analysis and is likely to be iterated on in future as I develop more familiarity with the operating system.

For a comprehensive guide on how to successfully set up a macOS VM on your ARM system, please see my blog post here.

Hash Values

#

This sample was obtained from VirusTotal. Hash values of the sample are as listed below:

I’m also including the link from malshare just to highlight this resource and its usefulness in finding macOS malware to analyse.

Key Considerations

#

This section of the blog highlights our key goals in completing analysis of this binary. For this sample, we will:

• Use static analysis to inform the initial capabilities of this strand of malware
• Identify the family of malware this sample belongs to
• Understand the capabilities and items of interest for this malware sample
• Create signatures in both YARA and SIGMA to stop execution of this malware on user endpoints

Understanding file structures and layout

#

I wanted to spend some time during this blog analysing and understanding the significance of each component of this malware to increase my own knowledge and understanding of the structure of macOS applications. By taking the time to understand this, analysis of more complicated and obfuscated samples should be made slightly easier.

The following information was obtained through manual exploration of the file structure of Pureland, navigating through the terminal.

# file list

\malware-samples\Pureland\PureLand%20Launcher.pkg
\malware-samples\Pureland\Installer.app\
\malware-samples\Pureland\Installer.app\Contents\
\malware-samples\Pureland\Installer.app\Contents\Info.plist
\malware-samples\Pureland\Installer.app\Contents\MacOS\
\malware-samples\Pureland\Installer.app\Contents\MacOS\Installer
\malware-samples\Pureland\Installer.app\Contents\Resources
\malware-samples\Pureland\Installer.app\Contents\Resources\icon.icns
\malware-samples\Pureland\Installer.app\Contents\_CodeSignature
\malware-samples\Pureland\Installer.app\Contents\_CodeSignature\CodeResources

The breakdowns provided in the following sections are largely in part due to working through Reverse Engineering iOS Applications available on GitHub.

info.plist

#

This file contains the configuration data, typically located in the root or contents directory of the application (as evidenced by the file list above). There is a lot of information contained within this file, which can assist in developing a preliminary understanding on what some capabilities of the malware are.

Below, is an excerpt from the Info.plist of PureLand.

...
<dict> 
  <key>CFBundleGetInfoStrings</key> # Now an obsolete key, replaced by NSHumanReadableCopyright
  <string>Installer</string>
  <key>CFBundleExecutable</key> # Defines the binary that's dynamically loaded by the bundle
  <string>Installer</string> # takes type string, binary name
  ...
  <key>CFBundleIconFile</key> # file containing the bundle's icon
  <string>icon.icns</key> # takes type string, file name containing icon
  ...
</dict>
...

To make sense of the components in this file, the Apple Developer documentation here and here can (and really should) be referenced.

In the case of this malware, there is not too much information that can be gleaned from analysis of this file except:

• The loaded binary name is called Installer - which we saw in our file list
• The icon file name is icon.icns - which we also discovered in our file list

The positive here is that we now have definitive evidence that confirms the initial recon analysis performed of the file structure.

Frameworks

#

Some iOS applications can and do leverage third party frameworks to assist in the creation and operation of an application. Its worth noting here because it could provide additional insight or potentially a way to fingerprint a strand of malware if a certain framework is always present alongside a malicious sample.

In the case of PureLand and our file list, no third party framework is used.

MacOS Malware Tools

#

A quick reference guide on what tools to install or leverage on your MacOS VM to aid in the analysis of this and other, more complex malware samples.

Delving into Analysis

#

Initial analysis of this malware saw us getting to know the file and folder structure of this application. In this process, we established:

• The executable’s name
• The application’s icon With this basic information, the focus turns to understanding the capabilities of the malware.

Initial analysis should always start with the ’lowest hanging fruit’ aka running strings across files of interest within the folder structure and inspecting files that do not execute, such as our Info.plist file from earlier. Noting that we are aware of the executable name for this malware already Installer, contained within the Contents\MacOS\ directory, we will run strings over this binary.

# run strings over executable and pipe output into file
strings Installer > output.txt

It is always wise to pipe the output of strings into a nice little file so that you can peruse it at leisure.

In this instance, the amount of information is initially overwhelming - there is a lot to unpack here but an initial scroll through the output reveals some very interesting information:

USER
http://193.168.141.107:8888/ # private IP Address range?? Attacker could connect to the stealer on this port? 
lastroute
zerocode
ixcozlabraham
BigSurApplication # developed for big sur?
CnbtldmsrSWS
CdrjsnoSWS
/Library/Application Support/Exodus/exodus.wallet/ # crypto wallet 
/.dkdbsqtl/vakkdsr # interesting folder and unique string

....

username
userbot
buildname
file
system_profiler SPHardwareDataType > /Users/
/Documents/
.txt
/Users/
SERIALNUMBERFILE
serialinfo
rm -Rf # what are you removing good sir/maam? 
alreadyserver
already
/Library/Application Support/Google/Chrome/Default/Local Extension Settings/nkbihfbeogaeaoehlefnkodbefgpgknn/ # interesting unique string contained here
metamask # crypto 
test
/Library/Application Support/Google/Chrome/Default/Local Extension Settings/bfnaelmomeimhlpmgjnjophhpkkoljpa/ # another one
phantom #crypto 
/Library/Application Support/Google/Chrome/Default/Local Extension Settings/ibnejdfjmmkpcnlpebklmnkoeoihofec/ # and another
tronlink # crypto 
/Library/Application Support/Google/Chrome/Default/Local Extension Settings/efbglgofoippbgcjepnhiblaibcnclgk/ # and another
MartianAptos # crypto 
/Library/Application Support/atomic/Session Storage/
atomic # crypo wallet
exodus # crypto wallet
pass # also might be a crypto wallet
electrum # crypto wallet
/Library/Application Support/zoom.us/data/zoomus.enc.db # looking for zoom? 
zoom
Zoom 404
cd /Users/
/ && find ~/Desktop -maxdepth 1 -name "*.txt" > uyganxmxcbcatkxnashygncbezj.txt
/uyganxmxcbcatkxnashygncbezj.txt # copy contents of all text files into this file
/ && find ~/Documents -maxdepth 1 -name "*.txt" > xcyckzmzxnxbasizlxxnbzys.txt
/xcyckzmzxnxbasizlxxnbzys.txt # cdopy contents of all text files into this file
/Library/Application Support/Google/Chrome/Default/Login Data
/Library/Application Support/Google/Chrome/Default/Cookies
Chrome
security 2>&1 > /dev/null find-generic-password -ga 'Chrome' | awk '{print $2}' > /Users/
/Documents/uxcmzxgcyxc.txt # outout content of generic chrome password into this text file
/Documents/kkxmxhmzxc.txt # and this one?
/Documents/ && rm -Rf uxcmzxgcyxc.txt && rm -Rf kkxmxhmzxc.txt # but then remove them both
https://api.ipify.org/ # could be making a request to identify the victims IP address to deliver to attacker infrastructure?
allocator<T>::allocate(size_t n) 'n' exceeds maximum supported size
NSt3__114basic_ifstreamIcNS_11char_traitsIcEEEE # interesting string, research this and those below
NSt3__113basic_filebufIcNS_11char_traitsIcEEEE
NSt3__114basic_ofstreamIcNS_11char_traitsIcEEEE

It’s always worthwhile making notes against strings and other interesting pieces of information you have uncovered. Yet another benefit to piping the output of strings into an individual text file

With this information alone, we know that the malware is interested in the presence of the following files/information:

• Exodus Wallet
• Zoom US
• Information contained on the Desktop and within the Documents folder
• Apps in the Applications folder
• Chrome Login Data
• Chrome Cookies
• Chrome Generic Password
• Atomic Wallet
• Electrum Wallet
• Metamask
• Phantom
• Martian
• TronLink

Additionally, we have gathered information about:

• Potential communications with C2 infrastructure
• Artefact locations when malware runs
• Unique identifiers to create a signature

From running strings alone in this instance and cross-referencing information within Ghidra, we have accrued some very valuable information to make an informed assessment of this malware’s capabilities and classification. This in turn allows us to create a robust behavioural signature for this info stealer. However, if we want to understand more about the flow of the program, as well as what that IP address could be in the context of this malware, additional analysis will have to be performed.

Host based indicators

#

Network based indicators

#

Signatures

#

Unique strings contained in malware is a very good start to developing signatures to stop this malware from functioning. From here, you should always run your rules against goodware to ensure that no other binary is impacted by your creation. This is a great way to grip up your understanding of the rule language you are leveraging and leads to much more robust and tight rule creation. Targeting unique identifiers can also have the added benefit of picking up other strands of the same malware family (if you pick them right). Unique errors embedded in malware samples tend to be a good pick for this (that is not to say that there aren’t any additional unique strings to target, such as spelling mistakes).

As with many things in reverse engineering (and most careers), it takes a while to understand and create good rules. I count myself amongst those still learning how to appropriately optimise my own rules.

YARA Rule

#

rule pureland_macos_campaign
{
meta: 
	created = "2024/02/14"
	modified = "2024/02/14"
	author = "polaryse"
	description = "Simple YARA rule to detect the presence of pureland on macos"

strings: 
	$unique_string_1 = "uyganxmxbcatkxnashygcbezj"
	$unique_string_2 = "bfnaelmomeimhlpmgjnjophhpkkoljpa"
	$unique_string_3 = "ibnejdfjmmkpcnlpebklmnkoeoihofec"
	$unique_string_4 = "efbglgofoippbgcjepnhiblaibcnclgk"
	$unique_string_file_structure = "/.dkdbsqtl/vakkdsr"
	$unique_txt_file_name_1 = "uxcmzxgcyxc.txt"
	$unique_txt_file_name_2 = "kkxmxhmzxc.txt"
	

condition:
	any of them
}

As I am building these rules, I perform tests on my macOS VM to ensure that it is firing correctly, and only picking up the sample of interest. If I find that there are additional items being picked up, I look back at the rule itself and tweak the parameters to further tighten it. Generally, rules start out very broad, based off of initial analysis findings and are narrowed through this testing on the system, and then against goodware.

The potential problem with the signature created for this sample is malware modification. At present, this signature only checks for the presence of the unique strings contained within this particular build. If the names were modified by the attacker, then the stealer could start working again. As more of this family of malware is analysed, it becomes possible to discover more unique identifiers for said family, which allows a reverse engineer to develop more robust signatures targeting new strands of malware as well as those that have been historically analysed. Ideally, this is the aim and aspiration of all signature creation.

MITRE ATT&CK Framework

#

How to find your own Mac Malware samples for analysis

#

There are multiple repositories that house macOS malware samples available both free and via a paid account. The following table attempts to document the easiest sources of malware for you to look at starting analysis.

References

#