Jump to content

Cleaning rootkit problem


Recommended Posts

Hi Dear ESET Admins.

We find over 10 System in a network that was infected with a Dll that work like a rootkit. it use svchost.exe and dllhost.exe to download other Trojans and coin-miners.

The main dll threat is : c:\windows\system32\Ms32A1591EApp.dll

https://www.virustotal.com/gui/file/7893c5e68ff78d76c0b4b8ba5ae2367fa9c285efe520de44ff12498ba90df5b0/detection

it's registered as a hidden service that just Gmer.exe can show in system32 (Hidden). while ESET detect this dll as A Variant Of Win32/Packed.VMProtect.ABO but in an infected system ESET Endpoint Security can not see that Dll and even can not scan it. just ESET will block injected Svchost.exe many times (As you can see in the pictures). Restart message will appear but after restart and deep scan still infection is exist.

we use kaspersky virus removal tool and it can scan and detect  Ms32A1591EApp.dll and clean the infection in normal environment (Not SafeMode or RescueDisk).

ESET Log Collector log of infected system :  https://we.tl/t-Ga6SeZWiTp

May be ESET SysRescue will clean this infection from a liveOS but the Questions are :

Why ESET Endpoint Security v8.0 can not scan that Dll in infected system but Kaspersky virus removal tool (Portable) can scan that file in normal environment (Not SafeMode or RescueDisk) at infected system.

Password of Zip file : infected

 

 

 

2.png

3.png

1.png

Ms32A1591EApp_Password_infected.zip

Edited by kamiran.asia
Link to comment
Share on other sites

2 minutes ago, Marcos said:

Please start off by running a disk scan with ESET SysRescue.

Hi dear @Marcos and thank you for quick reply as usual.

we think that ESET SysRescue will detect this file because it will clean it from a live OS . The problem is why Kaspersky Virus Removal tool can scan this file in normal mode But ESET can not see this !

it is very hard to clean suck these infected with sysrescue in a enterprise network!

Link to comment
Share on other sites

A word of warning here.

I just downloaded Kaspersky's Virus Removal Tool from their web site: https://www.kaspersky.com/downloads/thank-you/free-virus-removal-tool . When I went to run it, Win 10 SmartScreen threw a trusted publisher warning. Very odd indeed.

Well, it turns out the app is indeed not validly signed. Thanks but no thanks on its use.

KVRT_Invalid.thumb.png.c01f678cfbb8438ec29c9fb0717f7416.png

Edited by itman
Link to comment
Share on other sites

2 hours ago, Marcos said:

Please start off by running a disk scan with ESET SysRescue.

As we were testing SysRescue in this case , We find that it can not be update to latest signature.

Even with User/Pass and even from other ESET update servers.

Latest update is 22313 - 2020-11-13 and it can not be updated any more.

 

 

 

SysRescue.jpg

Link to comment
Share on other sites

Since no one has picked up on this yet, refer to my posted KVRT.exe download cert. screen shots. Note the signing time on the cert. shown. Err ........ June 14, 2021 12:15 PM. Give me a break!

What I am seeing here is an Internet in-transit man-in-the-middle attack. As these go and still thankfully, when the attackers re-signed their hijacked download copy, they couldn't change the signature encryption key. Seeing one these in-transit MITM attacks is very rare. I am assuming the hijacking occurred on a relay server within Russia. I am also assuming that the actual download hosted on the Kaspersky servers is legit.

Edited by itman
Link to comment
Share on other sites

Per the VT link you posted, Eset's detection of the .dll you found is "A variant of Win32/Packed.VMProtect.ABO."

Are your clients using cracked software?

Link to comment
Share on other sites

  • Administrators

Please provide a complete memory dump from the infected machine.

As for the problem with updating SysRescue, I'll check it out in the morning but recently it worked when I tried it.

Link to comment
Share on other sites

  • Administrators
7 hours ago, kamiran.asia said:

We think that ESET must work on this infection

That's why we've asked you for a complete memory dump from the infected machine which is necessary for further investigation of the malware.

Regarding ESET SysRescue, I didn't have any problems with update as long as the computer was connected to the Internet:

image.png

Link to comment
Share on other sites

@Marcos Unfortunately all infected system are cleaned right now by KVRT.exe 😔

We are working on this threat, we find an exe file that may be the source of infection. But when we run it in our test lab nothing happen, just it download a cert from

 
May be it detect virtual environment and decide to not run.
 
The File is Attached. password : infected
 
 

RFQ.zip

Link to comment
Share on other sites

  • Administrators

The sample is already detected:

Win32/TrojanDownloader.Delf.DFG

