The rise of .NET and Powershell malware

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

  1. Dermot7

    Dermot7 Registered Member

    Joined:
    Dec 20, 2009
    Posts:
    3,430
    Location:
    Surrey, England.
    https://securelist.com/blog/research/72417/the-rise-of-net-and-powershell-malware/
     
  2. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    A partial solution:

    Put PowerShell on the blacklist.
     
  3. Infected

    Infected Registered Member

    Joined:
    Feb 9, 2015
    Posts:
    1,134
    I have PS Sandboxed with drop rights.
     
  4. J_L

    J_L Registered Member

    Joined:
    Nov 6, 2009
    Posts:
    8,738
    Might as well whitelist all executables... PowerShell is yet another tool after all. Don't see the point unless you never use it and can somehow be infected only with that.
     
  5. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    From the article:
    Does anyone know of a delivery method other than an email/email attachment?

    I found these:

    .NET Keylogger: Watching Attackers Watch You
    http://phishme.com/net-keylogger-watching-attackers-watch/
    http://www.exploit-monday.com/2014/04/powerworm-analysis.html
    http://www.securitysift.com/phishing-with-macros-and-powershell/
    May 22, 2015
    http://blog.trendmicro.com/trendlab...s-malicious-macros-abuses-windows-powershell/
    http://blog.trendmicro.com/trendlab...-windows-powershell-used-again-in-new-attack/
    https://blog.gdatasoftware.com/blog/article/poweliks-the-persistent-malware-without-a-file.html
    http://darkmatters.norsecorp.com/20...g-powershell-and-leveraging-malicious-macros/
    ----
    rich
     
    Last edited: Oct 14, 2015
  6. root_access

    root_access Registered Member

    Joined:
    Nov 26, 2015
    Posts:
    13
    PS is a good vector cos it has low detection rate. BTW sanboxing powershell.exe doesn't solve your problems, essentially powershell.exe is just a wrapper for powershell which is a dll that can be started without powershell.exe (C# for example)
     
  7. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    17,546
    Location:
    The Netherlands
    Can you explain a bit more? Are you saying thay if it runs sandboxed, it can still do damage even outside the sandbox?
     
  8. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    What he is saying is you can start the dll without the exe by using something else to start it. But if what ever is used is sandboxed then it's contained. But reading that Darkmatters article, this is oh so easy to defend against. All it take is using your brains. Since it is emails targeting business mainly, anyone handling travel should know that confirmations don't come as zip files attached to emails. Also they should be taught to never turn on macros. Also any business person should be aware that Fedex never does any notifications that way.

    I have taken the following steps with Outlook.

    First its guarded with Appguard and HMPA. But also to be more proactive. I have some clients who are politically oriented and will do fund raisers. I have asked them not to use the business email for these, as I have instructed the 2 people who work on my computer that if they see emails from clients, that clearly are something other then business, to just delete without opening. This has solved a lot of issues.
     
  9. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    What he is saying is sandboxing powershell.exe will not fully prevent it's sub-processes from executing outside the sandbox. I have already posted an example in an other thread. Will repeat again:

    Powershell can be run from a C# or .Net program.

    -EDIT-

    You can host a powershell runtime inside a .net application using the System.Management.Automation dll. This BTW is the actual "guts" of Powershell. Powershell.exe is just an interface to System.Management.Automation dll

    If you try to block that .dll, you will most likely totally bork your OS.
     
    Last edited: Nov 28, 2015
  10. Online_Sword

    Online_Sword Registered Member

    Joined:
    Aug 21, 2015
    Posts:
    146
    Hi, @itman .:)

    Just now, I made a rule in McAfee Virusscan Enterprise to log any reading operation from any processes to System.Management.Automation dll (only log, not prevent).

    Then, I reboot the virtual machine and run several C# programs in it. I found that, VSE generates no log that any process tries to access System.Management.Automation dll.
     
  11. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590

    What happens if powershell.exe can't run?
     
  12. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Did you modify the C# program/s to actual load and use System.Management.Automation dll?
     
  13. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Hum .......... Thought I explained that. Powershell.exe is never executed; only it's primary component - System.Management.Automation dll
     
  14. Online_Sword

    Online_Sword Registered Member

    Joined:
    Aug 21, 2015
    Posts:
    146
    No, I have not. Because I just want to see whether this dll is really essential for the basic functions of the OS.

    If it is not, then I think, maybe, we can simply block it, or just prevent processes in user space from accessing this dll, without breaking down the OS, right?:)
     
  15. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    You explained you host it inside a .net management program. But is that something already on the system, or is it something modified by malware? In another how exactly does it get on the system to execute
     
  16. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Your call on that one. I have seen refs. that stated the OS uses System.Management.Automation.dll at boot and shutdown time.
     
  17. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Here's the code to run it from a C# program: http://pastebin.com/m69RLAwU/ . You're creating an instance of Powershell from within the C# program.
     
    Last edited: Nov 28, 2015
  18. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    Okay I looked at the code and see how powershell is created, but that doesn't answer one question. Some how that code has to get on my system and get executed. How does that happen?
     
  19. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    The C# malware program would be delivered any way malware can get on a system.

    The real point is to block the C# malware from executing in the first place. Sandboxing should stop it assuming all delivery sources are protected. Monitoring process startups from the locations where malware downloads to; %AppData%, %Temp, program directories, etc. will do it. A behavior blocker such as the one in EAM/EIS should be able to detect any malicious activities the C# program is doing. Finally, HIPS rules to protect your critical processes would also detect any malicious activities.
     
  20. Peter2150

    Peter2150 Global Moderator

    Joined:
    Sep 20, 2003
    Posts:
    20,590
    Okay thanks. That's what I suspected. I am covered
     
  21. Mr.X

    Mr.X Registered Member

    Joined:
    Aug 10, 2013
    Posts:
    4,796
    Location:
    .
    Yes, for starters Sandboxie and AppGuard then anti-exes. lol
     
  22. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Here is a link for coding to execute PowerShell scripts from a C# program that does not involve use of the System.Management.Automation.dll: http://blogs.msdn.com/b/kebab/archive/2014/04/28/executing-powershell-scripts-from-c.aspx

    A few notable excepts:

    Note: You do not have to distribute the System.Management.Automation assembly file with your application binaries - it is located in the GAC on machines with Windows PowerShell installed and should resolve automatically.

    However, you could statically link the System.Management.Automation assembly file to your application binary ensuring that it would run on a PC w/o PowerShell installed.

    More on what the GAC is here: https://msdn.microsoft.com/en-us/library/yf1d93sz(v=vs.110).aspx

    However, there is the issue of the default Powershell no script execution policy which still applies. The solution is:

    Execution Policy:

    When you invoke cmdlets through the PowerShell class in C#, the execution policy behavior is subject to the policy restrictions of the machine. This behavior is the same is if you opened up a PowerShell prompt on the machine. You can issue commands just fine, but invoking another script might get blocked if your execution policy is undefined or restricted in some way. An easy way to get around this is to set the execution policy for the scope of the application process. Simply run Set-ExecutionPolicy and specify the scope to be Process. This should allow you to invoke secondary scripts without altering the machine/user policies.

     
  23. root_access

    root_access Registered Member

    Joined:
    Nov 26, 2015
    Posts:
    13
    Indeed blocking it before it executes is the best to go for ...

    Regarding C# from this https://www.sixdub.net/?p=367:

    To blacklist a .NET assembly, specifically the PowerShell ones, you must block ALL of the related DLLs behind the assemblies. This includes the DLLs in GAC_MSIL and NativeImages if they both are present
     
  24. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    You beat me to the punch! I was just going to post the same. Everyone should read the article to see just how difficult it is to stop Powershell.

    Also, I believe this applies to .Net 4. Earlier .Net version assemblies are in stored in %Windows%\Assembly and there are no .dlls associated with those.

    -EDIT- Also this would not stop statically linked assemblies in the C# binary.
     
    Last edited: Nov 30, 2015
  25. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    Hi Pete!

    I haven't followed this in a while, but unless infection methods have changed, the entry point depends on the user accepting incoming malware attack emails to be legitimate, and following the instructions in those messages (opening an attachment, enabling MSOffice macros, etc.)

    A few examples:

    http://blog.trendmicro.com/trendlab...s-malicious-macros-abuses-windows-powershell/
    http://blog.trendmicro.com/trendlab...fects-systems-with-password-protected-macros/
    http://hackerhurricane.blogspot.com/2015/03/detecting-powershell-hacking-it-popular.html
    https://www.mysonicwall.com/sonicalert/searchresults.aspx?ev=article&id=816
    ----
    rich
     
  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.