Create a Post
Showing results for 
Search instead for 
Did you mean: 

IPS signature does not match with attack type

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 and Attacker is in-network

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 belowMS17-010.jpg


So I tried to change this protection from drop to inactive to verify if this changed behavior something.MS17-010_2.jpg




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

8 Replies

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.

Champion Champion

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

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!


Gateway Performance Optimization R81.20 Course
now available at

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

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.

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. 

Null Session.jpg

0 Kudos

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.

Hi Admin,

Thanks for the clarification.
0 Kudos

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


Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events