William, one of the other handlers, has been working on something a bit different. Like all of the handlers he has a lot on his plate so he hasn't had a chance to write things up, here is a little taste from Williams paper on something he has dubbed Hydraflux.
Fastflux is by now a staple for many phishing sites and malware delivery. It builds a stable network which is difficult to take down. In a fastflux environment many clients communicate with a flux node which in turn communicates with the mother ship. (Many clients ---Fluxnode:80----mothership:80) If you take out the fluxnode you affect a number of clients, but if you manage to take out the mothership, then the end result is more impressive. You have now taken out a number of fluxnodes as well as the many clients connected to it. Hyrdaflux changes this.
Asmall flux net(at the time) was observed where the behavior of the fluxnodes was different. The emergence may simply be an evolution in one flux herder codebase, or it represent a new fluxnet operation altogether. The uniqueness of this particular fluxnet does not become apparent until you see what is happening on theupstream side of thefluxnode traffic that is mothership bound. HydraFlux is bestowed as a result of operational behavioral based naming. In the observed network eachfluxnode endpoint maintained a one to many mothership relationship. The nodes also communicated with the mothership on a non standard port. (Many clients ---Fluxnode:80----Multiple Mother ships:4449) This type of structure now makes it more complicated to take the network down as the fluxnode can still receive instructions from the remaining motherships. The immediate upstream mothership was identified as nginx servers andthere is no easy methodto determine if the mothership tagged is the final destination, or just a hop in a network of motherships.
HydraFlux nodes inject the actual client IPinto mothership comms similar to how Storm and Warezov flux nets do (each in their own way). HydraFlux does this by injecting a client header X-Source: $IP following the Host: header, which is also modified on the upstream journey to the mothership(s) so that this header value represents the flux node incoming bind IP address, like so...
Client Traffic to - $FLUXNODE_IP:80
GET /servlet/?portal=kljasdliqwnnd78wnsnwjnsn HTTP/1.1
Accept: image/gif, (REDACTED_FOR_BREVITY), */*q=0.5
UA-CPU: x86Accept-Encoding: gzip, deflate .NET CLR 2.0.50727)
Host:
www.AAAAA.BBBBB.net
Connection: Keep-Alive
Traffic leaving fluxnode for one Mothership - aaa.bbb.vvv.ddd:4449
GET /servlet/?portal=kljasdliqwnnd78wnsnwjnsn HTTP/1.1
Accept: image/gif, (REDACTED_FOR_BREVITY), */*q=0.5
UA-CPU: x86Accept-Encoding: gzip, deflate .NET CLR 2.0.50727)
Host: $FLUXNODE_IP
X-Source: $REMOTE_CLIENT_IP
Connection: Keep-Alive
At 11 minute intervals the fluxnode endpoint communicates with the mothership. It targets each of the respectivemothershipsinvolved.The form-encoded data identifiestypical elementsrelated to the clientincluding OS version, etc but perhaps the most interesting part isthe (XOR'd 27) instruction file consistently named 'COMMON.BIN' that is delivered back to the clientas the server response to POST/forum.php data. This file contains the IP addresses of all upstream motherships for the node.
It would seem that a potentiallylarge number of mother shipscould easily become involved, or for better or worse turn this into an ugly redirector mix of fluxnode endpoints redirecting through fluxnode end points intent on annoying even the most aggressive investigator.
So as you can see the game has changed again. The above was observed back in April and May, research continues. Thanks to William for doing the research and allowing me to edit and publish the diary.
Mark H
More...
Breakout Champion!
Linear Mode
