IPS signature does not match with attack type

[Sarm_Chanatip]

Hello everyone!

I'm using R80.20 with StandAlone mode in my test environment and doing some test about IPS blade feature. 

IPS Scenarios Test
1. Using EternalBlue (MS17-010) exploit module in Metasploit in Kali Linux (Signature does not match correctly)
2. Using Microsoft Windows Remote Desktop protocol code execution (MS12-020) exploit module in Metasploit in Kali Linux 
(Signature is matched correctly)
3. Using Nikto Security Scanner in Kali Linux (Signature is matched correctly)
4. Using Internet Explorer same id property remote code execution (MS12-037) in Metasploit in Kali Linux 
(Signature is matched correctly)

Everything went smoothly as should be expected but I found something did not match in my test case. In this case,
 we are talking about the 1st scenario Using Eternal Blue (MS17-010) exploit module.

In my test case, I have two computer machines that they are in the different network subnet the one is Windows7 which act as Victim and another one is Kali Linux act as Attacker Where the Victim machine is in-network 192.168.210.0/24 and Attacker is in-network 172.168.210.0/24

I will explain to you all guys regarding my test IPS functionality.

The 1st screenshot is to search about the vulnerability that I wanted to test

The 2nd screenshot is to scan and lookup the vulnerability of the targeted host, and we found it!

The 3rd screenshot is to try to exploit the targeted host with below commands to prove if the command is able to use properly.  It works!

The 4th screenshot, I tried to filter logs and found the traffic matched with what I was testing in the next step

The 5th screenshot, Now I turned on IPS software blade to prevent this exploit the vulnerability with optimized profile

 

At this point, after policy installation completed I should see the IPS blade prevent this exploit as behavior as expected and match one or more signatures that I filtered as above screenshots.

But this did not look like what I wanted, the IPS was able to block this exploitation but with a different signature The signature was displayed in the logs view is Microsoft  Windows NT Null CIFS Sessions as a screenshot below

So I tried to change this protection from drop to inactive to verify if this changed behavior something.

Now, executed exploit command test again and found that it was prevented by IPS with the correct signature.

All of I mentioned I do not quite understand why it is preventing by Microsoft  Windows NT Null CIFS Sessions signature which is not being the correct signature of exploit vulnerability.

Anyone knows regarding this behavior.

Appreciate every comment

[G_W_Albrecht]

What you could see is that the attack is blocked triggered by one or the other attack type. So i think IPS is working very well 😉 First is a Protocol Anomaly (only), second the exploit you have used. Makes sense, i think.

[Timothy_Hall]

Agree with @G_W_Albrecht here, the prerequisite for launching the EternalBlue attack is the creation of a null CIFS session first which is what IPS matched against initially.  From https://research.checkpoint.com/eternalblue-everything-know/

EternalBlue works on all Windows versions prior to Windows 8. These versions contain an interprocess communication share (IPC$) that allows a null session. This means that the connection is established via anonymous login and null session is allowed by default. Null session allows the client to send different commands to the server.

So even prior to the disclosure of this vulnerability and the creation of the EternalBlue IPS signature, the attack would have been blocked anyway by the Null CIFS IPS signature which has been around 10+ years.  This sounds like a great outcome to me!

[Sarm_Chanatip]

Hi Timothy,

Thank you for your comment and for sharing the source of EthernalBlue researching.

So far, as my understanding EternalBlue is quite related to many behavior attacks, right? one of them is a Null session which will be matched this first as protocol anomaly detect.

I'm not sure if I understand it correctly as I'm not an IPS expert.

[PhoneBoy]

Just to reiterate what others have said: some of our IPS protections and/or inspection settings target specific protocol anomalies.
These anomalies can be exploited as a part of many different attacks, not just the ones you're discussing here.
Windows NT NULL CIFS occurs relatively early in the Eternal Blue exploit process.
Having prevented it at that phase, there's nothing else to see that indicates its Eternal Blue or some other attack that leverages Windows NT NULL CIFS.

How exactly it shows up in the logs is less interesting than the fact we prevented the attack.

[Sarm_Chanatip]

Hi Admin,

Thanks for the comment.

As you mentioned, "Windows NT NULL CIFS occurs relatively early in the Eternal Blue exploit process."  I got it.

However, can you clarify me more how about the sign as the screenshot below what does it mean?

I can see both IPS and Firewall symbol are in the same protection. 

[PhoneBoy]

The icon signifies this is a Core Protection.

Normally, for R80.x gateways, any changes to IPS protections require the Threat Prevention policy to be installed to take effect.
This is not the case for IPS on pre-R80.x gateways or when Core Protections are involved, which require the Access policy to be installed to take effect.

[Sarm_Chanatip]

Hi Admin,

Thanks for the clarification.

[Sarm_Chanatip]

Hi G_W_Albrecht

Thank you for your comment.

I think IPS is working well but just confusing about this signature, I will read over on this again to get a better understanding. 🙂