Unit 42 researchers have observed a new Remote Access Tool (RAT) constructed by an unknown actor of Italian origin. This RAT, referred to as uWarrior because of embedded PDB strings, has been previously described by an independent researcher who noted a potentially unknown exploit being used against Microsoft Office.
Initial research into the exploit by Unit 42 indicates that this actor has opted to include multiple exploits. One is CVE-2012-1856, reinvigorated with a novel ROP chain to bypass ASLR and deliver the uWarrior payload. The other appears to be CVE-2015-1770. The malware itself is a fully featured RAT, which uses a compressed, (optionally) encrypted, raw TCP socket and binary message protocol for command and control communications.
During the course of our research, it became evident that this actor had not built uWarrior from scratch, but rather opted to borrow components from several off-the-shelf tools. Linkages between older RATs are explored later in this blog.
RTF Exploitation and ASLR Bypass
The weaponized RTF document used by this actor contains multiple OLE objects. In this instance, we see two different exploits, as well as two methods of bypassing ASLR exploit mitigations. The first method was published in 2014 by Parvez Anwar. The method he describes involves creating an embedded OLE object which contains a ProgID for “otkloadr.WRAssembly.1”. This causes MSVCR71.DLL to be loaded, a library which is not compiled with /DYNAMICBASE.
When using OLE to perform exploitation, ActiveX objects can be used to cite specific CLSID values. This is useful to an attacker as many of these CLSID values map to DLLs on the system. Attackers can deliberately use this to load any DLL they desire into the affected application so long as it maps to a valid CLSID.
This method was actually described at Black Hat USA 2015 in the talk: “Attacking Interoperability: An OLE Edition” by researchers Haifei Li and Bing Sun of Intel Security.
As a result of this method, it is possible for the attacker to force the loading of less secure libraries which were not compiled with the /DYNAMICBASE compiler flag (enables ASLR at compile time), or other libraries which further enable the corruption and manipulation of memory.
From the RTF document, we can use oletools to extract each OLE object. Thus far, we have encountered two weaponized RTF documents.
Interestingly, both documents contained identical OLE objects:
7ff9ff29b79d0eb38813bfa0b0bb1c5b116d1f9e5468ae52674bb443468658d9 | object_00000020.bin |
7f29f2dc8b60c0e5a22575d9c76fd9c3d39604d1acf5cb4d938a63095c61a72e | object_000000E6.bin |
fe80d59686806afe3dc48f73d54b577558a7c871da17d08d937c5d7b3564e07b | object_000187A1.bin |
70ea7ef3bf9966c3297a4e78024e3083013558670d051c2ca3095e2588a576d8 | object_0002802C.bin |
Closer examination of each of the OLE objects reveals that two of them have compressed zip files embedded in them at an offset of 1577 bytes:
1 2 3 4 5 6 7 8 9 10 11 |
object_000000E6.bin: [+] Start search on 49201 bytes (48.0 KB) [+] File at 41 size=48128 (47.0 KB): Microsoft Office document [+] File at 1577 size=46556 (45.5 KB): ZIP archive [+] End of search -- offset=49201 (48.0 KB) object_0002802C.bin: [+] Start search on 50737 bytes (49.5 KB) [+] File at 41 size=49664 (48.5 KB): Microsoft Office document [+] File at 1577 size=47720 (46.6 KB): ZIP archive [+] End of search -- offset=50737 (49.5 KB) |
Once carved and unzipped, we can see a small directory structure. Within the word/activex directory, we can see ActiveX binaries, as well as XML documents associated with them. The XML files themselves are mostly identical; duplicates of only two particularly unique ones. The contents of these two files are as follows:
1 2 |
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <ax:ocx ax:classid="{1EFB6596-857C-11D1-B16A-00C0F0283628}" ax:license="9368265E-85FE-11d1-8BE3-0000F8754DA1" ax:persistence="persistStorage" r:id="rId1" xmlns:ax="http://schemas.microsoft.com/office/2006/activeX" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships"/> |
1 2 |
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <ax:ocx ax:classid="{cddbcc7c-be18-4a58-9cbf-d62a012272ce}" ax:license="9368265E-85FE-11d1-8BE3-0000F8754DA1" ax:persistence="persistStorage" r:id="rId1" xmlns:ax="http://schemas.microsoft.com/office/2006/activeX" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships"/> |
From this we can see that ActiveX objects are calling specific CLSIDs. From this, two relatively known exploits can likely be identified, based on both payloads, and the CLSIDs used.
CLSID | Target Component | Patch | Associated Vulnerability |
1EFB6596-857C-11D1-B16A-00C0F0283628 | MSCOMCTL TabStrip control | MS12-060 | CVE-2012-1856 |
CDDBCC7C-BE18-4A58-9CBF-D62A012272CE | OSF.DLL (memory corruption in ActiveX use cases) | MS15-059 | CVE-2015-1770 |
As a result of MSVCR71 being loaded via Parvez Anwar’s method, it would appear that exploitation of CVE-2012-1856 could be re-invigorated by the use of ROP gadgets (now with non-randomized gadget addresses) located within its address space, making a VirtualProtect() call and stage 2 shellcode trivial. At this time it is unclear whether the original patch was designed to correct memory mismanagement of the affected TabStrip control, or if the components to load it were simply changed to operate with ASLR enabled to limit the vectors of introducing arbitrary code. At any rate, the ActiveX binary from OLE object 0x000000E6 has the following approximate structure:
1 2 3 4 5 |
[Word Document Header] [HeapSpray of address 0x7c342404 (a RET instruction)] [ROP Chain of gadgets inside the MSVCR71 address space] [NOP Sled] [Stage 1 shellcode] |
Figure 1: We can see the end of the RET heap spray leading into a ROP chain and stage 1 shellcode
Keeping in mind that (of course) the addresses are backwards due to little endian byte ordering, we can observe the following ROP chain after the ret gadget 0x7c342404, and prior to actual shellcode:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
7C3651EB 7C3651EB 7C372B02 00000201 7C344364 00000040 7C35A128 7C342E9E 7C34A40F 7C3650DC 7C3415A3 7C347F97 7C37A151 7C378C4D 7C345C30 |
In the OLE object 0x0002802C, there are more XML files containing the CVE-2012-1856 CLSID, however 2 files (activeX39.xml and activeX40.xml), contain the CLSID for CVE-2015-1770, which does in fact, cause OSF.DLL to load. Examining the ActiveX binary reveals a not-too-dissimilar structure to the first one:
1 2 3 4 |
[Word Document Header] [HeapSpray of 0xCC byte] [series of 0x08 and 0x41 marker bytes] [stage 1 shellcode] |
Figure 2: We can observe the end of the 0xCC heap spray, the 0x08 and 0x41 memory markers as well as stage 1 code here.
Stage 2 shellcode in both cases is decoded and inserted from memory (rather than statically included in a file) and triggers a download of the uWarrior RAT itself. When executing this payload on systems with 64-bit version of Office, things may not quite go as the author intended. For example, on 64-bit systems, msvcr71.dll is part of the SysWOW64 libraries and not available in the Office15 native add-ons folder. Instead, MSVCR100.dll is loaded for those calls and the 64-bit edition of otkloadr.WRAssembly.1 is loaded as well. Furthermore this breaks many of the hard-coded addresses and ROP gadgets, landing at the following error:
1 2 3 4 5 6 |
(904.bec): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program Files\Microsoft Office\Office15\wwlib.dll - wwlib!FMain+0x508b: 000007fe`ee1468c7 8b18 mov ebx,dword ptr [rax] ds:00000000`7c38bd50=???????? |
The address 0x7c38bd50 is a reference back into the aforementioned, msvcr71 library which is not in memory.
It is important to note that analysis of the exploitation itself is on-going and many researchers around the industry have suggested differing vulnerabilities as a root cause; however, conclusive evidence is lacking and the combination of methods and affected code is both new and complex.
uWarrior Malware Analysis
After successful exploitation, a payload is saved to the system at “%AppData%\Roaming\TEST\WindowsUpdate.exe” and executed. The WindowsUpdate.exe application contains several artifacts that suggest that the malware author calls this Trojan uWarrior, one of which is the following debugging symbol path found in the sample:
D:\1-Visual Basic Proggetti\UtilityWarrior\UtilityWarrior\obj\Debug\UtilityWarrior.pdb
uWarrior begins by copying itself to a second location, which in this case was “%AppData%\Local\svchost.exe” and saves the path to this copied executable within the following file:
%AppData%\Roaming\warriors.dat
During execution, uWarrior logs its activities to a file located at “%AppData%\Local\Temp\bootloader.dec”, however, our team is aware of other uWarrior samples saving their logs to “C:\bootloader.dec” instead. We found that uWarrior has a configuration that follows the structure:
1 2 3 4 5 6 7 8 9 10 |
struct settings { string Host; short Port; string ID; bool Startup; bool BlueScreenOnTermination; string GUID; string StartupPath; bool SaveExePath; }; |
The settings structure found in this sample of uWarrior has the domain “login.collegefan.org” set as the C2 host, and 2020 for the communications port. When communicating with the C2 server, the uWarrior Trojan uses AES to encrypt the data sent to the C2, using the key and initialization vector (IV) seen in Figure 3.
uWarrior will receive commands from the C2 using this communication channel and will process the commands using a command handler.
Figure 3 AES Encryption Key and IV used by uWarrior
The C2 will send numerical values that the uWarrior Trojan will parse to determine which command to carry out. Fortunately, the author of uWarrior included an enumeration (a data type in programming that maps a constant value to a defined name), which applies a human-readable string to each command's numerical value. This enumeration makes analyzing the commands available within the malware much easier. The functionality within many of the commands are handled by a helper DLL that the uWarrior will extract from its resource section named Windows_Update.UtilityWarrior.dll and load.
Unit 42 analyzed the command handler to determine uWarrior’s capabilities and found the following commands available:
EnumValue | Command | Description |
10 | Handshake | Instructs the Trojan to use a new key and initialization vector (IV) to encrypt network communications. The Trojan will then creates a thread that it will use in an attempt to establish communications using the new key. |
14 | ShutdownClient | Exits the current instance of the Trojan. |
15 | RestartClient | Restarts the Trojan and exits the current instance of the Trojan. |
16 | UninstallClient | Creates a batch script with a temporary filename that deletes the Trojan and then the batch script. The script contains the following::Repeat:DEL \"<executable path>\"if exists \"<executable path>\" goto RepeatDEL \"<batch script path>\""One interesting thing to note is that there is a flag called "BlueScreenOnTermination", which if set in the configuration will set the Trojan's process to be system critical by calling the SetProcessIsCritical function. After the batch script deletes the files, the Trojan exits itself and causes a Windows error due to the fact the process was system critical. |
17 | RestartPC | Restarts the system using the command line "shutdown.exe -r -f". |
18 | ClosePC | Shuts down the system using the command line "shutdown.exe -p -f". |
19 | GetSoftware | Handled by the helper DLL, which opens a specified registry key in the HKLM hive and enumerates its sub keys looking for "DisplayName" and gathers all software packages that do not have "Hotfix", "Security Update" or "Update for" within their "DisplayName". It responds to the C2 with a list of software packages delimited by the string "|A|". |
21 | unistallSoftware | Handled by the helper DLL, which enumerates the "Software\Microsoft\Windows\CurrentVersion\Uninstall" registry key looking for the software package provided with the command and will uninstall it. It responds to the C2 with "Unistall is running" if successful or the exception if it fails. |
22 | GetDriver | Handled by the helper DLL, which enumerates the mounted storage devices, their total size and the available space left on them. The command concatenates this information into the following structure and sends it to the C2: "<drive number>|H|<drive's total size>/<drive's available space>|Q|". For systems with multiple mounted storage volumes, the command will concatenate the additional data following the same structure above. |
23 | GetFiles | Handled by the helper DLL, which lists the contents of a directory of a provided path. Each folder in the directory are added to a string, which is sent to the C2 in the a format of "<folder name>|G|Floader|G||G|<provided path>|H|". Each file in the directory are added to a string that is sent to the C2 in the format of "<filename>|G|<file extension>|G|<file size>|G|<provided path>|H|". |
24 | SearchFolder | Searches the filesystem for a specified folder. If it finds the folder, the Trojan will enumerate its contents using the same code as the "GetFiles" command. |
25 | RunFile | Starts a process using a specified file. Does not respond to the C2 with any messages. |
26 | DeleteFile | Deletes a specified file. If the command has "E" switch provided, it will delete a specified directory and all of its contents. |
27 | RenameFile | Renames a specified file. If the command has "A" switch provided, it will rename a specified directory. |
28 | DownloadTCP | Reads a specified file and sends it to the C2 server. |
29 | UploadTCP | Writes data provided by the C2 to a specified file. |
30 | DownloadURL | Downloads a file from a specified URL. The C2 will provide the URL to download from in the format "<domain or IP>|A|<filename>|A|<file extension>|A|<path/URL>". |
31 | RefreshLog | Sends the contents of the log file at "C:\bootloader.dec" to the C2 server. |
32 | ClearLog | Deletes the log file at "C:\bootloader.dec" from the system. |
36 | MonitorCounts | Uses the GetSystemMetrics API function to determine how many monitors are connected to the system. |
37 | PcBounds | Sends the height and width of a specified monitor to the C2. |
38 | ShortLinkFolder | Lists the contents of a special folder based on a value between 1 and 4: 1) Lists Desktop 2) Lists %TEMP% folder 3) Lists Cookies Folder 4) Lists My Documents folder |
Some of the values within the previously mentioned enumeration are not within the command handler. Unit 42 found only two of these specific values and found in the malware, specifically "Pipe" and "Status", which were used in network communications to designate the type of response the Trojan was sending to the C2. It does not appear that uWarrior uses the “Plugin”, “ErSoftware”, “RemoteDesktop”, “UnblockEverything”, “BlockEverything” values from within the enumeration, suggesting that the malware author did not remove these values from the enumeration even though their functionality was removed from the Trojan.
No Honor Amongst Thieves
Unit 42 researchers' examination of uWarrior has led to the discovery of suspected progenitor samples. These samples, identified as the for-sale ctOS RAT, contain similar configuration structures and share several functions with uWarrior samples. The ctOS RAT contains a significant amount of functionality compared to the uWarrior command set, suggesting that uWarrior could be a stripped down alternative.
uWarrior's configuration contains all of the same fields as ctOS, as well as an additional field (bool_2 in GStruct2 stucture in Figure 4), used to toggle whether "warrior.dat" should be utilized to store the path on the file system to the executable. Samples of both RATs contain a GUID field (string_2 fields in Figure 4), "TEST", which is used to define the path where the executable will be dropped.
Figure 4 Comparison of uWarrior (GStruct2) and ctOS (Struct4) Configurations
In addition to sharing similar configurations, it appears that the uWarrior author borrowed code from the ctOS RAT. uWarrior’s helper DLL (used to handle several of uWarriors functionality) has two functions that directly overlap with functions from ctOS source code, specifically one that gets the size of a specified file and the second that enumerates the mounted storage volumes.
Static analysis of ctOS and uWarrior samples reveals Italian language strings. These Italian strings are part of PDB paths and are prevalent throughout .net manifest data. This lends additional strength to the linkage between ctOS and uWarrior, as the former's control panel demos are also in Italian.
Palo Alto Networks WildFire identifies the exploit files and malware used in these attacks as malicious. Palo Alto Networks AutoFocus users can view the analysis related to these files using the uWarrior tag.
Indicators
Sample Hashes
WindowsUpdate.exe,5dce01ec5e1bc1b4f5012e0b4bf16532206284fc8c64cfb8dcf907f45caf98fc
Windows_Update.UtilityWarrior.dll,f4aa83297844eb8297711e32554e41f677cce290732171583199a57fb7a0674b
ammendment.doc, a6dea088c9e2c9191e4c2fc4ece7b7b7bd3f034f444362d35c8765f6ec4bd279
WUPOS_update.doc, 57a5d0da72655df9c5ca9137df7210b86845eeabae488537c70e36587274937c
File system indicators
%AppData%\Local\Temp\bootloader.dec
%AppData%\Roaming\warriors.dat
Network indicators
login.collegefan.org
login.loginto.me
63.142.245.12
23.249.225.140