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:
    27,655
    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:
    27,655
    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,910
    Location:
    U.S.A.
    You would think by now any corp. admin in his right mind would have disabled Word permanently macros.
     
  4. guest

    guest Guest

    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,501
    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,910
    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:
    12,582
    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,910
    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:
    12,582
    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,910
    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:
    12,582
    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,910
    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:
    12,582
    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,910
    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:
    12,582
    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.
     
  16. mood

    mood Updates Team

    Joined:
    Oct 27, 2012
    Posts:
    27,655
    MuddyWater Resurfaces, Uses Multi-Stage Backdoor POWERSTATS V3 and New Post-Exploitation Tools
    June 10, 2019
    https://blog.trendmicro.com/trendla...owerstats-v3-and-new-post-exploitation-tools/
     
  17. EASTER

    EASTER Registered Member

    Joined:
    Jul 28, 2007
    Posts:
    8,501
    Location:
    U.S.A. (South)
    Good old trustworthy Powershell. The best tasting dish Microsoft ever dished out into it's O/S.

    It ordinarily would be a very useful feature IF IT WAS GIVEN A CONTROL ONLY APPLICABLE TO THE PARTICULAR system hardware ID per each unit/release.

    But then there are ways the bad actors are also able to free up the O/S to release that too. The Hardware ID I speak of.

    As things stand and are, Powershell is an easy in for multiple instructions to carry out tons of different manner of intrusions
     
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.