> By the time Jon’s company got around to decrypting their data, they were forced by regulators to prove that no patient data had been exfiltrated from their systems.
There is absolutely no way they could have proven that...
If a network has been built such that your backups can be compromised by ransomware, I’d doubt network traffic is logged to an immutable store, if at all.
> “The challenge was that they delete the [public key] once the files are fully encrypted. Memory analysis gave us about a 5-minute window after files were encrypted to retrieve this public key.”
> Unit 221B ultimately built a “Live CD” version of Linux that victims could run on infected systems to extract that RSA-512 key.
I'm guessing most didn't make it within the 5-min window, so the Live CD would recover the "deleted" record from the Windows Registry database?
I am puzzled by the statement too. Live CD means restarting the host and boot it with that CD then retrieve whatever. I doubt that CD is sitting next to people got encrypted when it happens.
The more technical writeup [0] linked at the bottom of the article doesn't specifically mention it, but it sounds like they probably booted off the Live CD to get access to the registry.
> You can’t analyze the registry live on a windows machine because it locks the NTUSER.dat files by the process id (PID) 104 known as Registry.exe. Any useful registry information will be found in that process, and we recommend getting a memory and VAD dump of the Registry.exe process as soon as possible. You can do this quite easily with the REKALL tool, which can perform live and dead memory analysis on Windows machines.
Reading between the lines, I get the impression the key is deleted from the registry, but not explicitly erased, allowing recovery if the disk space isn’t reused yet.
“Since Zeppelin deletes the registry key store, we will have to extract unallocated cells from the registry to recover the Public Key section. […]
We have had 100% success carving the public key from NTUser.dat for live Zeppelin samples in the field”
This is covered by the write-up of unit 221 [1], also linked by splink
it turns out the registry key that was deleted can be recovered. Much like you can recover deleted files from a file-system, you can recover deleted keys from a windows registry.
In the words of the blog[1]:
Since Zeppelin deletes the registry key store, we will have to extract unallocated cells from the registry to recover the Public Key section. We use a combination of code and existing tools such as yarp and regipy to carve registry information from the hard drive, memory, registry backup, and transaction files. We also need to recover the deleted data. The most successful process used yarp-carve and yarp-print with the -deleted flag against NTUSER.DAT files, which are compressed.
No it won't. We are totally toothless here. A few ignorant politicians trying to score points by sounding tough in the media isn't going to make any difference.
Once a case is raised in the system they're flagged for Interpol and a European equivalent. It makes retaining them at a border simpler. There's no downside to filing a case and there might be an upside in the future.
Of our three-letter agencies, I'd really much prefer the domestic federal investigative arm of the DOJ not become comfortable beating secrets out of criminals.
They don’t have the criminals to beat secrets out of, they have a cooperative non-criminal researcher who is trying to help willingly and you guys want to beat them with a wrench because …. reasons.
Where would be the sanest choice if I need some CPU computational resources (say, 10k CPU-hours)? Researchers simply used DigitalOcean (under their generous resource grants), but I believe there would be another better way for computing if I can't get such donation...
Using the example in this article as a demo, on AWS, it takes $75 and 4 hours to crack a RSA-512 key, and it was the 2015 number. So it's certainly the correct choice here.
> Like Peter, Jon asked that his last name and that of his employer be omitted from the story, but he’s in charge of IT for a mid-sized managed service provider that got hit with Zeppelin in July 2020.
Uhmmm…. this is an article about breaking a 3-piece puzzle using one piece of the puzzle and you give us this highly deductible information?
Last year I also learned that ransomware attackers are not computer gods, necessarily.
My QNAP NAS was open to the internet (a forgotten but-not-in-use port forward on my router) and the famous QLocker ransomware got hold of it.
I got out, I got really lucky. I've millions of files (useless to anyone in the world but me) on my NAS and the ransomware encryption took literally days. I probably discovered it on the 3rd day of its activity.
Someone brighter than me already figured things out and posted this on the qnap forums, that there's a 7zip process running which encrypts the files and they process all files sequentially (aka: takes a long time in my case). This 7zip process gets executed for every file and gets passed the password for it on the command line, though in the process view it was masked for me. But I could just replace the invoked 7zip binary with a shell script and redirect all the arguments -> presto, I had the password.
I then wrote some more shell scripts to decrypt all the files infected so far, wrote it more efficient than the attacker, and within 24 hours everything was back to normal.
Before anyone cries "BACKUPS": yes, of course I've off-site backup and they also were not (yet) affected. But actually I only backed up the real important data for me and my family, due to the costs at that time, I didn't backup _everything_. But I since switched cloud backup storage to Backblaze which I figured was the cheapest vs. acceptable ergonomics for recovery, so I could increase the amount of data I back up.
Lesson learned, I guess. I know not everyone can help themselves like I could, I feel really lucky I got away with just some blood sweating.
I think asymmetric encryption is not usable for large amount of data, the only thing it is good for is to encrypt a passphrase or a binary signature (like a hash). If you can catch the process of encryption while it is running, it is likely that the passphrase is in memory (or used as a command line argument).
gpg supports using public / private keypairs to encrypt any amount of data you like. I use it for uni-directional backups from machines where trust is an issue.
Or is the reality of this that it's just encrypting a symmetric key with the asymmetric cipher, and then encrypting data using that key?
Everything is encrypted with a symmetric key. It is just that sometimes there is an asymmetrically encrypted symmetric key packet included in the message so that GPG (or whatever) does not have to ask you for the symmetric key. This is all fairly generic, if you actually have the symmetric key you can use it directly even if a key packet exists. This means that you can give some entity a key to decrypt a particular message/file without revealing your asymmetric secret key associated with your identity.
That's why you create a lengthy random key (that you know it cant be brute forced) and encrypt everything using it and symmetric encryption.
Than you store that random key encrypted with asymmetric algorithm.
Same goes for things like disk encryption. You never use the users key for encrypting the data. You always encrypt using random large key that is not brute-forcable and encrypt that one with user password, so the process of changing the user password is just decrypting the random key and encrypting it back with new password. Or you would have to re-encrypt the whole disk on password change
"It didn’t want to tip its hand to Zeppelin’s creators, who were likely to modify their file encryption approach if they detected it was somehow being bypassed."
It reminds me of something I learned when watching the movie "The Imitation Game" retelling how Alan Turing and his team cracked the Enigma code. They tried hard to make sure that the Germans wouldn't notice they had cracked it, and only used it sparingly so that it would not be noticeable.
Which, I realized, meant that the British and the Germans had teams of statisticians pitted against each other, one trying to make sure that their actions were not detectable statistically, and the other constantly monitoring the numbers to detect unusual patterns.
It wouldn't take the average (average, not great) general long to figure out that the enemy knows all their plans in advance if they don't take action to obscure that. A few times the worst possible counter is just bad luck, but only a few times and you know there is a leak. You might not know if it is a spy or your communications is monitored, but you can make a good guess that they know things they shouldn't.
The big air raids in Coventry are believed to be an example for this.
The british knew in advance of it, because of Enigma, but did not made special preparations, to keep the bigger advantage.
I learned this as a fact, but upon checking now, it likely has been a rumor/conspiracy.
It was actually the Poles who cracked Enigma and built the "bomba" machine (Marian Rejewski) to automate cracking the key. They passed the method to Britain. Turing refined the bomba to make the British bombe, which was then further refined by Harold Keen (Tommy Flowers produced an alternative design, not to be confused with his later design and construction of the Colossus computers for the Lorenz cipher). The designs were later passed to the US, and were further refined by Joseph Desch. My point here is that while Turing was certainly important in the campaign against Enigma, it wasn't just him and his team.
Why would the attacker use RSA-155? The obvious answer is data size because all of the files have a symmetric key that must be encrypted in the field size and communicated. Let's not go into any helpful discussions around that, but, I would like to ask if there is another reason. Perhaps the attacker uses the exact same procedure to crack their own keys because they have to assume that their private key is compromised and/or unsafe to use in a decryption scenario.
Also, I just realized how cryptocurrency wallet draining happens with these infections. I thought it was because they scanned the whole drive for private keys and sent those separately. It seems it's probably more accidental: The user gets to send them one file to decrypt.
For other confused readers, RSA with 512 bits uses 155 decimal digits. Hence RSA-155. This seems to be old notation from the RSA challenge that was clasiffied by the decimal length of numbers rather than the bit-length.
Note that RSA-155bit is much worse than RSA-512bit. Both are insecure and should not be used, but you are still looking at the difference of "you need to rent a server farm to crack is" and "you need a laptop to crash it". I'm probably underselling how trivial RSA-155 is to crack.
Maybe just to mention you an open-source, windows based countermeasure against ransomeware (and all other software that has tendency to trash its garbage all over the system disk). It should be widely known but unfortunately it isnt:
You declare a sandbox and run program there (by default or context menu) and all the changes, including registry will be done as "copy-on-write" into sandboxie folder. Even uninstalling complex software like adobe photoshop is just deleting that folder.
What ransonware will do in this case, it will open a file, but all the writes are going to be done within sandboxie directory leaving original files intact.
It is on completely different level, sandboxie doesnt use virtualization and is achieving its goal using API hooking. This means practically zero overhead.
Windows sandbox overhead is quite low. I've played several games using it and the performance hit is in the low single digits, typically 2-5% in my experience.
It's complicated but IMO virtualization seems to have less opportunities to fail vs a sandbox in terms of isolation.
My concern is that Sandboxie won't stop malware from stealing files, browser cookies, sessions, and opening a browser and puppeting it to steal your bank accounts.
I have been trying to find the name of this software (Outpost Firewall) on-and-off for a year; wondered what happened to it... sad that it is gone. Any good alternatives (I was never a fan of the Zone Alarm one)?
If you look at your logs of botnet attacks, most of the traffic is scattered evenly across the world, and cryptoware is probably similar. Ultimately the command and control will go back to Russia (usually), but firewalling Russia and China is unlikely to help much with any form of attach.
Minor rant. I wish people would stop putting 'quietly' in headlines. Are we expected to believe that they did this in total silence without talking to each other or listening to music as they worked? Ridiculous!
In seriousness though, 'quietly' is clickbait meant to imply this they were doing it secretly for some nefarious purpose. Also the fact that there is an article about it contradicts that meaning of quietly as its being published to the public.
/end rant
There is absolutely no way they could have proven that...
reply