and alternative encryption in the form of a variant of RC5, which isn’t commonly used
RC5 is uncommon because it's a crappy old 1990s cipher. If its use is suggestive of anything, it's probably cryptographic incompetence.
RC5 is uncommon because it's a crappy old 1990s cipher. If its use is suggestive of anything, it's probably cryptographic incompetence.
First, can we agree that any encryption algorithm better than a Caesar cipher is good enough for this particular application? That's because nobody who's analyzing this malware is going to bother with cryptanalysis because there's an easier approach. The encrypted data has to get decrypted before it runs. Therefore, you watch the execution with a debugger until it gets decrypted and executed, and then just capture the plaintext data (and the key if you want).
Given that resisting serious cryptanalysis is off the table, I can suggest several reasons for RC5:
- It has much smaller code size (500 bytes vs 15000 for AES).
- It's less vulnerable to fingerprinting. That is, anti-virus software might have checks for AES but not RC5. The malware writer would know this because they actually tested their malware against all the anti-virus products and found that none of them have signature or heuristic checks for RC5 but do against AES. (I'm just fleshing out the thought; I don't know if AV software checks for AES and RC5.)
- AES runs faster than RC5 in general, but maybe the particular platform or instruction set for this malware makes RC5 faster.
I'm also having trouble with the idea that the author of this trojan might be GCHQ or NSA (or sponsored by them), but that cryptanalytic techniques from the late 1970s are off the table.
I'm saying that because the author is sophisticated, they know that the strength of the algorithm doesn't matter (so long as it's not something ridiculously simple).
DES, AES, RC5, RC6, whatever. They're all good enough because Symantec (or whoever is analyzing the malware) is going to get the plaintext no matter what. Symantec is not going to do any cryptanalysis whatsoever. Symantec is going to run the sample malware in a debugger and watch it get decrypted. The malware must decrypt itself in order to run.
This could be worse. It could have encrypted routines for which the commands are the decryption keys. It doesn't appear to be particularly polymorphic. If there's a BIOS/PCI dropper, it's (sadly) long gone here.
Look at Flame's encryption functions [1, §4]. This is the malware that burned a chosen-prefix MD5 collision elsewhere, but still went ahead and used the simplest mangling functions possible. You also find plenty of other 'state-sponsored' malware using similarly stupid/weak/outdated encryption.
They might as well XOR'ed the data, but opted in for RC5 for some reason.
Speed is not a factor - size is. Cryptographic security is far less important than fingerprint evasion: rolling your own is not therefore as insane as it usually sounds.
RC5 is therefofe a slightly odd choice. Block function's a small Feistel, but the key schedule is a pain which totes constants around, which is poor especially from a polymorphic/metamorphic crypter's perspective, because that means you'll have to calculate them or include literals, and they're distinctive constants which make it pop out.
AES has a similar issue with the distinctive S-boxes - include or calculate them.
RC4 variants are more common (but you need scratch space), as are smaller more native stream ciphers, right down to good old XOR-based crypters, which will do the job. RC5 is just not the first thing that'd spring to mind to me.
It obviously was what sprang to mind to the author of that particular bit. Code styles differ, as do skill levels. Big team.
They speak English. It's big. They're interested in Ireland. US or UK is a good guess. I don't think this matches the Detica one for GCHQ, so my early suspicion still remains NSA. We're missing huge chunks though.
So far, that makes references to LEGSPIN, WILLISCHECK, HOPSCOTCH, STARBUCKS, FOGGYBOTTOM, SALVAGERABBIT.
I believe this may be NSA's UNITEDRAKE implant architecture, specifically.
Who names this stuff?! ANGRYFERRET? (Probably no relation to FERRETCANNON; whoever named that one is clearly a Sluggy Freelance fan.) SQUEAKYTOY?
For the truly curious, interested and daring enough to want to analyse nation-state malware, here's an actual live sample they've published. (Obviously, don't just run this code! Trite, I know, but… - password: "infected") https://s3.amazonaws.com/tiregin/regin.zip
Your tax dollars at work! … and mine. Bah.
Analyse it cold (from what I've seen from this, IDA Pro will be safe), or use a suitable simulator.
Mainstream VMs are not designed for secure encapsulation and are very detectable: at least one of the loaders in one of the samples of this is specifically looking for VMs (and that's not unusual at all with any half-assed malware).
Now? Someone reads Sluggy Freelance and thinks FERRETCANNON sounds funny.
They used to tell a story about this, the Germans in WW2, and their penchant for meaningful names allowing potentially meaningful guesswork. Of course, the new generation of brogrammer "cyber-specialists" in charge of Mastering The Internet never got the memo, on either side.
I'm really not sure how much credence I give crypto comments from Appelbaum. The idea doesn't make much sense: the NSA has access to tons of different ciphers; why would they use a patented commercial cipher nobody else uses? It's all the downside of COTS (a public target for cryptanalytic research and an idiosyncratic choice that makes it easier to attribute attacks to them) but none of the upside. With RC6 you don't even get good open source library support.
But either way: RC5 and RC6 are very different things.
Whoops. Silly. Thanks.
> I'm really not sure how much credence I give crypto comments from Appelbaum.
In this case it isn't a crypto comment as much as it is a forensic one. His suggestion comes from experience working with and reversing US malware. We do know that some US malware samples did use RC6, but that's hardly enough to say with confidence that this is a ubiquitous choice for all US malware. My guess would be that it is not.
> With RC6 you don't even get good open source library support.
I'm not sure how worried they are about this.
and it's been undetected for 7 years, so what does that tell you?