Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 20 replies
  • Answers 2 answers
  • Subscribers 29 subscribers
  • Views 2774 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

An attempt to communicate with a botnet or command and control server has been detected.

MJ_P1

I found some malware on a client PC not long ago, which we discussed at length in this thread: https://community.sophos.com/intercept-x-endpoint/f/discussions/132693/mal-polazert-a-removal/491955#491955.

Intercept X is deployed throughout the network for our last client getting these reports of 'An attempt to communicate with a botnet or command and control server has been detected' from the XG firewall. Not once has Intercept X detected malicious software or any alerts for this one client, yet the log file gets 4-5 entries per day like this in the screenshot:

The 52. and 54. servers you see are two we use from WebTitan for DNS filtering. Those appear in AD DNS, but the XG is configured for the two from OpenDNS. This leads me to believe the traffic is coming from inside the network and filtering through the AD DNS servers.

I enabled Sysmon DNS to capture the traffic, but that isn't converting these requests to an IP on the network after the 25.6. The 25.6 IP address is the domain controller/DNS server for this client. It is a small office, so the only DC/DNS server in the network.

I am at a loss to figure out where this traffic is coming from and how I can stop it. I have some DNS logs I have captured, but I'd rather not post these up here. I can't figure out how to trace the traffic from 25.6 to see what on the network is making the call to this bad website. I looked up the website. It's been cleaned up, but something in this client network is still making calls to it.

Are there some folks among us who could help me sort this out please? I can provide more details and DNS logs from the DC.

-Mike



