[dns-operations] MX record scanning

Fri May 13 18:14:06 UTC 2011

.CA seeing the same pattern starting today at noon EDT.

bash-3.2# grep emwej19.ca named-queries.log
13-May-2011 14:00:15.703 queries: info: client 123.26.155.109#12123:  
query: emwej19.ca IN MX + (192.228.27.X)
13-May-2011 14:00:18.466 queries: info: client 123.26.155.109#12501:  
query: emwej19.ca IN MX + (192.228.27.X)
13-May-2011 14:00:23.293 queries: info: client 123.26.155.109#13166:  
query: emwej19.ca IN MX + (192.228.27.X)
13-May-2011 14:00:26.384 queries: info: client 123.26.155.109#13562:  
query: emwej19.ca IN MX + (192.228.27.X)
13-May-2011 14:00:26.951 queries: info: client 123.26.155.109#13630:  
query: emwej19.ca IN MX + (192.228.27.X)
13-May-2011 14:00:32.146 queries: info: client 123.26.155.109#14317:  
query: emwej19.ca IN MX + (192.228.27.X)
13-May-2011 14:00:33.564 queries: info: client 123.26.155.109#14493:  
query: emwej19.ca IN MX + (192.228.27.X)
13-May-2011 14:00:35.868 queries: info: client 123.26.155.109#14760:  
query: emwej19.ca IN MX + (192.228.27.X)
13-May-2011 14:00:38.341 queries: info: client 123.26.155.109#15116:  
query: emwej19.ca IN MX + (192.228.27.X)
13-May-2011 14:00:42.406 queries: info: client 123.26.155.109#15586:  
query: emwej19.ca IN MX + (192.228.27.X)
13-May-2011 14:00:45.748 queries: info: client 123.26.155.109#15969:  
query: emwej19.ca IN MX + (192.228.27.X)
13-May-2011 14:00:47.661 queries: info: client 123.26.155.109#16212:  
query: emwej19.ca IN MX + (192.228.27.X)
bash-3.2# grep emwej19.ca named-queries.log |wc -l
12

It's not just 12 queries.

It's 12 queries to each of the nameservers in our NS RRset, total 100+  
queries for the same record in the span of 32 seconds.

Has anyone considered setting up a bogus DNS server+mail server and  
using policy-routing to send queries from these confirmed botnet hosts  
to it, to give some visibility into what it's doing at a lower level?

-Jacob Zack
DNS Administrator - CIRA (.CA TLD)

On 12-May-11, at 3:17 AM, Rickard Dahlstrand wrote:

> Hi,
>
> We have also been tracking this for a while and made a simple SQL- 
> query that you can use with our new tool PacketQ to quickly get a  
> list of all IPs used by this botnet from a PCAP-file. Like Igor and  
> some of you noticed, the client doesn't set the transaction ID to a  
> value greater than 256 and this allows us to make the following  
> simple query.
>
> # packetq --csv -s "select stdev(msg_id) as  
> STDAV,src_addr,qname,count(*) as Antal from dns group by src_addr  
> having Antal>100 and STDAV<100 order by src_addr desc " peak/07/ 
> G.ns.se-20110408-071500-em1.pcap.gz  | less
>
> "STDAV"  ,"src_addr"       ,"qname"                  ,"Antal"
> 74.629547,"95.82.107.106"  ,"aupuj.se."              ,1669
> 73.147445,"95.81.86.43"    ,"xtade.se."              ,333
> 71.684573,"95.81.105.20"   ,"emxoh-sebmm.se."        ,336
> 72.573712,"95.59.74.229"   ,"rienm-pmok.se."         ,947
> 75.940259,"95.59.22.195"   ,"sicon.se."              ,185
> 73.950355,"95.56.83.96"    ,"csehm.se."              ,4280
> 75.612308,"95.182.54.17"   ,"ce.luth.se."            ,1573
> 74.628871,"95.177.13.34"   ,"osdmm.se."              ,3429
> 73.082288,"95.158.3.130"   ,"vmmre2003.se."          ,512
> 73.826874,"95.135.83.29"   ,"ismag.se."              ,4940
> 74.313821,"95.134.123.83"  ,"qcveb.se."              ,357
> 73.659671,"95.133.188.120" ,"0md7sma795xj.se."       ,2964
> 72.658138,"94.96.154.239"  ,"topesa.se."             ,516
> 73.737935,"94.59.57.23"    ,"pessa.se."              ,628
> 72.062089,"94.55.108.244"  ,"avoye.se."              ,416
> 73.018824,"94.141.66.136"  ,"sunma.se."              ,1831
> 73.814160,"93.73.26.41"    ,"tkobrlhcjq.se."         ,4496
> 74.263140,"93.187.166.1"   ,"hesmu2003.se."          ,4813
> .
> .
>
> PacketQ can be downloaded from https://github.com/dotse/PacketQ and  
> we have a mailing-list set up at http://lists.iis.se/mailman/listinfo/packetq 
>  for any PacketQ-related questions.
>
> Rickard.
>
>
>
> 11 maj 2011 kl. 21.53 skrev José A. Domínguez:
>
>> On 05/11/2011 12:27 PM, Gilles Massen wrote:
>>>
>>> Why has there to be an entity "in charge"? From an operational  
>>> point of
>>> view the CERT to whom you are affiliated would seem the right  
>>> choice. It
>>> might not have the resources to handle it, but should have the  
>>> contacts to
>>> forward it to a useful place (cf. the email from Tim, Team Cymru).  
>>> From an
>>> idealistic point I'd rather have law enforcement track down the
>>> spammers....that is the *only* effective manner.
>>>
>>> But the point I'm trying to make is that this is not a specific DNS
>>> problem: DNS is one little helper in the chain. At the end of the  
>>> day, the
>>> bot is sending a spam email and will get caught by a spamtrap.  
>>> Like the
>>> others that are not working on a poisoned list.
>>>
>>
>> I agree with your statements right now. Once thing that we should  
>> try to
>> get is forensics in some of the machines doing this query so we can  
>> figure
>> out which botnet (or botnets) we are dealing with and whether it is  
>> just
>> new service on top of some well-know botnets.
>>
>> José.
>>
>> <signature.asc>_______________________________________________
>> dns-operations mailing list
>> dns-operations at lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>> dns-jobs mailing list
>> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
>