I wonder if anyone can help me clarify the following, we start receiving standard ATP alerts for the past month as per bellow, usually im able to investigate this alerts and they either are DNS recursive queries performed by out forwarders on Spam domain emails received and rejected by the SMTP proxy, or Web sessions hijack attempts trying to redirect traffic to malicious domains, but recently i been baffled by a a recurrent alert as bellow where im not able to make much sense, i parsed the logs for our SMTP proxy that shows traffic to a Tor node from what i can only assume being SMTP connections rejected by the UTM does anyone have any idea on this ?
A threat has been detected in your network The source IP/host listed below was found to communicate with a potentially malicious site outside your company.
Advanced Threat ProtectionDetails Total Events: 2 User/Host Threat Name Destination Events Origin 1 192.168.7.250 C2/Generic-A 18.104.22.168 2 192.168.7.250 C2/Generic-A 22.214.171.124
Got the same problem. Sophos was pointing to the internal DNS. Then I changed everything to best practice. Internal DNS --> Sophos --> WAN.
Still finding the connection in the SMTP proxy…
Hi and welcome to the UTM Community!
What do you see in the Advanced Threat Protection log at 2021-10-27 12:50?
Cheers - Bob
The ATP reports the standard, a threat has been detected as per bellow
A threat has been detected in your networkThe source IP/host listed below was found to communicate with a potentially malicious site outside your company.
Details about the alert:
Threat name....: C2/Generic-ADetails........: www.sophos.com/.../C2~Generic-A.aspxTime...........: 2021-10-27 12:50Traffic blocked: yes
The traffic then points to our DNS forwarder: ( AFCd UDP C2/Generic-A 192.168.7.250 →126.96.36.199) after parsing the logs from our internal DNS server i can see the requests from our UTM to the Exit node going through our external DNS forwarders, but no idea to what is causing the UTM to contact the Node, my idea initially was based on a DNS query on an Spam email received by the SMTP proxy but not entirely sure...
07FC PACKET 000000B9471601E0 UDP Rcv 192.168.7.254 c213 Q [0001 D NOERROR] A (10)tor-exit-3(4)zbau(7)f3netze(2)de(0)
07FC PACKET 000000B946134120 UDP Snd 188.8.131.52 0735 Q [0001 D NOERROR] A (10)tor-exit-3(4)zbau(7)f3netze(2)de(0)
0678 PACKET 000000B946134120 UDP Snd 184.108.40.206 0735 Q [0001 D NOERROR] A (10)tor-exit-3(4)zbau(7)f3netze(2)de(0)
May we see the relevant log lines from the ATP log?
This are the most up to date logs of a fresh incident, as per the SMTP proxy the utm is rejecting a connection from a tor node, that im trying to decipher why the constant attempt connections, as we have no internal hosts using mail servers
SMTP PROXY2021:11:07-06:43:35 srvutm-1 exim-in: 2021-11-07 06:43:35 SMTP connection from [220.127.116.11]:4524 (TCP/IP connection count = 2)2021:11:07-06:43:50 srvutm-1 exim-in: 2021-11-07 06:43:50 SMTP connection from tor-exit-16.zbau.f3netze.de [18.104.22.168]:4524 lost D=14s
ATP192.168.200.104 C2/Generic-A 22.214.171.124 192.168.7.250 C2/Generic-A 126.96.36.199 192.168.200.103 C2/Generic-A 188.8.131.52 192.168.200.113 C2/Generic-A 184.108.40.206 192.168.200.104 C2/Generic-A 220.127.116.11 192.168.7.250 C2/Generic-A 18.104.22.168 192.168.200.103 C2/Generic-A 22.214.171.124 192.168.200.113 C2/Generic-A 126.96.36.199
ATP LIVE LOG
06:43:40 AFCd UDP C2/Generic-A 192.168.200.103 → 188.8.131.52 drop 06:43:40 AFCd UDP C2/Generic-A 192.168.200.113 → 184.108.40.206 drop 06:43:42 AFCd UDP C2/Generic-A 192.168.7.250 → 220.127.116.11 drop 06:43:43 AFCd UDP C2/Generic-A 192.168.200.104 → 18.104.22.168 drop 06:43:47 AFCd UDP C2/Generic-A 192.168.200.103 → 22.214.171.124 drop 06:43:48 AFCd UDP C2/Generic-A 192.168.7.250 → 126.96.36.199 drop 06:43:49 AFCd UDP C2/Generic-A 192.168.200.104 → 188.8.131.52 drop 06:43:51 AFCd UDP C2/Generic-A 192.168.200.103 → 184.108.40.206 drop 06:43:52 AFCd UDP C2/Generic-A 192.168.7.250 → 220.127.116.11 drop 06:43:52 AFCd UDP C2/Generic-A 192.168.200.104 → 18.104.22.168 drop
just letting you know that we are currently facing the exact same issue,
We previously thought this may be caused by someone in our network using the Tor Browser to avoid our webfilter (=> because the destination IP is a Tor exit node), but we couldn't confirm this.
One thing to mention: From my understanding it is not the traffic itself that is getting detected as suspicious, but the destination IP itself is.
Even if we just ping that external IP, we receive an ATP alert from the UTMs.
Our UTMs only show our internal DNS servers as the cause, which doesn't help.
We have enabled DNS logging on our DNS servers, and usually when the UTM finds something suspicious, I can find the source IP in those DNS logs - but not this time.
I went through a lot of logfiles - could you please check your UTM's IPS logfiles? Ours shows "ICMP flood detected" action="ICMP flood" where the destination IP is our mailserver's WAN interface. - But I'm not sure if this is related.
Sorry I can't help you, but you are not alone with this problem.
We are getting those connection drops, too for the same destination subnet.Whats a bit strange is the fact that the source IP belongs to our internal Sophos SUM which manages our customer's firewalls.
Gruß / Regards,
KevinSophos CE/CA (XG+UTM), Gold Partner
Thanks for your input, i do believe that this are random probing and vuln scans being performed by hosts in the Tor subnet looking for potential ports or services exposed, this happens on a daily basis and most of Network admins are not aware as Firewalls or edge protection devices rebuke this probing attempts as we expect them to do, due to the ATP triggering an alert is what put us on alert mode but as long the UTM drops traffic , and all our external services or ports are not exposed i believe we are fine.
The only thing wrong here is that traffic originating from the Tor shouldn't be allowed to use public DNS resolvers or Tor Dns should be restricted to their own Dns subnet and not touch the open common Dns resolvers
It's confusing when you don't just copy the full log lines here.
Balfson, i never had to dissect the ATP full log lines, so not to sure how to fetch. Does it requires SSH ? If so what are the inputs