Objective-See's research, tools, and writing, are supported by the "Friends of Objective-See" such as:

...the world’s most-loved password manager.

...next-generation apple enterprise management.

...modern apple mdm & security for enterprise & education.

...the standard in apple enterprise management.

Become a Friend!

Background

At @ConfiantIntel we had some “luck” finding a new malware targeting the new Apple flagship M1 computers. I put “luck” between quotes, as we know when you do cyber, you don’t rely on luck to find stuff, but you look at places were most likely stuff like this is to be found.

This has to do with Confiant’s detection engine, and our unique position in the Killchain: scanning malicious ads as they load, on major publisher websites in the United States.

Not only do we see bad ads loading and we scan them, but we block them as well. In other words, security vendors won’t be able to see what we see, unless they scan as early as we do in the killchain. What did we find?

We found a malware we dubbed MapperState. We didn’t really choose this name as it was taken from the file name, and the C2 server this malware communicated with : mapperstate[.]com

MapperState was installed in our honeypot by OSX/Tarmac which itself was downloaded by a OSX/Bundlore loader, compatible ARM and notarized by Apple as we reported one week ago:

The chain of different stages has become very complex nowadays and the analysis phase takes more time, due to the malware authors’ understanding of how reverse engineering is being done, but also countering the tools we wrote to decrypt their malware. I recall, a couple of weeks after we’ve published OSX/Tarmac blogpost, new variants of OSX/Tarmac started re-surfacing implementing a trick rendering our previous decryption tools useless. MapperState is a continuation of the slowing-analysis tricks OSX/Tarmac authors use.

MapperState Analysis

Persistence:

Usually OSX/Tarmac has been dropping a legit copy of Adobe Flash Player as we reported before. This time, an unknown malware with the following sha-256:

919d049d5490adaaed70169ddd0537bfa2018a572e93b19801cf245f7fd28408

was downloaded and persisted in the location below, and installed as a launch daemon, the file to be executed at RunAtLoad is called MapperState.system:

At the time of writing this unknown sample isn’t in VirusTotal, and we uploaded it right after the publication of this blog.

String Decryption:

This sample contains about 943 functions, debug symbols stripped, no identifiable strings or known encryption algorithm used. The only give-away of functionality is the imported functions. In fact, if we see a popen or a CFHTTPMessageSetBody we know that this malware will create a process, or will connect via HTTP to a C2 server respectively. only that arguments passed to these function are encrypted and hidden deeply in the malware functionality that only executes in a specific state of the runtime.

Debugging this malware won’t cover all the malware functionality. We are left with the string decryption to get a real understanding of what this malware does. This is known by the malware authors, and this is where malware authors invested all their efforts to obfuscate the functionality.

MapperState authors used a very confusing method to encrypt their strings to slow down our analysis.

Below a block of code, copied and pasted 198 times (as many as strings to decrypt). This is a classic slow-debugging technique, meaning if we had only one function decrypting all the strings setting a breakpoint in this function will suffice. but now we have 198 blocks were we should put breakpoints, and that’s not an option anymore. we have seen this exact same slow-debugging technique used in new version of OSX/Tarmac as well.

This block of code is responsible for string decryption and makes a heavy usage of SSE instructions.

The encrypted String is stored in the variable unk_100051700, the decoded string is “00000000–0000–0000–0000–00000000000” a string written by our IDAPython decoder script that we will talk about shortly.

After investigation it seems the encrypted strings are referenced in the form of unk_ variables (as IDA Pro isn’t sure what type this is), and there’s always an integer value copied to the edx register that represent the encrypted string length.

In other words this block always takes two changing parameters, and we will use IDA Pro unk_ type to locate all these strings.

Rewriting the decryption routine in Python would take us a lot of time, so we decided to emulate this block, and decrypt all the strings while extracting them on the fly (taking into account the always changing length variable).

The full source code IDAPython script can be found here.

It is important to note, that we faced two difficulty with emulation. The encryption block calls some macOS APIs and those are not emulated by Unicorn Engine. so we have to emulate them as well. Mainly we added soft hooks on the following functions:

We only focused on emulating the memcpy and the new operator the rest of the hooks we just skipped the library call. Below a quick and dirty implementation for memcpy:

…and for new() operator:

Then once we were able to emulate the decryption code block entirely, we then focused our efforts on locating the _unk strings directly in the _text section:

Finally, we needed to get the changing length of the string (the value passed to edx). This string length is not always after the _unk parameter, it is sometimes instructions before, or after, as we can see in the blow assembly snippets:

So we wrote a function that will scan forward then backward of this value, 0x30 bytes each time:

All the pieces glued together, we can run the IDAPython script, that will emulate the decryption blocks for us, with each time passing a different encrypted string and its length, below is the script output:

Full list of the decryption strings can be found here.

Malware features:

MapperState have the capability to download and execute other programs it seems to be a simple downloader for another malware.

It is worth noting that this malware is checking for installed AVs:

We didn’t get to the point to see what this malware downloads, as the C2 server was replying with empty content. but we will keep hunting.

Early Attribution

Around September 2019 when we revealed and analyzed OSX/Tarmac, the malware name we chose wasn’t random. After decrypting OSX/Tarmac strings and searching for them on the internet, we found an interesting flashcards app, that was publicly exposing OSX/Tarmac Agent, Command And Controls commands.

