Tuesday, May 14, 2013

Domain: Directedat.asia



Lately I've been seeing some traffic for this directedat.asia domain. Normally it is not reported as an attack as it tends to stay under my 'attack' threshold, which is a x amount of request per y minutes.

What is in a domain name? directed at asia  -funny.
The IPs observed requesting / being attacked by this domain are mainly located in the Netherlands and a few have unconfigured web servers running.

Domain info:

Domain ID:D2608645-ASIA
Domain Name:DIRECTEDAT.ASIA
Domain Create Date:12-Apr-2013 03:21:04 UTC
Domain Expiration Date:12-Apr-2014 03:21:04 UTC
Domain Last Updated Date:03-May-2013 12:13:57 UTC
Last Transferred Date:
Created by:Internet.bs Corp. R176-ASIA (814)
Last Updated by Registrar:Internet.bs Corp. R176-ASIA (814)
Sponsoring Registrar:Internet.bs Corp. R176-ASIA (814)

The times that I did observe this domain and blogged about it was most likely manually. What I noticed to be odd was the low amplification my scripts calculate and I wonder why..

When looking at recent activity (http://dnsamplificationattacks.blogspot.nl/2013/05/nl-19216213762-as16265.html):

---------------------------------------------------------------------
Requested DNS record: directedat.asia
Query count: 9

Start: 2013-05-08 20:11:16
End: 2013-05-08 20:59:23
Duration: 48 minute(s)
Average query rate: 0.19 per minute

Detected a query rate below 1 per minute. Either a low query attack or there was a long break between bursts See chart for more details.

All request were made with the DNS id: 0xca0c
Average query size: 86 bytes
Average response size: 86 bytes
Amplification: 0%
--------------------------------------------------------------------------------


You can see a amplification of 0%. Not really effective now is it? So what does this domain name return when requested? Well as it runs out. A lot more than a 0% amplification. Check this dig query output on Pastebin: http://pastebin.com/2vdmzTGM

Wow that response contains about 260 values! Then why does my script only calculates a 0% amplification?

My server does not support TCP this port is not permitted and it is required as you can see:

dig any directedat.asia +edns=0
;; Truncated, retrying in TCP mode.

That is perhaps why my server teruns "Server failure" all the time. But in the pcaps I do see it receives 'some' values.

What I see:

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

1) I receive a spoofed DNS query for any directedat.asia from 192.162.137.62. (attacked ip)
src                        dst                     proto   len  desciption
192.162.137.62   192.168.10.37   DNS   86  Standard query ANY directedat.asia

2) I perform a DNS query to g.root-servers.net. for directedat.asia.
192.168.10.37 192.112.36.4 DNS 70 Standard query NS <Root>

3) Receive a response from the root server giving me the name servers for .asia:
192.112.36.4 192.168.10.37 DNS 753 Standard query response
Response records:
a0.asia.afilias-nst.info: type A, class IN, addr 199.19.55.1
a2.asia.afilias-nst.info: type A, class IN, addr 199.249.114.1
b0.asia.afilias-nst.asia: type A, class IN, addr 199.254.28.1
b2.asia.afilias-nst.org: type A, class IN, addr 199.249.122.1
c0.asia.afilias-nst.info: type A, class IN, addr 199.254.29.1
d0.asia.afilias-nst.asia: type A, class IN, addr 199.254.30.1
a0.asia.afilias-nst.info: type AAAA, class IN, addr 2001:500:d::1
a2.asia.afilias-nst.info: type AAAA, class IN, addr 2001:500:42::1
b0.asia.afilias-nst.asia: type AAAA, class IN, addr 2001:500:16::1
b2.asia.afilias-nst.org: type AAAA, class IN, addr 2001:500:4a::1
c0.asia.afilias-nst.info: type AAAA, class IN, addr 2001:500:17::1
d0.asia.afilias-nst.asia: type AAAA, class IN, addr 2001:500:18::1

4) I query d0.asia.afilias-nst.asia for any directedat.asia
192.168.10.37 199.254.30.1 DNS 86 Standard query ANY directedat.asia

5) Responds with authoritive name servers
199.254.30.1 192.168.10.37 DNS 624 Standard query response 9
Response Records:
directedat.asia: type NS, class IN, ns ns1.nitroushost.com
directedat.asia: type NS, class IN, ns ns2.nitroushost.com

6) I query f.root-servers.net for A/AAA ns2.nitroushost.com
192.168.10.37 192.5.5.241 DNS 90 Standard query A ns2.nitroushost.com
192.168.10.37 192.5.5.241 DNS 90 Standard query AAAA ns2.nitroushost.com
192.168.10.37 192.5.5.241 DNS 90 Standard query A ns1.nitroushost.com
192.168.10.37 192.5.5.241 DNS 90 Standard query AAAA ns1.nitroushost.com

