I'm a little on the fence. It's dead easy to read, but it reduces the amount of context I get from the surrounding code because of the little that fits on a single screen
Maybe they left the debug symbols because they knew that even when you disassemble it, you won't be able to extract any information that could help the victim. I.e. it was a "flex".
@@jordixboy the implication here is that they 'borrowed' the code, and didn't bother with removing the debug symbols, or didn't even know how one would do that
I'd rather think it's incompetence, ransomware authors typically "flex" by specially naming mutexes, threatening ransom notes, unobfuscated strings and so on instead of leaving the debug symbols.
Considering the part that causes actual harm is an unobfuscated *bash script,* it's pretty safe to say that leaving symbols in their generic encrypt/decrypt binaries wasn't a consideration.
This kind of malware is effective thanks to women in the workplace. You can rest assured that Karen from HR will click the link to reveal how she can claim the $500 amazon gift card she just won....every...friggin...time.
@@dingdong2103 Is it though? Funny, I mean. Demented and sad, maybe, but is it really funny? Like, two guys walk into a bar, which is weird because you would think that after the first guy walked into it, the second guy would have seen it. That's funny. Hey, want to hear a joke? This guy I don't know had all of his ERP files encrypted by some scammer using a regular shell script! He couldn't afford the ransom, so ended up losing his business! Ha ha ha ha! It was a shell script! Get it? That's not really funny, right? There's a set up, but not much of a pay off. I'm really sorry, I've gone off for far too long; I get like that sometimes. If by funny you mean, wow interesting, then yes, it is disturbingly interesting that the whole thing is based around PKI and a trivial shell script. Stupid simple, yet potentially devastating.
@@douggodsoe It's funny because anyone can read the bash script before running it so the chances of this attack being successful is close to none. It's done in an extremely amateur way.
@@dingdong2103 Oh, definitely, but people don't read, they just click and run. Good Times! Sorry for being a dick earlier. I get like that when I've been drinking, which is often. Still, good video, yeah?
Yeah, this is a very straightforward encrypt/decrypt solution using libssl. It's very similar to how TLS streams work at a high level (pub key used to encrypt a symmetric session key.) One property of good encryption & decryption algorithms is you should be able to know everything about them and how they work, and not be able to decrypt ciphertext without the secret or private key. In theory at least, for example there are implementation errors, like using a weak random number generator
Great video, this has been on my mind though: Why would a ransomware writer want to obfuscate their code? If their main goal was to collect ransom, and the program was cryptographically secure, wouldn't they want to lay out everything they did in an easy to understand way? Beeing able to see exactly how I was pwned would give me at least a little bit more confidence that I would get a key in exchange for money.
I don't think these people are that sophisticated to consider such things. It's like asking, why would a rock want to roll down a hill? Don't think too hard on it. The answer will not provide enlightenment.
@@Randrew .. which makes them much less likely to be detected as malware than custom code which has been used in other malware and is known to the anti-malware community.
This part of the malware is not the valuable part. This is just some basic encrypt / decrypt software that probably took them like half a day to make. Hell I'm surprised they didn't provide a readme / documentation for how it works. After all, their goal is to convince you that you'll get your stuff back if you pay the ransom. The real important part is how they got the files onto your server and ran them. That's the secret part that I'm sure they'd want to protect.
I'm approaching old fart status and I enjoy content on a 50 inch 4k TV as my monitor ;) Quite legible with small fonts no matter how many terminals or windows I choose to have open.
Be honest; small fonts are not the reason you don't read. I get it. Words are hard. I'm just teasing you, man. Don't go getting all angry and start beating your kids when they refuse to learn Python because untyped languages are for kitty cats. I, too, dig the big readable fonts.
I think they can leave the debug on because anyone analyzing the binaires will just learn that he cannot actually decrypt the files without the private key. The sooner the victim realizes that he cannot decrypt the files without the private key, the better for the scammer. The scammer could truly send the source code that it wouldn't matter. As for obtaining the private key form the public key, that is possible in theory. However, you won't be able to find the private key in practice unless the key is way too small (which is unlikely) or has been made by a program that is way way too predictable in how it generates its keys (and you know or guess that that program has been used to create the key) . You could wait until quantum computers with as many quantum bits as the public keys are a real thing (and boy that will be a mess when they reach that stage...) but that might be a long wait... As for using modern supercomputers, you are very unlikely to find the private key with them unless it was generated using some weak algorithms.
It is never impossible to decrypt a file, but if the expected decrypt time is too long, nobody will bother trying. Most professional cryptographers aim for a typical decryption time to sink to about 10 years before they improve their algorithms.
@@hb1338 how do people predict decryption times? As a hypothetical, say I have a four bit decryption key. That's 511 possible combinations. If I can test a combination every second, then there's a 50/50 if I get it in the first 255 seconds, then if I don't it's a 50/50 if I get it in the following 127 seconds, then if not it's a 50/50 if I get it in the next 63 then a 50/50 if I get it in the next 31, then a 50/50 if I get it in the next 15, then a 50/50 in the next 7 then a 50/50 in the next 3 and a 50/50 in the next 1.5 then 100% after 511 seconds. By the time you get to 7 seconds left that's a 1/64 chance that I haven't gotten it. So is it just the time it takes to test half of the possible combinations they use as an estimate or is it 3/4 or at what point do they consider it likely enough to be expected that you've found the combination?
Great video! 4:14 Large font is very much appreciated but 64 pt is maybe a tad TOO large. 48 pt or 56 pt might be a better compromise. 5:32 Also, maybe make your camera be a slightly smaller circle and move it up to the right so it doesn’t obscure the code
3:57 *Missing summary:* There are two types of encryption: * symmetric, and * asymmetric. *Symmetric* cryptography uses the *same key* for encryption and decryption. *Asymmetric* cryptography has the *FULL key split in half:* a public key and a private key.
Asymmetric encryption have not "key split in half", there's a private key that is pseudo-raandomly generated and a public key that is derived from the private key.
@@iAPX432 Not even wrong. 1. Yes, the FULL key is _effectively_ split in half, we call this the private key and public key. You are arguing over semantics. 2. Some people DO have access to TRUE random number generation. 3. It depends on the algorithm. In ECC this is true but in RSA this is false. p and q are used to calculate the private key (d,n) and the public key (e,n). While it is possible to generate (e,n) from (d,n), usually due to a bad e, it NOT a guarantee.
very nice code! I've seen corporate code that looked worse than this malware. Also: security lives from openness. The symbols were left in, so you could read it. And if you had found a bug, only then they could have improved your malware ^^
I just wanted to take a moment to express my appreciation for your incredible UA-cam channel. Your dedication to teaching low-level programming concepts and techniques is truly inspiring,. I would love to hear your personal story about how you learned reverse engineering, and any tips or advice you have for people who are just starting to explore this topic, and thank you.
There was a time when the only "easy" way to reverse engineer something was by examining hex code dumps. A very good way to learn reverse engineering is to do forward engineering - if I write this source code, what does it look like after it has been compiled etc
They bought the code. They didn’t write it themselves and must pay a fee to the script writer. The signatures are to ID the program and who must be paid.
Рік тому+49
Was the "encrypt" command really malware though? It looks like a useful cli tool for legitimate purposes, and maybe it's open source software that they pulled off someone's github - in which case they wouldn't care if someone gets into the source code.
You're mostly right. Like David mentions in this thread, the design is a tad aggressive about finding an openssl lib to load. Everyone else would stick to a major and/or minor openssl version and fail hard in other cases since incompatibilities open up support problems. But other than that, it's a very robust (would run on most any linux) pair of encrypt/decrypt openssl wrappers.
if you think about it, ransomwares are just script that encrypt your files. The action of encrypting things isn't malicious because you might want to do it yourself for privacy.
They can run just string reversion, for example taking some strings from the end of file and putting it to the start of file, so you cant open it, and mention that it's strongly encrypted. ive got a ransom like that once. Its time saving, when you need to corrupt large amount of data, before ransom to be found
I have been coding in assembly since the late '70s, working with processors like 8088/86. One effective method to avoid dealing with semi-script kiddie activities is to restrict access to specific files through a tunneling script stored in the RAM. There are various ways to achieve this using concise code snippets. It seems like the world has it backward; instead of preventing such issues with straightforward methods, many rely on extensive, advanced, and expensive antivirus software. What's the point?
Exactly, in fact it might make the victims more likely to payout because they can see that your binary uses openssl and therefore is unlikely to have cryptographic vulnerabilities.
Moreover, by keeping everything they show they understood the math. Obfuscation is only ever done to hide ineffective security algorithms or by those who do not understand at all. Hiding proprietary encryption would always amount to hiding probably ineffective algorithms, so even those cases are ruled out. If you understand science your only real option is to take a stance and show everything, they should even provide a donload link for the source code.
They use rsa_encrypt directly on a blank symmetric key? Did you check the public key for having a low exponent e? If it's 3 or 7 you might just be able to take the 3rd or 7th root of the value to get the symmetric key out.
Hey, cybersec engineer student here poking around with reverse engineering. Love the quality of the content! I'd love to try and apply my knowledge on some malware reversing. Is there any (softly) obfuscated malware that you would recommend to play with?
The way the ransomware is encrypting--ie. making the symmetric key with their public key, and then they supply the corresponding private key to that when someone pays--doesn't that imply that the first person to get that private key could decrypt anyone else's ransomware-encrypted files? ie. Their algorithm does not employ perfect forward secrecy.
As someone who often watches on his phone, I appreciate the effort, but you don't need the font THAT big. If you're watching a programming video in portrait mode on your phone you're doing something wrong. Also, "with debug_info, not stripped" LOL. I'm no infosec/reverse engineering guy, but seeing that in malware is hilarious.
You know what people I commented on a lot of videos about not being able to read them and stuff. This is the first content creators that I ran into that's actually blown it up for the people that have to use the phones that are too poor for the internet. So just content creator on the sign up for that thank you for considering us is part of your viewing group.
If they give you the private key, wouldn't that mean that you could just share it and everyone else will be able to decrypt their files? Also, I think the thing I was most curious about was how they encrypt the file in place. The cryptography stuff seems like they are just using standard stuff, seems unlikely they would mess up there. BTW, wouldn't they want for people to be able to inspect the code at some extent? If you are confident that the code will actually recover your files you're more likely to pay than if you suspect the files may just been overwritten entirely and are now impossible to recover. Leaving debug info may be intentional. There's nothing to hide there anyway, they are doing exactly what you'd expect and the only solution is paying them.
Conclusion: Nothing weird or unexpected. On a side-note, if more linux programs were made this way, where they scan for the libs they need and then check each lib to ensure it has what they need, they'd save people a lot of headache with the perpetual fail of libs and their dependencies, and the various versions of them, which often make it difficult to produce an executable that "just works" regardless of the distro.
The reason that apps usually don't do this is that there can be other changes not captured by the symbol name alone that would cause crashes or other misbehavior if it loaded the "wrong" version. So most apps, especially open source apps that will just be recompiled with exactly the right version, just expect a single known version to avoid potential incompatibilities.
@@Mirality While what you say is true, how is that worse than the program not working at all because of some subversion increment on a lib? Linux is by nature a collection of individual programs that do stuff, so while larger apps may not work using this approach, single-executable programs would probably work best. For example, megacli (for viewing details about LSI Logic raid controllers and making changes as needed).
Because "other misbehavior" is not limited to crashing. It could include formatting your drive or sending your credit cards to scammers. While this particular case is malware anyway so those things are on the table even without misbehavior, leaving those kinds of holes can be openings for malware to trick regular programs into doing it, or if you're really unlucky, it happening by accident. Provided that library authors follow the rules, that particular version number is only incremented for "serious incompatible change", which does require programs to at least recompile, if not also change their code. There are different version numbers for more backwards-compatible changes which do allow upgrading a library without recompiling.
@@Mirality You could make a malicious program that follows the "rules". I don't really see that as a valid counterpoint. There are also plenty of programs that do things the "right way" and still end up with memory leaks and vulnerabilities. Perhaps linux has been somewhat resilient to malware due to the poor to non-existent compatibility among distros but it is also a hindrance. From the programmers' perspectives you either compile for all distros you want to support or release source and let them do it...but maybe you just want to distribute a 'universally compatible' executable. There is nothing wrong with that, and rules are really just suggestions.
@LunacyStudy That's the theory, but you miss the point that the linker will only link what is on the particular distro you are building on. You can't compile an exe on fedora that depends on certain libs of certain versions, then expect it to run without issue on gentoo or even older versions of centos. Loading what you need at runtime works, and there really is no good argument against it, especially if you are dealing with basic stuff like openssl.
I think, even stripped binary without debug info would have symbol table. Due to external linkage in C/C++ for main function, you'll see it there as it is required for possibility of late symbol resolution (e.g. substituting original main with something else during run-time).
they left the debug info to prove that if they give you the private key, you can build a decrypter by yourself, so you know that there is something to buy. quite smart. also if you buy the decript key but you don't have a way to verify or build by yourself the decrypt program, the effort to write a decryptor could be significative and also you may not trust the decrypted data and then make less likely to buy the key. i think that it is really to make you to buy the key, and it is a very smart move.
It seems like the authors took "security through obscurity isn't security". I mean, having it not obfuscated probably lets the victims know there is no other way than paying up, and prevents wasting everyone's time I guess. And it also makes it abundantly clear that the only way out is the private key, and could also be a way to tell "lmao it's so simple, babies could write this encrypt binary, get rekt lol", so maybe a flex there too, I guess? This shows that the actual "malware" isn't advanced, the way they got it in is. And honestly, bringing light to this is the good part. Because let's face it, most OSs these days have good protection. The only "vulnerability" is probably the organization and/or the humans in the gears.
passwords are obscurity, encryption is obscurity, heck even a firewall is obscurity. Obscurity is big part of security. The way i fixed SSH brute force attempts is obscurity, not obscuring just by port but by ip address as well. You can block port scanning and use port knocking as well but ultimately what stopped it is getting a seperate IP adress for SSH(and not putting that IP address on your DNS records of your web service).
@@ChrisWijtmansI guess what I was trying to say is that obscurity shouldn't be the only / the most 'powerful' of the protections that are there, You do make valid points, but in my head, it feelsl like the only thing obscurity does is slow someone down. There are pretty good analyzers these days that might get through it. Basically, defeating obscurity is a matter of when, not a matter of if, unlike more established security practices. But yeah obscurity perhaps does have its place, at least at stopping the script-kiddies that just think "haha script go brr"
@@ChrisWijtmans passwords are entropy, not obscurity. the two are well-defined and distinct, but you are playing word games and rejecting what words mean.
Thank you LLL!!! Seriously bro, that move is next level! That is how you take care of the peeps consuming your content. This is the first video I have seen of yours but I have subbed and liked this vid. Keep killing it!
If you're confident that your encryption is good then not stripping the binary will just help security analyst tell their clients that they indeed would need to pay to be able to decrypt it faster. Ransomware is a full-on business at this point.
As someone who's recently been getting into the low-code/JS space due to work, this was very interesting, as you covered the main functions and described what they do, leading to better understanding! Got a subscribe from me.
One problem: first "customer" who pays up has now the decryption key that can be used to help all other victims of this particular copy of the malware. Unless they use different public keys for all of their victims, which seems to be not very practical.
4:06 - what? no. You encrypt using the public key, needing the private from them. - If you encrypted with private key, you could decrypt it with the public key :D (if it's possible at all) EDIT: yeah, ok, sorry, you corrected yourself. It was just a slip of the tongue.
They don't care if you have the encryption/decryption algorithm since it doesn't do much good without the private key. It seems unlikely they're "mad at you". Still, an interesting video.
So the only weird thing was the presence of debug symbols? I was expecting _a lot_ more with such a clickbait title. This ended up just being a walkthrough of the most basic steps for how _ordinary_ encryption/decryption works, and barely even that.
why should the attacker care if you reverse engineer their binary? 2:47 - They don't want you to find the vulnerability that gave them exec permission on the host. And they don't want the channel used for money transfer to lead to their identity. That's all. - Antivirus people will find a way to fingerprint the binary regardless of it being stripped or reverse engineered or what not. - If the data is "properly" encrypted, it doesn't matter that you know the alg - without the key you cannot do anything anyway.
My guess is the malware author intentionally left the debug symbols for analysis, so it would be obvious upon review that the victim was indeed screwed! Curious what an openssl dump of the public pem file would reveal??
People who got hit by this ESX attack should be fired. The version that was touched by this attack had been release in december 2020 for 7.x and february 2021 for 6.7 ! They were a year late in patching
Unfortunately, VMWare release practices prevent upgrading past the last version with hardware drivers released for a given server model. When the latest attack description came out it was something that should have been blocked by firewalls already (remote access to an internal admin network address). But yeah, replacing ESXi by something else will be more maintainable.
The concept of the series is nice but the example is not great. You can tell exactly what the binaries do just from looking at the shell script, and it doesn't really help to have debug symbols etc because what you really need is the private key. They pretty much could have done the same thing using readily available cli tools. It would be nice if you could show examples where reverse engineering lets you fix the damage because they have done something stupid like embedded the key in the binary etc, but I don't know how easy it is to find examples of that kind of thing.
Love your LL system-related content, could you do one regarding how to use the core dump of a segfaulted C executable? I'd love your explanations on that.
@@xblxckxpxny1005 A core dump contains the registers (such as IP), memory, and callstack; this can be used to help determine where add why the program crashed.
The debug info was probably intentional so it’s easy to see it’s cryptographically sound to anyone trying to analyze it. It doesn’t make the security any weaker, right?
Just a bunch of random data; you could consider it an IV or "key" or both... But I agree, I would refer to it as IV since that is usually stored with a file since it isn't secret whereas a (private) key is.
The big question is of course where or how is the keypair generated. If the attacker just provides the same pair, then a leaked private key that was once paid would be enough to make an universal decoder.
That would be a terrible idea. Because many people who now work in cybersecurity used to write these kinds of software themselves before „coming clean“. Also the death penalty is completely unjustified for this and completely immoral.
Ok, so its just a basic set of encrypt decrypt binaries. Nothing special about that. I wouldn't have stripped it either. Where is the actual virus part that maliciously gets the binaries on there and executes it without the user executing it? Reverse engineering the encrypt and decrypt binaries was just a waste of time and revealed nothing special.
The first thing that struck me was that the encrypt and decrypt binaries weren't really malware. The could have just use the openssl executables instead. The malware was the script.
Using RSA encryption on the symmetric key is a potential flaw in the malware depending on the key size. Prime number sieves are good enough now that any RSA key less than 1kb size can be cracked.
Two questions about how this scam works. One, how do the scammers have the decrypt key but the victim does not? And two, is that key unique per victim? If not, the scammer should expect to only sell one key.
It's due to the asymmetric pair of keys used... You can freely distribute a public key that can be used to encrypt any random piece of information, after which the cypher-text can only be decrypted with the corresponding private key LLL said at 3:57 he'll explain later, but i don't think he ever did. (or at least not in _this_ video). As for the "only sell one", you're technically correct, except how would a victim find any other internet user who bought that particular key from that particular ransomware-dealer from the billions potential ones? Especially considering their tech savviness allowed them to fall victim in the first place.
@@irrelevant_noobHowever the security consultant helping them could package up the key into a "save all machines hit by XYZ malware" tool, as has happened before when the key could be retrieved in other ways.
I'm a mobile user and the text size is way too big. Not sure why people keep using ridiculous text sizes, especially when you can zoom into videos in the UA-cam app.
Ok, I didn't expect a simple open bash script doing a lot of it. Possibly explains why there was a lot of seemingly rookie moves in the encryption code. I suppose it does what it needs to do to accomplish what they're trying to get done. It will be enough to get a result from most people and businesses.
I think leaving symbols is a good idea. If someone were victim to this ransomware and had the technical background to look at the code- that means they're being given confidence/trust that when you buy the key, it can/will actually decrypt the VM. Since it's encrypting VM's, it seems likely that they're attacking organizations where its quite plausible that someone could find this. Moreover, they didn't seem to have forgotten to remove symbols, they seem to have explicitly included an instruction to keep the symbols?
Thanks LLL, not mobile, but legally blind. I was able to read your 64 point font. Since they built the encryption right, it doesn't matter that they didn't strip the binary … all that does is tell you that if you pay, they CAN actually decrypt your data. OTOH it also tells you that once they give you the key that decrypts you, it probably decrypts everyone hit by this malware. That actually poses an interesting thought if I were a malware author myself-a ransom pool. By the time the ransomware is spreading, the servers that'll release the key have already been set up and will never be touched again. If the thing spreads fast and the ask is relatively conservative, a large entity hit hard might have just paid it by the time smaller fish get infected. The malware in that case may just suicide with a "you got lucky" message. Meanwhile before anyone's looking for the bastard who wrote it seriously, they've already cashed out and vanished. IDK why anyone would do that, but it'd be damned hard to catch the people doing their "one-time" heist. Especially if they truly did just do it one-time.
Not stripping the executable seems to be intentional. It's so you can validate that it is possible that you can get your data back (data recovery is possible, but who knows if they actually give it back). There are many 'ransomware' cases where the person has their data encrypted into oblivion and the keys being thrown out with no hope of recovery.
I'd be interested in how they get the RSA pubkey to the script in the first place. They must have distributed a bunch of separate pubkeys or else the first guy who pays the ransom could just share the private key with everyone else. Wannacry did a more sophisticated job of this -- it made up random keys just for you, encrypted those, then you'd send them in with your bitcoin to get them decrypted. In theory, anyway.
Leaving the debug information in the executable does not help you decrypt the data. What it does do is help you to find out that the crypto it is using is asymmetric and likely robust, which actually pushes you to wanting to get the private key. So really the debug information helps the attackers.
It would be very nice if you would summarize your result and present it in a simpler way. You explain everything very well but also very fast with jumping around in Ghidra. I would like to see some summary after all the code like: The program does: 1. This 2. This 3. This to archieve This and this... You could then explain a bit more detailed what all this means and also reach people who are not so much into the topic or don't know, for example, how SSL or asymmetric cryptography works. I'm a programmer but not a Security Analyst and would love get more background knowledge and information from your videos. Anyway. Very cool video definitely a subscription from me.
It makes a lot of sense to leave ransomware easily reverse-engineered, because it helps prevent a few of the ways the scam can fail if the victim suspects the ransomware isn't being candid -- about what it actually did to the files, or whether it's actually worth paying up in the hopes the decryption key they receive works. Keeping the malware easily inspected, a savvy victim can assure themselves that (a) the encryption _is_ reversible, the files aren't just scrambled to "look" encrypted, (b) there's no "stage 2" to the malware when they run the decrypt binary, (c) the encryption itself is sound, with no way to defeat it except by actually obtaining the key from the hacker, and (d) the files themselves probably haven't been exfiltrated, so there's no PII dump that'll be putting them in the news in a few weeks even if they _do_ pay up.
I had an email from a scammer telling me they had my password. They did, but it was a very old one that I only use for unsecure networks where I have to log into crap I don't want to use that I only use there. I remember the email was "I have my malware in your modem" or something "you can try to change your password but I will catch it every time". He demanded bitcoin and then he's go away, and "don't be mad, we all have our jobs". Seriously, who tries to pass off such disgraceful attacks as "just doing their job"? Obv the scum never got a penny.
Judging from this dive, it sounds like the ransomware does have one weakness*: as long as the binary depends on a static private key, once that key is out in the wild, basically anyone can "pirate" the key causing that specific binary to be easily defeatable. Obviously the author would want a decent windfall before that happens. And * it's not a cryptographic weakness of the code itself, but rather a social-engineering one.
I'm surprised the binary isn't simply just a call to "openssl encrypt " with the corresponding public key straight up. Eventually copying the parts of openssl required to do that. It's a low-effort yet still effective ransomware.
Great VLOG. Nicely done. I missed what they did with the private key. Stored it somewhere, or transmitted it back to themselves.? Thanks (I used to work at RSA on their cryptography architecture team.) I wound up in data security consulting.
that code in itself isnt ransomware. how it was used is. this would explain why they didnt bother removing the symbols. it wasnt initially designed for what it is being used for.
I haven’t a clue what you just did or either do I understand what you said, but I still appreciate your knowledge, and respect the fact you’re always trying, and most instances succeeding, to be one better than the people who cause so much misery to so many people. Thank you 🙏
Cool to see the walk through. How the script gets the argument ls to run the encrypt command. So we know what it ran. Even have how to use the decrypt binary. Still doesn’t save the day or what the decrypt rsa token would be.
wanna learn assembly? check out my courses at lowlevel.academy
Thank you, LLL ❤
Love the large cursed font on my mobile
Honestly, the large font size is useful on larger screens as well! Much, much easier to read.
large font gang rise up
My god i didn’t understand anything you said lol maybe it’s my age 76 😎
Yes, thank you!
I was able to watch this video from my neighbor's laptop without needing binoculars!
😄
I'm a little on the fence. It's dead easy to read, but it reduces the amount of context I get from the surrounding code because of the little that fits on a single screen
Agreed.
Even if I can read small print, doesn't mean that I want to when it's available in a larger size just as easily.
Maybe they left the debug symbols because they knew that even when you disassemble it, you won't be able to extract any information that could help the victim. I.e. it was a "flex".
That and it makes it clear that if they pay and get the private key that the data is actually recoverable.
Or the binaries were simply „borrowed” from something else by script kiddie… ;)
Borrowing code doesn't necessarily mean you are a script kiddie.
@@jordixboy the implication here is that they 'borrowed' the code, and didn't bother with removing the debug symbols, or didn't even know how one would do that
I'd rather think it's incompetence, ransomware authors typically "flex" by specially naming mutexes, threatening ransom notes, unobfuscated strings and so on instead of leaving the debug symbols.
Considering the part that causes actual harm is an unobfuscated *bash script,* it's pretty safe to say that leaving symbols in their generic encrypt/decrypt binaries wasn't a consideration.
This kind of malware is effective thanks to women in the workplace. You can rest assured that Karen from HR will click the link to reveal how she can claim the $500 amazon gift card she just won....every...friggin...time.
pretty funny to see it's a regular shell script
@@dingdong2103 Is it though? Funny, I mean. Demented and sad, maybe, but is it really funny? Like, two guys walk into a bar, which is weird because you would think that after the first guy walked into it, the second guy would have seen it. That's funny. Hey, want to hear a joke? This guy I don't know had all of his ERP files encrypted by some scammer using a regular shell script! He couldn't afford the ransom, so ended up losing his business! Ha ha ha ha! It was a shell script! Get it? That's not really funny, right? There's a set up, but not much of a pay off.
I'm really sorry, I've gone off for far too long; I get like that sometimes. If by funny you mean, wow interesting, then yes, it is disturbingly interesting that the whole thing is based around PKI and a trivial shell script. Stupid simple, yet potentially devastating.
@@douggodsoe It's funny because anyone can read the bash script before running it so the chances of this attack being successful is close to none. It's done in an extremely amateur way.
@@dingdong2103 Oh, definitely, but people don't read, they just click and run. Good Times! Sorry for being a dick earlier. I get like that when I've been drinking, which is often. Still, good video, yeah?
They made the binaries easy to use because they wanted you to know that there is no backdoor, you need to get (ie. pay for) the private key.
Plus not stripping also increases the odds that their genius will be talked about, maybe even on UA-cam.
Anyone qualified to make that determination would not need the debug symbols. (or trust them!)
Yeah, this is a very straightforward encrypt/decrypt solution using libssl. It's very similar to how TLS streams work at a high level (pub key used to encrypt a symmetric session key.)
One property of good encryption & decryption algorithms is you should be able to know everything about them and how they work, and not be able to decrypt ciphertext without the secret or private key. In theory at least, for example there are implementation errors, like using a weak random number generator
And more importantly they wanted their "customers" to trust that their data is recoverable.
Oh, geez. I just commented (see above) and then I saw that you guys (and some others) explained this better! Lesson learned.
Great video, this has been on my mind though: Why would a ransomware writer want to obfuscate their code? If their main goal was to collect ransom, and the program was cryptographically secure, wouldn't they want to lay out everything they did in an easy to understand way? Beeing able to see exactly how I was pwned would give me at least a little bit more confidence that I would get a key in exchange for money.
the point is presumably - they realize they could have bugs, so it makes sense to make it harder to find them
Ransomware authors may do so to evade AV heuristics and prevent other ransomware authors from copying features from their own product.
These two binaries are vanilla encrypt/decrypt apps with nothing to hide.
I don't think these people are that sophisticated to consider such things. It's like asking, why would a rock want to roll down a hill? Don't think too hard on it. The answer will not provide enlightenment.
@@Randrew .. which makes them much less likely to be detected as malware than custom code which has been used in other malware and is known to the anti-malware community.
Keep the cybersecurity stuff coming 😎
Yes please :)
This part of the malware is not the valuable part. This is just some basic encrypt / decrypt software that probably took them like half a day to make. Hell I'm surprised they didn't provide a readme / documentation for how it works. After all, their goal is to convince you that you'll get your stuff back if you pay the ransom. The real important part is how they got the files onto your server and ran them. That's the secret part that I'm sure they'd want to protect.
Yes, good point. It also makes it clear to the victim there is no trick they can do to recover the files.
Thank you LLL
Thank you LLL!
Thank you for the big fonts!! I wish the other UA-camrs would do this more: I only consume content from my phone and it’s always hard to read.
On made-for-mobile content the click here endings look silly. Everyone does them. I chuckle.
I'm approaching old fart status and I enjoy content on a 50 inch 4k TV as my monitor ;) Quite legible with small fonts no matter how many terminals or windows I choose to have open.
On mobile you can pinch to zoom in up to 8x.
Be honest; small fonts are not the reason you don't read. I get it. Words are hard.
I'm just teasing you, man. Don't go getting all angry and start beating your kids when they refuse to learn Python because untyped languages are for kitty cats.
I, too, dig the big readable fonts.
Thank you triple L. Loving the cyber security content! Keep it coming.
I think they can leave the debug on because anyone analyzing the binaires will just learn that he cannot actually decrypt the files without the private key.
The sooner the victim realizes that he cannot decrypt the files without the private key, the better for the scammer.
The scammer could truly send the source code that it wouldn't matter.
As for obtaining the private key form the public key, that is possible in theory.
However, you won't be able to find the private key in practice unless the key is way too small (which is unlikely) or has been made by a program that is way way too predictable in how it generates its keys (and you know or guess that that program has been used to create the key) . You could wait until quantum computers with as many quantum bits as the public keys are a real thing (and boy that will be a mess when they reach that stage...) but that might be a long wait... As for using modern supercomputers, you are very unlikely to find the private key with them unless it was generated using some weak algorithms.
It is never impossible to decrypt a file, but if the expected decrypt time is too long, nobody will bother trying. Most professional cryptographers aim for a typical decryption time to sink to about 10 years before they improve their algorithms.
@@hb1338 how do people predict decryption times? As a hypothetical, say I have a four bit decryption key. That's 511 possible combinations. If I can test a combination every second, then there's a 50/50 if I get it in the first 255 seconds, then if I don't it's a 50/50 if I get it in the following 127 seconds, then if not it's a 50/50 if I get it in the next 63 then a 50/50 if I get it in the next 31, then a 50/50 if I get it in the next 15, then a 50/50 in the next 7 then a 50/50 in the next 3 and a 50/50 in the next 1.5 then 100% after 511 seconds. By the time you get to 7 seconds left that's a 1/64 chance that I haven't gotten it. So is it just the time it takes to test half of the possible combinations they use as an estimate or is it 3/4 or at what point do they consider it likely enough to be expected that you've found the combination?
Great video!
4:14 Large font is very much appreciated but 64 pt is maybe a tad TOO large. 48 pt or 56 pt might be a better compromise.
5:32 Also, maybe make your camera be a slightly smaller circle and move it up to the right so it doesn’t obscure the code
3:57 *Missing summary:* There are two types of encryption:
* symmetric, and
* asymmetric.
*Symmetric* cryptography uses the *same key* for encryption and decryption.
*Asymmetric* cryptography has the *FULL key split in half:* a public key and a private key.
Asymmetric encryption have not "key split in half", there's a private key that is pseudo-raandomly generated and a public key that is derived from the private key.
@@iAPX432 Not even wrong.
1. Yes, the FULL key is _effectively_ split in half, we call this the private key and public key. You are arguing over semantics.
2. Some people DO have access to TRUE random number generation.
3. It depends on the algorithm. In ECC this is true but in RSA this is false. p and q are used to calculate the private key (d,n) and the public key (e,n). While it is possible to generate (e,n) from (d,n), usually due to a bad e, it NOT a guarantee.
very nice code! I've seen corporate code that looked worse than this malware. Also: security lives from openness. The symbols were left in, so you could read it. And if you had found a bug, only then they could have improved your malware ^^
common lowlevellearning W
I just wanted to take a moment to express my appreciation for your incredible UA-cam channel. Your dedication to teaching low-level programming concepts and techniques is truly inspiring,. I would love to hear your personal story about how you learned reverse engineering, and any tips or advice you have for people who are just starting to explore this topic, and thank you.
There was a time when the only "easy" way to reverse engineer something was by examining hex code dumps. A very good way to learn reverse engineering is to do forward engineering - if I write this source code, what does it look like after it has been compiled etc
They bought the code. They didn’t write it themselves and must pay a fee to the script writer.
The signatures are to ID the program and who must be paid.
Was the "encrypt" command really malware though? It looks like a useful cli tool for legitimate purposes, and maybe it's open source software that they pulled off someone's github - in which case they wouldn't care if someone gets into the source code.
Probably was malware, given that they opened OpenSSL and dynamically loaded symbols. You usually wouldn't do that...
True, but if it's open source, maybe that's the only thing they actually changed.
You're mostly right. Like David mentions in this thread, the design is a tad aggressive about finding an openssl lib to load. Everyone else would stick to a major and/or minor openssl version and fail hard in other cases since incompatibilities open up support problems. But other than that, it's a very robust (would run on most any linux) pair of encrypt/decrypt openssl wrappers.
Forgetting to remove debugging symbols is just inefficient. No reason not to remove them in your final executable.
if you think about it, ransomwares are just script that encrypt your files. The action of encrypting things isn't malicious because you might want to do it yourself for privacy.
They can run just string reversion, for example taking some strings from the end of file and putting it to the start of file, so you cant open it, and mention that it's strongly encrypted. ive got a ransom like that once. Its time saving, when you need to corrupt large amount of data, before ransom to be found
I have been coding in assembly since the late '70s, working with processors like 8088/86. One effective method to avoid dealing with semi-script kiddie activities is to restrict access to specific files through a tunneling script stored in the RAM. There are various ways to achieve this using concise code snippets. It seems like the world has it backward; instead of preventing such issues with straightforward methods, many rely on extensive, advanced, and expensive antivirus software. What's the point?
Why should they strip their code? If it is secure, then this information is useless anyway?
Exactly, in fact it might make the victims more likely to payout because they can see that your binary uses openssl and therefore is unlikely to have cryptographic vulnerabilities.
Moreover, by keeping everything they show they understood the math. Obfuscation is only ever done to hide ineffective security algorithms or by those who do not understand at all. Hiding proprietary encryption would always amount to hiding probably ineffective algorithms, so even those cases are ruled out. If you understand science your only real option is to take a stance and show everything, they should even provide a donload link for the source code.
They use rsa_encrypt directly on a blank symmetric key? Did you check the public key for having a low exponent e? If it's 3 or 7 you might just be able to take the 3rd or 7th root of the value to get the symmetric key out.
Hey, cybersec engineer student here poking around with reverse engineering. Love the quality of the content!
I'd love to try and apply my knowledge on some malware reversing. Is there any (softly) obfuscated malware that you would recommend to play with?
The way the ransomware is encrypting--ie. making the symmetric key with their public key, and then they supply the corresponding private key to that when someone pays--doesn't that imply that the first person to get that private key could decrypt anyone else's ransomware-encrypted files? ie. Their algorithm does not employ perfect forward secrecy.
LLL Is the best! Thank you! Just a question, the name of disassembler software that you use is "Ghidra" ?
Yes, correct
So what was the weird thing you found? That the debug into was left in?
As someone who often watches on his phone, I appreciate the effort, but you don't need the font THAT big. If you're watching a programming video in portrait mode on your phone you're doing something wrong.
Also, "with debug_info, not stripped" LOL. I'm no infosec/reverse engineering guy, but seeing that in malware is hilarious.
The bigger font is helpful for computer users and people who struggle to see. Not everyone can afford glasses sadly
It's not the malware, it's the payload. The malware is the program that loads and executes theese programs.
As a cell phone user i love that you made the font larger 🙃 i appreciate your thoughtfulness
Thank your triple L
You know what people I commented on a lot of videos about not being able to read them and stuff. This is the first content creators that I ran into that's actually blown it up for the people that have to use the phones that are too poor for the internet. So just content creator on the sign up for that thank you for considering us is part of your viewing group.
If they give you the private key, wouldn't that mean that you could just share it and everyone else will be able to decrypt their files? Also, I think the thing I was most curious about was how they encrypt the file in place. The cryptography stuff seems like they are just using standard stuff, seems unlikely they would mess up there.
BTW, wouldn't they want for people to be able to inspect the code at some extent? If you are confident that the code will actually recover your files you're more likely to pay than if you suspect the files may just been overwritten entirely and are now impossible to recover. Leaving debug info may be intentional. There's nothing to hide there anyway, they are doing exactly what you'd expect and the only solution is paying them.
They would encrypt with a different public key per victim, so the corresponding private key wouldn't be helpful to anyone else
@@I3i11W So this is spear phished? It's not clear from this info where the RSA keypair comes from.
Sha-256 salted is what they use to do
Conclusion: Nothing weird or unexpected.
On a side-note, if more linux programs were made this way, where they scan for the libs they need and then check each lib to ensure it has what they need, they'd save people a lot of headache with the perpetual fail of libs and their dependencies, and the various versions of them, which often make it difficult to produce an executable that "just works" regardless of the distro.
The reason that apps usually don't do this is that there can be other changes not captured by the symbol name alone that would cause crashes or other misbehavior if it loaded the "wrong" version. So most apps, especially open source apps that will just be recompiled with exactly the right version, just expect a single known version to avoid potential incompatibilities.
@@Mirality While what you say is true, how is that worse than the program not working at all because of some subversion increment on a lib?
Linux is by nature a collection of individual programs that do stuff, so while larger apps may not work using this approach, single-executable programs would probably work best. For example, megacli (for viewing details about LSI Logic raid controllers and making changes as needed).
Because "other misbehavior" is not limited to crashing. It could include formatting your drive or sending your credit cards to scammers. While this particular case is malware anyway so those things are on the table even without misbehavior, leaving those kinds of holes can be openings for malware to trick regular programs into doing it, or if you're really unlucky, it happening by accident.
Provided that library authors follow the rules, that particular version number is only incremented for "serious incompatible change", which does require programs to at least recompile, if not also change their code. There are different version numbers for more backwards-compatible changes which do allow upgrading a library without recompiling.
@@Mirality You could make a malicious program that follows the "rules". I don't really see that as a valid counterpoint. There are also plenty of programs that do things the "right way" and still end up with memory leaks and vulnerabilities. Perhaps linux has been somewhat resilient to malware due to the poor to non-existent compatibility among distros but it is also a hindrance. From the programmers' perspectives you either compile for all distros you want to support or release source and let them do it...but maybe you just want to distribute a 'universally compatible' executable. There is nothing wrong with that, and rules are really just suggestions.
@LunacyStudy That's the theory, but you miss the point that the linker will only link what is on the particular distro you are building on. You can't compile an exe on fedora that depends on certain libs of certain versions, then expect it to run without issue on gentoo or even older versions of centos. Loading what you need at runtime works, and there really is no good argument against it, especially if you are dealing with basic stuff like openssl.
If all universities taught like this, we would have a much difficult time getting jobs...
what was the something WEIRD? the debug symbols?
I think, even stripped binary without debug info would have symbol table. Due to external linkage in C/C++ for main function, you'll see it there as it is required for possibility of late symbol resolution (e.g. substituting original main with something else during run-time).
Yes, it's also required for dynamic linking if I am not wrong.
they left the debug info to prove that if they give you the private key, you can build a decrypter by yourself, so you know that there is something to buy. quite smart. also if you buy the decript key but you don't have a way to verify or build by yourself the decrypt program, the effort to write a decryptor could be significative and also you may not trust the decrypted data and then make less likely to buy the key.
i think that it is really to make you to buy the key, and it is a very smart move.
It seems like the authors took "security through obscurity isn't security". I mean, having it not obfuscated probably lets the victims know there is no other way than paying up, and prevents wasting everyone's time I guess.
And it also makes it abundantly clear that the only way out is the private key, and could also be a way to tell "lmao it's so simple, babies could write this encrypt binary, get rekt lol", so maybe a flex there too, I guess? This shows that the actual "malware" isn't advanced, the way they got it in is. And honestly, bringing light to this is the good part. Because let's face it, most OSs these days have good protection. The only "vulnerability" is probably the organization and/or the humans in the gears.
passwords are obscurity, encryption is obscurity, heck even a firewall is obscurity. Obscurity is big part of security. The way i fixed SSH brute force attempts is obscurity, not obscuring just by port but by ip address as well. You can block port scanning and use port knocking as well but ultimately what stopped it is getting a seperate IP adress for SSH(and not putting that IP address on your DNS records of your web service).
@@ChrisWijtmansI guess what I was trying to say is that obscurity shouldn't be the only / the most 'powerful' of the protections that are there, You do make valid points, but in my head, it feelsl like the only thing obscurity does is slow someone down. There are pretty good analyzers these days that might get through it. Basically, defeating obscurity is a matter of when, not a matter of if, unlike more established security practices. But yeah obscurity perhaps does have its place, at least at stopping the script-kiddies that just think "haha script go brr"
@@ChrisWijtmans passwords are entropy, not obscurity. the two are well-defined and distinct, but you are playing word games and rejecting what words mean.
@@ElusiveEel another fake security expert.
Thank you for the font size! - and also for the great content in general 🙂
Thank you LLL!!! Seriously bro, that move is next level! That is how you take care of the peeps consuming your content. This is the first video I have seen of yours but I have subbed and liked this vid. Keep killing it!
If you're confident that your encryption is good then not stripping the binary will just help security analyst tell their clients that they indeed would need to pay to be able to decrypt it faster. Ransomware is a full-on business at this point.
As someone who's recently been getting into the low-code/JS space due to work, this was very interesting, as you covered the main functions and described what they do, leading to better understanding! Got a subscribe from me.
One problem: first "customer" who pays up has now the decryption key that can be used to help all other victims of this particular copy of the malware. Unless they use different public keys for all of their victims, which seems to be not very practical.
Thank you LLL, as a mobile consumer it’s appreciated
4:06 - what? no. You encrypt using the public key, needing the private from them.
- If you encrypted with private key, you could decrypt it with the public key :D (if it's possible at all)
EDIT: yeah, ok, sorry, you corrected yourself. It was just a slip of the tongue.
They don't care if you have the encryption/decryption algorithm since it doesn't do much good without the private key. It seems unlikely they're "mad at you".
Still, an interesting video.
Thanks for putting up with the large font, certainly was appreciated. Cheers ~Smile oN
So the only weird thing was the presence of debug symbols? I was expecting _a lot_ more with such a clickbait title. This ended up just being a walkthrough of the most basic steps for how _ordinary_ encryption/decryption works, and barely even that.
Loved what I could watch of the video, but UA-cam was running 30 seconds of ads for every 1:30 seconds of content. It just made the video unwatchable.
why should the attacker care if you reverse engineer their binary? 2:47
- They don't want you to find the vulnerability that gave them exec permission on the host. And they don't want the channel used for money transfer to lead to their identity. That's all.
- Antivirus people will find a way to fingerprint the binary regardless of it being stripped or reverse engineered or what not.
- If the data is "properly" encrypted, it doesn't matter that you know the alg - without the key you cannot do anything anyway.
My guess is the malware author intentionally left the debug symbols for analysis, so it would be obvious upon review that the victim was indeed screwed! Curious what an openssl dump of the public pem file would reveal??
> Curious what an openssl dump of the public pem file would reveal??
Not much, really.
People who got hit by this ESX attack should be fired. The version that was touched by this attack had been release in december 2020 for 7.x and february 2021 for 6.7 ! They were a year late in patching
Unfortunately, VMWare release practices prevent upgrading past the last version with hardware drivers released for a given server model. When the latest attack description came out it was something that should have been blocked by firewalls already (remote access to an internal admin network address). But yeah, replacing ESXi by something else will be more maintainable.
You could just get the encryption key, by looking at the changes made to the magic number of each file type
nope.
The concept of the series is nice but the example is not great. You can tell exactly what the binaries do just from looking at the shell script, and it doesn't really help to have debug symbols etc because what you really need is the private key. They pretty much could have done the same thing using readily available cli tools.
It would be nice if you could show examples where reverse engineering lets you fix the damage because they have done something stupid like embedded the key in the binary etc, but I don't know how easy it is to find examples of that kind of thing.
I'm just smart enough to hear you speak and know that I'm not smart enough to understand 90% of what you said.
Whatever you're doing, keep it up
Love your LL system-related content, could you do one regarding how to use the core dump of a segfaulted C executable? I'd love your explanations on that.
wdym "use the core dump"?
@@xblxckxpxny1005 A core dump contains the registers (such as IP), memory, and callstack; this can be used to help determine where add why the program crashed.
@4:20 ,while watching from phone, Thank You. :)
love this type of content !
Well they are certainly going with the No Security Through Obscurity Principle.
Thank you triple L! Excited for more rev content! Also binary exploitation and other cyber subjects would be cool
The debug info was probably intentional so it’s easy to see it’s cryptographically sound to anyone trying to analyze it. It doesn’t make the security any weaker, right?
Good stuff. Still eagerly awaiting part 2 of the baby monitor pen testing too 😉
Another here who likes the large font. I watch via casting to my TV and it made everything nice and easy to read. No squinting required. Thanks!
Correct me if I’m wrong (probably am) but the random bytes is the initialisation vector for each chunk? (9:20)
Just a bunch of random data; you could consider it an IV or "key" or both... But I agree, I would refer to it as IV since that is usually stored with a file since it isn't secret whereas a (private) key is.
It's a key, and they don't store it directly, only an encrypted copy.
The big question is of course where or how is the keypair generated. If the attacker just provides the same pair, then a leaked private key that was once paid would be enough to make an universal decoder.
I would love to see death penalty for those who write ransomware and malware.
That would be a terrible idea. Because many people who now work in cybersecurity used to write these kinds of software themselves before „coming clean“.
Also the death penalty is completely unjustified for this and completely immoral.
The .pem file in the encrypt argument list gave everything away, even without the debug info.
The faster they know that the cryptography is sound the faster they pay
Ok, so its just a basic set of encrypt decrypt binaries. Nothing special about that. I wouldn't have stripped it either. Where is the actual virus part that maliciously gets the binaries on there and executes it without the user executing it?
Reverse engineering the encrypt and decrypt binaries was just a waste of time and revealed nothing special.
Agreed. Didn't really understand the value here.
The first thing that struck me was that the encrypt and decrypt binaries weren't really malware. The could have just use the openssl executables instead. The malware was the script.
Thank you LLL for the readable font size. I watch on monitor and mobile. Nice to have programming oriented channels that you can view on the bus 🙏
Using RSA encryption on the symmetric key is a potential flaw in the malware depending on the key size. Prime number sieves are good enough now that any RSA key less than 1kb size can be cracked.
Two questions about how this scam works. One, how do the scammers have the decrypt key but the victim does not? And two, is that key unique per victim? If not, the scammer should expect to only sell one key.
It's due to the asymmetric pair of keys used... You can freely distribute a public key that can be used to encrypt any random piece of information, after which the cypher-text can only be decrypted with the corresponding private key LLL said at 3:57 he'll explain later, but i don't think he ever did. (or at least not in _this_ video).
As for the "only sell one", you're technically correct, except how would a victim find any other internet user who bought that particular key from that particular ransomware-dealer from the billions potential ones? Especially considering their tech savviness allowed them to fall victim in the first place.
@@irrelevant_noobHowever the security consultant helping them could package up the key into a "save all machines hit by XYZ malware" tool, as has happened before when the key could be retrieved in other ways.
I'm on the toilet with my phone on hand really appreciating the fontsize. Thank you Mr. Triple L
I'm a mobile user and the text size is way too big. Not sure why people keep using ridiculous text sizes, especially when you can zoom into videos in the UA-cam app.
Ok, I didn't expect a simple open bash script doing a lot of it. Possibly explains why there was a lot of seemingly rookie moves in the encryption code. I suppose it does what it needs to do to accomplish what they're trying to get done. It will be enough to get a result from most people and businesses.
I think leaving symbols is a good idea. If someone were victim to this ransomware and had the technical background to look at the code- that means they're being given confidence/trust that when you buy the key, it can/will actually decrypt the VM. Since it's encrypting VM's, it seems likely that they're attacking organizations where its quite plausible that someone could find this.
Moreover, they didn't seem to have forgotten to remove symbols, they seem to have explicitly included an instruction to keep the symbols?
props to you for including mobile/partially blind accessibility
Thanks for the large font indeed 🙏simplest is for you to lower screen definition, also font size 64 is quite large
Who in here also expected him to find a flaw in the code and managed to decrypt the files for free?
Thanks LLL, not mobile, but legally blind. I was able to read your 64 point font.
Since they built the encryption right, it doesn't matter that they didn't strip the binary … all that does is tell you that if you pay, they CAN actually decrypt your data. OTOH it also tells you that once they give you the key that decrypts you, it probably decrypts everyone hit by this malware.
That actually poses an interesting thought if I were a malware author myself-a ransom pool. By the time the ransomware is spreading, the servers that'll release the key have already been set up and will never be touched again. If the thing spreads fast and the ask is relatively conservative, a large entity hit hard might have just paid it by the time smaller fish get infected. The malware in that case may just suicide with a "you got lucky" message. Meanwhile before anyone's looking for the bastard who wrote it seriously, they've already cashed out and vanished.
IDK why anyone would do that, but it'd be damned hard to catch the people doing their "one-time" heist. Especially if they truly did just do it one-time.
Not stripping the executable seems to be intentional. It's so you can validate that it is possible that you can get your data back (data recovery is possible, but who knows if they actually give it back). There are many 'ransomware' cases where the person has their data encrypted into oblivion and the keys being thrown out with no hope of recovery.
Looking at the debug was interesting…however unless you have the private key, they would still not have their data back.
I'd be interested in how they get the RSA pubkey to the script in the first place. They must have distributed a bunch of separate pubkeys or else the first guy who pays the ransom could just share the private key with everyone else. Wannacry did a more sophisticated job of this -- it made up random keys just for you, encrypted those, then you'd send them in with your bitcoin to get them decrypted. In theory, anyway.
Leaving the debug information in the executable does not help you decrypt the data. What it does do is help you to find out that the crypto it is using is asymmetric and likely robust, which actually pushes you to wanting to get the private key. So really the debug information helps the attackers.
Thank you LLL. Fascinating stuff, can barely follow it ( last time I "played" with code was Dos. LOL. Yeah, old). But its nice to see a pro work.
As someone that binges these during downtime while not at my pc I appreciated the larger font
It would be very nice if you would summarize your result and present it in a simpler way.
You explain everything very well but also very fast with jumping around in Ghidra.
I would like to see some summary after all the code like: The program does:
1. This
2. This
3. This
to archieve This and this...
You could then explain a bit more detailed what all this means and also reach people who are not so much into the topic or don't know, for example, how SSL or asymmetric cryptography works.
I'm a programmer but not a Security Analyst and would love get more background knowledge and information from your videos.
Anyway. Very cool video definitely a subscription from me.
It makes a lot of sense to leave ransomware easily reverse-engineered, because it helps prevent a few of the ways the scam can fail if the victim suspects the ransomware isn't being candid -- about what it actually did to the files, or whether it's actually worth paying up in the hopes the decryption key they receive works.
Keeping the malware easily inspected, a savvy victim can assure themselves that (a) the encryption _is_ reversible, the files aren't just scrambled to "look" encrypted, (b) there's no "stage 2" to the malware when they run the decrypt binary, (c) the encryption itself is sound, with no way to defeat it except by actually obtaining the key from the hacker, and (d) the files themselves probably haven't been exfiltrated, so there's no PII dump that'll be putting them in the news in a few weeks even if they _do_ pay up.
I had an email from a scammer telling me they had my password. They did, but it was a very old one that I only use for unsecure networks where I have to log into crap I don't want to use that I only use there.
I remember the email was "I have my malware in your modem" or something "you can try to change your password but I will catch it every time". He demanded bitcoin and then he's go away, and "don't be mad, we all have our jobs".
Seriously, who tries to pass off such disgraceful attacks as "just doing their job"? Obv the scum never got a penny.
Judging from this dive, it sounds like the ransomware does have one weakness*: as long as the binary depends on a static private key, once that key is out in the wild, basically anyone can "pirate" the key causing that specific binary to be easily defeatable.
Obviously the author would want a decent windfall before that happens. And * it's not a cryptographic weakness of the code itself, but rather a social-engineering one.
I'm surprised the binary isn't simply just a call to "openssl encrypt " with the corresponding public key straight up. Eventually copying the parts of openssl required to do that.
It's a low-effort yet still effective ransomware.
So basicly remove the option to set a private/local key without permission and 90% of all programs dont work anymore xD
Thank you LLL, my eyes appreciate it.
As a mobile user, the font is more than big enough, could be smaller and still readable
Great VLOG. Nicely done. I missed what they did with the private key. Stored it somewhere, or transmitted it back to themselves.? Thanks (I used to work at RSA on their cryptography architecture team.) I wound up in data security consulting.
I have no idea about cyber security, but wouldnt the actual important part about this type of malware be how they get write access to your data?
With debug info not stripped, that's luxurious :D
Also, thanks youtube algorithm for recommending this!
that code in itself isnt ransomware. how it was used is. this would explain why they didnt bother removing the symbols. it wasnt initially designed for what it is being used for.
I haven’t a clue what you just did or either do I understand what you said, but I still appreciate your knowledge, and respect the fact you’re always trying, and most instances succeeding, to be one better than the people who cause so much misery to so many people. Thank you 🙏
I feel the same 😂
Cool to see the walk through. How the script gets the argument ls to run the encrypt command. So we know what it ran. Even have how to use the decrypt binary. Still doesn’t save the day or what the decrypt rsa token would be.