New PowerShell Backdoor Resembles "MuddyWater" Malware

Discussion in 'malware problems & news' started by mood, Nov 30, 2018.

  1. mood

    mood Updates Team

    Joined:
    Oct 27, 2012
    Posts:
    13,059
    New PowerShell Backdoor Resembles "MuddyWater" Malware
    November 30, 2018
    https://www.securityweek.com/new-powershell-backdoor-resembles-muddywater-malware
     
  2. mood

    mood Updates Team

    Joined:
    Oct 27, 2012
    Posts:
    13,059
    Experts at Yoroi – Cybaze Z-Lab analyzed MuddyWater Infection Chain
    December 7, 2018
    https://securityaffairs.co/wordpress/78748/apt/muddywater-infection-chain.html
     
  3. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    7,429
    Location:
    U.S.A.
    You would think by now any corp. admin in his right mind would have disabled Word permanently macros.
     
  4. Umbra

    Umbra Registered Member

    Joined:
    Feb 10, 2011
    Posts:
    5,572
    Location:
    Europe then Asia
    Being admin or developer, doesn't forcibly mean being a security specialist.

    I know many Corp admins who have no more skills than an average joe in term of security...letting employees with admin accounts, disabling updates, using cracked Windows and softs, etc...
     
  5. EASTER

    EASTER Registered Member

    Joined:
    Jul 28, 2007
    Posts:
    8,207
    Location:
    U.S.A. (South)
    ....and Powershell can easily be unplugged until an admin needs it.
     
  6. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    7,429
    Location:
    U.S.A.
    Based on this and the code associated with it:
    It appears Powershell is being loaded directly into memory to run the script. As such, conventional methods to detect its startup as a separate process would fail. Technique in many ways is similar to current Python malware reeking havoc where the Python engine and script are bundled into an executable. Note the LSASS program is a .Net executable or C, C++ based which can directly execute .Net subassemblies.

    Or and most likely, Powershell is being run remotely from the attackers device. Note that all that is required for a remote PowerShell attack is:

    1. A backdoor to establish the remote connection.
    2. A locally based PowerShell script.

    All these have been met in this attack.
     
    Last edited: Dec 9, 2018
  7. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    11,523
    Location:
    The Netherlands
    The thing what these malware analysts don't mention and explain is that even "in-memory" malware still needs to run inside an executable. So I'm guessing that all malicious activities are done from within excel.exe, so if you restrict these MS Office processes, you can block this stuff.
     
  8. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    7,429
    Location:
    U.S.A.
    My best guess this is a remote attack which is characteristic of APTs:
     
  9. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    11,523
    Location:
    The Netherlands
    Would do you mean with that? All of these attacks need to get control of the exploited PC, but if you block the exploit by restricting excel.exe for example, then attackers can't take control from a remote PC.
     
  10. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    7,429
    Location:
    U.S.A.
    You still don't understand how remote attacks work and frankly, I am tired of trying to explain this to you.
     
  11. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    11,523
    Location:
    The Netherlands
    I suppose you're kidding me right? Because seems you're the one that doesn't understand it. If you block hackers from getting control over MS Office or any other exploited tool, you have already blocked this attack. You make it sound like you can get control over a remote system simply by using magic. But in fact, you need to get malware (in-memory or not) or some system tool like powershell.exe running on the attacked system.
     
  12. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    7,429
    Location:
    U.S.A.
    Virtually all these advanced attacks discussed are against corps. and originate from e-mail based malware. RDP as a rule is enabled in corp. environments. Once the attacker has compromised the device/network, he establishes a RDP connection to his attack C&C server and runs PowerShell remotely; i.e. on the server, to execute a script he has previously dropped on the targeted device.

    Anyone using the Home version of Windows does not have to worry about RDP attacks since it is permanently disabled. For home users using other Windows versions, RDP should be disabled by disabling its associated services unless there is some need for it. If that is the case, they should be using a more secure alternative such as a VPN connection to connect to their workplace for example.
     
  13. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    11,523
    Location:
    The Netherlands
    Yes, there are various ways how to compromise a system, but we're now talking about MuddyWater, and this one tries to exploit MS Office, it hasn't got anything to do with RDP. But I always see you keep mentioning ''run powershell from remote'', as if this is something new.

    Once hackers have control of the exploited machine, they can indeed run commands on the attacked machines from remote. So the key is to interfere with this stuff. Let's say malware wants to access files, take screenshots, log keystrokes, or run some process, you can all block this via behavior blocker and not to forget a firewall to block communication to C&C. That's what these articles fail to mention, weirdly enough.
     
  14. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    7,429
    Location:
    U.S.A.
    All the related Yori article states in regards to the PowerShell code payload download is this:
    Something had to run this payload code ……………… Now it is possible that the macro had additional code to directly execute the downloaded PowerShell code locally. Most likely via invoking .Net associated subassembly execution. However if this was the case, the macro could have imbedded the PowerShell payload code eliminating the need to establish the remote connection to do so. Hence my assumption that the downloaded payload was a script and its was executed remotely. To do so however, something else would have to been in placed to allow for remote execution such as Mimikatz/PowerSploit was in play. There is no reference of same in this attack.
     
    Last edited: Dec 22, 2018
  15. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    11,523
    Location:
    The Netherlands
    The way I see it, is that these attacks work as RAT's, as soon as malware is running they can launch commands from remote, I don't see why this is so hard to visualize for you? You're overthinking things.
     
Loading...
  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.