The list of infected countries might tell us a thing about the attacker:
Russia and Saudi Arabia at the top: classical US intelligence targets.
Pakistan and Afghanistan: Likely anti-islamists effort.
Austria, Belgium, Iran: Opec, IEAE, tons of EU-institutions - someone who wants better intel about the nuclear talks with Iran?
Ireland, Mexico, India: Hard to find political reasons for those countries, but if you look at it economically: Ireland is the main hub for US companies into the EU, Mexico is a neighbouring country to the US, India: rival to China
My totally far-fetched guess would be that this trojan comes from the NSA or the GCHQ, I don't see China caring that much about Saudi Arabia and AfPak.
It's funny to me that we posit attackers building malware of such sophistication that they can only be nation-state in stature, while at the same time supposing that they know so little about the AV industry that they could be revealed by a heat map of the countries their malware was spotted in.
How about: it's Russia, Russia doesn't care about infecting hosts in its own country (in fact, they may prefer to do so; those might be their targets), and, while Russia surely does have an aggressive program of intrusions into the US [and China], they don't use this particular piece of malware to execute it?
I have no reason to believe it's Russia. I just think: that story is as plausible as the others being tossed around this thread.
If I have a bias about the origin being the US, hand to God, it's that I'd like to believe my tax dollars can pay for better malware than this. I have, for what it's worth to the thread, absolutely no doubt in my mind that the US has stuff like this in the field.
The Saudi infections are obviously a decoy and the main target is clearly Russia. Latvia, as a former SSR and recent NATO addition, is nervous about Putin's next moves in the region. Wasn't there also recently a Russian sub spotted in the Baltic Sea? You'd have to be an idiot not to see Riga's fingerprints all over this thing.
Expectedly, tptacek is all over the infosec thread, arrogantly dissuading the public from the notion of a possible involvement of the US intelligence community :)
Attribution is always thorny - but yes, targeting metadata does match those possible conclusions.
Quite a bit of the other information in the 'technical report' (which isn't as technical as I would like) does seem eerily reminiscent of what we know about the CHIMNEYPOOL framework, and (to some extent) FOXACID. A little overengineered, and a little sloppy in places - and that's everything I'd expect from a pork barrel remote intrusion tool with serious dollars thrown at it.
Go on, match it up and see what tallies! Assume "Stage 0" is the VALIDATOR egg (or a cousin), which is memory-resident, never touches disk, and fetches the rest, and work from there.
In particular, I'd single out as particularly telling the 7a69-CRC ICMP filled with string-literal (and very English) shit, and… a 20-round variant of RC5? That has a strong smell of hamburger to it, although I'd wonder if the analysts perhaps mistook it for RC6, or if this is perhaps an earlier version?
Yes, at first blush, this may indeed be NSA malware!
Are the samples available for analysis, Symantec? Inquiring minds want to take a closer look at this creature, and you have piqued my interest. My email won't be hard to find. Deadlists are fine. https://keybase.io/akr
What else makes you think serious dollars were thrown at it? What evidence would you be looking for of that? We managed to throw 900MM at a health insurance portal. :)
Is it really that unusual for trojans to be elaborately staged? I feel like I was on a CanSec stage with Jose Nazario about 12 years ago talking about malware staging. Staged malware, that is, is 2004 CanSec Jose Nazario levels of sophistication (due respect to Jose).
The Wikipedia page for RC5 says to use 20 rounds, because RC5 sucks and fell to differential cryptanalysis, which NSA knew about in the 1970s.
This is without having seen it, natch, so I can't speak to its quality except for what's in the "technical" paper: this is initial impressions and speculation, but I'd definitely love to see concrete deadlistings.
The overengineering, and the serious dollars? I say that because it's a large, modular framework, with perhaps more stages than strictly necessary - which they cut down on later on. This isn't a small, precision piece of malware from one highly-skilled VXer. This is a project. Abstraction, modularity, plugins. Exploits (0days?) and payloads and C&C mechanisms, all as plugins. A big project, designed for lots of people to work on, probably of very different skill levels. Adapted over time. Hell, there's a linkfiler in there and their own RPC. So, kind of like any other big software project: it sounds a little sprawling. And big means expensive, as you know. I know GCHQ and NSA developed theirs via contractors. Seems reasonable this is the kind of thing they might put out. (Note CHIMNEYPOOL was specifically mentioned as a framework for malware.)
Why did I call it sloppy in places? Because it's a (purported, and probable) nation-state espionage malware that touches disk, never mind the failure to clean up! Programmers of different skill levels; perhaps operators of different skill levels, too.
I want to know more about the C&C. I would expect to see a C&C technique that transmits decryption keys for encrypted functions as selectors, but I think this is not quite that advanced.
RC5 is indeed an odd cipher to use in the late 2000s (as is just bumping the rounds of it, rather than using a better one). I called that out, because at least one other piece of software which sounds very similar seems to use RC6 (the failed AES candidate), which is also a very unusual choice. It's not infeasible the two are linked, but I'm obviously lacking context here.
Right on. While I'm dubious about this being a US trojan, candor requires me to say that some of these observations are also things friends of mine pointed out to me about Stuxnet when I was doubting that was a US project. You probably can look at a raw assembly dump and get a sense of how many different people worked on it, and, if it's a lot, sure, maybe it's a defense contractor.
And a very fat finger points at the US/UK because if they were simply present in statistically normal quantities in the samples they would be amongst the largest of the groups encountered. The fact that they are not suggests a conscious decision not to target those countries, likely emanating from a law rather than from a desire.
If this were done by China then the US would be represented strongly.
I agree that US/UK are most likely but I see other possibilities too: Israel, or one of the other EU states.
Israel might not have any qualms about targeting American targets -- at the very least they would have no legal restriction against doing so. But they might not do so for pragmatic reasons: lack of interest, or to generate the impression that the threat is U.S. based.
I think you can rule out the other EU states based on capability alone. Israel is a good one, hadn't thought of that.
China as a target is a hard one. In part this is because they have relatively little IT infrastructure relative to the size of the population and because the number of juicy targets is rather limited (government mostly).
Based on what capability? Symantec's PR machine aside: what do you think something like this would cost to develop? Based on the high-level summary we have here, it looks like a 6-figure project. Latvia could afford to build this thing.
I probably didn't look at this any more carefully than you did, so if there's some specific capability you think narrows down the sources of this trojan, let me know; I probably missed it.
Capability is constrained by more dimensions than just a financial one.
Try to imagine the fall-out of say the Dutch spying on all these countries, including one of their EU countries is interesting. I really can't see any of the EU countries that might be implicated by a thing like this having to admit at some point in time on having spied on Belgium or Austria. That they can afford it is besides the point, though I'd like to see some politician willingly sign off on this.
Since the put-out-to-pasture trajectory of past their prime EU politicians is to be promoted to Bruxelles I highly doubt they would limit their careers in such a drastic way.
Whoever did this needed to have the desire first, the capability second (technical capability, for instance (this doesn't strike me as a small undertaking easily contracted out), but also to be un-encumbered legally) and then finally they need the money. That's the least of the problems but I don't see them crossing the legal barrier to begin with.
The French have had some egg on their faces in the past with actions against non-government entities operating nominally under the flag of other member states (for instance, the Rainbow Warrior incident) and they will forever be remembered because of that. I don't think (or maybe wish to think) that any of the countries that are currently signatory to the various EU and other treaties would willingly cross the lines on something as sensitive as this.
Just six figures? To build this and maintain it over multiple years, including a menu of payloads and exploits? When individual exclusive 0day exploits each rank at 5 figures upwards? Salaries?
That seems unrealistically low for this. Sounds like much better value for money than any nation state would actually get in practice, and more in the ballpark of Malware-as-a-Service outlets like Hacking Team.
I'm not counting payloads and exploits against the cost of the framework, because the framework is all we have to go on. Exploits cost a lot of if you (a) need zero-day, (b) need mass-infection, or (c) need to foil attribution. They're significantly cheaper if you relax those concerns.
Similarly: I assume the payload that physically corrupts a centrifuge array is a bit pricier than the one that scans the hard drive for credit card numbers.
Latvia's just the smallest EU economy that came into my head.
Hah, this is 8 figures easily. I'm honestly baffled that you could have any doubt it would be the work of the US. Like I was when you were skeptical of stuxnet. Everything about it screams nation state.
Hmm... good point there. Could also be a private entity -- governments aren't the only ones out there doing this kind of thing. There's a lot of money to be made on commodities markets, for example.
[Edit: I missed the PDF whitepaper before writing this comment. It doesn't answer all my questions bit I'll give them credit for a really nice detailed whitepaper.]
This article makes me very suspicious of Symantec. How long have they known about this, really? Are they just releasing this information now as a marketing reaction to recent discoveries by competing firms?
The vaguely written timeline says in passive voice that Regin has been observed since 2008. By who? Why are we just hearing about it now? I wouldn't blame them for keeping some discoveries quiet for a while so they can do some stealth research, but the timing here really smells like they are being PR driven instead of being driven by doing what's best for the overall security community.
What would inspire much more confidence would be a story of how this was discovered, and how the discovery and research played out, as we have seen for some other malware. Instead this looks like they have know about this for a long time, and now for reasons they aren't going to disclose, they have decided, or have been given permission, to reveal some of what they know.
Once malware is identified properly antivirus firms will usually go through their detection archives and pull out earlier hits.
The reason why they don't see them sooner is because they get tends to hundreds of thousands of new threats each week and don't have time to go through each one.
Mikko from F-Secure also reported on Twitter that they found Regin[0]. The same thing happen with Stuxnet, and just about every other malware - it is why these firms will keep and check the archives of new detected threats.
As for your general suspicions, this is endemic with infosec since there is a natural conflict of interest where those doing the research and reporting on it are also selling solutions.
If it makes you feel any less suspicious, the research departments within these antivirus firms are generally isolated from parts of the companies involved in sales and marketing. They are usually small teams that just go out and publish information on cool things they find - although there is often a race to be the first to dissect and publish the details of new malware (which is why you wouldn't sit on knowledge of a new threat).
The same thing happen with Stuxnet, and just about every other malware - it is why these firms will keep and check the archives of new detected threats.
My favorite is how Stuxnet was discovered just after Win2000 ended support.
So what made Symantec, McAfee, etc so horrible BTW?
which looks unrelated to the point of being incorrect.
also quite strange that they say in the PDF it's a kernel mode driver, as my understanding is that windows 7 & co do not allow those to be installed if they are unsigned. EDIT: The pdf covers this later on:
> The 64-bit version of Regin’s Stage 1 (wshnetc.dll) is no longer a kernel mode driver, as drivers under 64-bit Windows
must be signed. Instead, Stage 1 is a user mode DLL loaded as a Winsock helper when the computer is starting
up.
Well people are sending suspicious files to the AV vendors all the time, so Symantec may have found the backdoor a lot later and then found it existing in their DBs.
On a less related note, beyond the shiny GUI layer, just how advanced is today's antivirus software anyway?
Do they still primarily rely on signature detection? I know that modern systems also perform what's broadly titled "heuristic analysis", but I'm not sure what that specifically entails. Is there any form of system call tracing, sandboxing, file monitoring or what?
Heuristics look at what a process is doing. For example, a very simple heuristic rule may look like this:
if a process does the following:
Open another .exe file then
Writes to that .exe file
Close that .exe file
Then it's a virus.
Such 'rules' are then used by the detection engine of the anti-virus software, if a program triggers any of these rules it is often labeled as a 'generic' Trojan or virus. Often this tracking is achieved by 'hooking' syscalls of your operating system. But some anti-virus programs also employ emulation and/or sandboxing. Comodo is an example that does sandboxing.
Recent developments in anti-virus are what's called 'host-based protection'. Instead of relying on blacklists, such as heuristics and signatures, a custom made 'profile'(whitelist) of the host is made which looks at which applications are installed and what they should be doing. For example: your browser should never attempts to start another process. If it does it means something is wrong.
Such host based approaches can detect unknown threats/exploits as they happen. If your browser is exploited and tries to download and execute malware, the system will detect it because it was previously established that your browser has no business starting other applications.
A lot of modern malware prevention focuses on monitoring network traffic. Rather than rely on a single machine to self-report its health, technologies monitor the main channel of infection and data transmission, which is communication with the internet.
Examples:
- FireEye
- OpenDNS (where I work)
- Palo Alto Networks
- ZScalar
Case in point - at OpenDNS, we can often identify signs of infection (e.g. communication with DGA domains) before pinpointing the particular malware involved.
Signature based antivirus, as in "after the fact"-heuristics, remains the most useful. Because, as advanced as the other methods may be, their usefulness remains limited by their public existence. Any malware writer checks their creations against VirusTotal and change it as long as anything flags.
The most awesome comment from AT&T was that "this telephone system offers a means of espionage to which general warrants and writs of assistance were the puniest instruments of tyranny and oppression".
[I]t is better that a few criminals escape than that the privacies of life of all the people be exposed to the agents of the government, who will act at their own discretion, the honest and the dishonest, unauthorized and unrestrained by courts
Why bother cracking RedPhone when you can just trigger something remotely on the completely unaccredited radio chip, or the SIM, or the OS platform itself. A modern phone does not have one operating system, but 3-4 and they all can - after you crack one - ask services freely from others.
The whole architecture of cellphones is so broken that installing RedPhone and thinking someone with resources can't do anything about it is plain laughable. Yes, it drops casuals and non-targeted attacks. But targeted? Never.
Let's not jump to conclusions. If Symantec's characterization of the sophistication of this malware is accurate, then surely they could have afforded some crypto expertise.
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.
The term you're looking for is "crypter". Heuristics may be more sensitive to the executable-packer-like behaviour than the crypter itself. Signatures which look for crypters will obviously target constants if they're around.
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.
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
If I wanted to take that sample and actually run it inside a VM, what would I need to do? It looks like I need to know the file extension of each file and then rename the files?
Um… what you need to do is not do that. This is not incredibly technically sophisticated compared to some of the stuff I've seen, but it is still not a toy!
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).
In the case of the GCHQ, I believe there's a system which picks two random words to concatenate. The intention is that the codename would not reaveal anything about the program to which it refers.
Yeah, that's what they should be doing, same with the NSA. Maybe 20 years ago.
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 having trouble parsing this comment. Your suggestion is that the author is sophisticated and that's why they chose RC5? RC5 is a broken 1990s cipher. If the authors wanted to minimize code size, they'd have used a native stream cipher, not a 64-bit block cipher.
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.
> the author is sophisticated and that's why they chose RC5
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.
The malware must decrypt the parts that it runs. (There's an obfuscation technique that's apparently quite strong in existence, but it produces gigabyte executables for simple 5-condition if statements you can brute force by hand, so it's ludicrously impractical.)
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.
Choosing RC5 is an irrelevant implementation detail; they probably used whatever was in hand at the time. The only requirement is that the function makes things random-looking, really. I agree with alister in that the reason---if there was any reasoning applied here---was likely code size / simplicity.
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.
I guess if you're saying you can't read RC5 as being a point in favor of or against GCHQ, I find your argument plausible. RC5 is more plausible at least than RC6, which (a) few people have at hand and (b) calls significantly more attention to itself.
It's not supposed to really encrypt anything. It's an obfuscation method. It doesn't matter how "broken" it is, as long as anti-virus applications have no idea about how to "decrypt" it.
They might as well XOR'ed the data, but opted in for RC5 for some reason.
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.
> 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.
They should be, because popular open source implementations (really, any popular implementation --- it just happens that every popular crypto implementation is open source) provide deniability.
I think the thing that's most frightening here is that those who created this thing have had 6 years to iterate and improve on the design before being discovered, so what has been found may just be the tip of the iceberg.
Amazing how Symantec use this to push their software rather than providing even a clue to determining whether you're infected or not. Never miss an opportunity to cash in, I suppose.
I don't think this post comes off as an attempt to make more money.
Rather, I think it's applaudable that they release information on threats from governments (and not only traditional spyware/virus).
Since this is (probably) built by a government, one can be certain that a government somewhere (presumably Western, given the infected countries) is upset about the release. And they didn't cave in to that, which is good.
I would guess they didn't cave because no Government has registered their upset at this. If they did, it would be pretty clear which Government it was - making me think the Government in question has few levers to pull against Symantec.
I disagree. Symantec is one of the few companies on the planet that has had to deal with this exact situation before: Stuxnet.
By late 2010, Synametic had come to the conclusion that Stuxnet was most probably a joint US/Israeli malware project, designed to disrupt Iran's quest for a nuclear bomb. [1]
Just try and imagine that the gravity of that moment. They had stumbled into an international covert action involving weapons of mass destruction. I mean the closest thing I can even compare this with is fiction (the "too many secrets"/"using the magic box" scene in the movie Sneakers). But this wasn't fiction, and Symantec researchers and management had to decide what to do.
They could have just shut up and said nothing. After all they were a US company, forbidden by law to even to do business in Iran. But they didn't do that. Rightly or wrongly, they published their findings in a whitepaper and told the world about it.
I think Synmantec has earned the benefit of the doubt when dealing with state sponsored malware.
Stuxnet: named for files .stub (where config was stored) and mrxnet.sys (main driver), by Microsoft
Duqu: named for the "~DQ-" temporary files it created, by researchers in Hungary who found it and wrote report
Flame: is from a routine called "InstallFlame", so the malware name is likely same between discoverers and writers.
The naming convention is usually to find a unique identifier used in the malware. Portmanteau's are common. We often don't find out what the writers name was, although both Stuxnet and Flame were part of Operation Olympic Games[0]
Yes, generally malware is named by the researchers who found it - often even if the creators obviously named it otherwise. I wouldn't be surprised if "Regin" was a reference to how the researchers found big chunks of it tucked away in the registry, or something like that.
For example, there's a reference to the name "Myrtus" in Stuxnet, which was (I think) probably the name its creators gave it (and may point to its Israeli origin)?
"In Nordic mythology, the name Regin is associated with a violent dwarf who is corrupted by greed. It is unclear how the Regin malware first got its name, but the name appeared for the first time on the VirusTotal website on March 9th 2011."
Double meaning or coincidence? e.g. did the authors of this piece just google "Regin" and find out about this dwarf?
I'm sorry, but this seems incredibly naive. Stuff like this, which is apparently used against designated targets, surfaces because Symantec and similar companies casts an incredibly wide net looking for odd stuff in the wild.
Few does this at a large scale for Linux, and I guess nobody does it for FreeBSD. But just because noone has caught sophisticated malware from a nation state in the wild doesn't mean it isn't there. So even if the code doesn't apply to you, the determination this shows from the attacker, would if you have something to hide.
Do you seriously expect the NSA (or their chinese counter parts) just to give up and go home if a target they are interested in happens to use something else than Windows?
Perhaps antivirus deployment on Linux is low enough that they simply didn't encounter the Linux version. One fairly telltale thing would be if there were indications of a platform abstraction layer, but the report does not mention anything like that.
That kind of information should be published by the CIA, FBI, NSA, ... themselves instead of destroying Democracy with their secret gag orders. “I'm not allowed to say that I'm not allowed to say anything”. Can it still get worse than it already is? Any random terrorist is more honorable than the Feds. At least they're not lying about being terrorists.
Russia and Saudi Arabia at the top: classical US intelligence targets. Pakistan and Afghanistan: Likely anti-islamists effort. Austria, Belgium, Iran: Opec, IEAE, tons of EU-institutions - someone who wants better intel about the nuclear talks with Iran?
Ireland, Mexico, India: Hard to find political reasons for those countries, but if you look at it economically: Ireland is the main hub for US companies into the EU, Mexico is a neighbouring country to the US, India: rival to China
My totally far-fetched guess would be that this trojan comes from the NSA or the GCHQ, I don't see China caring that much about Saudi Arabia and AfPak.