features too. We were interested only in those pages hosted on Weebly because we were able find multiple pages all with some sort of the same pattern in their code when performing a search using the same keyword. So we fine-tuned our search and added one more keyword: “weebly”.
Figure 9: Search results from keyword: Double Cad,serial number,weebly
Figure 9.1: Search results from keywords: Autodesk,serial number, weebly
Figure 10: Encrypted script
We decoded the script and identified that there are two layers before the actual check is completed and a fake download page pops up.
Figure 11: Script layer 1
In the second layer, the script checks if “document.referrer” contains any of the entries listed in Figure 12. If not, the script will skip popping up the fake download page and additionally check if the user agent doesn’t match any of the entries listed in Figure 13. This comprehensive check of both aspects is done to avoid serving content to crawlers that visit the URL directly without referrers.
Figure 12: List of accepted referrers
Figure 13: List of blocked user agents
Figure 14: Script that avoids crawlers and pops-up a fake download page
After passing the above checks, a fake download page pops up that tricks the user into clicking the download button. Then, a few redirects happen before the setup.zip file drops onto the machine. While analyzing the traffic, we were able to find the response which provides the download link to setup.zip. It also contained an iframe that loads an image from https://crdms.images.consumerreports.org/t_pcard_sm,dpr_2.0,w_200,c_scale/prod/products/cr/product-groups/28984 measuring 1px X 1px , which in turn updates the DNS cache with the domain name crdms.images.consumerreports.org. Now it is clear how the domain name containing the string “dms.images.consumer” is present in the DNS cache of each victim’s machine. Additionally the response had an IP fingerprinting function.
Figure 15: Fake download page
Figure 16: Response with download link and DNS cache entry for decryption
While tracking this threat, we noticed that most of the time attackers, are hacking clean websites and hosting the malware. We also spotted that the hacked clean websites are poorly configured using outdated web server versions, making life easier for the attacker to hunt for and exploit these kinds of websites.
Figure 17: Hosted malware example 1, Open Directory
Figure 18: Hosted malware example 2, Open Directory
Now armed with knowledge about how the pre-execution check works, it is easy to reproduce this in the analysis environment. That said, we did a bit more static analysis just to confirm if any more checks were still happening before the loader proceeds. This time we edited the value of the argument “pbSecret” to “reports.org13d32” which is passed to the BCryptGenerateSymmetricKey API. The decrypted resource was a shell code which resolves a set APIs. It then enumerates the whole process using K32EnumProcesses. As a next step it uses Process IDs to retrieve the handle to process using the OpenProcess function, and from the retrieved handles it loops to find the file path of all loaded processes using GetModuleFileName. From the list of file paths of the loaded process, it searches for the Avira process names listed below. If found, it won’t execute further and exits the programs.
Figure 19: Avira Antivirus process
The loader’s next step is to decrypt the server URL and request an update. Based on the response, the loader decides how to continue processing.
Figure 20: Connecting to the update server
From our analysis we noticed that the server URL changes quite often, but the domain registration pattern and page to which the request is directed doesn’t:
domain name pattern—<alphabet, length 6~8>-cloud.icu. “-cloud.icu” has been present in the domains for a long time.
page—”update.php” was the page name in all the samples we’ve analyzed so far.
In the next stage of execution, the loader drops further components into the directory under “%windir%\System32\microsoft\protect\S-<random>\ or “%windir%\Syswow64\microsoft\protect\S-<random>\ and marks ownership of the folder and files to NT AUTHORITY\SYSTEM and attributes to Hidden and System.
Figure 21: List of further components dropped by the loader
RB_18.104.22.168.exe—Clean Apple Push executable, which imports AppleVersions.dll. Naming of the file is random, but the prefix is always RB_.
msvcp100.dll & msvcr100.dll—Microsoft® C Runtime Library.
AppleVersions.dll & data.dll—Second stage component of the loader, which decides whether a further payload is dropped to the machine
RB_22.214.171.124.exe loads AppleVersions.dll due to DLL search Order Hijacking
Final Stage components are dropped by Second Stage Components of the Loader
TiWorker.exe – Clean Sysinternals tool NotMyfault
Riched32.dll – Final Stage component of the loader
Final stage components are usually dropped under “%windir%\System32\<random>\S-<random>\” or “%windir%\Syswow64\<random>\S-<random>\” .
TiWorker.exe loads Riched32.dll due to DLL search Order Hijacking , not directly imported by NotMyfault tool but internally loads it using LoadLibrary API
The loader tries to disable Windows Defender features by altering the corresponding Windows Defender registry settings.
Figure 22: Altering Windows Defender settings
The loader alters the machine’s power scheme using the Windows utility powercfg.exe. The commands listed below are typically used by coin miners and keep the machine running even though the user isn’t actually using it. In this case, the loader seeks to actively install further payloads like pay-per-install campaigns.
Figure 23: Altering the power scheme
The loader schedules the Apple Push (RB_126.96.36.199) executable to run every 15 minutes indefinitely, with the loader leveraging taskschd.dll to achieve this.
Figure 24: Loader persistence
The payload varied each time the loader was activated. Of course, the loader may behave differently based on the particular system and victim’s geographical location. One thing we noticed during multiple runs of the loader was that in most cases the download assistant was dropped to the %Temp% directory with the filename run_<6-digit random number>.exe or just <6-digit random number>.exe. See below for a list of each malware family that got into the machine directly or indirectly while the loader was activated. The payloads never stayed the same and always varied.
Figure 25: Malware dropped by the loader during one of the successful execution attempts
CoinLoader is a highly sophisticated campaign that has been running for at least a year. It updates its components on a daily basis, ranging from files to hosting URLs. It also tries to evade security solutions through various means, from initial infection vectors to the final payloads.
Figure 26: Execution flow of CoinLoader
CoinLoader abuses free web hosting services, exploits poorly configured clean websites to host its payloads, and further abuses clean software using DLL search order hijacking. Ultimately, the main reason for its success is due to users still falling victim to social engineering scams. CoinLoader once again proves that social engineering still plays a major role in spreading malware.
All components associated with the CoinLoader family are detected by Avira as TR/CoinLoader.Gen & TR/AD.CoinLoader.B
T1027– Obfuscated Files or Information
T1038– DLL Search Order Hijacking
T1043– Commonly Used Port
T1053– Scheduled Task
T1059– Command-Line Interface
T1089– Disabling Security Tools
T1129– Execution through Module Load
T1158– Hidden Files and Directories
IOC: CoinLoader Full IOC List available here