20 February 2013
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
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:
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.
(Scanned by Norton. For assurance, do your own.)