Current state of malicious Powershell script blocking

Discussion in 'other anti-virus software' started by itman, Aug 9, 2017.

  1. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    Yes, I thought that was already clear, the only reason I posted about them is because PowerShell attacks are mostly a risk to bigger corporations.

    I already posted a link to Minerva in another thread. But I don't think it's relevant in this thread, since I'm guessing it won't block PowerShell related attacks. It is however a clever approach, but should be used together with NG-AV.

    Speaking of SentinelOne, I have to correct myself, they are focused on blocking exploits, but I'm not sure if they are using advanced exploit mitigation (via hooking) like Sophos/HMPA. BTW, enSilo was mentioned in this interesting article:

    http://www.csoonline.com/article/32...-anti-virus-protection-may-not-be-enough.html
     
  2. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Actually, nothing was stated in this article that has not already been posted in this thread and in much greater detail I might add.

    In review, PowerShell ver. 5.0 added increased event logging capability. This will assist in post-attack detection and manual mitigation efforts. PowerShell "Constained Language" mode is only available "out of the box" on Enterprise vers. of Windows via the AppLocker feature. It can be employed on other Windows vers. by registry hack and system modification of environment variable and is not officially "approved or recommended" by Microsoft. Obviously, there is no need to further discuss Win 10 AMSI script scanning feature which is the basis for this thread.

    What hasn't been discussed is Microsoft has publically stated that enhanced PowerShell mitigation capability will be provided in the fall release of Win 10 CE via Windows Defender ATP; an extra cost subscription service only available on Win 10 Pro+ versions. Whether these mitigations will actually be effective against PowerShell based malware will have to be verified through independent testing and actual malware attacks. Ref.: https://blogs.technet.microsoft.com...ng-detecting-new-and-unusual-breach-activity/
     
    Last edited: Aug 27, 2017
  3. ronjor

    ronjor Global Moderator

    Joined:
    Jul 21, 2003
    Posts:
    163,072
    Location:
    Texas
    The point is, Microsoft is aware and working on it. Information adds more knowledge and for those that are not coders, information can be helpful.
     
  4. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    As far as Microsoft "working on the problem" is concerned, the most pressing issue is that I noted in reply #16.

    That is the ability for malware authors to create scripts that can bypass Win 10's AMSI anti-obfuscation processing. For example, the Empire offensive PowerShell tool has such capability. Microsoft went to lengths in its write up for AMSI to describe how it can unobfuscate scripts thereby allowing AV engines to examine them prior to execution. It is therefore reasonable for AV solutions employing AMSI to rely on it for such capability.

    The problem is that this is "much easier said than done" given the complexity of determining what are and are not valid character deployments in a given script. So it appears to me that the solution is for Microsoft to modify its scripting engines, notably Powershell, not to ignore select non-contiguous characters in a script as is now possible.

    -EDIT- Here's another solution. Microsoft loads the suspicious script probability algorithms its own security researcher developer over two years ago to their Azure AI servers. Then modify amsi.dll to dial out for suspicious script obfuscation activity whenever a script is processed. -CONTINUED- Since the script has already been uploaded, a full behavior analysis should also be performed. If Microsoft's AI scanning is as effective as claimed, this should eliminate the majority of script based malware. If the script scans clean via AI behavior detection, the AV engine will again scan it for signature detection. It will now be able to do so since token obfuscation is no longer an issue.

    Finally and unless I am missing something, the load impact on the AI servers would be minimal since home users or SMBs as a rule don't create scripts for daily processing activities. The protection could be eliminated on Win 10 Enterprise vers. since they can use AppLocker to control script execution.

    Time Microsoft put some "substance" behind their claim that Win 10 is a more secure OS.
     
    Last edited: Aug 28, 2017
  5. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Came across this great FireEye presentation and whitepaper on recent Powershell obfuscated attacks given at Blackhat 2017. Among many other techniques given in the whitepaper is the ability of Powershell attackers to obfuscate the recording of Powershell attack activity in the Event log:
    https://www.fireeye.com/blog/threat-research/2017/07/revoke-obfuscation-powershell.html

    White paper ref.: https://www.blackhat.com/docs/us-17/thursday/us-17-Bohannon-Revoke-Obfuscation-PowerShell-Obfuscation-Detection-And Evasion-Using-Science-wp.pdf
     
  6. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    To get things back into "balance" a bit, it should be observed how effective Win 10 AMSI is against current prevalent "real world" javascript and PowerShell script attacks. The MRG test was a simulated attack employing an offensive Powershell tool. Such attacks do occur but are usually targeted attacks against high value targets with many falling in the APT category. Additionally as noted previously, obfuscation of Powershell scripts are rare although there is no assurance such will remain the same in the future.

    Prevalent PowerShell attacks fall into two categories; e-mail and drive-by download based. In the past, e-mail Powershell based attacks were most prevalent. However that is changing and drive-by download attacks are increasing in frequency; a fact I can personally attest to. Last April, AVLab in Poland conducted an AV consumer and Endpoint product comparative using 0-day browser based drive-by download delivered malware consisting of Powershell script and obfuscated javascript malware.

    The test was employed on Win 10, so AMSI would have been available to allow vendors deploying it to examine the script in memory after it was unpacked and unobfuscated. The fact that the most of major AV vendors that employ AMSI were able to detect all or most of the malware via use of their web filtering protection attests to the fact that AMSI currently is quite effective in allowing the examination of prevalent script based malware. Of note is that AMSI use in itself does nothing to rectify poor malware detection within the script as evidenced by Windows Defender poor detection rate. The AVLab test is unique in that it notes what protection method by the AV product the malware was detected.
    Note that the following report extract shows the AV protection method by which the attacks were detected:
    Ref.: https://avlab.pl/sites/default/files/68files/avlab_drive_by_download_test_en.pdf
     
    Last edited: Aug 29, 2017
  7. cruelsister

    cruelsister Registered Member

    Joined:
    Nov 6, 2007
    Posts:
    1,649
    Location:
    Paris
    The actual source is totally inconsequential since for the malware to work it has to call up and run Powershell on the Local System. So it does not matter if it is a drive-by, email link, or running and infected keygen- in all cases PS will be called up and subsequent commands will be implemented (and it is the PS commands and resulting actions that are the basis of malicious activity and NOT Powershell itself). This has been the issue with ANY scriptor (PS, VBS, Java, Python)- most security products cannot distinguish between legitimate and malicious (except by "dumb" definitions, and my cat can make any scriptor zero-day while she is using the litterbox). That has always been the point of AMSI- the ability to differentiate being good and bad.

    Also, the obsession about web exploits being somehow magical and worse than other malware sources has been a matter of constant amusement to me (and my cat).

    .
     
  8. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Actually not since remote execution of Powershell on the local system bypasses most security protection.
     
  9. cruelsister

    cruelsister Registered Member

    Joined:
    Nov 6, 2007
    Posts:
    1,649
    Location:
    Paris
    That is true as long as Powershell Remoting is specifically enable on the target system, which I'm sure you will agree is not likely on Home systems. On Corporate systems this is indeed possible (and I have always wondered why some IT folk take up so much time to put in place PS restriction policies which can be negated so easily by the bypass command) as remote PS may well be active. And further complications may exist for the attacker in gaining access to credentials (although Mimikatz will assist here, depending...).

    But even in this case Powershell itself is not the issue. The resulting script must still be run locally for any malicious action to take place. Don't get me wrong- if your point is that traditional security measures absolutely suck against scriptors I couldn't agree more (and have been harping on this for years in my videos); but with the proper security program in place the end goal of the PS script can be detected and contained.
     
  10. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
  11. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Interesting indeed:
    Appears to be a way to bypass the internal whitelist of .Net modules allowed to run in "Constrained Language" mode but I believe in the context of how scripts are written. His prevention recommendation is addressed to script developers. As such, nothing can really be done on the user end about it.

    As far as his recommended mitigation:
    Scriptblock logging would only be applicable to AppContainer installations. If you set "Constrained Language" mode outside of AppContainer, all PowerShell scripts are allowed run. In other words, it is AppContainer policy settings that can only restrict Powershell script execution.
     
  12. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Continuing reply #111, what is being exploited is this feature of "Constrained Language" mode:
    https://docs.microsoft.com/en-us/po...bout/about_language_modes?view=powershell-5.1

    by overriding C# code and Win32 API load restriction.
    Also this attack falls in the category of script obfuscation:
    -EDIT- Realized it probably still isn't clear to many what is going on.

    What is shown is a way to memory inject malicious code into a signed Powershell script running under AppLocker if the script is not properly coded. Something MS wasn't aware of as evidenced by the recent CVE patches that were issue.
     
    Last edited: Aug 30, 2017
  13. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    A very recent example of both javascript and Powershell obfuscation occurred this week to a U.S. government web site. Luckily the web site hack was discovered in a couple of hours. The hack served up Cerber ransomware. Luckily the ransomware payload served up by the obfuscated PowerShell script was an older one which all the major AV's have signatures for. However, this attack does show first that ransomware is being employed by drive by download, and it is using obfuscated Powershell commands to do so.

    Below is the obfuscated PowerShell command and what it actually executes. Also this not a script execution but use of a .Net subassembly:
    https://blog.newskysecurity.com/us-government-site-unwittingly-hosting-malware-f1f4f11b6a1d

    The ransomware installer BTW was Nemucod.

    -EDIT- Also of note was that the javascipt to run the command shell execution of PowerShell was itself obfuscated in a clear attempt to bypass anti-exec and HIPS Powershell startup monitoring.

    Couldn't think of a better example why all script engines startup need to be monitoried.
     
    Last edited: Sep 1, 2017
  14. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    I still don't get it, what is so special about this? AE/white-listing will easily will block this. It will block the malware from running since it's not white-listed, no matter if it's launched via PowerShell or not. And certain AE's will block cmd.exe and powershell.exe from running in the first place. Like I said, you're way too fascinated by this stuff.
     
  15. cruelsister

    cruelsister Registered Member

    Joined:
    Nov 6, 2007
    Posts:
    1,649
    Location:
    Paris
    Agreed- it's not in any way special as it is just a downloader/initiator for the actual ransomware vector. It can be confusing to some as although the PS script itself may have limited detection by AV's, the Cerber payload is probably detected by everyone and their cat. Also as you mention ransomware can be easily prevented by solutions more advanced than the traditional AV.
     
  16. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Not if Powershell was launched remotely or from memory. Although, it was not the case in this attack.

    Additionally, the ransomware code can be contained entirely with the Powershell script/code and also within javascript code via node.js usage as noted here: https://arstechnica.com/information...cover-javascript-based-ransomware-as-service/

    Again, AE/whitelisting effective only for local disk based malware execution. Also, only for local disk based script execution monitoring.

    As far as bypassing whitelisting or anti-exec blocking offensive PowerShell tools and powershell.exe, you might want to read this. He also lists some other bypasses not listed yet in this thread. Again, if one is directly monitoring cscript.exe or wscript.exe execution, the attack could be stopped assuming the target actually blocked the execution. Also if employed via exploit and the script run from memory, game over.
    https://www.peerlyst.com/posts/star...r-blocking-of-powershell-exe-benjamin-infosec
     
    Last edited: Sep 2, 2017
  17. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Win 10 AMSI can only examine scripts directly executed by powershell.exe, cscript.exe, or wscript.exe. It will not examine scripts from other scripting engines such as Python. So if a Starfighters or like memory script execution or another scripting engine was employed by the malware, it would totally bypass AMSI. That leaves the only detection mechanism to be employed is advanced memory scanning(AMS) if the security product has such capability. Since AMS is post-execution detection, there is a high likelihood that ransomware or other malware could have run for some time prior to detection; if detected at all.
     
    Last edited: Sep 2, 2017
  18. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    Yes we already know this, but the point is that both disk and in-memory based malware can be stopped or contained. I just read the Symantec report about PowerShell attacks, and this affirms what I already thought. It's certainly sneaky, but not unstoppable. And I also need to correct myself, PowerShell isn't really used in exploit attacks at the moment, so it's more about spear phishing, trying to make people run malicious scripts.

    Exactly, just because PowerShell is involved doesn't automatically mean it's an advanced attack.
     
  19. cruelsister

    cruelsister Registered Member

    Joined:
    Nov 6, 2007
    Posts:
    1,649
    Location:
    Paris
    Rasheed- there is a rec ent Kovter variant (Symantec describes it as both fileless and "residing only in the registry to evade detection") that is turning systems into ransomware spewing Zombies similar to what was reported here: https://www.wilderssecurity.com/thr...ails-distribute-locky-in-a-single-day.396506/

    (Of course in the article attached to that post only the ransomware part is described- the author totally ignores how the malware was delivered to the victim. So Typical!!!).

    This one is cool in that the malware can be delivered up by a web drive-by, a downloaded doc or an exe. It uses mshta to startup PS, which then sets itself up for persistence and malware activation by creating registry entries in places that are ignored by any Startup Monitor that I am aware of. After that it will inject into either svchost or regsvr32, so on system start the only thing that can be seen are legit MS processes- but a closer look will show that these processes are sending out malware in the hundreds without end.

    But even this can be simply stopped by the use of an outbound firewall, some of which will block the connections by default and without any alerts! One must really wonder why Windows Firewall does not have restrictions in place that would parallel something like WFC. It is totally unacceptable that it does not, but until Windows users are aware of the uselessness of the current WF and actually harass Microsoft for immediate changes nothing will ever be done.
     
  20. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Yes. I noted this previously.

    All script engines outbound communication must be monitored/blocked. Some additional ones I monitor are; all .Net MSBuild executables, WinRM service, ntvdm.exe, rundll32.exe, cmd.exe, wsmprovhost.exe, regsvc32.exe.

    Additionally, I set up a fixed port for WMI and monitor all inbound communication for that port.

    -EDIT- As far as the current Locky campaign that encrypts file with the .lukitus extension, it employed a .vba .vbs script archive that was inbedded in another archive. Obviously, the e-mail was a Word document. Also assumed is the script was packed, encrypted, and obfuscated to avoid AV sig. detection of the ransomware downloader contained within.

    The .doc file would have to be opened outside of MS Word Protected Mode. And even if this was done if VBA option was disabled in Word security settings, the script would never have run.

    If the target was running Win 10 and using a security solution employing AMSI, the .vbs script would have been scanned in memory for signature detection. The problem is if the script was not fully unobfuscated at time of security solution scanning, it will bypass detection by the majority of AV products as noted in the MRG test. Same would apply if no sig. exists for the downloader. At that point, the only protection available is advanced memory scanning post-execution. And as noted in past ransomware incidences that is usually too late; most of your files have been encrypted.

    Obviously if you were monitoring wscript.exe execution, the script could be blocked.
     
    Last edited: Sep 4, 2017
  21. cruelsister

    cruelsister Registered Member

    Joined:
    Nov 6, 2007
    Posts:
    1,649
    Location:
    Paris
    Seems like a lot of work to me, and would not be needed if Microsoft would improve the default protection of Windows Firewall and elevate it from the current relic of yesteryear that it currently is. Yes indeed, one can make it more secure by the input of complex and arcane Rules, but would this be a viable option for the Great Unwashed?

    You are a Pro, but the majority of those reading this post (if any) are not- they are Home users. These folk should be using their computer for its intended purpose and not be spending a majority of their time in monitoring, scanning, and various other security application upkeep tasks.

    Microsoft can make this more of a reality by converting WF into something that actually has a point. It really saddens me when I see comments like "Windows firewall is more than enough!".

    And apparently a WF upgrade would save quite a bit of your time...
     
  22. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I use Eset's firewall.
     
  23. Azure Phoenix

    Azure Phoenix Registered Member

    Joined:
    Nov 22, 2014
    Posts:
    1,556
    You are probably already aware but apparently Microsoft is working on a new feature called Network Protection for its Fall Creators Update

    https://www.wilderssecurity.com/thr...-windows-10-needs.383448/page-45#post-2702605
    Minimize the exposure of your devices from network and web-based infection vectors.
    It expands the scope of Windows Defender SmartScreen to block all outbound HTTP(s) traffic that attempts to connect to low-reputation sources
     
  24. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I can't wait for the FP issues this will cause:
     
  25. xxJackxx

    xxJackxx Registered Member

    Joined:
    Oct 23, 2008
    Posts:
    8,625
    Location:
    USA
    I agree. I hope it can be disabled if it causes problems.
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.