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
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.
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?
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.
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.
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.
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.
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?
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.
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!
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.
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.
I think you meant "..........\v4.0_4.0.0.0__b77a5c561934e089\System.Management.Instrumentation.dll" ?
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. .
Some talk about abusing Powershell to bypass Application Whitelisting by using Powershell to invoke shellcode even when Powershell scripting is disabled. The Powershell part starts at Page 23: https://bsidesvienna.at/slides/2015/a_case_study_on_the_security_of_application_whitelisting.pdf
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
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
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
I don't get it, if I'm correct he advises to block PowerShell from loading, but I thought that wasn't enough to stop these kind of attacks?
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?
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.