The rise of .NET and Powershell malware

Discussion in 'malware problems & news' started by Dermot7, Oct 12, 2015.

  1. Peter2150

    Peter2150 Global Moderator

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

    Thanks. Yeah, I got a bunch of those emails, and some of them are so dumb, you have to wonder why they work. Got one this morning and all it said was Please help me and open these documents. Duh.

    Pete
     
  2. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Regarding the Word macro based malware, there was a Wilders member a while back complaining about paranoid mode being removed from the behavior blocker of Emsisoft when ver. 10 was released. He stated that it wasn't protecting against this particular malware sample like previous versions did with paranoid mode set on. With a bit of prodding, he admitted the malware sample was a Word doc. attachment with a malicious macro embed in it. A bit more prodding and he admitted that indeed Word did issue the default setting warning about macro execution. He allowed the macro to execute. He contented overriding the macro warning was immaterial; EAM behavior blocker should have detected the macro based malware which BTW was a malicious Powershell script.

    I have also seen the same twisted logic applied to people who run with UAC turned off or full administrator privileges since they find the prompt an irritant.

    So in many cases, instructing people on safe e-mail practices is akin to talking to a brick wall.
     
  3. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    OK, I didn't know that, so blocking or sandboxing Powershell doesn't guarantee that malware might still do any damage? But I assume HIPS will still block suspicious behavior, or isn't this possible since .NET apps are trusted?
     
  4. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I never said blocking powershell.exe was a good idea. I said monitoring it, i.e. ask rule in a HIPS, is. Also, I have been monitoring it for some time and have yet to receive a HIPS alert. So its use is infrequent at best by any valid OS function.

    The .Net issue centers around C# programs being able to access PowerShell assemblies directly. Specifically, the .dlls associated with those assemblies which I have already noted only applies to .Net 4+ applications. Remember there are earlier versions of .Net which most people leave installed on their PCs which applications have been developed for.

    The Wilders Bouncer aka block .dll monitoring crowd are doing "cartwheels" over the issue. I guess they ignored my posting about the difference between static linking versus dynamic loading. Those PowerShell assemblies could be statically linked into a C# binary which would also result in any associated .dlls also being included as machine code within the binary. As such, there is no way to 100% prevent the Powershell assembly execution short of blocking the program containing C# binary from executing.

    Also of note is a quote from the www. sixdub link previously posted:

    Blacklisting should be considered nothing more than a stop gap and will be overcome by a dedicated attacker.
     
    Last edited: Nov 30, 2015
  5. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Here's a collection of Powershell hacking "goodies": http://www.kitploit.com/2015/11/powertools-collection-of-powershell.html. Scroll down to the PowerPick section for a read.
     
  6. guest

    guest Guest

    Set Comodo (or your HIPS) on paranoid mode (if it have one) and you will be alerted about every Powershell's activity , after then you can whitelist those you deems safe.
     
  7. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    Yes, but you would think that if you blocked or sandboxed it, you would already be safe, I guess I will need to do some reading. And the other stuff that you talked about is a bit too technical for me.
     
  8. root_access

    root_access Registered Member

    Joined:
    Nov 26, 2015
    Posts:
    13
    You should also consider that the general attacker(script kiddie ish) would use tools available or not very complicated thus he'd be leveraging powershell.exe as is. I would guess that one should be a high level target in order to get an actual "Black hat" targeting them, where if powershell would be the attack vector, you could bet that the infection would come through a zero-day (likely Flash or similar) with a reflective dll as a payload. Your best bet will be your own awareness of where/what you click in order not to get infected. I think currently popular sites expose big risks and I hope they try to make everything they possible can to protect themselves because if they get hacked for one reason or another, we as users(Most of us) are vulnerable.

    Just curious by the way, no EDIT option?
     
  9. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    You don't have to be a crack programmer these days to develop sophisticated malware. Web both dark and light is full of sites with prepackaged malware available for download.
     
  10. marzametal

    marzametal Registered Member

    Joined:
    Mar 19, 2014
    Posts:
    766
    While running in a LUA on W7...

    I put "C:\Windows\Microsoft.NET" into SecureFolders as "No Execution", then whitelisted relevant apps when they kicked up a fuss (ADP Monitor, AdGuard (was a bit ticked off about this... I had forgotten that AG relies on .NET - tempted to drop it and just rely on uBlock and uMatrix), HexChat, WFC, etc...). For the PowerShell stuff, I included the relevant files in NVT-ERP Vulnerable/Blacklist since I run in Lockdown Mode (whitelist command lines only).

    Will have a look into this when I get closer to my next backup...

    Thanks for the ripper info!

    EDIT: The site in your quote mentions a way to discover the DLL for Powershell Assembly ([PSObject].Assembly.Location). Any idea how to do this for .NET? Gotta' love SecureFolders; powershell didn't load up until I added it to Trusted Apps screen because I have Microsoft.NET listed as No Execution. Typing "help" in PS triggered an ERP notification, asking permission for a file called "more.com" to run... Ummmm, no thanks!
     
    Last edited: Dec 3, 2015
  11. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    If your asking where the referenced .dll is stored, it is stored here on my WIN 7 x64 build:

    C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Management.Instrumentation\v4.0_4.0.0.0__b77a5c561934e089\System.Management.Automation.dll

    Again this only applies to C# programs using the .Net 4+ framework. Again, I don't not recommend blocking this .dll.

    -EDIT- Note that this .dll is Microsoft signed and resident in a Windows directory. Would imagine that as such, any dll blocking software rules allowing signed .dlls in a Trusted folder would override any block attempts of it.
     
    Last edited: Dec 3, 2015
  12. root_access

    root_access Registered Member

    Joined:
    Nov 26, 2015
    Posts:
    13
    I am not sure if its possible but if you could allow access to the DLL only to PowerShell.exe and you monitor that executable with HIPS/some rules, it could be a way around the C# issues. Like in an invoronment where your employees are not IT developers specifically C# and PowerShell is used only by IT Support, should be a go. I would actually like to test and see if that would work.
     
  13. marzametal

    marzametal Registered Member

    Joined:
    Mar 19, 2014
    Posts:
    766
    I think you meant "..........\v4.0_4.0.0.0__b77a5c561934e089\System.Management.Instrumentation.dll" ?
     
  14. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    The .dll I quoted is used by System Management assembly which is the .dll quoted in the sixdub link. The .dll you quoted is used by System Management Instrumentation assembly.
    .
     
  15. marzametal

    marzametal Registered Member

    Joined:
    Mar 19, 2014
    Posts:
    766
    Gotcha... was confused for a while there... damn directories! Thankyou Sir!
     
  16. WildByDesign

    WildByDesign Registered Member

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

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    From the Conclusions section:

    Application Whitelisting can protect against trivial attacks

    APT attackers can easily bypass the protections with the described techniques

    In some cases the application(whitelisting) even lowers the security of the operating system

    •Allocation of a RWE section in all processes

    •Kernel vulnerabilities which allow privilege escalation
     
  18. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    From The Attack Vectors Section:

    •Common attack vectors
    • Any kind of social engineering
    • Java Applets / Drive-by-Downloads
    • Microsoft Office Macros
    • Memory Corruption Exploits (Browser, PDF Reader, Microsoft Office, ...)
    • Web application vulnerabilities (command injection, SQL injection, file uploads, ...)

    From the Basic Code Execution Section:

    •Simple ideas:
    • User in front of a system (Kiosk systems, Social Engineering, ...)
    • Malicious USB stick (rubber ducky)
    •What if we don't have such a possibility?
    • Send victim a file
    • Victim opens/starts the file
    • Victim is infected
    ----
    rich
     
  19. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    Thanks Rich. Still shows, that before they can get it to do all the highly technical stuff they have to get it on your system, and that is where it's easiest to block
     
  20. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
  21. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Article notes that if Powershell is whitelisted or not installed, you can exploit a JAVA app that will give you equivalent capability. Do you really have JAVA installed?
     
  22. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    I'm not following you, who is talking about Java? I noticed that in the article he says it's wise to block PowerShell from running, but I thought that you explained that it's not enough to protect from malware that's using .NET and PowerShell.
     
  23. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    The McAfee article didn't cover anything on .Net use of Powershell assemblies.
     
  24. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    OK I see.
     
  25. Dermot7

    Dermot7 Registered Member

    Joined:
    Dec 20, 2009
    Posts:
    3,430
    Location:
    Surrey, England.
    Uncovering Active PowerShell Data Stealing Campaigns « Threat Research | FireEye Inc
     
  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.