Unfortunately without a complete memory dump we can't improve protection against this rootkit.

Link to comment
Share on other sites

10 hours ago, itman said:

Per the VT link you posted, Eset's detection of the .dll you found is "A variant of Win32/Packed.VMProtect.ABO."

Are your clients using cracked software?

No We think that this DLL file is encrypted by VMProtect . So ESET Detect it as Win32/Packed.VMProtect.ABO

Link to comment
Share on other sites

4 hours ago, Marcos said:

That's why we've asked you for a complete memory dump from the infected machine which is necessary for further investigation of the malware.

Regarding ESET SysRescue, I didn't have any problems with update as long as the computer was connected to the Internet:

image.png

Dear @Marcos

We test again , Nup file will downloaded but Version of VSD not update more than 22313

Latest update : 22313 - 2020-11-13 and it can not be updated any more.

It seems that there is a problem in linux update files for sysrescue.

Link to comment
Share on other sites

BTW - found a very nasty hidden rootkit on my device recently.

To begin, my Win 10 build had been acting up for much of May. The most obvious issue was that every time Win Store would attempt to update it would crash. Running wsreset.exe would fix the issue for a few days and it would return. There were also other issues pointing to security credential issues that weren't obviously serious. So I had been ignoring those. Other issues were system not shutting down properly at times. The security issues getting worse, and finally a Win 10 memory bug check at system shutdown.

Time for a full forensic analysis!

Ran sfc /scannow and corrupt files found and replaced. The CBS log interestingly showed Win 10 system apps; not system32, etc. processes were the issue. Eset system checker utility also showed system changes. I had been also ignoring those since I had done numerous system tweaks in the past but reset all those to system defaults. Still no help to the issue.

Then I remember I had also recently updated my Realtek network adapter driver since the one in the Win driver directory was unsigned. So I thought, let's try to set Win 10 HV memory integrity on; something I was never able to previously do. Wallah - success! Also thereafter, no more Win Store updating issues. But this did lead me to believe a possible rootkit existed.

At this point, I believe the Win Store updating issue was due to a borked MS Office update. But this caused the rootkit to start unmasking itself. So I downoaded MBAM's anti-rootkit utility. Ran it and it hung at the end when scanning the registry - not good. Also thereafter, this SMB event log entry showed up:

SMB_rootkit.png.0d22a59920bafe4f8a02abb296812e77.png

So it does look like a SMB related rootkit - yikes! Also, the only way I could get rid of this entry was to manually enter the default reg. key value. I also created an Eset HIPS rule to monitor write activity to this key and the rootkit blew right past it with the rule never triggering.

Ran Eset SysRescue and it didn't find anything.

At this point, I fired up Process Explorer and low and behold, sitting at the top of the list was a svchost.exe entry. I have PE configured to show processes in load order and svchost.exe never ever appeared at the top of the list. The service I believe was name "location." Note there is no such Win 10 service. There is a legit geolocation service.

Next ,cleaned the Win page file via reg. key shutdown option. Still a no go on that bogus service entry.

Last thing left to do prior to a reformat and reinstall of Win 10  was to delete the hiberfil. Sucess!! Bogus service entry gone. PC security issue log entries gone. PC running great currently.

I also believe this rootkit was on my system for a while and might be coin miner related. I don't have my tower case fans constantly spinning up as occurred previously.

Since this malware was SMB related, it might track to a suspicious SMB incident about 6 months ago.

Edited by itman
Link to comment
Share on other sites

It's also appropriate to note that what occurred in this posting incident is a user mode rootkit.

Mitigations to prevent re-occurrence are:

Quote

Best Practices against User Mode Rootkit

This section states the best practices with the User-Mode Rootkit:

  • For key system files, cryptographic hashes must be obtained. Also use tools like File Integrity monitor must be deployed to check for any unauthorized change to the key system files.
  • To prevent Windows DLL injection, restrict the DEBUG right in the system. This can be set under secpol.msc >Local Policies > User Rights Management.

071015_1035_RootkitsUse2.png

  • Keep the system patched with the latest updates from vendors.
  • If system is infected with this rootkit, then reinstalling the system with reformatted drive is the best choice.
  • To disallow another attack, patch the systems and change all the previous set admin passswords.

 

Edited by itman
Link to comment
Share on other sites

On 6/15/2021 at 5:51 AM, kamiran.asia said:

We are working on this threat, we find an exe file that may be the source of infection. But when we run it in our test lab nothing happen, just it download a cert from

For what's it worth, this might have been a SuperNova malware attack or a variant of one:

