DNS trap bogus IP

[Benjamin_Hofst1]

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: morejobs.ch
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 62.0.58.94. 

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

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

....

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

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

Btw. I am using R80.10

Regards,

Benjamin

[Vladimir]

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.

Regards,

Vladimir

[Benjamin_Hofst1]

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

[Evren_Buyer]

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?

[Vladimir]

Evren,

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.

[Evren_Buyer]

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.

[resource_classification_mode]
dns=policy
http=policy
smb=policy
smtp=policy
[email_links_classification]
max_scan_size=4096
max_scan_url_per_mail=10
max_url_len=128
#possible values for action [by_policy or prevent or detect or inactive]
override_av_action=by_policy
override_ab_action=by_policy
scan_all_traffic=false
obfuscate=false

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,

[Timothy_Hall]

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

[andy_currigan]

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

[Chris_Atkinson]

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?

[PhoneBoy]

Keep in mind DNS is basically two packets: An outgoing "who is host.example.com" and an incoming reply of "host.example.com 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).

[Evren_Buyer]

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

[Emil_T]

Should I allow traffic to the bogus trap IP in security policy rule?