A forum for reverse engineering, OS internals and malware analysis 

WinNT/Simda

Forum for analysis and discussion about malware.

Re: Malware/Not classified

 #16794  by EP_X0FF
 Sat Nov 24, 2012 2:47 am
Win32:Virut wrote:Simda?
Yes, with multiple AntiVM, AntiSandboxie, anti-forensics on board.

Blacklisted Windows Product ID's
Code: Select all
76487-337-8429955-22614 (Anubis)
76487-640-1457236-23837 (Anubis)
55274-640-2673064-23950 (JoeBox)
76487-644-3177037-23510 (CWSandbox)
Checking presense of installed apps
Code: Select all
HKEY_CURRENT_USER\Software\CommView
HKEY_CURRENT_USER\SYSTEM\CurrentControlSet\Services\IRIS5
HKEY_CURRENT_USER\Software\eEye Digital Security
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\
Uninstall\Wireshark
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\
App Paths\wireshark.exe
HKEY_CURRENT_USER\SOFTWARE\ZxSniffer
HKEY_CURRENT_USER\SOFTWARE\Cygwin
HKEY_CURRENT_USER\SOFTWARE\Cygwin
HKEY_CURRENT_USER\SOFTWARE\B Labs\Bopup Observer
HKEY_CURRENT_USER\AppEvents\Schemes\Apps\Bopup Observer
HKEY_CURRENT_USER\Software\B Labs\Bopup Observer
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\
Uninstall\Win Sniffer_is1
HKEY_CURRENT_USER\Software\Win Sniffer
HKEY_CURRENT_USER\SOFTWARE\Classes\
PEBrowseDotNETProfiler.DotNETProfiler
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\
Explorer\MenuOrder\Start Menu2\Programs\Debugging Tools for Windows (x86)
HKEY_CURRENT_USER\SYSTEM\CurrentControlSet\Services\SDbgMsg
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\
Explorer\MenuOrder\Start Menu2\Programs\APIS32
HKEY_CURRENT_USER\Software\Syser Soft
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\
Uninstall\APIS32
HKEY_CURRENT_USER\SOFTWARE\APIS32
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\
Uninstall\Oracle VM VirtualBox Guest Additions
HKEY_CURRENT_USER\SYSTEM\CurrentControlSet\Services\VBoxGuest
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\
Uninstall\Sandboxie
HKEY_CURRENT_USER\SYSTEM\CurrentControlSet\Services\SbieDrv
HKEY_CURRENT_USER\Software\Classes\Folder\shell\sandbox
HKEY_CURRENT_USER\Software\Classes\*\shell\sandbox
HKEY_CURRENT_USER\SOFTWARE\SUPERAntiSpyware.com
HKEY_CURRENT_USER\SOFTWARE\Classes\SUPERAntiSpywareContextMenuExt.SASCon.1
HKEY_CURRENT_USER\SOFTWARE\SUPERAntiSpyware.com
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\
Uninstall\ERUNT_is1
Checking list of running processes
Code: Select all
cv.exe
irise.exe
IrisSvc.exe
wireshark.exe
dumpcap.exe
ZxSniffer.exe
Aircrack-ng Gui.exe
observer.exe
tcpdump.exe
WinDump.exe
wspass.exe
Regshot.exe
ollydbg.exe
PEBrowseDbg.exe
windbg.exe
DrvLoader.exe
SymRecv.exe
Syser.exe
apis32.exe
VBoxService.exe
VBoxTray.exe
SbieSvc.exe
SbieCtrl.exe
SandboxieRpcSs.exe
SandboxieDcomLaunch.exe
SUPERAntiSpyware.exe
ERUNT.exe
ERDNT.exe
EtherD.exe
Sniffer.exe
CamtasiaStudio.exe
CamRecorder.exe
Checking presense of the following libraries in memory
Code: Select all
SBIEDLL.DLL
SBIEDLLX.DLL
DBGHELP.DLL
OLLYDBG
Check the following conditions: "CompName = Sandbox" || "UserName = CurrentUser" || FileName = "file.exe" When a number of these conditions are met, backdoor executes in infinite loop.


