[nsp-sec] rundll841.com wwwDOTwin496.com wwwDOTtag58.com err68.comandsysid72.com sqlinjection sites.
Smith, Donald
Donald.Smith at qwest.com
Thu Jun 5 13:44:58 EDT 2008
Security through obscurity WORKS against some worms and ssh attacks:)
Donald.Smith at qwest.com giac
> -----Original Message-----
> From: William Salusky [mailto:william.salusky at aol.net]
> Sent: Thursday, June 05, 2008 11:14 AM
> To: Smith, Donald
> Cc: nsp-security at puck.nether.net
> Subject: Re: [nsp-sec] rundll841.com wwwDOTwin496.com
> wwwDOTtag58.com err68.comandsysid72.com sqlinjection sites.
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hey Don,
>
> Responses inline. The short answer == yes, this is HydraFlux.
>
> | I assume you checked the IP addresses involved and
> validated this was
> | the hydraflux net?
>
> The IP addresses I've listed are involved as the upstream motherships
> themselves and management/monitoring nodes, they are not fluxnode
> endpoints themselves. You would not see any subset of those IPs
> advertised as A or NS records for any of the active flux domains.
Makes sense.
>
> | I assume this is in the drive-by category. Does that imply the sql
> | injection team has leased a portion of the hydra-flux network?
>
> I can't say with authority that any of the content types
> being serviced
> by this particular flux net is a leasing/rental arrangement, but the
> varying M.O's involved in content delivery seem to suggest that a
> leasing of flux services is involved. If you consider the overall
> design, management and dynamic reconfiguration capabilities of this
> fluxnet, It would be *criminally* underutilized if it were not
> specifically purposed to service the larger miscreant community. :/
>
> | I have not run a netflow report on the fast fluxed hosting
> addresses but
> | it might be interesting to see whom they are talking to
> besides port 80.
>
> If you do run flow for endpoints transiting your networks, you should
> see both TCP 80 (config checks) and TCP 4449 (flux content
> redirection)
Yes I am seeing 80 and 4449.
I also saw some 39428 -> 1460 tcp but that was between a single host and
an end node.
I don't think that is bot c&c coms.
> to the upstream motherships that are listed on the HydraFlux
> page. The
> most direct approach in flow reporting would be to pull flow
> solely for
> the mothership IPs. Perhaps you might find some interesting
> interactive
> control channels worthy of sharing. ;)
>
> Here's the active mothership list to shortcut your flow
> reporting needs!
>
> 'host 203.117.170.42 or host 216.150.79.226 or host
> 64.191.14.85 or host
> 64.191.39.85 or host 66.197.168.5 or host 66.197.216.229 or host
> 66.197.233.133 or host 66.199.241.98 or host 66.232.102.169'
I am seeing 66.232.102.169, 216.150.79.226, 203.117.170.42, and
66.199.241.98 communication on 4449 to the end nodes.
Do you see any reason not to take action against those IP addresses?
>
>
> Looking at the round-robin on rundll841.com:
>
> rundll841.com. 600 IN A 87.205.169.60
> rundll841.com. 600 IN A 79.185.9.66
> rundll841.com. 600 IN A 82.143.130.48
> rundll841.com. 600 IN A 84.121.222.104
> rundll841.com. 600 IN A 83.8.41.4
> rundll841.com. 600 IN A 77.91.20.173
> rundll841.com. 600 IN A 83.242.74.153
> rundll841.com. 600 IN A 156.17.227.155
> rundll841.com. 600 IN A 85.60.114.1
> rundll841.com. 600 IN A 83.11.157.206
> rundll841.com. 600 IN A 78.92.72.81
> rundll841.com. 600 IN A 12.207.206.75
> rundll841.com. 600 IN A 83.24.137.250
> rundll841.com. 600 IN A 78.130.145.225
>
> ;; AUTHORITY SECTION:
> rundll841.com. 172800 IN NS ns2.rundll841.com.
> rundll841.com. 172800 IN NS ns3.rundll841.com.
> rundll841.com. 172800 IN NS ns1.rundll841.com.
> rundll841.com. 172800 IN NS ns4.rundll841.com.
>
>
> You can fingerprinting the HTTP redirect behavior of any live
> fluxnodes
> demonstrating the same nginx version, 'ETag' hash, last modified
> date/etc... (do this based on content known to be actively served in
> this fluxnet... details.aspx is phish related)
>
> $ HEAD http://84.121.222.104/details.aspx
> 200 OK
> Connection: close
> Date: Sun, 06 May 2007 02:43:05 GMT
> Accept-Ranges: bytes
> ETag: "108140-1f6b-44dcc616c5780"
> Server: nginx/0.6.31
> Content-Length: 8043
> Content-Type: text/html; charset=UTF-8
> Last-Modified: Thu, 22 May 2008 07:08:30 GMT
> Client-Date: Thu, 05 Jun 2008 16:52:00 GMT
> Client-Peer: 84.121.222.104:80
> Client-Response-Num: 1
>
> $ HEAD http://87.205.169.60/details.aspx
> ^[[6~^[[6200 OK
> Connection: close
> Date: Sun, 06 May 2007 02:38:44 GMT
> Accept-Ranges: bytes
> ETag: "108140-1f6b-44dcc616c5780"
> Server: nginx/0.6.31
> Content-Length: 8043
> Content-Type: text/html; charset=UTF-8
> Last-Modified: Thu, 22 May 2008 07:08:30 GMT
> Client-Date: Thu, 05 Jun 2008 16:47:39 GMT
> Client-Peer: 87.205.169.60:80
> Client-Response-Num: 1
>
>
> Worth noting is that the nginx server version reports differently when
> checking against the base index versus actual URI paths configured in
> the <hls> section for redirection to the motherships determined by the
> <s> config chunk. If I get a chance to confirm I will, but
> the generic
> nginx/0.5.33 Server: value may simply be built into the
> fluxnode client
> for responses to default content paths that are NOT configured in the
> <hls> config section.
>
> $ HEAD 87.205.169.60
> 200 OK
> Connection: close
> Date: Thu, 05 Jun 2008 16:37:21 GMT
> Accept-Ranges: bytes
> ETag: "10816a-5d-44e691ba25a40"
> Server: nginx/0.5.33
> Content-Length: 93
> Content-Type: text/html; charset=UTF-8
> Last-Modified: Fri, 30 May 2008 02:07:29 GMT
> Client-Date: Thu, 05 Jun 2008 16:38:10 GMT
> Client-Peer: 87.205.169.60:80
> Client-Response-Num: 1
>
> $ HEAD 79.185.9.66
> 200 OK
> Connection: close
> Date: Thu, 05 Jun 2008 09:41:51 GMT
> Accept-Ranges: bytes
> ETag: "10816a-5d-44e691ba25a40"
> Server: nginx/0.5.33
> Content-Length: 93
> Content-Type: text/html; charset=UTF-8
> Last-Modified: Fri, 30 May 2008 02:07:29 GMT
> Client-Date: Thu, 05 Jun 2008 16:38:21 GMT
> Client-Peer: 79.185.9.66:80
> Client-Response-Num: 1
>
>
> If you dig against any of the NS records, you see consistent
> delivery...
>
> ;; ANSWER SECTION:
> ns2.rundll841.com. 600 IN A 66.233.229.99
> ns2.rundll841.com. 600 IN A 86.16.211.245
> ns2.rundll841.com. 600 IN A 62.121.110.4
> ns2.rundll841.com. 600 IN A 68.202.106.222
> ns2.rundll841.com. 600 IN A 77.253.254.126
> ns2.rundll841.com. 600 IN A 217.28.146.253
> ns2.rundll841.com. 600 IN A 75.137.93.12
> ns2.rundll841.com. 600 IN A 71.59.102.113
> ns2.rundll841.com. 600 IN A 79.184.58.105
> ns2.rundll841.com. 600 IN A
> 172.170.167.178 <- Heh!
> ns2.rundll841.com. 600 IN A 89.228.212.197
>
>
> You can fingerprint HydraFlux's wildcard DNS behavior through *any* of
> the fluxnode endpoints regardless of whether they are
> advertised solely
> as the A record or NS auth record round-robin, or not
> advertised at ALL
> but are known entities from recent history of dns monitoring that you
> might have in place.
>
> 'blah.poop.com' is NOT a flux domain, but as you see by this arbitrary
> request issued to one of the flux node endpoints, they service any
> inbound NS request as dictated by the last fluxnode forum.php config
> update defined in the <d_n> section.
>
> $ dig blah.poop.com @66.233.229.99
>
> ; <<>> DiG 9.2.4 <<>> blah.poop.com @66.233.229.99
> ; (1 server found)
> ;; global options: printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49504
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 15, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;blah.poop.com. IN A
>
> ;; ANSWER SECTION:
> blah.poop.com. 600 IN A 79.185.9.66
> blah.poop.com. 600 IN A 99.194.80.27
> blah.poop.com. 600 IN A 76.97.50.172
> blah.poop.com. 600 IN A 78.92.72.81
> blah.poop.com. 600 IN A 83.242.74.153
> blah.poop.com. 600 IN A 83.11.157.206
> blah.poop.com. 600 IN A 79.184.189.79
> blah.poop.com. 600 IN A 91.192.58.61
> blah.poop.com. 600 IN A 78.130.145.225
> blah.poop.com. 600 IN A 82.143.130.48
> blah.poop.com. 600 IN A 156.17.227.155
> blah.poop.com. 600 IN A 84.121.222.104
> blah.poop.com. 600 IN A 77.91.20.173
> blah.poop.com. 600 IN A 83.8.41.4
> blah.poop.com. 600 IN A 83.24.137.250
>
> ;; Query time: 67 msec
> ;; SERVER: 66.233.229.99#53(66.233.229.99)
> ;; WHEN: Thu Jun 5 09:40:24 2008
> ;; MSG SIZE rcvd: 271
>
>
>
>
>
>
> - --
>
> William Salusky
> william.salusky at aol.net
> Sr. Technical Security Investigator - AOL Operations Security
> 703-265-4924 (desk)
> 703-201-8873 (cell)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (Cygwin)
>
> iD8DBQFISB7VXyx2ON3+G40RAj5NAJ9KWElXkNDEqm3BuTL0IvhJSKXpnwCdEUO6
> phRGMha1GKIZUnAoq8BSMPg=
> =fDp2
> -----END PGP SIGNATURE-----
>
This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.
More information about the nsp-security
mailing list