The commands we found in our sample, 100% matched the commands listed in the flash cards app. In fact, this is where the name Tarmac originally came from. Below are one of the flashcards of the Tarmac malware:

Tarmac Messages, documented in a Flash cards appThe account disclosing this information of the flashcards app, will be referred to as Individual X. Based on the OSINT info, it seems that Individual X is living somewhere in San Diego, CA , and have registered a domain name Y, using what looks like a personal gmail account. Furthermore, the individual X have a Github account, with the same handle and same profile photo as in the flashcards app account. Most of the repos are related to web development:

Another finding while looking at other flashcards published by the same Individual X, revealed another malware dubbed Hydromac:

Looking at Hydromac messages flashcards, we found the exact commands in our MapperState sample! see listed below, as an example the command HM_RA_Download_Started_1 (HM referring to Hydromac) that we decrypted from the sample are listed in the Flashcards app published by Individual X:

Another command HM_RA_Init_1 sent from MapperState. This time we dumped it from the debugger to confirm that it was really sent to the C2. We do this as sometimes malware contains random strings that are not even used. below is MapperState HM_RA_Init_1 command before it get encrypted and sent to the C2 server:

This command HM_RA_Init_1 is listed in the flashcard app for Hydromac:

So did we finally found Hydromac? The answer is yes and no. The sample we found (MapperState) is actually a Hydromac Root Agent (referred to as HM_RA_XXX) in the flashcard apps, doesn’t have all the commands listed in the Hydromac Flashcards app, but only initial commands referring to downloading and executing other binaries.

Beside the Hydromac Root Agent that we found, there’s a Hydromac Agent and a Hydromac Agent Plugin (based on the Flashcards app leaks). Writing a simple yara rule, helped us locating some Hydromac components, in an online malware repository. This rule will look for anything related to Hydromac Root Agent, Hydromac Agent or Hydromac Plugin, components:

rule CFNT_HYDROMAC_COMPONENTS
{
meta:
author = "taha@confiant.com"
strings:
$a = "HM_A_Init_1"
$b = "HM_A_Init_1" wide ascii
$c = "HM_RA_Init_1"
$d = "HM_RA_Init_1" wide ascii
$e = "HM_A_P_Init_1"
$f = "HM_A_P_Init_1" wide ascii
condition:
    ($a) or ($b) or ($c) or ($d) or ($e) or ($f)
}

At the time when we did a retro hunt, it gave us a single hit, which was a Hydromac Agent, and with all debug symbols:

7f7c7e1b181142592b2f8b7c823a969fb79160c9a5920abd718364eae98d1496

Interestingly, among the strings, I found that this Hydromac Agent, communicated with a known C2 server: api[.]mughthesec.com

This C2 server has been the C2 for a famous malware dubbed Mughthesec (originally analyzed in 2017, by macOS security expert Patrick Wardle).

This got me intrigued. I went to check Mughthesec and found that Mughthesec contains the OSX/Tarmac agent commands: (TRMC_XXX referring to Tarmac) as we can see below (string dump):

We also reported about the commands above, in the previous OSX/Tarmac sample analysis we published in 2019.

The information to retain here, is the Hydromac Agent we found, and the previous Mughthesec from 2017, and the recent Hydromac Root Agent (MapperState) are related and were used in real malware campaigns through malvertising affiliates.

This is based on the overlap we found in the payloads, and the C2 servers and the key information leaked from the Flashcards app and the malveritising campaigns that we track delivering both OSX/Tarmac, and now OSX/Hydromac.

In other words, the information present in the Flashcards app is legit and corresponds to real malware that is found in the wild.

One could believe that Individual X, did what we call in our Cyber Security jargon, an Operational security (OPSEC) mistake: by disclosing a name, photo ID, personal email and probably an indication of a physical address, though we are not sure.

It is interesting to note, Individual X is linked to a questionable organization called “CashwithFB”, based on wayback machine, and old forums posts from 2017, it seems this company runs ads campaigns from other people’s Facebook ads accounts, by renting them and help the subscribers to “make at least 50$ in 2 days and up to $100 in a week”. A classic.

Side note: CashWithFB run the ads relying on victims IP addresses used to logging into facebook . This is done by using a remote desktop software called Splashtop:

Whether Individual X is related to HydroMac flashcards, or the malware itself is unclear, though we noticed suspicious links between Individual X and the classic malvertising schemes operated by companies in the US.

The malvertising links, Tarmac/Hydromac being a malware dropped through Malvertising, Web developement skills, flashcards apps describing malware commands, numerous Opsec mistakes, make us believe that Individual X might be linked to malvertising affiliates. A relationship though which we are not 100% sure, and we will leave this individual level attribution to more competent organizations.

Conclusion

To close this chapter, it is worth noting that this is not the first time critical information is leaked via Flashcards apps, interestingly this week Bellingcat has reported that US Soldiers exposed Nuclear Weapons Secrets via Flashcard Apps, as they were using them for learning purposes.

The usage of Flashcard apps might be used for training purposes? Or could Individual X be only one member of a larger organization? We do not know but we will keep hunting.