• Support
  • Forums
  • Blogs

Multiple Alarms for Sinkhole Anubis This Week

owl06owl06

New Life Form
+1
edited August 2017 in Open Threat Exchange (OTX) > General
Hi all,

We've been seeing alarms for C&C activity for days now, which is appearing both on Windows laptops and some Android BYOD devices. It involves: 
195.22.26.248 Spamming

The domain in question is ust-af.com, which our firewall blocks. It's all happening over Port 90 and 443 (SSL).

This must be a false positive. Nobody is clicking anything on phishing emails, people aren't visiting rogue web sites (and aren't all using IE), antivirus turns up nothing, and it involves multiple unrelated platforms. Is anyone else seeing this recently? Was there a bad pulse that flagged legit domains?

Regards,

David
Sandra

Share post:

Comments

  • The formatting on this BBS is awful. How do I fix it? WYSIWYG didn't look anything like the post above.
    austxjrAaron1616
  • Hi There,

    We too are experiencing the same in one of our client's environments. We're received multiple alarms of this nature every day for the last week, all of which are for different work stations. We've located the potentially infected machines, taken them offline and run scans on them with a range of different tools, the results always come back clean. We would love to know what is triggering this.
    owl06t001z
  • We are having the same issue. It is trigered multiple times a day always in diferent ip's and users. We have checked all the laptps with scans but we got nothing.

    Did anyone find a solution? We have no idea what it could be.
    owl06
  • So I've been seeing this for about a week now and it's driving me insane as well. I pulled ten minutes prior to the alarms from the SIEM on 15 different hosts last Thursday. I noticed that within 10 minutes of the alarm they all visited IP addresses on the 69.172.216.0/24 block. two of them being .111 and .55 which are also in the OTX. After a little research I had found more info that those IP addresses are owned by integral ad inc. and have been known for their stuff to get compromised.

    My theory (and only a theory), This integrated advertising service is compromised and when users are just surfing the web and come across a site with the compromised ads, it redirects to 195.22.26.248 which are being caught by my external firewall. 

    I could very well be wrong, I'm just basing this on what I know about waterholes and that these hosts with alarms have in common as far as traffic. It would explain why it's completely random considering we have over 600 workstations across 35 sites and have had probably a max amount of 20 of these alarms per day. Also it is never just one site across the board, we could have one or two from one site, one or two from another, and so on. 

    Hope this helps?!
    ashleighlowl06Sandradgrant001zcrober
  • I have been seeing the same as well, and tend to agree with avjonah (above) .  I have also looked at the traffic just before this detection and believe it is advertising related as well.  In my searches, I've seen a fair amount that I believe are advertising related also. I believe most of mine are stemming from subnet 61.213.187.128/25 (Geniee) who is a "Google certified publishing partner" or an affiliated advertiser.  I've also seen a common trends of contact with Google (this could be common to everyone), contact with Geniee just before and after the alert fires.  Seems to be common to all we are seeing.  

    It tends to correlate when people are browsing.   


    owl06
  • Hello, we are also affected by connections to the ust-af.com domain from different pcs (Windows environment). The connections are always in the outgoing direction on port 80 and 443 and it seems that for the hours the behavior was reproduced at the users logon.

    We have blocked the IP in the proxy and we have passed McAfee Antivirus and Malware Antimalware on the computers without detecting any infection.


    The domain ust-af.com was created on July 7, 2017 and the first connection was made on day 8.

    We are discussing the possibility that it is something related to the navigation or the mail, or the possibility of being a Botnet since the alert of Alienvault catalogs the IP 195.22.26.248 like Command and Control Sinkhole Anubis.The discovery of a C & C (command and control) Server makes it possible to redirect DNS requests for that server to a law enforcement computer or other analyzing machine. The specially configured DNS server can simply route the requests of the bots to a faked C & C server, where the requests provide information to researchers about the nature of the botnet. And common ports are 80 and 443 in a CnC https://attack.mitre.org/wiki/Command_and_Control

    Let's see if anyone can give us more light on this matter.

    Best regards!
    t001z
  • edited July 2017
    I'm also seeing a large influx of these ust-af[.]com anubis sinkhole alarms since 7/7/17 across several environments. Anubis sinkholes aren't new to us, but because of how prevalent this one seems to be in particular, I was thinking that it must be related to an ad on a common/high traffic website, but I can't find anything to confirm that theory. No adware/PUP is detected when doing various endpoint scans either. It seems to correlate with browsing activity as outbound web traffic for the endpoint at the exact time has revealed a lot of ad based web
    traffic to openx[.]org, adnexus[.]net, doubleverify[.]com, sync.1rx[.]io, 8.41.222[.]241, and
    sync.rhythmxchange[.]com. 

    Someone commented on this in OTX suggesting that it was an ad hosted on www.whitepages[.]com, but I cannot find anything to confirm that. 

    avjonahSandra
  • I'm glad it's not just me. Been flipping out on this one for days and have even pulled some machines and we're doing forensics with no results so far. See my list of associated IPs in my comment here: https://otx.alienvault.com/indicator/ip/195.22.26.248 ; Yes, the one that's formatted incorrectly should end with a fourth octet of .0.

    94.42.166.230 is always associated within the same second of network traffic with 195.22.26.248.

  • I too noticed the 94.42.166[.]230 IP, which is also related to one of the ad domain I mentioned above (rhythmxchange)

    94.42.166.230 60379 80 op="GET"
    dstname="delivery.clickonometrics.pl" arg="/rhythmxchange/set-cookie?uid=[RX_UUID]&randcb=4710962451"  geo_dst="POL"  (HTTP-proxy Out-00) 
  • I'm on the same boat. Our Fortigate web filter reported a few of these ust-af.com hits. Wondering if there are any specific actions recommended to take on top of adding that domain to web filter.
  • The ust-af.com domain and the 92.42.166.230 IPs are both related to the rhythmxchange ad network, which is why we see sync.1rx.io, 8.41.222.241, and
    sync.rhythmxchange.com associated as related traffic.  
    7-18-2017 9-27-58 AM

    Each that I've seen have an "&randcb=" at the end of the URL. Searching for that string on urlscan reveal a few more:

    There are many referring websites too including twitter and google. What is different about the ust-af.com domain and the others? Nothing that I can tell. They are both advertisement related except ust-af.com was sinkholed and others haven't been. 


    BF
  • Difference is ust-af.com is triggering alarms and google and twitter are not lol
  • Kyle, go to the urlscan.io and you can see some of the referrers. i.e. the sites that are hosting ads. Such as twitter static ads and google adsense. These ads that i'm talking about are associated with rhythmxchange as they all have &rand= at the end. I have hundreds of examples. If you  have web filtering logs in your USM, try doing a search for payload "&rand=" and you'll see countless examples of these ads. What's the difference between all of those that you aren't alarming on and the ust-af.com domain? There is no difference except ust-af.com was sinkholed and is now throwing up alarms. Block the ads and the alarms will go away.
    KyleKat
  • edited July 2017
    This has been driving me a bit crazy the last several days.  The alarms I'm seeing are all due to user browsing activity and happen when our DNS server tries to resolve ust-af.com or another domain in the 195.22.26.0/24 address block.  Checking on what the users are doing, it seems simply browsing news sites like www.chicagotribune.com can produce these.  Directive "AV Malware, the DNS server replied with a sinkhole address, infected host resolving a CnC domain - Anubis Sinkhole" is looking for "|00 04 c3 16 1a|" which is "195.22.26".  That's part of the 195.22.26.192/26 address block that's registered in Portugal.  I've not been able to find any actual malware.  Checking URLvoid.com shows that only Fortinet views ust-af.com as malicious.  I'm treating these as false positives, but blocking all traffic to that address block.
    KyleKatdgran
  • Thanks for the additional insights given here.  I too have seen many of these and also haven't been able to find any infection on workstations.  I've gone the route of blocking the traffic.
  • edited July 2017
    I have been seeing similar traffic ongoing in my environment with dozens of users. After analyzing all of the traffic from my web gateway and SIEM, I am inclined to agree with most here that it is from an infected malicious ad campaign. 

    I have seen this alert being triggered after people access large/popular websites such as Expedia, Travelocity, ESPN, MLB, etc.

    After scanning PC's and analyzing them, I see nothing malicious ongoing. Hopefully we can get some closure soon.
  • Well I've finally called stand down at this point. We have a bunch of the associated networks blocked at the firewall now and have yet to find any creepy artifacts during our forensics. No hits on any hashes associated with this main .248 IP and no AV hits. Still, I'm personally uneasy about this and will keep watching like a hawk.

    Did we block too many IPs at the firewall? Maybe, but sounds like a service to the community as web ads are the worst thing ever created.
  • I'm still evaluating web filtering so I'm just blocking this IP. I'll see how many Firewall Deny alarms pop up and i'll just temporarily modify the directive until I get my web filtering straightened out. Thank you everyone for contributing to this thread and it's great that our community could help each other out. 


    crober
  • I agree, this community has been a huge help with this issue. I already have a few more alerts today that look once again to be ad related. I just wish we could figure out why this specific ad is being flagged as malicious...
  • I did the following to figure out what common IP addresses these hosts were navigating to was this. I went to Analysis > Security Events (SIEM) and filtered that src IP of the host for the alarm, and Datasources (this could be different for you) was our firewall. From there I filtered the time to about 10 minutes prior and 5 minutes after and exported a CSV file. I uploaded a csv file to a linux box (in my case it was Kali) through sftp and used grep -R -B 20 195.22.26.248 to query all the csv for that value. The -B prints out the 20 lines before that. You'll get a lot of data and the line containing 195.22.26.248 will have some html in there. You can use regular expression to parse out the html like this:

    [email protected]:~/path/to/files grep -B 20 -R 195.22.26.248 | sed 's/<a.*a>//'

    I used some regex in different ways to massage the data in a readable format so I can analyze it and come up with similarities.  Hope this helps.

    vthelpdesk
  • the general consensus is that these are ADs and i agree 100%, every sign i see indicates the same thing. as to the reason why it comes up as an alarm is that the IP block these adds point to has been sinkholed.

    whats happening is that when your users are surfing the web, (a multitude of sites like amazon, espn.... have been identified), a page they are on contains these ADs which initiates a connection to the sinkholed address block, the reason there is nothing found when you scan the workstations is because the connection was never established (sinkholed). 

    if you look in config/threat intel/ directives and search for anubis or seach in datasouces/nids (1001) and search for anubis you will find that any reply from 195.22.26.192/26 will create an anubis alarm. your more than welcome to dig deeper and if anyone else finds out more information please update us!! but for those that need a quick break from the current alarms you can go ahead and try blocking the domain "ust-af.com" at the firewall level.  this appears to be the specific domain that has been sinkholed.
  • Perhaps I am misunderstanding that once we have a user browsing to a web that is serving this malicious ad, it then "attempts" to connect the malicious ust-af domain. However, when you say it is sinkholed and therefore we will never see a connection, could you explain further? Perhaps I am completely misunderstanding the sinkholing functionality behind this.
  • Well at least I am in good company.  I have seen these appear over the last few days and have gone the route of pulling machines off network, scanning and finding nothing.  All of my traffic is going to a single IP address (195.22.26.248) which I have blocked all access to at egress points.  I guess I will wait for further guidance and information.
  • @titansprotect19 so say we have a domain in this case ust-af.com with the ip 192.168.1.45, when it is "sinkholed" it means that this domain has been flagged as malicious and taken over by a service. whenever a device on your network requests the address of ust-af.com instead of the DNS servers responding with 192.168.1.45 they respond with 195.22.26.248. 

    your device attempted to connect to the ust-af.com domain but was instead redirected to 195.22.26.248, it was never able to establish a connection to the ust-af.com domain and therefore should not have the potential virus contained at Ust-af.com

    @t001z blocking 195.22.26.248 isnt likely to stop the alarms your getting. as long as AV sees this IP the alarm will be triggered. that can be from NIDS or firewall syslogs. if you have fortigate you will see in your logs thats its already being blocked.
    KyleKatWardSOCt001z
  • edited July 2017
    look into your dns query logs. you are logging those aren't you....haha your DNS servers may not log all queries as I found out. you may have to go to the pcaps.

    you may see domains such as bttrack[.]com being requested. If you resolve that it resolves to 64.38.119.27. The workstations will then turn around and request the reverse dns lookup, yes they will request to resolve 64.38.119.27. It is this request and others in the same network that are triggering this alert. Meaning there are other URLs that could also trigger it.

    What is happening:
    1. user visits website that uses service such as bttrack[.]com(could be others)
    2. that resolves to 64.38.119.27
    3. workstation does the reverse lookup to your DNS server
    4. your DNS server reaches out to resolve from root dns servers
    5. root DNS server replies with another NS for where to look
    6. your DNS server makes another request for the address to the NS that the root replied with
    7. that DNS server is replying with another NS to request but that name server is in the sinkholed domain
    8. your DNS server makes same request to that sinkholed domain name server..
    9. then your alert triggers on your DNS server request

    You will likely need a sniffer trace/tcpdump from your DNS server to see this. Also you may be able to look at the cache of your DNS for that reverse request and likely see those domains there.

    the domains NS records that caused the alert trigger were ns[.]controlgaming[.]net or something like that.

    Keep in mind if you do an nslookup or host on that such as:
    host 64.38.119.27 

    It will fail to resolve. It is the requests that your DNS server is making in the background....

    This could be cleaned up by now too....
  • edited July 2017
    This traffic come from ads on various different sites. 
    The IP 195.22.26.248 belongs to AnubisNetwork, where it looks like the ISP decided to sinkhole this IP due to it's horrible web reputation.

    This traffic is generated by a web-browser, not some kind of RAT or bot. 
    ust-af.com is harmless as long as the domain / IP stays sinkholed, but I'd still blacklist it in my firewall.

    GET /rtmn_us.gif?redir=RX-293acecf-dafd-4391-98de-7f3db423a583&randcb=7872916072 HTTP/1.1

    Accept: image/png, image/svg+xml, image/jxr, image/*;q=0.8, */*;q=0.5

    Accept-Language: nb-NO
    User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko

    Accept-Encoding: gzip, deflate

    Host: ust-af.com

    Connection: Keep-Alive



    GET /rtmn_us.gif?redir=RX-013656c1-810a-4a9c-88b7-a4a6be7ccb9f&randcb=4985829854 HTTP/1.1

    Accept: image/png, image/svg+xml, image/jxr, image/*;q=0.8, */*;q=0.5

    Referer: http://www.liverpoolecho.co.uk/sport/football/football-news/andy-robertson-liverpool-milner-injury-13379127

    Accept-Language: nb-NO

    User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko

    Accept-Encoding: gzip, deflate

    Host: ust-af.com

    Connection: Keep-Alive


    Hope this helps


    - Eplox

    JS309
  • Is anyone now seeing a similar web address along with the UST-AF such as (http://sync.rx.us-east.zenoviaexchange.com)? I have seen a few of these pop up when an alert for the sinkhole is occuring. It looks like a compromised website.
  • edited August 2017
    I reached out to AnubisNetworks and asked about UST-AF.  Here's their response.

    ----------------------------

    Hi Josh, 

    At this point the ust-af.com domain is not categorised as malicious and we believe it is Ad related. If that changes I will let you know.

    There
    is a miss understanding on the security community regarding our catchall
    sinkhole 195.22.26.248, some rules from the ET ruleset and maybe others tag it
    as a general malware sinkhole - it’s not. We use that IP address for a lot of
    other stuff besides malware and sometimes we pick and register domains based on
    traffic patterns that are not malicious but interesting enough for us and point
    these to the same catchall for analysis. 

    If
    the domain under research is not malicious it stays on that IP address, with
    others that could be malicious but are still on queue for human analysis. If
    the domain is malicious proper categorisation and documentation is done and
    they start to resolve to our malware-related sinkholes.

     ----------------------------------------------------------------------------

    WardSOCrdiethKyleKatTDowns
Sign In or Register to comment.