New PowerShell Backdoor Resembles "MuddyWater" Malware November 30, 2018 https://www.securityweek.com/new-powershell-backdoor-resembles-muddywater-malware
Experts at Yoroi – Cybaze Z-Lab analyzed MuddyWater Infection Chain December 7, 2018 https://securityaffairs.co/wordpress/78748/apt/muddywater-infection-chain.html
You would think by now any corp. admin in his right mind would have disabled Word permanently macros.
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...
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.
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.
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.
You still don't understand how remote attacks work and frankly, I am tired of trying to explain this to you.
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.
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.
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.
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.
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.
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/
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
