Skip to content

Preliminary Network Analysis of Flame CnC Traffic

2012-06-01

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine

I’ve spent the past few days letting Flame do its thing, watching the effect on various test platforms. Here’s an update to Wednesday’s first report I published about Flame. I promise to refrain from making breathlessly melodramatic, or inane, fire-themed puns, like where there’s smoke there’s fire, or Flame Trojan: Burnin’ Down the House? throughout this post.

My mom would have loved Flame if she’d sent it to college instead of me, because it phones home regularly. About once an hour, Flame has been pushing pingbacks at its command-and-control server. The traffic is encrypted using SSL, and the server uses the same certificate every time. It looks like this.

The certificate’s nominal issuer is, supposedly, Internet Widgits Pty Ltd. Sound familiar? The Australian heritage of the issuer’s name on the cert is a stain on the reputation of the security people I met down under a few weeks ago. In any case, the cert is untrusted, which means that if anyone tried to use it on a real Web site and visit as you normally would — using a browser — the browser would throw an error that would make the problem apparent. However, if you don’t care about the error a browser might display, you can still use the untrusted cert to encrypt your communications.

Well, maybe some places. Not on our lab network.

I’ll list some of the identifying characteristics of the bad cert on the following page, so people can tune their firewall/IDS appliances to watch for it. The following page also includes interesting contents of these supposedly-encrypted comms. There haven’t been many hours when the box hasn’t sent something up to its CnC server, and whatever it’s sending varies in size each time: The first was only about 70KB, but within a few hours, it began pushing about 1MB to 1.5MB of binary data down to the CnC each time it connected.

The certificate was created to become valid on 2012-05-26 with validity for one year. Here are the bad cert’s properties:

KeyID=14 bd 22 b8 12 59 ab 38 a0 77 22 02 17 f3 1f 70 1f 37 87 88
Certificate Issuer:
     Directory Address:
          O=Internet Widgits Pty Ltd
          S=Some-State
          C=AU
Certificate SerialNumber=00 9f 15 00 76 cb 46 91 6c
Thumbprint: 04 19 12 83 e4 70 ba fd 10 24 4e 6a f4 76 3b 88 84 69 52 00

While the conversations themselves are wide open, I haven’t yet begun to try to decrypt the contents of those data blobs, but thanks to the Crysys team‘s and Kaspersky‘s published work, there’s a few places we can start: These files are, quite likely, encoded using one of the algorithms so thoroughly documented in the various reports from these other guys.

One thing that was notable, however, was how predictable the query string is. Here is how it is structured (where the # symbol represents a numeral, and the emphasis is mine):

UNIQUE_NUMBER=#########&PASSWORD=LifeStyle2&ACTION=#&FILE_NAME=#&FILE_SIZE=######&CRC=##########

That’s a nine-digit unique ID, a static (so far) password — and let me be the first to say: nice password, goofball — a single number for both ACTION and FILE_NAME, and what appears to be a ten-digit (supposedly for error-detection) CRC code.

Who puts error-detection in their malicious code designed for data theft? Someone who cares about the quality of their exfiltrated information, that’s who. If it is really a CRC, and not just some other encoded data, one might reasonably infer that this indicates that the creators put a little thought into the data integrity problem.

After the Trojan pushes the query string to the browser, it’s followed immediately by the data blob. Distinctive aroma? You might say so: The exfiltrated data’s header has been the same each time I’ve seen it: the hexadecimal characters FEED. The filename used for the HTTP POST to the server has been counter.cgi each time.

Like I said earlier, the data blobs I’ve seen so far range in size from under 100KB to 1.4MB. DeepSee’s DPI engine correctly interprets the data blob’s MIME type as application/octet-stream.

The Trojan hasn’t switched over to any of the other domains I assume also belong to its creator and/or distributor. The .info domain it is using for its CnC, as mentioned earlier, is hosted on LeaseWeb space in the Netherlands. At least, that’s where MaxMind thinks it is. Its DNS hasn’t changed in two days.

You can follow the @SoleraBlog Twitter feed for faster updates and news about other developments. If interesting stuff crosses the wires over the weekend, you’ll find it there.Solera blog stats

Comments are closed.

%d bloggers like this: