Current state of malicious Powershell script blocking

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

  1. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,400
    Location:
    U.S.A.
    MRG recently ran an ad hoc test on Win 10 in regards to determining the anti-malware scan interface(AMSI) effectiveness when used by AV products. Note: many vendors still do not deploy it. AMSI allows AV products to examine packed and obfuscated PowerShell scripts in a container as they unpacked and de-obfuscated but prior to execution.

    This testing involved three script execution methods; file based, memory based w/o obfuscation, and memory based w/obfuscation. Most of the tested AV products did well against disk based script execution noting that a number of those products do not use AMSI. Such was not the case for memory based script execution with only three products detecting the non-obfuscated script - all of those using AMSI - and only one AV product detecting the obfuscated script.

    -EDIT-
    Note: there is a "surprise" in the test results.
    https://www.mrg-effitas.com/current-state-of-malicious-powershell-script-blocking/
     
    Last edited: Aug 11, 2017
  2. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    Fascinating. Thanks Itman
     
  3. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,400
    Location:
    U.S.A.
    A good follow-up "read" to this testing is here: https://adsecurity.org/?p=2921 . I believe that again running PowerShell in "Constrained Language" mode will block in memory execution of it based on what is posted in the article. @Zoltan_MRG , any chance you can perform the same Mimikatz testing with PowerShell set to "Constrained Language" mode?
    Some additional ways AMSI can be disabled. Note this only applies to Windows Defender. The AV vendors use their own custom AMSI .dll. As long as the AV solution kernel process runs as protected in OS kernel mode, you're OK:
    https://redmondmag.com/Articles/2016/10/01/Dissecting-Windows-10-Security.aspx?Page=2
     
    Last edited: Aug 9, 2017
  4. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,400
    Location:
    U.S.A.
    Since Zoltan hasn't replied to my previous question, I will add that setting Powershell to "Constained Language" mode will block the Invoke-Mimikatz in memory execution of Powershell as shown in the below screen shot given in the previously posted adsecurity.org link:

    PS_Constrained.png
     
  5. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,400
    Location:
    U.S.A.
    Also of note is that Microsoft is removing Powershell 2.0 in Win 10 CE fall update. By default, it is presently installed on all Win 10 versions. More important is all the attacker has to is run PowerShell for example by specifying its version number via command shell at startup time, and AMSI will be bypassed as noted here:
    https://www.petri.com/microsoft-deprecate-powershell-2-0-windows-10-fall-creators-update

    Ways to run Powershell v2.0 both locally and remotely by an attacker are given here: https://docs.microsoft.com/en-us/po...ndows-powershell-2.0-engine?view=powershell-6

    So PowerShell v2.0 needs to be uninstalled in Win 10 via Control Panel -> Programs -> Uninstall optional features or by using the PowerShell v5.0 command noted in the petri.com article.

    -EDIT- Also implied, I will state this explicitly. Not only will use of PowerShell v2 bypass Win 10 AMSI, it will also bypass PowerShell "Constrained Language" mode. This is because
    PowerShell v2 does not support that mode setting. POC given here: https://pentestn00b.wordpress.com/2017/03/20/simple-bypass-for-powershell-constrained-language-mode/
     
    Last edited: Aug 13, 2017
  6. NormanF

    NormanF Registered Member

    Joined:
    Feb 20, 2009
    Posts:
    2,742
    Uninstalled Powershell v. 2.0 now that its being deprecated.
     
  7. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,400
    Location:
    U.S.A.
    Finally in spite of our heroic efforts to block all potential malicious use of resident installed Powershell locally or remotely, we can still get "nailed" by it.

    Malware will download a hacked version of powershell.exe and use it to trash your PC. One example among a number of malware that have done so is:
    https://securityintelligence.com/news/fileless-malware-loaded-into-memory-via-powershell/

    Whether this malicious powershell.exe was actually a renamed P0wnedShell mentioned in the adsecurity.org lined article trying to bypass whitelisting and the like, I have no way of knowing. What I do know for sure is "where there is malware "will," the malware will find a "way."

    I believe Powershell "Constained Language" mode will catch most of the crap. However if the execution is being done at the lowest Powershell code level via a C or assembler language program, the only thing that will prevent is setting Powershell to "No Language" mode. This mode prevents all Powershell execution except directly from the PowerShell GUI interface itself. Of course, this mode will in all likelihood "bork" existing valid OS use of Powershell.
     
    Last edited: Aug 11, 2017
  8. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,400
    Location:
    U.S.A.
    Oops. Forgot to mention this.

    Open up in Windows Event Viewer the Windows operational log for PowerShell. You will observe a number of recent events logged there. Proof that your existing HIPS, whitelisting, anti-exec, SRP you name it method to block PowerShell.exe running is doing "diddly squat" in regards to blocking all Powershell execution. All that it is doing is blocking any direct execution of it.

    Next look for Event ID 4104 with the wording "Remote Execution" associated with it. Those should be all flagged as "Warning" with a yellow exclamation point. Browse through those. In my log, most looked benign; mostly Win 10 telemetry crap and the like. However, some were interesting such as Powershell version checking and the like indicating suspicious external probing activities. What I do know for sure is once I set PowerShell to "Constrained Language" mode, there hasn't been a single remote execution event logged.

    -EDIT-
    https://www.fireeye.com/blog/threat-research/2016/02/greater_visibilityt.html
     
    Last edited: Aug 11, 2017
  9. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,400
    Location:
    U.S.A.
    Expanding upon my previous comment about low level component PowerShell use is how that can be done to bypass Powershell "Constained Language" mode. Below is a POC that does just that. So Wilders folks that employ a security solution that can monitor use of System.Management.Automation.dll use can detect such activity:
    http://www.3nc0d3r.com/2016/12/pslo...6/12/pslockdownpolicy-and-ways-around-it.html

    BTW - use of PowerShell "Restricted Language" mode blocks all PowerShell script execution including ". \" use as done in this POC. So I am exploring if that option is a viable solution.
     
    Last edited: Aug 13, 2017
  10. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    Hi Itman

    I've execution of that DLL blocked. I assume that will stop that activity. I've not seen any ill effect from blocking it.
     
  11. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,400
    Location:
    U.S.A.
    Another good ref. to current issues with Powershell 5.0, AppLocker, SRP, and Application Whitelisting Layer overall:
    https://www.sysadmins.lv/blog-en/powershell-50-and-applocker-when-security-doesnt-mean-security.aspx
    https://www.sysadmins.lv/blog-en/po...hen-security-doesnt-mean-security-part-2.aspx
     
  12. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,400
    Location:
    U.S.A.
    What the bypass POC author failed to specifically note, and I also did likewise, is this. All these POC bypasses are done for Enterprise users "enlightenment." It is these environments that are using PowerShell scripts on a daily basis. As such, they are not deploying HIPS or anti-exec rules to monitor powershell.exe startup like I assume anyone who frequents Wilders is by now doing.

    As far as use of a C or C++ based .Net executable deploying customized Powershell code that was illustrated, it has to be run under the Powershell command shell to utiilize System.Management.Automation.dll processing. That .dll is only loaded and of use in the PowerShell command shell run environment.

    However as posted previously, there have been instances of hacked versions of powershell.exe being downloaded by malware. If that malware powershell.exe attempted to deploy anything that required use of System.Management.Automation.dll processing, the System.Management.Automation.dll would have to be statically linked into the .exe at compile time. As such, use of .dll would be impossible to detect by any security solution.
     
  13. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    Ah, thanks. I can only hope the fake powershell.exe would be snagged by the AE software
     
  14. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,400
    Location:
    U.S.A.
    It would be also advisable for folks to test their anti-exec, HIPS, etc. if it detects basic ways malware could execute PowerShell.

    Running PowerShell from a non-admin command prompt, the following command bypassed VoodooShield's detection of PowerShell startup:

    powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -noprofile -noexit
    Powershell_Bypass.png

    How malware gets creative is to use the above command as follows to run the downloaded payload script in memory:
    Running the command via WMI using a macro in a Word e-mail attachment as shown here: https://researchcenter.paloaltonetworks.com/2016/03/powersniff-malware-used-in-macro-based-attacks/
     
    Last edited: Aug 13, 2017
  15. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    And before opening that stuff even though it seems obvious, in this environment I now would make it a practice to call and confirm the email. I do this now with attachments even from people I know. I call them and verify they are sending something.
     
  16. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,400
    Location:
    U.S.A.
    Getting back to the MRG blog posting specifically in regards to why almost all AV products failed the memory based obfuscated PowerShell malware test, even those employing AMSI, is the following. What is most troubling to me is the mitigation techniques recommended are almost 2 years old. Perhaps because they involve probabilistic determination which would require the security solution to employ automated algorithm use; i.e. Next Gen/AI methods? Of most interest was the mitigations were developed by a Microsoft researcher. Further evidence that there is a lack of coordination in that organization between developing a concept and implementing it in their products, e.g. Windows Defender.
    https://cobbr.io/ObfuscatedEmpire.html
     
    Last edited: Aug 14, 2017
  17. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,400
    Location:
    U.S.A.
    I was looking over the macro code from the link I posted in reply #7 and #14. The detailed analysis of that attack is given here: https://researchcenter.paloaltonetworks.com/2016/03/powersniff-malware-used-in-macro-based-attacks/ . Couldn't think of a better code example for why macros are so damn dangerous; because of the low-level code execution capability they have. However, that same code could be imbedded in a C or C++ program. What the malware is doing is starting up an instance of svchost.exe for the WMI winmgmts service. It then spawns a child instance of Powershell for it running as hidden. As far as I am aware of this will bypass all or most anti-exec, SRP, etc. restrictions since svchost.exe is a trusted Window system process.

    It however will not bypass most HIPS checking of powershell.exe startup assuming the rule is properly coded to monitor "all" process startup of it. A classical HIPS is not "sensitive" to child process spawning regardless of how many child process levels exist. What I will say in this regard is you have to be very careful how you respond to HIPS alerts. Most HIPS's give two options in regards to process startup; "run once" and "run until process completion." Using a malware hidden execution of Powershell via command shell example and assuming you're monitoring cmd.exe startup via HIPS rule, the following will occur.

    You receive an alert about cmd.exe startup.

    If you respond "allow - run to process completion," powershell.exe will run w/o alert although what actually started it was the child conhost.exe process spawned from cmd.exe. This is so because you gave explicit allow permission to cmd.exe to run any resultant child processes.

    However, if you respond "allow - run once" to the cmd.exe startup alert, you will receive another alert on the powershell.exe startup attempt from conhost.exe since you only gave explicit permission to run cmd.exe and not any result child processes from it.​

    Of course, most folks will block the cmd.exe startup upon alert or in the case of the macro based malware, the alert on svchost.exe starting up powershell.exe via conhost.exe. But this is an example that you do have to be aware of how HIPS rule precedence works.
     
    Last edited: Aug 15, 2017
  18. Nightwalker

    Nightwalker Registered Member

    Joined:
    Nov 7, 2008
    Posts:
    1,309
    Does this kind of attack works if Office Macro is disabled or/and if Protected Mode is enabled?

    If it doesnt, it still needs social engineering and human error to work, like almost all malware.

    I see the potential of this attack against organizations (ATP), but for home users it is just one more malware to be dealt with.
     
    Last edited: Aug 15, 2017
  19. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,400
    Location:
    U.S.A.
    No. These attacks are e-mail based and by spear phishing techniques the attacker will try to trick the user into enabling macros. Obviously that can only be done disabling Word protected mode or opening the document outside of protected mode.

    There is a current e-mail attack underway where the malware creators registered a bunch of Banco Santander sub-domains and are using same as sender e-mail addresses. The e-mails all have realistic looking bank logos and headers and for all practical purposes look legit. Since a lot of home users get bank alerts and the like via e-mail, it is obvious how they can be lured into opening such an e-mail outside of protected mode and enabling macros via explicit e-mail instructions to do so.
     
  20. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    14,825
    Location:
    The Netherlands
    Why was it bypassed? Is the developer aware of this?
     
  21. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,400
    Location:
    U.S.A.
    Thought it was obvious. It can't detect the hidden startup of Powershell when spawned from conhost.exe via command shell execution.
     
  22. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,400
    Location:
    U.S.A.
    I guess it should also be noted that Powershell can be run from any of the Windows shells. Besides cmd.exe, the most commonly used ones are; explorer.exe, regsvc32.exe, rundll32.exe, InstallUtil.exe, mshta.exe, and any of the MS Office executables. And if it is run as hidden, it will invoke conhost.exe to do so from the aforementioned. Ditto for the other Win script engines.
     
    Last edited: Aug 16, 2017
  23. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,400
    Location:
    U.S.A.
    Dang! I could have saved myself a lot of posting work and cross linking by just referencing Mittal's "cookbook" on bypassing AMSI and Powershell execution detection. Everything you need to know is containing within this one posting: http://www.labofapenetrationtester.com/2016/09/amsi.html including how to run Powershell scripts without using powershell.exe!

    The thing that caught my eye was a novel AMSI bypass that even has Mittal confused:
     
  24. imuade

    imuade Registered Member

    Joined:
    Aug 4, 2016
    Posts:
    751
    Location:
    Italy
    What about Comodo Firewall? Can it be bypassed too?
     
  25. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,400
    Location:
    U.S.A.
    I assume you are referring to Defense+ which is its HIPS? I depends on what its default rules are for powershell.exe are. It is very easy to test.

    1. Open non-admin command prompt window.
    2. Copy the this: "powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -noprofile -noexit" less the quotes and paste into command prompt window. Then press the Enter key.

    If you don't get an alert from Defense+ about powershell.exe startup, then it is running w/o detection. Can be verified by using Process Explorer or Windows Task Manager.
     
  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.