[Emerging-Sigs] Question about ET TROJAN DNS Reply Sinkhole - Anubis - 126.96.36.199/26 -- Likely FP but for a different reason?
joao.gouveia at anubisnetworks.com
Mon Jul 17 10:34:59 EDT 2017
Just to clear up this topic: This is indeed one of our Sinkholes.
We run sinkholes on multiple address spaces, and the one mentioned on this
thread (188.8.131.52/26) is primarily used for on going investigations
within the context of our Labs threat research team.
This means that often there will be plenty of perfectly legitimate domains
sinkholed to this network address, that end up not being related to malware
If you have traffic hitting this address space, that should definitely
raise a flag, but be aware that often it isn't going to be related to
HTML/JS for the specific purpose of collecting browser metadata ( such as
versions, plugins, etc. ) that can be helpful to support investigations.
Obviously, there's nothing malicious about those files.
On Thu, Jul 13, 2017 at 10:36 PM, Jason Williams <
jwilliams at emergingthreats.net> wrote:
> I don't believe so,
> Anubis Networks sinkholes many domains and are not "the bad guys". If you
> have a host on the inside beaconing to a sinkholed host, this means your
> communicating host *may* (TM) be compromised and reaching out to a domain
> which Anubis has sinkholed or taken away from the actual bad guys. When
> they sinkhole a domain, they work with the dns hosting company to change
> the ip address the malicious domain resolves to one that anubis owns in the
> subnet referenced in this rule. Because we know the range Anubis uses for
> sinkholing, we provide this signature to inform you that you have a host
> communicating with a sinkholed host.
> As to the file in question, that's a question for Anubis as the activity
> sources from their IP space. My guess is that someone / some script in
> Anubis IP space uploaded the file to VT in 2015.
> [image: Inline image 1]
> Both domains referenced in the file point to Anubis IPs.
> IMO, this is not a reliable sample to consider Anubis to be serving up
> malware, but you could always hit them up and find out what the deal is.
> You're not alone in finding these rules confusing, a bit of googling turns
> up similar threads.
> On Thu, Jul 13, 2017 at 3:49 PM, <emerging-sigs at zestysoft.com> wrote:
>> Please don't give up on me yet.. I'm almost there I promise. I'm sure I'm
>> not the only one confused about this. I'm trying to be as verbose as
>> possible when reasoning all of this out.
>> So that IP block's reverse delegation is controlled by anubisnetworks
>> That reverse delegation was likely how the original rule creator came up
>> with the IP block. This clears up a lot of my confusion. Thank you.
>> However, I'm still not clear on the rest.
>> I think this is where I fell off the rails: When I visited
>> www.anubisnetworks.com, I saw a website about an email protection
>> service. I assumed this meant these are the good guys and that they also
>> provide a dns-sinkhole service to the public. Thus the title of the rule:
>> "DNS Reply Sinkhole - Anubis"
>> That meant that somehow anibusnetworks was replacing the real IP address
>> of that ust-af.com site with one of their own -- good. However, I
>> couldn't wrap my head around the fact that the IP address their service is
>> returning is also known to serve bad stuff. That seems to be doing the
>> opposite of what a sink-hole service is supposed to do -- it's protecting
>> you from one bad type of traffic by replacing it with another. I'm basing
>> this assumption that they are returning bad traffic based on the url you
>> provided: (https://www.virustotal.com/en/ip-address/184.108.40.206/info
>> Stuff like:
>> Latest detected files that were downloaded from this IP address
>> Latest files that are detected by at least one antivirus solution and
>> were downloaded by VirusTotal from the IP address provided.
>> 1/57 2015-10-26 16:02:23 2e89848ec69bdd20a33c3a9239d0a1
>> So here's my attempt to get back on the tracks:
>> I /think/ what is really going on is that AnubisNetworks are (for a big
>> chunk of that IP block) the bad guys. They don't provide a sinkhole
>> service. There is merely this ET rule that suggests that if it triggers,
>> you're getting traffic from the evil anubisnerworks and that you should
>> take additional steps to somehow sinkhole this traffic yourself.
>> Please tell me I'm close.
>> On 7/13/2017 12:54 PM, Will Metcalf wrote:
>> >That's just it though -- it's /not/ an Anubis sinkhole.
>> Yes it is.
>> nslookup 220.127.116.11
>> Server: 127.0.0.1
>> Address: 127.0.0.1#53
>> Non-authoritative answer:
>> 248.26.22.195.in-addr.arpa canonical name =
>> 248.192/18.104.22.168.in-addr.arpa name = anubisnetworks.com.
>> >I cannot find any indication that ns1.csof.net is controlled by
>> Not a requirement for sink-holing a domain.
>> >There are other exempted domains in the rule that are examples of other
>> domains that should not be classified this way too, but yet still exist in
>> that IP block.
>> They are Anubis run domains served out of the same block.
>> >If you were setting up a dns black-hole, would you resolve to real ip
>> addresses that you don't own and that are actively sending malvertisements?
>> ......???????....... So that people wouldn't be served malverts, or
>> whatever terrible thing was being hosted on this domain, take stats on
>> geo-spread of ip's, referring sites, etc to get scope of campaign?
>> > This whole rule is nonsense.
>> If you are so sure it's nonsense, disable it. imho this would be a
>> mistake. I'm done with this thread... If we haven't convinced you already
>> we probably wont' be able to do so.
>> On Thu, Jul 13, 2017 at 2:17 PM, <emerging-sigs at zestysoft.com> wrote:
>>> That's just it though -- it's /not/ an Anubis sinkhole. I thought I did
>>> a thorough job investigating this. I cannot find any indication that
>>> ns1.csof.net is controlled by AnubisNetwork. ns1.csof.net is the DNS
>>> server for ust-af.com, and that DNS server returns 22.214.171.124. This
>>> is not an example of Anubis's DNS servers returning that IP address, or
>>> some security software substituting the real IP address with that one.
>>> There are other exempted domains in the rule that are examples of other
>>> domains that should not be classified this way too, but yet still exist in
>>> that IP block.
>>> The IP block in this rule wasn't sanctioned by or maintained by
>>> AnubisNetworks, it was arbitrarily created by the person who created that
>>> 2014 thread. Two posts later in that thread, this was uncovered, however
>>> for whatever reason the rule stuck -- likely because it was a quick fix for
>>> the trojan threat at that time.
>>> If you were setting up a dns black-hole, would you resolve to real ip
>>> addresses that you don't own and that are actively sending
>>> malvertisements? This whole rule is nonsense.
>>> The Virustotal results certainly show that the /IP address/ has been
>>> questionable, however that doesn't mean a) Anubis was involved, b) that a
>>> Trojan is also involved, or that c) the bad stuff ever came from
>>> A reverse lookup of that IP address shows a TON of other domains point
>>> to that IP address:
>>> So either "evil" controls the IP address, some how yougetsignal.com
>>> only has results from Anubis networks DNS servers, or there is a hosting
>>> company that isn't doing much to police their traffic.
>>> Instead (or in addition to?) this IP address should be put into a low
>>> reputation ip ruleset because that would be a much better indicator about
>>> the type of traffic we're dealing with.
>>> On 7/13/2017 10:13 AM, Will Metcalf wrote:
>>> %s:/doomed to fail/working as expected/g
>>> It's an Anubis sinkhole.. if you need 3rd party public validation...
>>> Generally if you see this trip in your env you have some investigating
>>> to do... My guess is that this was malvert domain.
>> Emerging-sigs mailing list
>> Emerging-sigs at lists.emergingthreats.net
>> Support Emerging Threats! Subscribe to Emerging Threats Pro
> Emerging-sigs mailing list
> Emerging-sigs at lists.emergingthreats.net
> Support Emerging Threats! Subscribe to Emerging Threats Pro
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 87942 bytes
Desc: not available
More information about the Emerging-sigs