Current state of malicious Powershell script blocking

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

  1. boredog

    boredog Registered Member

    Joined:
    Feb 1, 2015
    Posts:
    2,488
  2. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    4,988
    Location:
    U.S.A.
    I also believe this new Win 10 CE network protection will be "short lived." Just imagine that barrage of complaints directed to Microsoft from legit web site owners whose sites are being blocked due to "low reputation." AV vendors have and currently been struggling with the same issue in regards to blocking sites because of legit malware detection on the sites.

    What Microsoft should be doing instead is enhancing the Win firewall outbound GUI to alert and create rules as required.

    Just one more example of Microsoft's never ending security "babble" spewing with resultant delivery of the to be expected "Band-Aid" solution.
     
  3. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    4,988
    Location:
    U.S.A.
    As I see it in regard to Win 10 AMSI, the current pressing issue in regards to script based malware is obfuscation as illustrated in the MRG blog posting.

    It also is an issue that Microsoft appears to be unwilling to "take the bull by the horns" and do something about. This is evidenced by the Microsoft researcher who two years ago developed detection algorithms, representing the same research again at the 2017 Blackhat conference. Appears Microsoft's stance is that its up to the third party security vendors to apply that research to their products. To that I say - baloney! Microsoft is the one who stated that Win 10 AMSI was capable of deobfuscating malware scripts. Obviously it is not.

    Since Microsoft won't fix the obfuscation problem, here is what they should do. Develop an isolated container, i.e. sandbox, for AMSI. Start the script in the sandbox at which time the script would be fully deobfuscated. Proof of this unmasking capability currently exists in PowerShell v5 event logging capability which clearly shows the script after being fully deobfuscated. The AV vendors could examine the unobfuscated script in the sandbox.

    If the script is malicious, they could block and delete the script from the AMSI sandbox. They would also additionally remove the physical script by quarantining it if disk based.

    If the script is benign, the AV vendors would release the script from the AMSI sandbox and let it run normally.
     
    Last edited: Sep 5, 2017
  4. boredog

    boredog Registered Member

    Joined:
    Feb 1, 2015
    Posts:
    2,488
  5. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    4,988
    Location:
    U.S.A.
  6. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    7,149
    I agree. It's a long overdue.
     
  7. cruelsister

    cruelsister Registered Member

    Joined:
    Nov 6, 2007
    Posts:
    1,166
    Location:
    Paris
    The Network Protection Module is going to be disabled by default. However it can be easily (for some) Enabled/Disabled in Group Policy.

    Also note that many of the security improvements (?) will be ONLY available on 64bit systems running the Enterprise Edition.
     
  8. xxJackxx

    xxJackxx Registered Member

    Joined:
    Oct 23, 2008
    Posts:
    4,294
    Location:
    USA
    Thanks for the info. We're running Pro so it shouldn't be an issue.
     
  9. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    4,988
    Location:
    U.S.A.
    Along with the "token" use in PowerShell scripts noted in reply #16, there a number of like methods available for VBScripts given in this article: https://support.smartbear.com/testcomplete/docs/scripting/working-with/strings/vbscript.html .

    The problem again is that AV signatures are nothing more than contiguous string of binary values that are being compared to like data in a script. Use of tokens causes that comparison to fail. And the detection of "malicious" token use is extremely difficult to detect since they are oftentimes used in legitimate scripts.
     
  10. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    4,988
    Location:
    U.S.A.
    Actual, you can download Nishang from GitHub which incorporates 5 AMSI bypass methods into one script:
    https://github.com/samratashok/nishang/blob/master/Bypass/Invoke-AmsiBypass.ps1

    -EDIT- A great tool for obfuscating scripts is:
    http://www.labofapenetrationtester.com/2016/09/amsi.html
     
    Last edited: Sep 5, 2017
  11. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    4,988
    Location:
    U.S.A.
    A few more screenshots of Powershell malware delivery posted below. The one I was not fully aware of was Win Help i.e. hh.exe athough it was mentioned in the recent Symantec report. Of note is examples of WMIC use and Web Management Service for remote connection. BTW - WinRM service default startup in Win 10 is manualo_O. I set is to disabled and as noted previously, firewall block any traffic from/to it. Ditto for remote desktop service. As best as I can determine, Powershell outbound traffic using Web Management Service has to be initiated within Powershell itself.

    PS_1.jpg

    PS_2.jpg

    Ref.: https://www.slideshare.net/EC-Council/the-dark-side-of-powershell-by-george-dobrea
     
  12. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    4,988
    Location:
    U.S.A.
  13. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    9,498
    Location:
    The Netherlands
    Yes exactly, on my system WFC blocks outbound access automatically, even from system processes. About this attack (see link), you have already won the battle by blocking MS Office from running tools like regsvr32.exe and powershell.exe, and if this isn't possible, you can always block process hollowing which is used in a later stage. And like you mentioned, if outbound access is blocked, it can't download malware via hijacked system processes. So yes, it's sneaky, but far from unstoppable.

    https://security.radware.com/ddos-threats-attacks/threat-advisories-attack-reports/codefork-malware/
     
  14. cruelsister

    cruelsister Registered Member

    Joined:
    Nov 6, 2007
    Posts:
    1,166
    Location:
    Paris
    On thing that would be smart for folks (who just use WF and tradition AV) to do occasionally would be to see what on their computer is connecting out and to where. As in the case of this type of malware, all one would have on their systems would be a legit, although forked, process (like regsve32 or svchost) and some obfuscated reg entries (I still like them dropped into HK), so the infective cascade would be pretty much invisible.

    Using something like the Network monitor of Killswitch (or similar product) would show the forked process lighting things up like a Christmas Tree- a fairly good indication that something sub-optimal is going on.
     
  15. boredog

    boredog Registered Member

    Joined:
    Feb 1, 2015
    Posts:
    2,488
    Last I checked Killswitch was not listed for Windows 10 just up to 8.
     
  16. larryb52

    larryb52 Registered Member

    Joined:
    Feb 16, 2006
    Posts:
    1,129
    why is this pointless back and forth going on to no eventual ending please close this thread, for corp and pros not the standard home user...thanks and sorry guys
     
  17. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    4,988
    Location:
    U.S.A.
    From the Radware article note what I have underlined:
    It is unknown what was the actual delivery mechanism for this attack. Radman used Casey Smith's "squibeedoo" exploit via a Word macro as an example of one possible way the use of Powershell could have been deployed in the delivery phase of the attack. In reality, it is one in a number of ways a wscript could have been remotely executed; if indeed remote script execution was used at all.

    From forensic examination of the Powershell log events, all Radman knows for sure was Powershell was used maliciously in the attack.

    Also there was no process hollowing performed for the Powershell malware injection. What occurred was the malicious encrypted .dll was written to the below noted registry key. It was then reflectively loaded into PowerShell using the following command via the Invoke-ReflectivePEInjection module from PowerSploit framework:
    -EDIT- Now as far as the bitcoinminer downloader malware that is loaded from the code injected into Powershell, that indeed does process hollowing as noted below. Appears the code injected into Powershell contains the Gamarue malware plus the code to inject it into werfault.exe and perform process hollowing against msiexec.exe. Assumed is once the injection is completed into werfault.exe, powershell.exe is terminated. So by the time the desktop appears at boot time, the only process running is msiexec.exe:
    The Gamarue malware running from msiexec.exe:
    The "beauty" of this attack is that all malware code and activities are hidden within Powershell and legit Windows system processes. The only trace that this malware exists on a device is the encrypted .dll registry key and a Run registry key containing the above Powershell command.

    Despite the "elegance" of this attack, I can only give it a grade of "B" due to the use of the registry Run key for persistence. I would have opted for a WMI wscript based consumer event to run the Powershell command. This would bypass any wscript and Powershell startup monitoring.

    -EDIT- Here's the "Execute PowerSploit's Invoke-ReflectivePEInjection module on a host" reference: https://github.com/Veil-Framework/V...codeexecution/invoke-reflectivepeinjection.py
     
    Last edited: Sep 10, 2017
  18. cruelsister

    cruelsister Registered Member

    Joined:
    Nov 6, 2007
    Posts:
    1,166
    Location:
    Paris
    Boredog- Killswitch works just fine on W10.
     
  19. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    19,003
    Do feel free to not read this thread.
     
  20. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    4,988
    Location:
    U.S.A.
  21. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    4,988
    Location:
    U.S.A.
    There is another malware abusing Powershell that is "eerily" similar to CodeFork; namely the ReflectivePEInjection of Powershell and the storage of the encrypted malware plus the Powershell startup in registry keys for persistence. It is called JS_POWMET. Trend Micro has a detailed analysis of it here: http://blog.trendmicro.com/trendlab...e/look-js_powmet-completely-fileless-malware/ . Appears CodeFork "borrowed" the JS_POWMET Powershell abuses in its attack.

    Like CodeFork, the actual delivery mechanism remains unknown. However, a bit more is known about JS_POWMET:
    Since there are marked similarities between both malware, it can be reasonably assume CodeFork arrives in a like fashion. Note we are talking about a web based delivery mechanism.

    JS_POWMET and very possibly CodeFork is a two-stage registry based attack. Stage one entails storing Casey Smith's "squibbedoo" exploit in a Run registry key. Stage two involves running the exploit via dllhost.exe at next boot, downloading the JS_POWMET malware, and setting up persistence so it runs at every subsequent reboot.

    -EDIT- Someone at GitHub did a detailed analysis of JS_POWMET code here: https://github.com/Fare9/JS_POWMET . Of note is:
     
    Last edited: Sep 10, 2017
  22. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    4,988
    Location:
    U.S.A.
    Time to talk about how Powershell can be deployed maliciously without using powershell.exe.

    First up is:
    https://www.blackhillsinfosec.com/p...ion-whitelisting-environment-restrictions-av/

    This one caused quite a stir on Wilders last year with everyone scurrying to block use of System.Management.Automation. Never understood that one since its use was embedded in a C program. WL and anti-exec bypassing didn't come from the running of the program by itself but rather from the way the C program was deployed; namely using a valid system executable to do so:

    In reality, there are much better ways to use Powershell w/o executing powershell.exe.

    One well know example is:
    https://www.fireeye.com/content/dam/fireeye-www/global/en/solutions/pdfs/wp-lazanciyan-investigating-powershell-attacks.pdf

    The problem with the above is it requires that Windows Remote Management i.e. WinRM service to be active. Most people in non-corp. environments have that pretty well locked down. So here are a few ways to get around that plus the situation where PowerShell is not installed at all on the targeted device.

    Invoke a remote command without WinRM, psexec or similar – Access administrative shares even if they have been removed
    http://maikkoster.com/invoke-a-remo...rative-shares-even-if-they-have-been-removed/

    Tunnel a PowerShell script to a remote machine and invoke via WMI
    http://maikkoster.com/tunnel-a-powershell-script-to-a-remote-machine-and-invoke-via-wmi/
     
  23. true indian

    true indian Registered Member

    Joined:
    Sep 24, 2012
    Posts:
    872
    Location:
    india
    From my end,I think power shell is more exploited by emotet and hancitor.They usually are used to run scripts in power shell to download trickbot or lokibot and sometimes even ransomware like locky.

    Also I think this abuse of power shell has been going on for a while.The problem is that power shell is running just about every script.There is no set method where power shell alerts the user that a unsigned/unknown app is trying to run a script.
     
  24. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    9,498
    Location:
    The Netherlands
    Once again, you're making things too complex. I already described how the attack could have been stopped easily. No matter if stuff is downloaded "reflectivity" into memory. If you block system processes from connecting out, it's game over.

    https://security.radware.com/ddos-threats-attacks/threat-advisories-attack-reports/codefork-malware/

    All of these attacks still need to run a system process which can be blocked or monitored. Same goes for white-listing bypass methods.

    https://github.com/subTee/ApplicationWhitelistBypassTechniques/blob/master/TheList.txt
     
  25. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    9,498
    Location:
    The Netherlands