[nsp-sec] rundll841.com wwwDOTwin496.com wwwDOTtag58.com err68.comand sysid72.com sqlinjection sites.
White, Gerard
Gerard.White at aliant.ca
Thu Jun 5 14:10:46 EDT 2008
Bonus Info:
Two major incarnations on the go:
FIRST INCARNATION:
POST /forum_asp.php HTTP/1.1
...
Content-Type: multipart/form-data; boundary=FiElDBoUnDaRy
SECOND INCARNATION:
POST /forum.php HTTP/1.1
...
Content-Type: multipart/form-data; boundary=1BEF0A57BE110FD467A
Most Excellent Post, Mr. Salusky...
GW
855 - Bell Aliant
> -----Original Message-----
> From: nsp-security-bounces at puck.nether.net
[mailto:nsp-security-bounces at puck.nether.net] On Behalf Of
> William Salusky
> Sent: Thursday, June 05, 2008 2:44 PM
> To: Smith, Donald
> Cc: nsp-security at puck.nether.net
> Subject: Re: [nsp-sec] rundll841.com wwwDOTwin496.com wwwDOTtag58.com
err68.comand sysid72.com
> sqlinjection sites.
>
> ----------- nsp-security Confidential --------
>
> -----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.
>
> | 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)
> 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'
>
>
> 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-----
>
>
> _______________________________________________
> nsp-security mailing list
> nsp-security at puck.nether.net
> https://puck.nether.net/mailman/listinfo/nsp-security
>
> Please do not Forward, CC, or BCC this E-mail outside of the
nsp-security
> community. Confidentiality is essential for effective Internet
security counter-measures.
> _______________________________________________
More information about the nsp-security
mailing list