Telegram API ransomware wrecked three weeks after launch Ransomware scum abusing the protocol of the popular Telegram encrypted chat app have been wrecked and their malware ransom system decrypted. TeleCrypt throws a message to Russian-speaking victims thanking them for helping the "Young Programmers Fund" via the US$78 (5000 ruble) ransom payments, a comparatively small charge …
Good news. But it's bad.
Let me explain why :
Going forward the ne'er-do-wells who write such encryption programs will learn from their mistakes, and start patching their programs so that no loophones to decrypt files will be possible.
Expect decrypting files to be much harder, if not impossible with future versions of any encryption-type malware/ransomware.
Time to get out of IT... and let somebody deal with the problem. I've had enough.
Simple solution.
Have good backups and test them. Perhaps a fileserver that has snapshots in some form.
Somebody gets infected, isolate them, clean the machine, and rollback the fileserver to the last good version or restore backup.
Sadly the state of IT is backups = some drive somebody copies some files to on occasion.
> Sadly the state of IT is backups = some drive somebody copies some files to on occasion.
This saved my sister who got the ransomware. My 4yo daughter knows how to handle a computer better than my sister who speaks 4 languages ... you cannot be good at everything ... Anyway, I told her to do backups on a weekly basis, and she, luckily, unplugged the hard drive after each ... when the email came and somebody launched the cryptor exe, she called me ... had her wipe drive, reinstall Windows (with help of her teen), restore backup, all good.
Teen feels like a hacker for installing Windows 10 successfully, I understand ... sister is currently testing/evaluating Mint Sarah ... that will be the next step ... no more crap like this ... ;-)
I wanted to experiment with ransomware (well, to be honest, more like user error :-) ) resistance, so I set up a small home ZFS system. It's old hardware but it can still snapshot every minute at my usage level (family media server) without anyone noticing. I haven't tried it in a small business setting yet, because I need to load-test it.
It keeps 2 hours' worth of minutely snapshots; a day's worth of 10-minutely snapshots; a week's worth of hourlies ... blah blah ... and keeps the quarterlies for ever. ... probably about 1000 snapshots in all (another cron job tidies them up). They are read-only, of course, and only root may delete the snapshots (and root may not log in remotely). No-one who may log in remotely is in is in sudoers. I haven't yet had the nerve to deliberately infect myself (not sure I'd know how) but I've tried doing my worst to delete and corrupt files from my client devices and it all seems fine, they can always be rescued from a previous snapshot. There's probably a better way of doing this so please feel free to educate me - in particular you have to hunt back through snapshots for the most recent good copy.
Storage is so cheap these days (relative to the expense of data loss) I'm not really sure why we don't automatically keep version history of every file like we used to in the old VMS days.
They are all retarded to the bone.
Each and every OS out there has file-based encryption overlay for a directory. Most implementations are pretty much unbreakable without access to 3 letter agency resources. All you need is to generate a new key and/or ship it out erasing it on the target machine afterwards.
The fact that they are Rolling Their Own Crypto means they are retarded to the bone and have the competence of a PFY beginner sysadmin. So as long as they continue to manifest such levels of incompetence it will be broken. Regularly.
The scary bit will start when they start leveraging the OS resources properly.
Some are retarded , some arnt. Its not not the retarded ones to worry about.
No one needs to write their own encryption , as you say , and even these idiots didnt. They might have done better if they did . Real strong encryption is not hard to write anyway , the formulas are well known and simple.
There are plenty of real strong Ransomewares out there, that malwarebytes wont be saving you from .
Do backups.
and try to notice the ecrption before your backup cycle is up and your backups are encrypted . which for me is 2 weeks
and try to notice the ecrption
You will not notice it if it uses overlay. That is the "cornerstone of retardedness" and why rolling your own crypto is retarded. It is not the crypto part, it is the OS accessing the files.
The current implementations encrypt and lock you up there and then so you notice immediately. At that point you can just wipe and restore from backups. If the implementation uses overlay it can delay the moment until it asks for your money for an arbitrary amount of time and the only way to notice it is to actually read your backup logs. Something very few people do.
"dosent that double the size of your files?"
No. The addition is done at individual byte level. Remember that most files on your computer aren't plain text, but contain non-ascii data. Your jpeg or mp3 file will contain millions of bytes of data, all within the range of 00 to FF (0 to 255).
The key is (presumably) added to these individual bytes to change the value of that byte.
If we use your example though, lets assume that your data is plain ASCII in a text file.
Looking at the ASCII values for both the original data and the key, we get something like this...
ASCII
t - 74
e - 65
s - 73
t - 74
i - 69
n - 6E
g - 67
1 - 31
2 - 32
3 - 33
m - 6D
y - 79
k - 6B
e - 65
y - 79
1 - 31
Adding the key to the data on a byte-by-byte basis, we're doing this:
(t+m) (e+y) (s+k) (t+e) (i+y) (n+1) (g+2) (1+3) (2+m) (3+y)
... or in hex:
(74+6D) (65+73) (73+6B) (74+65) (69+79) (6E+31) (67+6D) (31+79) (32+6B) (33+65)
That would ultimately give you this:
(E1) (D8) (DE) (D9) (E2) (9F) (D4) (AA) (9D) (98)
Your plain text message would now appear as áØÞÙâŸÔª ˜" when you opened your text file.
* - This is a quick explanation - the ASCII codes, or the additions may be completely wrong.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
