Regin: Top-tier espionage tool enables stealthy surveillance
symantec.com
symantec.com
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.
http://arstechnica.com/tech-policy/2013/11/uk-spies-continue...
If this were done by China then the US would be represented strongly.
I'm at a loss to guess attribution behind this one.
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.
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).
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.
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.
(Why the love for .lv?)
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.
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.
One leak and the press would be all over this.
China is one of the world's largest markets for many industries. Why not industrial espionage against them?
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
Where do you see the overengineering?
What parts seem sloppy?
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.
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.
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.
I'd really like to believe it was Latvia.
He doesn't say it's not the US, he just says that the data is not enough to support that conclusion.
It might be time for another HN article on Bayes' Theorem.
Any big tech company investing in industrial espionage. It's not as if they don't have the development staff.
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.
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.
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).
My favorite is how Stuxnet was discovered just after Win2000 ended support.
So what made Symantec, McAfee, etc so horrible BTW?
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?
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.
if a process does the following:
Open another .exe file then
Writes to that .exe file
Close that .exe file
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.
Neither China nor the USA is among the ten countries with most infections.
Wow. Just wow.
It should not surprise us, but I wonder what the reaction was when people first realised telephones could be and were being tapped?
Outrage?
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.
https://www.eff.org/deeplinks/2007/08/how-ma-bell-fought-you...
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
Yes.
RC5 is uncommon because it's a crappy old 1990s cipher. If its use is suggestive of anything, it's probably cryptographic incompetence.
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.
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.
and it's been undetected for 7 years, so what does that tell you?
https://www.f-secure.com/weblog/archives/00002766.html
"Securelist - Regin: Nation-state ownage of GSM networks"
http://securelist.com/blog/research/67741/regin-nation-state...
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.
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.
[1] http://www.wired.com/2011/07/how-digital-detectives-decipher...
Is "Regin" or "Stuxnet" a string somewhere? Do the researchers make the names up?
(And, what do the creators think of the name their tool is given vs. what they called it.)
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)?
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]
"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?
[0] https://firstlook.org/theintercept/2014/11/24/secret-regin-m...
But this is HN: Now how do we ensure our servers are unaffected?
No, it's not. As usual, you can thwart "nation state" malware by simply not running Windows.
Wake me when there's malware for FreeBSD (seriously - it would change my world).
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?
But the takeaway here is how we should update our threat levels and paranoia levels as a result of this new knowledge.
In this case, as usual, it appears to be "not much".