7) Received response:
4 times the same.
192.5.5.241 192.168.10.37 DNS 785 Standard query response
a.gtld-servers.net: type A, class IN, addr 192.5.6.30
b.gtld-servers.net: type A, class IN, addr 192.33.14.30
c.gtld-servers.net: type A, class IN, addr 192.26.92.30
d.gtld-servers.net: type A, class IN, addr 192.31.80.30
e.gtld-servers.net: type A, class IN, addr 192.12.94.30
f.gtld-servers.net: type A, class IN, addr 192.35.51.30
g.gtld-servers.net: type A, class IN, addr 192.42.93.30
h.gtld-servers.net: type A, class IN, addr 192.54.112.30
i.gtld-servers.net: type A, class IN, addr 192.43.172.30
j.gtld-servers.net: type A, class IN, addr 192.48.79.30
k.gtld-servers.net: type A, class IN, addr 192.52.178.30
l.gtld-servers.net: type A, class IN, addr 192.41.162.30
m.gtld-servers.net: type A, class IN, addr 192.55.83.30
a.gtld-servers.net: type AAAA, class IN, addr 2001:503:a83e::2:30
b.gtld-servers.net: type AAAA, class IN, addr 2001:503:231d::2:30

8) I query h.gtld-servers.net for ns2 and ns1 .nitroushost.com in A/AAAA:
192.168.10.37 192.54.112.30 DNS 90 Standard query A ns2.nitroushost.com
192.168.10.37 192.54.112.30 DNS 90 Standard query AAAA ns1.nitroushost.com
192.168.10.37 192.54.112.30 DNS 90 Standard query AAAA ns2.nitroushost.com
192.168.10.37 192.54.112.30 DNS 90 Standard query A ns1.nitroushost.com

9) Receive response from h.gtld-servers.net:
192.54.112.30 192.168.10.37 DNS 713 Standard query response
Received Records:
eva.ns.cloudflare.com: type A, class IN, addr 173.245.58.114
eva.ns.cloudflare.com: type AAAA, class IN, addr 2400:cb00:2049:1::adf5:3a72
tim.ns.cloudflare.com: type A, class IN, addr 173.245.59.145
tim.ns.cloudflare.com: type AAAA, class IN, addr 2400:cb00:2049:1::adf5:3b91

10) I query tim.ns.cloudflare.com for ns1 ns2 .nitroushost.com in A / AAAA
192.168.10.37 173.245.59.145 DNS 90 Standard query A ns2.nitroushost.com
192.168.10.37 173.245.59.145 DNS 90 Standard query AAAA ns1.nitroushost.com
192.168.10.37 173.245.59.145 DNS 90 Standard query AAAA ns2.nitroushost.com
192.168.10.37 173.245.59.145 DNS 90 Standard query A ns1.nitroushost.com

11) Responses (combined):
173.245.59.145 192.168.10.37 DNS 95 Standard query response A 192.95.50.70
173.245.59.145 192.168.10.37 DNS 95 Standard query response A 192.95.50.69

12) query ns2.nitroushost.com for directedat.asia in any:
192.168.10.37 192.95.50.70 DNS 86 Standard query ANY directedat.asia

--- No response ---

13)  query ns1.nitroushost.com for directed.asia in any:
192.168.10.37 192.95.50.69 DNS 86 Standard query ANY directedat.asia

--- No response ---

- A few more attempts at both name servers but no luck.
My server responds with:

14 ) Server failure sent to spoofed IP:
src                      dst                     proto   len  desciption
192.168.10.37  192.162.137.62  DNS  86  Standard query response, Server failure

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

This was an interesting example of DNS recursion. 


After a few requests from the spoofed IP I observe a response from the name server:

Request and response ns1.nitroushost.com:
192.168.10.37 192.95.50.69 DNS 75 Standard query ANY directedat.asia
192.95.50.69 192.168.10.37 DNS 554 Standard query response SOA ns1.nitroushost.com NS ns1.nitroushost.com NS ns2.nitroushost.com A 204.11.52.232 A 204.11.52.233 A 204.11.52.234 A 204.11.52.235 A 204.11.52.236 A 204.11.52.237 A 204.11.52.238 A 204.11.52.239 A 204.11.52.240 A 204.11.52.241 A 204.11.52.242 A 204.11.52.243 A 204.11.52.244 A 204.11.52.245 A 204.11.52.246 A 204.11.52.247 A 204.11.52.248 A 204.11.52.249 A 204.11.52.250 A 204.11.52.251 A 204.11.52.252 A 204.11.52.253 A 204.11.52.254 A 204.11.52.255

The response is too big for one packet and my servers attempts but fails to fall over to TCP.

This results my server to respond for this domain with 'server failure'.
I think TCP 53 is blocked for all incoming packets including '--related'.

I will look in to this to see if I can participate in these attacks to see its amplification. Especially if the spoofed client IP will participate in a TCP handshake or not.

UPDATE:

Today I saw another 'attack' with this see HERE and noticed an amplification of 133%. Interesting.

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

Requested DNS record: directedat.asia
Query count: 19

