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,428
    Location:
    U.S.A.
    The above posting leads into something I have been "pondering." How about Microsoft via Windows Defender Exploit Guard create mitigation policies in regards to PowerShell use? Namely the ability to set ExecutionPolicy level and disable the use of Invoke-Expression?
     
  2. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    2,497
    Location:
    Italy
    In the Advanced section of OSA there is a rule to mitigate IEX:

    Immagine.jpg
     
  3. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,428
    Location:
    U.S.A.
    Interesting.

    Assumed it is scanning the command line for Invoke-Expression, IEX, etc.. This also implies other like security software e.g. AppGuard might have like capability. Also possibly some HIPS, but they would need the capability to scan the entire command line and recognize parameters. Many don't have such capability. Also ask the developer if he can detect like activity if done via a WMI command event? Doubtful I would think. Finally if OSA is using PostCommandLookupAction as noted in the above linked TechNet article, it can be bypassed.

    Ask the developer to add like capability to set ExecutionPolicy to "Constrained Language" mode. Should be doable since OSA is policy based software. This alone will prevent most .Net features from functioning via Powershell.

    Finally, blocking IEX usage via command line is great, but malware can execute the same PowerShell .Net based assemblies and functions via a .exe.
     
    Last edited: Feb 4, 2018
  4. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,428
    Location:
    U.S.A.
  5. mood

    mood Updates Team

    Joined:
    Oct 27, 2012
    Posts:
    42,809
    Yes, it is doing it (it monitors processes, parent processes & command-lines). Regarding PowerShell it also blocks "ExecutionPolicy Bypass"
    Collection of available PowerShell/WMI-options:
    [X] Prevent PowerShell from using Invoke-Expression via cmdline
    [X] Block execution of Windows PowerShell
    [X] Block execution of .ps1 (PowerShell) scripts
    [X] Block "ExecutionPolicy Bypass" on command-line (PowerShell)
    [X] Block "WindowStyle Hidden" on command-line (PowerShell)
    [X] Block ShellExecute\Start-Process in PowerShell cmdline

    [X] Block execution of PowerShell malformed commands
    [X] Block execution of PowerShell encoded commands
    [X] Prevent regsvr32.exe from using /i:Powershell

    WMI:
    [X] Prevent WMIC from using "process call create" via cmdline
    [X] Block any process executed from wmic.exe
    [X] Block any process executed from wmicprvse.exe
     
  6. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    2,497
    Location:
    Italy
    Probably the monitoring function sought could be included in the rules below:

    Immagine.jpg

    But you should ask the developer directly.:thumb:
     
  7. shmu26

    shmu26 Registered Member

    Joined:
    Jul 9, 2015
    Posts:
    1,538
    @Sampei Nihira why don't you post this idea in the OSA thread?
    I kind of doubt it can be done, because I don't think that OSA modifies Windows policies, but maybe I will be pleasantly surprised.
     
  8. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    2,497
    Location:
    Italy
    :)

    In my opinion, the Developer already has a lot of work to do.***
    For me it should be itman himself if he is interested in asking this question.
    At least this is the mentality of us Italians.
    Thanks for the consideration.
    :thumb:;)

    P.S. *** And also apparently of our French cousins (see comment Cruelsister).
     
    Last edited: Feb 5, 2018
  9. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,428
    Location:
    U.S.A.
    Dnx.exe can be used to bypass Device Guard as noted below:
    Note that Device Guard gives many of the same mitigations in regards to Powershell as AppLocker:
    https://enigma0x3.net/2016/11/17/bypassing-application-whitelisting-by-using-dnx-exe/

    As far as using WMI to create a malicious Powershell consumer event via WMIC as noted here: https://www.fireeye.com/blog/threat-research/2016/08/wmi_vs_wmi_monitor.html , OSA has a mitigation for WMIC use. However, the same activity can be accomplished using for example MetaSploit as noted here: https://www.rapid7.com/db/modules/exploit/windows/local/wmi_persistence .
     
  10. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,428
    Location:
    U.S.A.
    BTW - Most of the recent WMI persistence attacks against Win OS servers I have recently observed employing PowerShell were RDP brute force attacks. Even when the installations were informed of this, they still refused to lockdown RDP for operational reasons.:rolleyes:

    Note that the Powershell based attack shown in reply #174 was not WMI based. All that was required in that instance was the attacker finding an open inbound port.
     
  11. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,428
    Location:
    U.S.A.
    Blocking Malicious PowerShell Downloads
    https://www.crowdstrike.com/blog/blocking-malicious-powershell-downloads/

    Nothing "earth shattering" in this Cloudstrike posting released today. It does show, as I recently posted, the increased use of .Net's new-object system.net.webclient by Powershell to download malware.

    -EDIT- Oops - got the dates wrong; this was issued a year ago. Forgive me since my eyesight in my old age is not what it was when I was younger.
     
    Last edited: Feb 6, 2018
  12. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,428
    Location:
    U.S.A.
    Now this one is a new one ..............
    https://community.spiceworks.com/to...gn-hides-malicious-powershell-script-in-image
     
  13. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,428
    Location:
    U.S.A.
    This just might be the ultimate PowerShell and MS Word combo attack.

    Securityweek.com just posted this Middle East targeted attack:

    Actor Targeting Middle East Shows Excellent OPSEC
    https://www.securityweek.com/actor-targeting-middle-east-shows-excellent-opsec

    Of interest is the following:
    Take note of what I underlined above.

    Next up is a POC that can bypass Win 10 Controlled Folders protection that was posted and commented up in the 'Windows Defender is Becoming blah-blah" thread: http://www.securitybydefault.com/2018/01/microsoft-anti-ransomware-bypass-not.html?m=1 . Of note is the following code:
    Note that when running Word in the above fashion, all protective measures that would be provided by opening a .doc/x file using winword.exe are bypassed; including prohibiting the execution of macros.

    Combining the two attack methods yields:

    1. Execute a VBScript designed to create a second stage PowerShell script that would create a Microsoft Office document. The document, e.g. malicious.docx, created would contain nothing but the malicious macro.

    2. Run the following python script compiled into a Win .exe -or- download Python to the target and use that to execute the script:

    import win32com.client
    filetoberun = r'C:/................/malicious.docx'
    word = win32com.client.Dispatch("Word.Application")
    word.visible = 0
    doc = word.Documents.Open(filetoberun)
    word.Documents.Item(1).Close()
    word.Documents.Item(1).Delete()
    word.Application.Quit()

    Bingo! You're nailed.

    Ref.: https://techblog.dorogin.com/generate-word-documents-with-powershell-cda654b9cb0e
     
    Last edited: Feb 9, 2018
  14. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,428
    Location:
    U.S.A.
    Another "goodie" from Blackhat Asia 2017:

    HACK MICROSOFT USING MICROSOFT SIGNED BINARIES
    https://www.blackhat.com/docs/asia-17/materials/asia-17-Braeken-Hack-Microsoft-Using-Microsoft-Signed-Binaries-wp.pdf

    Also use of PowerMemory is not new as noted here: http://securityaffairs.co/wordpress/39721/hacking/powermemory-extract-credentials.html .
     
    Last edited: Feb 23, 2018
  15. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,428
    Location:
    U.S.A.
    I have previously mentioned the use of Empire as a way of getting nailed by a Powershell attack but did didn't get into a lot of details. So lets do that.

    You are blocking/monitoring execution of the default version of PowerShell installed on your PC. You have uninstalled PowerShell 2.0 or are using Win 10 1709 on which it is uninstalled by default. You have set PowerShell to "Constrained Language" mode in the event it is employed via .Net methods. You think you are safe from a PowerShell attack. You are not:
    https://blog.stealthbits.com/how-attackers-are-bypassing-powershell-protections/

    -EDIT- Here's a more recent article that describes how Empire does the privilege escalation that was not detailed in the previous article. Also how WD was totally useless against this attack: https://www.alpinesecurity.com/blog/2018/1/11/empire-a-powershell-post-exploitation-tool
     
    Last edited: Feb 27, 2018
  16. guest

    guest Guest

    Research CobaltStrike, experts on metasploits using powershell and various reflective injections.
     
  17. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,648
    Location:
    Slovenia, EU
    That privilege elevation mentioned in script and described here really looks interesting. I don't know why a normal user can set environment variables in HKCU. It would probably be better to store them only in HKLM.
    I also wonder if MS fixed it already or did they just say "UAC is not a security boundary". Under SUA elevation - and consequently exploit - wouldn't work.
     
  18. shmu26

    shmu26 Registered Member

    Joined:
    Jul 9, 2015
    Posts:
    1,538
    Does that privilege escalation work on Windows 10?
    Either way, disabling system.management.automation.dll would prevent this exploit, correct?
     
  19. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    2,497
    Location:
    Italy

    OSA block the attack:

    Immagine.jpg

    Configuring Additional LSA Protection:

    https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn408187(v=ws.11)
     
    Last edited: Feb 28, 2018
  20. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,648
    Location:
    Slovenia, EU
    From blog:
    Interesting, that built-in software restriction policies also show problems if default rules with variables are used. Maybe MS should reconsider their usage and just use absolute paths instead.

    IDK about exploit itself and if disabling that DLL would mitigate it.
     
  21. shmu26

    shmu26 Registered Member

    Joined:
    Jul 9, 2015
    Posts:
    1,538
    So it sounds like the current version of win10 is not vulnerable to it.

    As far as I understand, if powershell.exe is blocked, and also system.management.automation.dll is blocked, it is pretty hard to get any powershell functionality.
     
    Last edited: Feb 28, 2018
  22. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,648
    Location:
    Slovenia, EU
    Yes, but there could be a problem if another instance of powershell is downloaded and run from some other location. And with elevated rights that could be possible.
    You might be using a security approach where user can run things from where he can't write and can write things from where he can't run anything. If privileges are elevated, that approach falls apart.
     
  23. shmu26

    shmu26 Registered Member

    Joined:
    Jul 9, 2015
    Posts:
    1,538
    Right. If malware already has elevated privileges, it's too late.
     
  24. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    One of the beauties of adding MZwritescanner to the fold. It doesn't matter where exe's or dll's are downloaded. You are alerted and initially it is blocked.
     
  25. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,428
    Location:
    U.S.A.
    Hum ............... Looks like everyone missed Empire's capabilities.

    Please re-read reply #190. Empire's use of PowerShell is totally independent of Window's based PowerShell or any of its components such as system.management.automation.dll. Empire employs equivalent PowerShell capability in the Agent modules it deploys. Therefore blocking anything to do with Windows based PowerShell, any of its system components, or restricting execution of same thru language mode restrictions have absolutely no impact on Empire's use of Powershell functionality.

    Another way to understand Empire is it is the equivalent of Windows PowerShell but being run from the attacker's server.
     
    Last edited: Feb 28, 2018
  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.