20 February 2013

APT BISCUIT

JF sends:

Attribution as you see fit/necessary, I just want the info out there in hopes someone finds it useful.

Two sidenotes; there should be a FOIA'able document showing the 'BISCUIT' malwares commands appear to be a foreign language transliterated.

_____

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,

http://intelreport.mandiant.com/

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 127.0.0.0/8 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 servers.

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.

http://cryptome.org/2013/02/apt-biscuit.tar.bz2 (Scanned by Norton. For assurance, do your own.)