Start: 2013-05-14 09:46:41
End: 2013-05-14 19:36:31
Duration: 9:49:00
Average query rate: 0.0322580645161

All request were made with the DNS id: 0x8f1c / 36636
Average query size: 86 bytes
Average response size: 200 bytes
Amplification: 133%

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


Looking at one of the query's in my pcaps, I see that my server retuns only the SOA and NS records for the domain, the old name server records for that matter.

New name server details:


#dig any directedat.asia @8.8.8.8

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> any directedat.asia @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44011
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;directedat.asia.               IN      ANY

;; ANSWER SECTION:
directedat.asia.        4510    IN      SOA     ns1.voidhost.net. support.voidhost.net. 2013051406 86400 7200 3600000 86400
directedat.asia.        4510    IN      NS      ns1.voidhost.net.
directedat.asia.        4510    IN      NS      ns2.voidhost.net.

;; Query time: 14 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue May 14 21:00:45 2013
;; MSG SIZE  rcvd: 125

No more 200+ response?

End of update


-------------------------------------------------------------------
Attacks and its origin
-------------------------------------------------------------------

It seems it is the same host that is performing these 'attacks'.. I concluded this by looking at the TTL values of all the IPs that requested directedat.asia.

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

01-May-2013_134.19.181.30
     79x 247
01-May-2013_50.7.190.60
     28x 247
04-May-2013_134.19.181.30
      3x 245
    179 247
      1x 55
      1x 57
05-May-2013_134.19.181.30
      8x 245
     81x 247
08-May-2013_192.162.137.62
     10x 245
09-May-2013_178.18.17.16
      2x 245
09-May-2013_192.162.137.62
      4x 245
10-May-2013_178.18.17.16
      5x 245
11-May-2013_188.95.48.25
      4x 245
25-Apr-2013_134.19.181.30
      4x 247
      1x 55
      1x 57
25-Apr-2013_89.248.160.192
     15x 247
      1x 56
26-Apr-2013_134.19.181.28
      2x 245
     27x 247
27-Apr-2013_134.19.181.28
      1x 247

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

I normally use the TTL value to determine if it is one host performing this attack. As a single stable TTL cannot realistically be spoofed.

The TTL of 247 seems the most common and is probably the main source of the attacks. What the other hosts are.. perhaps a bot or two? Who knows!
UPDATE: Seeing some activity for nukes.directedat.asia 511 A records in the response. All records are in the 172.33.44 and 172.33.43 range. The response exceeds the 1400 size limit for UDP and tries to fallback to TCP. But the attacked client obviously doesn't do this.

UPDATE:
MyDnsScan.Us is related to DirectedAt.Asia see this post: http://dnsamplificationattacks.blogspot.nl/2013/06/domain-mydnsscanus.html

Update 25/06/2013

Dongs.directedat.asia same name servers also 511 return records.


Update 11/07/2013

d.directedat.asia is being used. 256 A records in 172.33.43.x range. ~4115 response size.

UPdate 14/070/2013

f.directedat.asia is using 119 A records in the 172.33.43 range. ~1939 response size.



7 comments:

  1. 21 may 2013, 22 may 2013, Netherlands

    Getting many directedat.asia queries on our non-recursive DNS from many sources.

    Although recursive queries are denied, amplification still seems to be about 200% (wireshark out-bytes = 2 x in-bytes)

    Responses seem to go to many different ip-addresses.

    What could this be?

    ReplyDelete
    Replies
    1. Odd to see your non-recursive name server being used for these attacks. Seeing just a few 'discovery' queries every now and than is what I would expect to see.
      I am surprised by the size of these "recursion denied" packets. Did not think it would cause a 200% amplification.

      What you are seeing are IPs that are being attacked by whoever is spoofing those IPs. Essentially the same things I am blogging about here. Except that because I do reply recursively I am much more likely to be used in these attacks.

      Delete
  2. This attack has been saturating our pipe for a week. Finally got some rules on our upstream router to throttle the udp connections to 2 of our web servers. The udp was blocked by the firewall but by then it was too late. We are a school so this is my first experience with this type of thing.

    ReplyDelete
    Replies
    1. So you were on the receiving end of an attack like this?

      Delete
  3. Hey guys,

    This www.digitalgeneration.com website which claims to "pay" you 1$ per day to keep a thread running seems to be querying massively directedat.asia, by massively I'm talking about 19-24 queries every second.

    You aware of any of this?

    Cheers!

    ReplyDelete
  4. I had an email from rackspace saying my cloud server was causing these problems 5.79.20.25 - Am I able to add anything to windows firewall or is there and services I can stop to disable these attacks?

    This was a great article but a little over my head :-)

    Thanks in anticipation- Martin

    ReplyDelete
    Replies
    1. Hi Martin. I advice you to visit openresolverproject.org. Here you have a seach field that will show you that your server is an openresolver meaning it is participating in dns amplification attacks.

      Look up how to disable recursion on your type of dns server.

      Delete