This thread was automatically locked due to age.
Parents
  • 0

    What you need to do: XG Firewall has detected and possibly blocked this traffic. It is recommended that you configure the firewall to block these events if it is not already configured to do so. Under Advanced threat menu, check that the policy is set to "Log and Drop". If it is already set to drop these events, then no further action is needed.

    ePayitonline Login

  • 0 in reply to Joe Phillips

    I've already done that.

    This happens, 9, 10, sometimes more times per day. While I'm glad the traffic is being blocked, we need to know which device on the network is making calls to this former C&C server.

    -Mike

  • 0 in reply to MJ_P1

    this looks like XG is resolving the virus hosts on it's own.

    Do you have this host as FQDN Host in your firewall configuration? If yes, the XG will resolve it from time to time.

    Eventually you have created a block rule to that host?

    btw: you dont need to care about the bad checksum

  • 0 in reply to LHerzog

      yes, I did find it there.

       

    I don't know how it got on this list.

    Does this mean it is only the firewall trying to resolve the address, and not malware on the client network?

    It tries to resolve 5-10 times per day, sometimes more, only when the client office is open for business.

    If I remove it from here, will it stop the alerts?

    -Mike

  • 0 in reply to MJ_P1

    Someone created it manually.

    I'd remove it from there, but first check, if there is a firewall rule, referencing on this host. I assume, there is one. Check with your team if it's OK to delete it.

    Have you re-configured your clients not to use 8.8.8.8 as DNS but your firewall or other internal DNS?

    You asked:

    Does this mean it is (only) the firewall trying to resolve the address: YES

    and not malware on the client network?: PROBABLY not -> you need to continue tcpdump for that host

  • 0 in reply to LHerzog

    All endpoints in the network point to the domain controller which is also the only DNS server in the network, the 192.168.25.6 address. The DNS server uses 52.9.90.57, 54.241.17.112, then also 8.8.8.8. The XG is using those same three DNS servers.

    My plan will be to remove this entry, and any rule referring to it. There is one other person who manages this firewall with me who has confirmed he did not create a rule for this .info address and does not see a need for it.

    I will run the tcpdump throughout the day and wait to see if I get an alert from Sophos Central.

    Thank you for helping me get this far.

    -Mike

  • 0 in reply to MJ_P1

    you can check the admin log from live viewer to see who created it (if not the "admin" user). but do not expect too much. It goes only back 2 or 3 days back in time. Is your firewall reporting to sophos Central? you could use the report generator on central to check older logs.

  • 0 in reply to LHerzog

    I see it now. A rule was created to block this website. I remember now that it was me who did this as an early troubleshooting step. That would explain the entry in the hosts:

    -Mike

  • 0 in reply to MJ_P1

    I deleted the rule and the host entry. An hour or so later, we got the alert again. This is the dump file:

    192.168.25.6.57067 > 52.9.90.57.53: [udp sum ok] 33960+ [1au] A? vxvhwcixcxqxd.com. ar: . OPT UDPsize=4000 DO (46)
    10.1.10.118.57067 > 52.9.90.57.53: [udp sum ok] 33960+ [1au] A? vxvhwcixcxqxd.com. ar: . OPT UDPsize=4000 DO (46)
    52.9.90.57.53 > 10.1.10.118.57067: [udp sum ok] 33960 q: A? vxvhwcixcxqxd.com. 2/0/0 vxvhwcixcxqxd.com. A 192.73.252.18, vxvhwcixcxqxd.com. A 192.73.252.25 (67)
    52.9.90.57.53 > 192.168.25.6.57067: [udp sum ok] 33960 q: A? vxvhwcixcxqxd.com. 2/0/0 vxvhwcixcxqxd.com. A 192.73.252.18, vxvhwcixcxqxd.com. A 192.73.252.25 (67)
    192.168.25.6.57298 > 52.9.90.57.53: [udp sum ok] 28024+ [1au] AAAA? vxvhwcixcxqxd.com. ar: . OPT UDPsize=4000 DO (46)
    10.1.10.118.57298 > 52.9.90.57.53: [udp sum ok] 28024+ [1au] AAAA? vxvhwcixcxqxd.com. ar: . OPT UDPsize=4000 DO (46)
    52.9.90.57.53 > 10.1.10.118.57298: [udp sum ok] 28024 q: AAAA? vxvhwcixcxqxd.com. 2/0/0 vxvhwcixcxqxd.com. AAAA 2607:f740:0:3f::1c7, vxvhwcixcxqxd.com. AAAA 2607:f740:0:3f::1d0 (91)
    52.9.90.57.53 > 192.168.25.6.57298: [udp sum ok] 28024 q: AAAA? vxvhwcixcxqxd.com. 2/0/0 vxvhwcixcxqxd.com. AAAA 2607:f740:0:3f::1c7, vxvhwcixcxqxd.com. AAAA 2607:f740:0:3f::1d0 (91)
    192.168.25.6.55906 > 52.9.90.57.53: [udp sum ok] 4145+ A? vxvhwcixcxqxd.net. (35)
    10.1.10.118.55906 > 52.9.90.57.53: [udp sum ok] 4145+ A? vxvhwcixcxqxd.net. (35)
    52.9.90.57.53 > 10.1.10.118.55906: [udp sum ok] 4145 q: A? vxvhwcixcxqxd.net. 2/0/0 vxvhwcixcxqxd.net. A 192.73.252.25, vxvhwcixcxqxd.net. A 192.73.252.18 (67)
    52.9.90.57.53 > 192.168.25.6.55906: [udp sum ok] 4145 q: A? vxvhwcixcxqxd.net. 2/0/0 vxvhwcixcxqxd.net. A 192.73.252.25, vxvhwcixcxqxd.net. A 192.73.252.18 (67)
    192.168.25.6.57395 > 52.9.90.57.53: [udp sum ok] 42814+ [1au] AAAA? vxvhwcixcxqxd.net. ar: . OPT UDPsize=4000 DO (46)
    10.1.10.118.57395 > 52.9.90.57.53: [udp sum ok] 42814+ [1au] AAAA? vxvhwcixcxqxd.net. ar: . OPT UDPsize=4000 DO (46)
    52.9.90.57.53 > 10.1.10.118.57395: [udp sum ok] 42814 q: AAAA? vxvhwcixcxqxd.net. 2/0/0 vxvhwcixcxqxd.net. AAAA 2607:f740:0:3f::1c7, vxvhwcixcxqxd.net. AAAA 2607:f740:0:3f::1d0 (91)
    52.9.90.57.53 > 192.168.25.6.57395: [udp sum ok] 42814 q: AAAA? vxvhwcixcxqxd.net. 2/0/0 vxvhwcixcxqxd.net. AAAA 2607:f740:0:3f::1c7, vxvhwcixcxqxd.net. AAAA 2607:f740:0:3f::1d0 (91)
    192.168.25.6.55638 > 52.9.90.57.53: [udp sum ok] 26494+ [1au] A? vxvhwcixcxqxd.info. ar: . OPT UDPsize=4000 DO (47)
    10.1.10.118.55638 > 52.9.90.57.53: [udp sum ok] 26494+ [1au] A? vxvhwcixcxqxd.info. ar: . OPT UDPsize=4000 DO (47)
    52.9.90.57.53 > 10.1.10.118.55638: [udp sum ok] 26494 NXDomain q: A? vxvhwcixcxqxd.info. 0/8/0 ns: h86rl202cahtd6ffjrkka6rsougg8ujj.info. Type50, h86rl202cahtd6ffjrkka6rsougg8ujj.info. RRSIG, info. SOA a0.info.afilias-nst.info. hostmaster.donuts.email. 1649262096 7200 900 1209600 3600, info. RRSIG, hdergbk5kocun0trmtiis1vvb7ius0td.info. Type50, hdergbk5kocun0trmtiis1vvb7ius0td.info. RRSIG, dr3kecftk5dlgg1gdcs9q10f5vjs86ll.info. Type50, dr3kecftk5dlgg1gdcs9q10f5vjs86ll.info. RRSIG (1033)
    192.168.25.6.55638 > 54.241.17.112.53: [udp sum ok] 26494+ A? vxvhwcixcxqxd.info. (36)
    10.1.10.118.55638 > 54.241.17.112.53: [udp sum ok] 26494+ A? vxvhwcixcxqxd.info. (36)
    54.241.17.112.53 > 10.1.10.118.55638: [udp sum ok] 26494 NXDomain q: A? vxvhwcixcxqxd.info. 0/1/0 ns: info. SOA a0.info.afilias-nst.info. hostmaster.donuts.email. 1649262096 7200 900 1209600 3600 (115)
    192.168.25.6.55638 > 8.8.8.8.53: [udp sum ok] 26494+ A? vxvhwcixcxqxd.info. (36)
    10.1.10.118.55638 > 8.8.8.8.53: [udp sum ok] 26494+ A? vxvhwcixcxqxd.info. (36)
    8.8.8.8.53 > 10.1.10.118.55638: [udp sum ok] 26494 NXDomain q: A? vxvhwcixcxqxd.info. 0/1/0 ns: info. SOA a0.info.afilias-nst.info. hostmaster.donuts.email. 1649262096 7200 900 1209600 3600 (115)
    192.168.25.6.55191 > 52.9.90.57.53: [udp sum ok] 159+ A? vxvhwcixcxqxd.in. (34)
    10.1.10.118.55191 > 52.9.90.57.53: [udp sum ok] 159+ A? vxvhwcixcxqxd.in. (34)
    52.9.90.57.53 > 10.1.10.118.55191: [udp sum ok] 159 NXDomain q: A? vxvhwcixcxqxd.in. 0/1/0 ns: in. SOA ns1.registry.in. dns.registry.i

    192.168.25.6 is the domain controller/DNS server.

    10.1.10.118 is assigned to the WAN port on the XG.

    -Mike

  • 0 in reply to MJ_P1

    that malware is obviously still in your network

    192.168.25.6.57067 > 52.9.90.57.53

    -> your internal DNS Servers 192.168.25.6 should only use your XG as DNS forwarder, do not let them forward to external servers.

    That's the only way you can see what's going on.

    192.73.252.18 is IP of vxvhwcixcxqxd.com

    Either a client using your internal DNS as forwarder is trying to reach that FQDN. Check that DNS logs on your internal DNS server. If you haven't, do a tcpdump there.

    Or malware already running on your internal DNS server.

    You need to check the DNS logs on your internal machines.

    Concider your network as "hacked".

  • 0 in reply to LHerzog

     We followed your previous suggestion to send DNS traffic to the XG, with a DNS request route for local domain traffic back to the DC. Once we did this, we had a definitive identification of the endpoint with malware.

    We found the endpoint with the malware. It is an old Mac. So old, Intercept X would not install on it. It was agreed the device would be unplugged from the network.

    Thank you for your help in sorting this out.

    -Mike

  • 0 in reply to MJ_P1

    I'm glad you could identify and remove the machine from your network. I hope, you do not see those ATP's anymore!

    Regards

Reply Children
No Data
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?