Snort alert due to .pw DNS request : rule 1:28039
-
Hi everybody!
I have a strange snort alert since yesterday, at first every hour, stopping at 22:32 yesterday (no browser open at that time, nobody sitting at the computer).
Now today it started again at 18:01, 18:31, 19:02, 19:12, 19:32, 19:38
The alert says there is a "suspicious .pw dns request" and warns of "A Network Trojan detected".
I did a package capture and found the address requested is for
cahoots.pw
which is according to google a website to visualize journalist networks or something like that via a Firefox plugin. I have no such plugin installed.
Why does snort alert for these .pw DNS requests?
How to find the application sending these requests?
The system is an openSuse 13.2 x64 (dual boot with Win 7 64, no wine, Windows not started for days).
I haven't installed any software recently, but made some regime-unfriendly posts against the NSA on a security forum yesterday :-)
Any suggestions? Any help highly appreciated!
Kind regards
chemlud
-
I've seen these sporadically in the past. In my case they did not represent actual Trojans. Could be some syndicated ad network causing it.
Also, don't worry about offending the NSA. If they want to compromise your network, you can bet they are not dumb enough to trigger an IDS/IPS with their work… ;). You would never know they had been there until some future Edward Snowden leaked more secrets.
Bill
-
Hi Bill!
Many thanks for taking time to give me info! Highly appreciated every time.
May I ask what a "syndicated ad network" is? :-)
Any idea how to find the culprit process on the machine initiating the DNS request? Even if I find the events with a long-term wireshark I have no idea where look for the respective process.
Kind regards
chemlud
-
Update:
Same alert (Thursday, Friday evening) for same cachoots.pw domain DNS request in another network, on a Windows 7 64 computer.
Why that?
Very strange. What is trying to resolve this strange page?
-
Hi Bill!
Many thanks for taking time to give me info! Highly appreciated every time.
May I ask what a "syndicated ad network" is? :-)
Any idea how to find the culprit process on the machine initiating the DNS request? Even if I find the events with a long-term wireshark I have no idea where look for the respective process.
Kind regards
chemlud
Are you running Snort on your LAN interface? If so, the alert should show the local IP address that initiated the request. If you run Snort only on the WAN, then Snort only sees your local outbound traffic after it has been NAT'd, and inbound traffic only before it has been NAT'd. In other words, Snort running on your WAN can never show you which LAN client is the source or destination of alerts. Only your WAN IP will show.
So if you are running Snort on just your WAN, I suggest moving it to your LAN instead. You can do this easily on the SNORT INTERFACES tab. Just change the interface drop-down box "lan" from "wan".
Bill
-
Hi!
Always running on LAN… I see the IPs of the computers initiating the DNS request for cahoots.pw, but have no idea why in one network a Linux machine and in a totally different network (different router, different internet connection) a Windows 7 machine should try to reach the same cahoots.pw.
It's a miracle to me, what is initiating the request, no user sitting in front of the machine, no browser open...
regards
chemlud
-
Update:
The Windows 7 machine with the alerts is also dual boot, with Opensuse 13.1
From Yesterday on (AFTER the alerts) I booted it to Linux and let it run the whole day.
This evenening (as al LINUX machine !) it tried to access the same cahoots.pw at 18:06, 19:06, 20:06, for 4 (four) times each.
It simply does not matter which OS is running, the requests are initiated anyway.
I don't get this.
-
Hi Bill!
Many thanks for taking time to give me info! Highly appreciated every time.
May I ask what a "syndicated ad network" is? :-)
Any idea how to find the culprit process on the machine initiating the DNS request? Even if I find the events with a long-term wireshark I have no idea where look for the respective process.
Kind regards
chemlud
Are you running Snort on your LAN interface? If so, the alert should show the local IP address that initiated the request. If you run Snort only on the WAN, then Snort only sees your local outbound traffic after it has been NAT'd, and inbound traffic only before it has been NAT'd. In other words, Snort running on your WAN can never show you which LAN client is the source or destination of alerts. Only your WAN IP will show.
So if you are running Snort on just your WAN, I suggest moving it to your LAN instead. You can do this easily on the SNORT INTERFACES tab. Just change the interface drop-down box "lan" from "wan".
Bill
When I start it torrent, I get a same warning. But I found it ;)
-
Lucky you! :-)
Here no idea which application is causing these requests. Apparently something triggers DNS requests for things visited hours ago even after closing the browser. No idea what is doing this.
Some kind of Firefox feature?
Addons installed:
BetterPrivacy 1.68
CipherFox 3.10.1
HTTPS-Everywhere 5.0.3
NoScript 2.6.9.2
SSL Version Control 0.4 (minimum TLS 1.1) -
I too am getting bombarded with these alerts. Have yet to figure out why PCs on my network would be sending DNS queries for .PW
-
…for me it stopped as suddenly as it began... no idea what was going on here, maybe some kind of infection somewhere in the network, I think I will never know.
-
Same problem here. Multiple times per minute, completely flooding the alerts tab.
"And now for something completely different" ( ;D ):
It even does that when nothing is connected to pfSense (unplug the switch, so only pfSense and the modem are connected to each other). I left it running for 30 minutes like that, and after that the log was still flooded like before. I have the same with two other SID's, btw.
-
It looks like you have that Snort rule "28039" on the WAN interface… Disable that rule for the WAN, and enable it on the LAN. This will show which LAN IP is making the request ...
But if you removed the LAN devices, maybe one of the NTP IPs you defined in pfSense or another service is going to a .pw domain?
It doesn't mean that everything in .pw is bad, its just a suspicious behavior…
http://blog.talosintel.com/2016/04/enabling-evil.htmlYou can also use the Packet capture GUI feature to collect DNS requests to get more insight.
-
It looks like you have that Snort rule "28039" on the WAN interface… Disable that rule for the WAN, and enable it on the LAN. This will show which LAN IP is making the request ...
But if you removed the LAN devices, maybe one of the NTP IPs you defined in pfSense or another service is going to a .pw domain?
It doesn't mean that everything in .pw is bad, its just a suspicious behavior…
http://blog.talosintel.com/2016/04/enabling-evil.htmlYou can also use the Packet capture GUI feature to collect DNS requests to get more insight.
BB! ( :-* )
Thank you, BB (Latina is almost ready ;D ;D ;D ).
How do you quickly find out in which category that SID is, BB? Is there a way to search? Because browsing through thirty categories is not exactly efficient, dogs want me outside to play with them while the sun shines, not waste hours on browsing to find something :-[
-
How do you quickly find out in which category that SID is, BB?
In the screenshot… it says "INDICATOR-COMPROMISE"
So short answer: "Snort-Indicator-Compromise" category…Looking at the rule, its enabled with the "Balanced" and "Security-policy" setting:
alert udp $HOME_NET any -> any 53 (msg:"INDICATOR-COMPROMISE Suspicious .pw dns query"; flow:to_server; content:!"|01|u|02|pw"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"|02|pw|00|"; distance:0; fast_pattern; metadata:policy balanced-ips alert, policy security-ips drop, service dns; classtype:trojan-activity; sid:28039; rev:5;)You can click on the "Disable Sid" Icon in the Alerts, or Blocked Tab, to disable on the WAN… and then goto the "LAN Rules" tab in Snort/Suricata and select the Category "Snort_indicator_compromised.rules" and enable sid 28039. You might need to re-start the Interfaces for it to take effect...
If you find that its a False Positive, you could add a suppress to the LAN Interface suppress List, so the rule will only fire for other .pw domains, excluding this particular DST IP... (Once you figure out which DST IP you want to suppress that is...)
suppress gen_id 1, sig_id 28039, track by_dst, ip x.x.x.x -
How do you quickly find out in which category that SID is, BB?
In the screenshot… it says "INDICATOR-COMPROMISE"
So short answer: "Snort-Indicator-Compromise" category…Looking at the rule, its enabled with the "Balanced" and "Security-policy" setting:
alert udp $HOME_NET any -> any 53 (msg:"INDICATOR-COMPROMISE Suspicious .pw dns query"; flow:to_server; content:!"|01|u|02|pw"; content:"|01 00 00 01 00 00 00 00 00 00|"; depth:10; offset:2; content:"|02|pw|00|"; distance:0; fast_pattern; metadata:policy balanced-ips alert, policy security-ips drop, service dns; classtype:trojan-activity; sid:28039; rev:5;)You can click on the "Disable Sid" Icon in the Alerts, or Blocked Tab, to disable on the WAN… and then goto the "LAN Rules" tab in Snort/Suricata and select the Category "Snort_indicator_compromised.rules" and enable sid 28039. You might need to re-start the Interfaces for it to take effect...
If you find that its a False Positive, you could add a suppress to the LAN Interface suppress List, so the rule will only fire for other .pw domains, excluding this particular DST IP... (Once you figure out which DST IP you want to suppress that is...)
suppress gen_id 1, sig_id 28039, track by_dst, ip x.x.x.xYou know I love you with all my heart, BB :P
But I have no'Snort-Indicator-Compromise'-category, really not ;D Pic to prove**:-*** It turns out I found it, thanks to your tip, in IPS Policy - Security.It was disabled, I enabled it now. Let's see what shows up now.
Thanks BB :P
