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.

A small 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 the upstream side of the fluxnode traffic that is mothership bound. "HydraFlux" is bestowed as a result of operational behavioral based naming.  In the observed network each fluxnode 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 and there is no easy method to determine if the mothership tagged is the final destination, or just a hop in a network of motherships.

HydraFlux nodes inject the actual client IP into 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), */*

Accept-Language: en-gb,en-us;q=0.5
UA-CPU: x86
Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .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), */*

Accept-Language: en-gb,en-us;q=0.5

UA-CPU: x86
Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .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 respective motherships involved.   The form-encoded data identifies typical elements related to the client including OS version, etc but perhaps the most interesting part is the (XOR'd 27) instruction file consistently named 'COMMON.BIN' that is delivered back to the client as 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 potentially large number of mother ships could 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