Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 20 replies
  • Subscribers 5 subscribers
  • Views 33419 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

ATP triggers for botnet but scans show nothing on server

Lucas Villanueva

 

Since not quite the first of the month, we've had a very interesting and chronic trigger on our firewall...

 

I have been continually running different malware/antivirus scans on the server and resetting to see if I have cleared off the problem, but to no avail. I know it's possible these could be false positives, but it just seems so odd that there's so dang *many* triggers, up in the thousands per day. I've Googled just about everything I can think of to try to find more information, to try to figure out if indeed we have an infection or if this is a wild goose chase, but I'm not 100% certain yet. Thankfully, this means that any of the packets being sent to that destination are being dropped, so if it is a bad site, it's not as bad as it could be... but I would prefer to get the triggers to stop altogether, rather than just resetting every time I run a scan. There are two destination IPs connected to this host - 208.67.222.222 and 208.67.220.220. A cursory Google will show that both of these are OpenVPN server addresses. We happen to use the VPN built in to the Firewall, but we've been using that for awhile now and it never triggered anything like this.

Has anybody else seen anything like this? Any other thoughts or suggestions? I can only run the same malware and virus scans so many times before it gets old. 



This thread was automatically locked due to age.
  • 0

    Is the alarm pointing at your dbs server?  If so, then it is probably a suspicious DNS lookup.

    In particular, UTM does this for any .tk lookup.   You have to enable DNS logging to find the DNS query initiator.

  • 0 in reply to DouglasFoster

    I was about to go turn it on when I realized it's already turned on.

    That's one thing I was thinking, though, that it might be a false positive DNS lookup. It was just odd because I googled the url that's been showing up as the destination and it's being reported as a known malware site.

    So I barely understand how to read any of this:

    2017:10:26-00:00:51 nkc_utm ulogd[8981]: id="2014" severity="info" sys="SecureNet" sub="packetfilter" name="DNS request" action="DNS request" 
    fwrule="60011" initf="eth0" srcmac="d4:ae:52:a0:69:7b" dstmac="00:1a:8c:4b:61:30" srcip="10.0.4.12" dstip="208.67.222.222" proto="17" length="109" 
    tos="0x00" prec="0x00" ttl="128" srcport="57108" dstport="53"


    The IP 208.67.222.222 shows up... 27,749 times in the latest log.

    Is it possible that since we use the VPN built in on our firewall (which uses OpenVPN) that this is just reporting our remote users almost constant connection to the server?

    And it's showing as connected to a bad site because whoever set that site up is using OpenVPN to try to cover their tracks?
  • 0 in reply to Lucas Villanueva

    Hi, Lucas, and welcome to the UTM Community!

    Doug's suggestion is what you need.  This is not a false positive.  Some device is asking your server to resolve a suspicious FQDN.

    You're confusing OpenVPN with OpenDNS.

    You might be interested in DNS best practice.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Thank you for that clarification - I had a feeling I was probably getting some things confused, but I wasn't 100% sure. I am working on adjusting our firewall rules to fit the DNS best practices, see if that helps at all.

    I was looking at the firewall log again and every DNS request for that particular destination IP looks pretty much the same as what I copied. I have Sysmon running on the server, and it's picking up when connections are being attempted, but that's about all the info I get... though that's probably because the Firewall ends up blocking it. I had thought initially that it must be on the server itself, but since it's a DNS query, is it always going to show from our DNS server, no matter what device is actually trying to make the connection?

  • 0 in reply to Lucas Villanueva

    Hey Lucas.

    You should be looking at the queries made to your internal DNS server by your endpoints, not at the UTM. UTM is just doing it's job and blocking the query as it transverses it. I assume you have an Active Directory domain setup and your internal DNS forwards requests to the UTM, right? If so, check this for instructions on how to enable logging/debugging at the internal DNS server. After enabling it, analyze the logs, find the origin and remove whatever malware its making the DNS requests and causing your ATP to react.

    Regards,

    Giovani

  • 0 in reply to giomoda

    That's correct. I will follow these instructions and see what I can find out. I'll post again if I find anything. Thank you!

  • 0 in reply to giomoda

    So here are a few examples of what I am seeing:

    Error - RESPONSE_FAILURE: TCP=0; InterfaceIP=10.0.4.12; Reason=System; Destination=10.0.4.1; QNAME=oiqbgenbchsss.com.; QTYPE=1; XID=35521; RCODE=2; Port=63546; Flags=33154; PacketData=0x8AC1818200010000000000010D6F69716267656E62636873737303636F6D00000100010000290FA0000080000000

    Error - RECURSE_QUERY_TIMEOUT: TCP=0; InterfaceIP=0.0.0.0; Destination=208.67.220.220; QNAME=oiqbgenbchsss.com.; QTYPE=1; XID=16617; Port=0; Flags=256; ServerScope=.; CacheScope=Default

    Information - RECURSE_QUERY_OUT: TCP=0; Destination=208.67.220.220; InterfaceIP=0.0.0.0; RD=1; QNAME=oiqbgenbchsss.com.; QTYPE=1; XID=3429; Port=0; Flags=256; ServerScope=.; CacheScope=Default; PacketData=0x0D65010000010000000000010D6F69716267656E62636873737303636F6D00000100010000290FA0000080000000

    The .12 is our internal server, the .1 is our firewall. I have not seen 0.0.0.0 before - a cursory Google search says it could be a number of different things. 

  • 0 in reply to Lucas Villanueva

    I also turned on DNS logging on the server and I'm trying to find it there... same thing, it's showing as either 10.0.4.1 or 208.67.220.220 or 208.67.222.222. I'm going to look into this again in the morning.

  • 0 in reply to Lucas Villanueva

    10/31/2017 7:27:53 AM 0AF4 PACKET 0000001935EDA0B0 UDP Rcv 10.0.4.1 ee9c Q [0001 D NOERROR] A (13)oiqbgenbchsss(3)com(0)
    UDP question info at 0000001935EDA0B0
    Socket = 516
    Remote addr 10.0.4.1, port 25872
    Time Query=2056206, Queued=0, Expire=0
    Buf length = 0x0fa0 (4000)
    Msg length = 0x002e (46)
    Message:
    XID 0xee9c
    Flags 0x0100
    QR 0 (QUESTION)
    OPCODE 0 (QUERY)
    AA 0
    TC 0
    RD 1
    RA 0
    Z 0
    CD 0
    AD 0
    RCODE 0 (NOERROR)
    QCOUNT 1
    ACOUNT 0
    NSCOUNT 0
    ARCOUNT 1
    QUESTION SECTION:
    Offset = 0x000c, RR count = 0
    Name "(13)oiqbgenbchsss(3)com(0)"
    QTYPE A (1)
    QCLASS 1
    ANSWER SECTION:
    empty
    AUTHORITY SECTION:
    empty
    ADDITIONAL SECTION:
    Offset = 0x0023, RR count = 0
    Name "(0)"
    TYPE OPT (41)
    CLASS 4096
    TTL 32768
    DLEN 0
    DATA
    Buffer Size = 4096
    Rcode Ext = 0
    Rcode Full = 0
    Version = 0
    Flags = 80 DO

    10/31/2017 7:27:53 AM 0AF4 PACKET 0000001935B9A190 UDP Snd 208.67.222.222 f162 Q [0001 D NOERROR] A (13)oiqbgenbchsss(3)com(0)
    UDP question info at 0000001935B9A190
    Socket = 17308
    Remote addr 208.67.222.222, port 53
    Time Query=0, Queued=0, Expire=0
    Buf length = 0x0fa0 (4000)
    Msg length = 0x002e (46)
    Message:
    XID 0xf162
    Flags 0x0100
    QR 0 (QUESTION)
    OPCODE 0 (QUERY)
    AA 0
    TC 0
    RD 1
    RA 0
    Z 0
    CD 0
    AD 0
    RCODE 0 (NOERROR)
    QCOUNT 1
    ACOUNT 0
    NSCOUNT 0
    ARCOUNT 1
    QUESTION SECTION:
    Offset = 0x000c, RR count = 0
    Name "(13)oiqbgenbchsss(3)com(0)"
    QTYPE A (1)
    QCLASS 1
    ANSWER SECTION:
    empty
    AUTHORITY SECTION:
    empty
    ADDITIONAL SECTION:
    Offset = 0x0023, RR count = 0
    Name "(0)"
    TYPE OPT (41)
    CLASS 4000
    TTL 32768
    DLEN 0
    DATA
    Buffer Size = 4000
    Rcode Ext = 0
    Rcode Full = 0
    Version = 0
    Flags = 80 DO

  • 0 in reply to Lucas Villanueva

    I'm not sure, but from these logs it appear the query is coming from your UTM to your internal DNS. Are you using your AD DNS as a forwarder on your UTM by any chance?

    Regards,

    Giovani

Unfiltered HTML