Preventing/Block Meterpreter

[Rana]

Is there any advice to prevent/block Meterpreter?

Situation: an external audit shows, the Meterpreter-connections are not blocked, even if Meterpreter-IPS-Protections (there are 3 of them) are set to Prevent.

The following Blades are active: IPSec VPN, Mobile Access, Application Control, URL-Filtering, ClusterXL, Monitoring, IPS, Anti-Bot, Anti-Virus.

Tia
Christian

[_Val_]

What about HTTPSi?

[Rana]

Sorry, it was not in the listing: https-interception is enabled.

[HeikoAnkenbrand]

Hi @Rana,

I always use SNORT signatures/rules in these cases when there are no manufacturer signatures available.

Most of the time you can extract some good ASCII signatures from the meterpreter exploit code. Then you can create a SNORT signature and import it via the SmartConsole. This is not so easy most of the time but works quite well.

I always try to extract signatures from metasploit,... or other tools.

More information on how to import SNORT signatures can be found here:
https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_ThreatPrevention_AdminGuide/Topics...

PS: Enable https interception.

[Cesar_Almada]

HI mr Heiko, you can provide please examples

thanks

[_Val_]

Can you please provide particular CVEs for alleged vulnerabilities, or any other info that would help to understand the details?

[Rana]

Sorry, but I cannot provide any CVEs.

As long as I know, Meterpreter is a plugin for metasploit and used by hackers for pen-tests and of course can be used by evil persons. 😉

The auditor used this for his work and noticed, that Meterpreter-connections should be blocked by a firewall, and that he knows Check Point, and that should be "easy" to configure.

So, Meterpreter itself is not a malware, but can be used to infect hosts.
I not sure, if Meterpreter was downloaded over the firewall or is installed in some other way.

What I found, were these three IPS-protections:

All 3 IPS-protections are enabled for the used IPS-profile, but didn't seem to work, as there are no logs seen.

What I'm not sure about it: these IPS-protections should prevent from "downloading" Meterpreter (the plugin?) through the firewall, or should prevent using Meterpreter through the firewall.

Additional information I got/was seen in the log:

At second attempt with the IPS-protections enabled, commands over Meterpreter were blocked (traffic at port 80), but as Application, which is not allowed for the user (blocked by Application Control). Don't know, if IPS detection should be before or after detection by application.

APLC is configured to accept only some applications for different user-groups (identity awareness).

After that, the communication within Meterpreter was BASE64-encoded over port 80, and all the traffic passed the firewall.

As I see, no https-traffic was used, so enabled https-interception is not necessary for detecting Meterpreter connections.

Christian

[_Val_]

Thanks for spending time with the explanation. I know what Metepreter and Metasploit are. I am looking for actual attack information that should be blocked and is not. Any example you can provide?

[Rana]

I was sure, you know ... I learnt it. 😉

Unfortunately I have only rare information, about what the auditor exactly did. I got the following two screenshots by the customer:

This attempt was blocked by APCL:

The second (should be some BASE64-encoded transfer) was accepted by the firewall:

I have to wait till mid August, for the next meeting with the customer and the auditor.

HTH
Christian

[_Val_]

I would suggest you to reach out to your local office, or TAC, or both. Reproducing the issue might be required, to find the exact action.

[Rana]

OK, thanks, I will do this.

Regards
Christian

[Thomas_Eichelbu]

Hello Rana, 

you have any news regarding this issue ?

i have faced the same unlucky event ... an unannounced Pen Test really pierced through the firewall like a hot bullet.
(from inside to outside, the Pen Test was run from a domain joined client, in seconds all domain credentials where retrieved too,
so the malware was not sent via email or whatever. just a webshell via powershell was run, to make it "easier")

HTTPS Inspection was NOT enabled, but MeterPreter was run port port 80 ... so it did not matter.
Connections on 443 of course also went trough also ... 
The IPS protections for Metasploit/Meterpreter were only set to "Detect", because of Staging Settings ;-(

the APPL blade said only "Non HTTP traffic that does not match any other application" ... 

so a mess ... 
the question is now ...
how to block this thing ... any one who has some ideas?


best regards
Thomas

[Rana]

Unfortunately no.

It seems to me, that only trying to block "non http traffic" will resolve this specific problem. But because we expected a lot of sideeffects and following configurations of exceptions, we did not implement this solution.

Regards
Christian/Rana