thrilla_killa

Mods, you can do away with this thread and close it. In the end: Generic Payloads: 1 ; Detections: 0

Metasploit was not used to exploit vulnerabilities. Neither was the Metasploit "check" module. MSFVenom was used to compile payloads. The payload was not Meterpreter, it was a reverse TCP shell that could be caught by netcat (nc).

I get that as well. Trust me, I completely know and understand how to strengthen security. That is my Blue Team's job. On the Red Team, my goal is to emulate threat actors and processes. In this case, again, very generic attacks were undetected from the client level. Other segments using other solutions detected these items and stopped them during or before runtime.

Yes, I am very familiar with this article. Also, I am familiar with the C2 software such as Cobalt Strike and Empire that is able to bypass AV, such as ESET. There are others that you can download on Github as well.

Really we just went around in a circle with the most obvious outcome: the protection is lacking in capabilities and other solutions need to be looked at. New attacks are missed whereas items that are known are not.

Which leads to my clients' take on signature vs signature-less solutions line Cylance.

I get it, there are mitigations that can be taken by the business. However, the AV should catch malicious payloads and terminate generic items like "meterpreter" when they are in memory, and in the active Red Team tests we conducted, they did not. Though, they got a local .ps1 file. But why would they not be able to quarantine an IN MEMORY, malicious and widely known process like meterpreter???

Yep.

Again, the machines are fully patched and MS Office was a fresh, updated and Windows Updated build.

Was not DDE nor the item shown. I am familiar with this attack vector and it closed in December.

Was a simple formula embedded in a document that pointed to a remote server to load the .ps1 file.

None of these tests were conducted on a standalone machine. The testing occurred in a business environment running the latest ESET Endpoint Security with the Firewall setting, Dangerous Applications, Potentially Unsafe applications and Live Grid settings on as well as the AMSI scanner. The OS's in use were never HOME editions, they were fully patched Windows 10 Enterprise builds in an Enterprise environment. The attack was also not executed via RDP either. The attack occurred when a user opened an MS Office document that was provided to them in a phishing campaign against the business. (Email protection was enabled as well). Another quick note regarding the local execution of powershell scripts: Meterpreter .ps1 files are detected (hooray!) after execution, however, they fail to kill the session and still allow the attacker to have full control of the meterpreter session after the execution of the .ps1 file(?!?!?! does that count as not detected???). Memory scans and disk scans post execution detect nothing. Not. One. Thing. I think the verbiage you have in the AMSI scanner for the business product needs to state that it "only detects locally executed powershell attacks" and that "botnet protection" only stops communications of known botnets. Also, how does ESET Augur play into all of this when an item is validly malicious in nature?

The after the fact VBS/WMI tool will not really help us if the client did not know that there was even executed.

Even testing super generic reverse_tcp connectors coded as powershell commands, when loading from an external source and not executing on disk, the script executes flawlessly without ESET intervention and will produce a command shell back to the attacking machine. ALL ESET settings are on and updated such as the AMSI scanner, Unsafe applications, dangerous applications, Live Grid, etc...

Unfortunately, I am not providing my source code at this time. I just wanted to advise that powershell, which is readily available on windows systems, can easily bypass the ESET systems and allow commands to be run from remote agents with ease.