There is also few exploits inside like this one for example
Code: Select all
\00--><Actionstask%d\\?\globalroot\systemroot\system32\tasks\<Principals>
<Principalid="LocalSystem">
<UserId>S-1-5-18</UserId>
<RunLevel>HighestAvailable</RunLevel>
</Principal>
</Principals>
<ActionsContext="LocalSystem">
<Exec>
<Command>%s</Command>
http://technet.microsoft.com/en-us/secu ... n/MS10-092

and

http://technet.microsoft.com/en-us/secu ... n/MS10-015

Contains Image of Adobe flash installer main window and fake installation dialogs.

Re: Win32/Simda

 #19755  by Horgh
 Sun Jun 23, 2013 9:01 pm
So I looked at a simda binary today to find they included a new section in the backdoor. Now we have this :

Image

The new section .abk (a... bootkit ?) appears to be TrojanDropper:Win32/Rovnix.H, so it looks like the guys behind simda decided to add a bootkit component to their backdoor (I didn't dig further, but it seems that the driver infection capabilities of simda are still here as well (.driver section + code procedures). I looked at some other fresh TrojanDropper:Win32/Rovnix.H from VT and they all seem to share the same packer, the one used by simda since a very, very long time, and the code looks alike. I extracted the components from the abk binary : LDR (bootkit code), D32 (driver x86), D64 (driver x64). D32 & D64 also contain respectively HST32 & HST64 (dlls, HST = ?). All components are compressed by aplib, and are located in the .rsrc sections.

In the simda configs, we have 2 ips (google.com), the usual domain to download the rootkit module, and the usual google redirections.
Code: Select all
74.82.216.6
94.23.116.81
hxxp://update1.cl64domain.com/?abbr=RTK&action=download&setupType=umx&setupFileName=process_64.exe
In the archive : simda + unpacked, uacdll + unpacked, uac64, userm + unpacked, abk + unpacked.
Extracted from abk : LDR + D32 + D64 + HST32 + HST64
pwd : infected
(1.87 MiB) Downloaded 137 times

Re: Win32/Simda

 #19757  by EP_X0FF
 Mon Jun 24, 2013 3:08 am
Simda with BkLoader added to Bootkits/Rootkits sections, thanks for sharing. I assume we can except this leaked crap now in every somehow average bot.
And there is no need to allocate such huge regions for APLib decompression. Each aplib block described by common structure that has OrigSize in bytes as member and compressed buffer right after this structure.
Code: Select all
typedef struct _AP32Head {
	DWORD dwTag; //AP32
	DWORD SizeOfHeader;
	DWORD dwPackedSize;
	DWORD dwPackedCrc;
	DWORD dwOrigSize; //size of buffer to hold unpacked data
	DWORD dwOrigCrc;
} AP32Head, *PAP32Head;
just get this value and use it.

Re: Win32/Simda

 #19765  by Horgh
 Mon Jun 24, 2013 1:40 pm
And there is no need to allocate such huge regions for APLib decompression. Each aplib block described by common structure that has OrigSize in bytes as member and compressed buffer right after this structure.
Actually I just dumped the memory regions allocated where the aplib compressed components were decrypted, they have a fixed size in the code (0x1400 for LDR, 0x19000 for D32 + D64, 0x32000 for HST32 + HST64. So the blame is mostly on the coder of this :]

Edit : I took a look at older binaries to determine when the bkloader was integrated. This one for example (f811bfa8fe5411e10d7ac06fe45a1347) was first submitted a month ago on VT (First submission 2013-05-25 10:23:22 UTC). So the integration of bkloader was made before the carberp sale, and before the leak as well. I don't have earlier samples, so I can't give a precise date for this integration.
 Return to “Malware”