Source Sends

So, Mandiant put out a report recently detailing the ongoings of a
 group they call 'APT1', linking it to the PLA and so on. It's a pretty
 good report full of details pretty rarely included in public
 documentation on this specific subject,

 As a 30 second background; years ago, circa 2005-2007 I worked for a
 FLA (four letter acronym) on this exact subject and recognize a lot of
 the tools in question. Amusingly, I tried to give a talk that was
 essentially a sanitized appendix of their report at 25C3 ('we got
 owned by the (rhymes-with-unease) and didn't even get a lessons
 learned') and was visited by the FBI who 'encouraged' me to not
 perform the talk.
 At any rate, a new age has dawned and another page has turned and
 we're apparently far more open on this subject these days. In
 particular, I note one of the tools that Mandiant identifies as
 "BISCUIT"; I worked on what appears to be earlier variants of this
 tool. There are *a lot* of variants as it morphed over the years.
 Initially it operated as a DLL named "wauserv.dll", which was supposed
 to look like the Windows Update DLL "wuauserv.dll" (windows update
 automatic update server dll). They would change a registry key and
 point the DLL loaded by Windows Update to their DLL and effectively
 hijack the Windows Update service (+1 point, clever).
 The backdoor traffic at the time would contact C&C servers via domains
 that were hardcoded into the DLL, although over time this changed and
 remote updating functionality was included. Every X minutes (random
 timeframe that was something like mod 10 minutes) the service would do
 a DNS lookup of the C&C domain name and most of the time it would
 receive a reply that resolved to a loopback IP address (something in
 the subnet; the TTL for the DNS records were low, like 1
 minute IIRC). Whenever the intruders were ready to access the
 backdoors, they would switch the DNS records to make it resolve to a
 new IP. This is a tactic that I imagine still occurs to this day, and
 so SOCs (security operation centers) and similar might find IPS
 (intrusion prevention system) rules that detect DNS replies resolving
 to loopback IPs with low-TTLs; from memory, this had some false
 positives that needed to be worked out in particular this sort of DNS
 reply sometime although semi-rarely legitimately occurs and rules
 written too loosely on the TTLs will flag on many many public DNS
 At the time, and this looks to have evolved, but at the time, the
 actual backdoor traffic went out over port 443 (although in later
 variants and similar tools this was configurable), but it used
 home-grown encryption that was basically in the format of:
"Http 123456789#<ciphertext>"

 Where 123456789 was a semi-variable length integer that served as
 essentially a seed to a crypto key generation routine that looked like
 it had potentially been copied out of a book, 'numeric recipes in c'.
 Following the hash symbol was the actual cipher-text, the seed would
 be copied out, a key generated (symmetric cipher) from the seed and
 the traffic following the hash symbol was either encrypted/decrypted
 depending on direction.
 I know during my time there, a significant advance in defense was
 first deploying IPS rules that would detect non-SSL on SSL ports and
 later to implement products that did this in a more efficient manner
 (for instance, this is likely why many many government networks around
 the world have Bluecoat hardware as at one point it was basically the
 only player in town with a tool out of the box that blocked this type
 of behavior). At any rate, from the Mandiant report, it looks like
 they've only worked with (or enumerate) one or two of the later
 variants that wraps itself in valid SSL.
 That all said, at one point in time, *a lot* of public sector
 organizations found the tool I have attached useful. It decrypts PCAP
 dumps of old variants of what Mandiant has called 'BISCUIT',
 specifically network traffic formatted in the manner described above.
 I've not looked at the code in years, but I know later variants of it
 included support for decrypting a variant of this form of encryption
 which lacked the Http portion of the string and would find one's
 complement of the ascii numeric digits and hash symbol, so that might
 be included as well.
 It's probably of minimal use now as it sounds like the tool in
 question has evolved over the years, but it's one of the tools I
 could've feasibly gone to prison for years ago and the coast seems
 clear to release it now and someone somewhere might find the tool
 useful to decrypt old logs they have or similar. As I said, it's been
 years since I've looked at it, but it should work on 32-bit/64-bit
 Linux boxes with the crypto routines being almost a direct assembly
 rip from the backdoor and embedded in the application as C functions
 wrapping inline assembly; they are the original instructions sans
 lines I added to support 64-bit machines. Within reasonable limits,
 I'm willing to help anyone who might need with the tool and similar.