IceXLoader was discovered last June by FortiGuard Labs. It is a commercial malware used to download and deploy additional malware on infected machines. While the version discovered in June (v3.0) looked like a work-in-progress, we recently observed a newer v3.3.3 loader which looks to be fully functionable and includes a multi-stage delivery chain. 

Figure 1. IceXLoader delivery chain

First Stage Dropper 

The victim receives an archived file which holds the first-stage extractor. The extractor contains the next stage executable as well as different extract settings in the resources: 

Figure 2 – Dropper resources

The extractor creates a new .tmp folder under C:\Users\<username>\AppData\Local\Temp and drops the next-stage file (STOREM~2.EXE – .NET downloader) into it: 

 

Figure 3 – Dropped File

 

If the REBOOT resource is set, the infected station will be rebooted. The extractor then creates a new registry key under HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce named wextract_cleanup0 and sets it to “rundll32.exe C:\Windows\system32\advpack.dll, DelNodeRunDLL32 “C:\Users\username\AppData\Local\Temp\IXP000.TMP\””. This will delete the temporary folder created by the extractor during the next computer restart. 

Finally, the next-stage downloader is executed, and the extractor process exits. 

Downloader 

The executable (STOREM~2.EXE) dropped by the extractor is a simple .Net downloader which downloads a “.png” file from a hardcoded URL: 

Figure 4 – Download of IceXLoader dropper 

 

The downloaded stream is converted into a byte array, (Fcyozgdveenwuzwbrsmfqu.dll), which is then loaded in a new thread of the downloader (STOREM~2.EXE) It then invokes a method hardcoded by the author:  

Figure 5 – Execution of the dropper 

 

IceXLoader dropper 

The downloaded DLL is highly obfuscated, and is responsible for : 

  1. Decrypting the IceXLoader 
  2. Ensuring that the file is not executed inside Microsoft Defender’s emulator by verifying that the hostname is not equal to “hal9th”, and the username is not “johndoe”. This is considered a common evasion technique.  
  3. Delaying the execution for 35 seconds – by executing PowerShell with an encrypted command – “C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe” -enc UwB0AGEAcgB0AC0AUwBsAGUAZQBwACAALQBTAGUAYwBvAG4AZABzACAAMwA1AA==” – the technique usually used by threat actors to evade sandboxes due to an execution timeout. 
  4. Injecting IceXLoader into a new process (STOREM~2.EXE) by using the Process Hollowing technique. 

IceXLoader v3.3.3 

Version 3.3.3 of IceXLoader is written in the Nim language. “The Nim programming language is a concise, fast programming language that compiles to C, C++ and JavaScript”. Lately, the use of this language has become increasingly popular by threat actors, used also by  the Chinese threat actor in Nimbda loader, and the TA800 threat actor in Nimza loader. 

IceXLoader collects the following information about the victim and sends it to the C&C server: 

  1. Nickname – the nickname set by the malware author and hardcoded in binary; in our case the nickname is “Opus One”. 
  2. IP address. 
  3. UUID. 
  4. Username and machine name. 
  5. Windows OS version. 
  6. Installed security products. 
  7. Presence of .NET Framework v2.0 and/or v4.0. 
  8. Loader Version – in our case is v3.3.3. 
  9. RAM information. 
  10. CPU information. 
  11. GPU information. 
  12. Time stamp. 

 

 

Figure 6 – information collect 

While executing for the first time, IceXLoader copies itself into two directories: 

  1. “C:\Users\username\AppData\Roaming\Opus.exe” 
  2. “C:\Users\ username \AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\Opus.exe”  

It also creates a new registry key under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run named “Opus” and sets it to “C:\Users\<username>\AppData\Roaming\Opus.exe”. 

Both above techniques are used to provide persistency. 

 

 

Figure 7 – Registry persistency 

After creating persistency, the loader executes the newly copied instance of itself by executing the following command: “cmd /c timeout 2 & “C:\Users\<username>\AppData\Roaming\Opus.exe””. This  delays  execution by two seconds, and deletes the currently executing file, in our case the “C:\Users\<username>\AppData\Local\Temp\IXP000.TMP\ STOREM~2.EXE”. as the loader was injected into it. 

When executed again, the loader bypasses AMSI (Antimalware Scan Interface) protection by overwriting (patching) the AmsiScanBuffer API (which scans the user-input) in memory. The AMSI is a set of Windows APIs that allows any application to integrate with an antivirus product (assuming that product acts as an AMSI provider). Windows Defender, naturally, acts as an AMSI provider as do many third-party AV solutions. 

 

 

 

Figure 8 – Changing AmsiScanBuffer memory to writable 

The loader also creates and executes a .bat file which disables Windows Defender’s real-time scan and also adds exclusions to Windows Defender to prevent it from scanning the directory IceXLoader was copied to.  

 

Figure 9 – PowerShell commands to disable Windows Defender 

 

 

The list of the commands supported by version 3.3.3 is the same as described by FortiGuard Labs.  

IceXLoader attempts to download an additional executable from its C&C server. This file is saved as medianupdate.exe in the user’s temp folder. At the time of our investigation, the C&C server was available, but all the files except the victims’ DBs were removed. 

Victim DBs 

It would appear that the DB file is still being constantly updated (according to the “Last modified” column). 

Figure 10 – C&C server 

 

We examined the DB file, appearing to be SQLite, which contained thousands of victim records, which contained consisting of a mix of private home PCs and corporate PCs. We started informing the The affected companies are being informed after the discovery. 

 

Minerva Labs Anti Ransomware Prevention  

Minerva Labs Memory Injection Prevention module, which is part of the Minerva Armor Ransomware Protection solution, prevents IceXLoader at the very initial stage of its deployment, thus preventing the further execution flow and stopping the attack before it effectively even starts: 

  

 

MITRE ATT&CK: 

T1105 – Ingress Tool Transfer 

T1140 – Deobfuscate/Decode Files or Information 

T1620 – Reflective Code Loading 

T1497 – Virtualization/Sandbox Evasion 

T1055.012 – Process Injection: Process Hollowing 

T1592 – Gather Victim Host Information 

T1590.005 – Gather Victim Network Information: IP Addresses 

T1547.001 – Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder 

T1059.001 – Command and Scripting Interpreter: PowerShell 

T1562.001 –Impair Defenses: Disable or Modify Tools 

 

IOCs: 

Hashes: 

  • 49d6552ae5c5027ce1e68edee2438564b50ddc384276fd97360c92503771d3ac – first stage dropper 
  • 7bb69f98d77ca7609c10b9a0ab1ce32be2e26b160413203d5335f65c1bc8ee72 – downloader (STOREM~2.EXE) 
  • 9a9981d9bd10d3e004457ca4509aeb2bd828f54213f61b8a547c90e52f0b08eb – IceXLoader dropper (Fcyozgdveenwuzwbrsmfqu.dll) 
  • 0911819d0e050ddc5884ea40b4b39a716a7ef8de0179d0dfded9f043546cede9 – IceXLoader (Opus.exe) 

URLs: 

  • hxxps[:]//www.filifilm[.]com.br/images/colors/purple/Ejvffhop.png – IceXLoader dropper 

 

References: 

  • https://rastamouse.me/memory-patching-amsi-bypass/