image.png.44a78f71e1eaf5685f2b269870f9da76.png

If you review the behavior analysis from the VirusTotal link you posted to the detailed SuperNova malware analysis given here: https://0xthreatintel.medium.com/uncovering-supernova-malware-e82bba302fcb , there are too many similarities to be ignored.

Edited by itman
Link to comment
Share on other sites

in Universal Virus Sniffer it might look like this.

In normal mode:

eset_com.jpg.3e025e0b1142c27019701d2db9ec958c.jpg

from under Winpe + uVS

Quote

Полное имя                  C:\WINDOWS\SYSTEM32\MS5AC23CA6APP.DLL
Имя файла                   MS5AC23CA6APP.DLL
 

www.virustotal.com          2021-06-01 00:20 [2021-05-05]
DrWeb                       Trojan.Packed2.43111
ESET-NOD32                  a variant of Win32/Packed.VMProtect.ABO
Kaspersky                   Trojan.Win32.Agentb.kkyb
Microsoft                   Trojan:Win32/Vigorf.A

                          
Доп. информация             на момент обновления списка
SHA1                        5FC84FB8A1052C66C3456B39FF0B2F1BA30BAC01
MD5                         BA8C6938AA6973E5081F48F1D61E2969
                           
Ссылки на объект           
Ссылка                      HKLM\uvs_system\ControlSet001\Services\Ms5AC23CA6App\Parameters\ServiceDLL
ServiceDLL                  C:\Windows\System32\Ms5AC23CA6App.dll
Name                        Ms5AC23CA6App
Изменен                     25.05.2021 в 14:12:38

 

Edited by safety
Link to comment
Share on other sites

those. uVS (Universal Virus Sniffer - there is a Russian, there is an English version) from normal mode can show malicious threads injected into a clean process. and then, if we do not find out who created these streams, we need to analyze the system from under Winpe, as a rule, either a rootkit driver, or dll is launched through a service, or MBR is infected

Link to comment
Share on other sites

On 6/15/2021 at 2:27 PM, Marcos said:

The sample is already detected:

Win32/TrojanDownloader.Delf.DFG

Unfortunately without a complete memory dump we can't improve protection against this rootkit.

Unfortunately as i said we don't have any infected system right now to analyze more (Memory dump or etc..) .

Quote

The sample is already detected:

Win32/TrojanDownloader.Delf.DFG

Yes , The source of infection is detected by eset , may be No AV was installed when PCs infected.

as you know the main problem is Rootkit dll hide it self from Windows and ESET kernel so just Gmer or liveOS can see it.

We will update this topic if we find another infected system.

 

Link to comment
Share on other sites

10 minutes ago, kamiran.asia said:

as you know the main problem is Rootkit dll hide it self from Windows and ESET kernel so just Gmer or liveOS can see it.

check also in tdsskiller from Kaspersky

Link to comment
Share on other sites

by the way, kamiran.asia, in this version of the rootkit there should also be a security policy, check

Active IPSec Policy [Local]: SOFTWARE\Policies\Microsoft\Windows\IPSEC\Policy\Local\ipsecPolicy{9cebfa4f-4ea7-4c53-b4ce-fbeba78b7175}

Link to comment
Share on other sites

If MS5AC23CA6APP.DLL is allowed to run, the following will occur.

The sample submitted to VT shows the malware was executed via:

  • %windir%\System32\svchost.exe -k WerSvcGroup
  • %windir%\system32\WerFault.exe -u -p 2592 -s 124

-u stands for user mode, -p is process id, and -s means it was executed via SilentProcessExit API mode.

Other analysis of this malware I reviewed notes a malicious .dll is first registered . Then the legit service registry key corresponding to svchost.exe -k WerSvcGroup .dll reference is modified to point to the malicious .dll.

eset-wersvc.thumb.png.d25aae44aac56cb8ad5db1192463adbb.png

The real mystery is why Eset didn't detect MS5AC23CA6APP.DLL upon download. My best guess is its packed, encrypted, etc. code.

Edited by itman
Link to comment
Share on other sites

One last comment here.

If @safety description of how MS5AC23CA6APP.DLL was installed applies to this installation, no rootkit activity was deployed.

Instead, something installed a service to run the .dll when the service was started. The best way to create a service without suspicion is to install something that runs in Trusted Installer mode. Or alternatively, run msiexec.exe standalone but that would draw more attention by security monitoring software.

Again per the Infosec link I posted, user rootkits manifest via some form of .dll injection; direct, reflective, etc. into a running svchost.exe process. I would also say employing process hollowing activities against a svchost.exe instance would also fall into this category.

 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...