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

DNS trap bogus IP

Hi All,

I saw a Anti-Bot log message 


Destination Port: 53
IP Protocol: 17
Protection Name: Operator.Trojan-banker.Win32.Zeus.w.eb
Malware Family: Zeus
Description: DNS response was replaced with a DNS trap bogus IP. See sk74060 for more information.
Confidence Level: High
Severity: High
Malware Action: DNS query for a C&C site
Protection Type: DNS Reputation
Destination DNS Hostname:
Vendor List: Check Point ThreatCloud

Blade: Anti-Bot
Product Family: Threat

The source of this DNS Request is an internal DNS Server. According to  sk74060 the default value for DNS trap IP is 

To find the infected host i have to check the logs for access to Is this correct? I see three access requests to Logs like this below (i removed the IPs)

Service ID: http
Source: <removed>
Source Port: 52778
Destination Port: 80
IP Protocol: 6
Product Family: Access
Description: http Traffic Accepted from <removed> to


The <removed> IP address is now the infected client? Check Point is not logging this "bogus IP" ( in any special way?

Is it a good idea to create a special Access Rule to Drop the Access to and Log it with an Alert?

Btw. I am using R80.10



0 Kudos
10 Replies

In most conventional infrastructures, your DNS lookups traversing the firewall will be from the internal DNS server configured to perform recursive lookups, not the actual client.

I.e. in rudimentary AD environment, this role is frequently resides on Domain Controller servers configured as DNS.

So the typical lookup from the client queries the DC for the resolution of the name, if it is not yet cached there, DC then performs the lookup and created a brunch in its cache for the domain in question.

If your environment is similar to what I am describing here, or if you are using any recursive DNS servers, check their logs to see which client has requested lookup of bad domain.

As to creating a special rule for handling this and alerting you, It makes little sense in my opinion, as C&C networks are pretty dynamic and the built-in threat prevention is designed to handle it.

From the point of view of finding the infected clients, especially in recursive DNS environments, If you have SmartEvent, I would configure a notification alert to either email or send an SNMP trap for these events and, if you would like to further automate the process of looking up infected clients, use a third party such as phantom:

Phantom: Security Automation & Orchestration Platform

You can request a fully functional and non-expiring copy of it for free from vendor, its only limitation is the number of events it will be allowed to process per day.

Otherwise, you'll have to script the process.




Thank you Vladimir. This is exactly my setup. And I am installing an Alert Notification for it.

0 Kudos

Hi Vladimir,

I'm new in the community but not in Threat Prevention. That's why I'm gonna ask a question to an old article.

Q: Even I enabled the prevent mode for DNS Traps some malicious DNS queries are still in Detect mode as you may see below. How am I supposed to Prevent them? Where am I doing wrong?

0 Kudos


From the looks of it, it was actually handled by replacing response with the one from your DNS Trap:

So whatever payload was expected, it has never arrived at the query originator.

As to why you are seeing it in Detect vs. Prevent, please check if the Threat Prevention profile assigned to the protected scope has this particular protection enabled.

I.e. you may have Default, Optimized and Strict profiles out of the box and have this protection in "Prevent" NOT in the profile applied to the scope in question.


Hi Vladamir,

Thanks for your detailed answer and I appreciate you took time for it...

In my situation, after I read the article SK74060 (Anti-Virus Malware DNS Trap feature) , I thought problem was the "dns=bg" value, in [resource_classification_mode] setting of the $FWDIR/conf/malware_config. So I adjusted the value as "dns=policy" as recommended and you may see below.

#possible values for action [by_policy or prevent or detect or inactive]

After all, what I expected the DNS Reputation protection to be PREVENT instead of DETECT. Cause in my Thread Prevention policy aciton was set to  PREVENT in "HIGH" "Confidence Level" also in "Severity Level" is "Medium or Above" as you may see below:

I've also set the Low Confidence Level "INACTIVE" for false positive logs. Bu no chance nothing changed.

So now I'm suspicious that according to my set of protections, is DNS Reputation working and are the settings correct? Or not?

As you paid attention and described, the Malicious DNS Query was replaced by Bogus IP, it seems to be a protection, but then, why it does not say "PREVENT" although the Confidence Level and Severity of the threat is HIGH in the log file?

Thanks for your time and interest,

Legend Legend

In R81 this type of activity is now logged as Prevent:  sk178804: Malware DNS Trap protection in R81 and higher generates "Prevent" logs

Gateway Performance Optimization R81.20 Course
now available at

Hi, same issue to my R81.10 cluster, did you fix it?

0 Kudos
Employee Employee

Note this post was from 2018 before the release of R81 where the logging behavior changed for some AB scenarios.

How does your TP configuration compare?


0 Kudos

Keep in mind DNS is basically two packets: An outgoing "who is" and an incoming reply of " is x.y.z.w"

At best, all we can do in this situation is replace the result with a benign address, which is what this log entry indicates.

Is it preventing bad things from happening? Maybe.

However, there may be a legitimate reason for looking up that particular DNS entry.

As such, it's marked as "Detect" as DNS in and of itself isn't malicious (except maybe for data exfiltration purposes).


Yeah Dameon I have the same curiosity and concern, due to a possible "data exfiltration purposes"  that's why I'm digging the situation.

0 Kudos


Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events