1 00:00:00,000 --> 00:00:03,500 Alright everybody, we're kicking off. Thanks for being here at Crypto and Privacy Village. 2 00:00:03,740 --> 00:00:09,040 We've got some amazing speakers here and I saw a video at Black Hat for how they were 3 00:00:09,040 --> 00:00:14,260 introducing their keynote and stuff. Is anybody interested in a Black Hat style intro for our 4 00:00:14,260 --> 00:00:20,520 next speaker? Oh yeah, okay, we're on this. Alright. Answer, answer, answer, answer. 5 00:00:21,140 --> 00:00:26,800 People of Earth, ladies and gentlemen, welcome to the Crypto and Privacy Village. Thank you 6 00:00:26,800 --> 00:00:35,900 for being here. Our next amazing topic, lasers, lasers, lasers, lasers, is cryptanalysis in 7 00:00:35,900 --> 00:00:46,120 the time of ransomware. Lasers, lasers, lasers, laser fingers everybody. And now it is my 8 00:00:46,120 --> 00:00:51,540 great pleasure to introduce the amazing Mark Magan. 9 00:00:56,800 --> 00:01:03,160 Thank you very much. That was great. I will never have another intro quite like that. That was really really good. 10 00:01:06,460 --> 00:01:11,420 Alright, so a little bit about me. My name is Mark Magan. I'm a senior malware researcher at 11 00:01:11,420 --> 00:01:16,740 endgame. I do reverse engineering in software development. Please do note, I am not a 12 00:01:16,740 --> 00:01:21,060 cryptographer so if I get up here and start babbling about something that's very, very wrong 13 00:01:21,060 --> 00:01:26,380 about crypto, please point it out or, you know, take me off to the side and, you know, embarrass me in private. 14 00:01:27,840 --> 00:01:32,140 You can follow me on Twitter. My Twitter handle is Magerbomb, just like Jagerbomb. 15 00:01:33,660 --> 00:01:39,000 So just to go over the agenda really quick here, we're going to discuss very briefly 16 00:01:39,000 --> 00:01:45,180 typical ransomware execution flow. Then I'm going to discuss a kind of a high-level methodology 17 00:01:45,180 --> 00:01:49,820 for working through cryptanalysis of encryption schemes within ransomware. 18 00:01:49,820 --> 00:01:56,500 Then I'll do walk-throughs through four unique pieces of ransomware from four different 19 00:01:56,500 --> 00:02:02,480 families. I'll briefly discuss current research that's out in the field. Then I'll wrap things up 20 00:02:02,480 --> 00:02:09,880 with a conclusion and hopefully have time for questions. So in a typical ransomware variant, 21 00:02:10,000 --> 00:02:16,160 what you're going to see are a few different things. So typically a payload is going to be 22 00:02:16,160 --> 00:02:19,800 written to disk and executed. There's going to be some kind of a code that's going to be 23 00:02:19,820 --> 00:02:23,840 encoded. There's going to be some sort of key generation or retrieval routine. Optionally 24 00:02:23,840 --> 00:02:30,620 there's a key exchange with the C2, but that's more in asymmetric encryption implementations. 25 00:02:30,840 --> 00:02:35,020 So we don't always see that. Sometimes with symmetric encryption, we're going to have 26 00:02:35,020 --> 00:02:42,380 hard-coded keys or some sort of key generation that's done on the fly. Then in terms of 27 00:02:42,380 --> 00:02:48,560 actually encrypting the files, there has to be enumeration and directory traversal of the 28 00:02:48,560 --> 00:02:49,800 contents on the disk. So we're going to have some sort of key generation or retrieval routine. 29 00:02:49,820 --> 00:02:58,140 So as the ransomware goes through the file system, it individually encrypts the files and 30 00:02:58,140 --> 00:03:04,180 sometimes it leaves very nicely written ransom notes in each directory just to remind you that 31 00:03:04,180 --> 00:03:12,280 you're completely hosed and all your files are gone. So in order to do cryptanalysis on 32 00:03:12,280 --> 00:03:19,640 ransomware, you kind of have to attack it kind of like a typical sort of malware reverse engineering 33 00:03:19,820 --> 00:03:24,940 or malware analysis scenario. So typically in that sort of scenario, you want to start off with 34 00:03:24,940 --> 00:03:31,860 dynamic analysis approach. You're basically just detonating the ransomware in a virtualized 35 00:03:31,860 --> 00:03:36,260 environment, something that's sandboxed and isn't going to reach out and actually touch any sort of 36 00:03:36,260 --> 00:03:44,120 sensitive files that you have, you know, compromise your actual host. And the goal here is to just 37 00:03:45,260 --> 00:03:49,800 passively analyze what the ransomware is doing to your environment. So you're going to have to 38 00:03:50,800 --> 00:03:57,520 observe any sort of network communications that are inbound or outbound. You want to look for any sort of 39 00:03:57,520 --> 00:04:02,360 forensic artifacts that are going to be left on disk, registry keys being modified, files are being 40 00:04:02,360 --> 00:04:08,900 dropped, any sort of effect on event logs. And then finally, you'll want to actually look at the 41 00:04:08,900 --> 00:04:15,060 results of the encryption, right? So you want to analyze the encrypted files. And what we're looking 42 00:04:15,060 --> 00:04:19,680 for when I say we want to analyze the files is, right, okay, so if these are encrypted files, 43 00:04:19,820 --> 00:04:23,280 you're going to look in there and say, oh, it's crypto. You know, it doesn't make any sense. 44 00:04:23,800 --> 00:04:29,260 What we're looking for are commonalities kind of across the board between files that are encrypted 45 00:04:29,260 --> 00:04:34,100 from multiple different file types. So you want to look for magic byte sequences or watermarks 46 00:04:34,100 --> 00:04:39,620 that are either in the header or the footer of the files. And you also want to try to determine if 47 00:04:39,620 --> 00:04:46,680 the ransomware is trying to encrypt the entire contents of the file or just implement sort of 48 00:04:46,680 --> 00:04:49,620 some sort of partial encryption. Because if their goal is to try to, 49 00:04:50,480 --> 00:04:55,580 you know, essentially encrypt, you know, all files on your system that meet certain file extension 50 00:04:57,000 --> 00:05:01,340 restrictions, then, you know, that's definitely going to be a lot of throughput. And, you know, 51 00:05:01,360 --> 00:05:04,840 in order to make it easier for them, sometimes the ransomware authors will only encrypt maybe the 52 00:05:04,840 --> 00:05:10,560 first two kilobytes, two megabytes, you know, something along those lines. And when you're doing 53 00:05:10,560 --> 00:05:16,520 dynamic analysis, it's definitely okay to repeat your tests multiple times. You know, you have your 54 00:05:16,520 --> 00:05:19,800 virtual virtualized environment. You can do reverts as much as you want. But if you're doing a 55 00:05:19,820 --> 00:05:21,360 fullERV, which is a lot of simple things, you need a lot of teams to run the type of NVG. So you're 56 00:05:21,360 --> 00:05:29,040 going to want to adjust your environment, you know, and control variables as needed in order to gain a 57 00:05:29,040 --> 00:05:36,240 little bit better understanding of the ransomware. And when it comes to that, when we're initially 58 00:05:36,240 --> 00:05:43,000 deployed within this virtualized environment and we initially detonate the ransomware, we're 59 00:05:43,000 --> 00:05:49,800 essentially doing a known plain text attack. Because just by launching the ransomware, you know, 60 00:05:49,800 --> 00:05:51,940 we'll see the ciphertexts that are produced. 61 00:05:52,240 --> 00:05:56,020 When we revert back to the clean state 62 00:05:56,020 --> 00:05:57,360 before we launch the ransomware, 63 00:05:57,540 --> 00:05:59,920 we have our plaintext back. 64 00:06:00,240 --> 00:06:04,400 So knowing that, we can compare the original plaintext 65 00:06:04,400 --> 00:06:05,820 to the ciphertext that we've generated. 66 00:06:06,240 --> 00:06:08,000 Now, in more of a chosen plaintext scenario, 67 00:06:08,840 --> 00:06:13,400 we're going to try to feed specifically crafted files 68 00:06:13,400 --> 00:06:19,040 to the ransomware in order to try to get it 69 00:06:19,040 --> 00:06:21,140 to leak a little bit more of maybe its key stream 70 00:06:21,140 --> 00:06:23,440 or key data, something that will give us 71 00:06:23,440 --> 00:06:25,180 a little better idea maybe of what's going on 72 00:06:25,180 --> 00:06:27,260 under the hood without having to fully reverse engineer 73 00:06:27,260 --> 00:06:27,900 the ransomware. 74 00:06:29,140 --> 00:06:31,560 So after initial dynamic analysis, 75 00:06:31,640 --> 00:06:34,880 and maybe we've learned a little bit about the ransomware, 76 00:06:36,000 --> 00:06:38,880 we'll want to do more static reverse engineering. 77 00:06:39,620 --> 00:06:42,000 And so the goal of this is to, one, 78 00:06:42,020 --> 00:06:44,400 identify any sort of crypto algorithms 79 00:06:44,400 --> 00:06:45,560 that are going to be used. 80 00:06:45,780 --> 00:06:48,800 If it's something standard like AES, triple DES, 81 00:06:48,800 --> 00:06:52,000 whatever, or if it's something more custom, 82 00:06:52,100 --> 00:06:53,120 just like a simple XOR. 83 00:06:54,680 --> 00:06:57,720 And when we're trying to identify the crypto algorithm, 84 00:06:57,980 --> 00:07:00,280 once we find the code section that contains 85 00:07:00,280 --> 00:07:02,140 what appears to be the crypto algorithm, 86 00:07:03,380 --> 00:07:07,420 we can then look into identifying implementation mistakes 87 00:07:07,420 --> 00:07:10,140 that are going to weaken the overall crypto 88 00:07:10,140 --> 00:07:14,440 and potentially provide us an avenue that we can attack 89 00:07:14,440 --> 00:07:17,880 and either leak the key or provide us 90 00:07:17,880 --> 00:07:18,780 with a decryption capability. 91 00:07:18,800 --> 00:07:22,980 And then the second part of the reverse engineering 92 00:07:22,980 --> 00:07:26,160 that we'll want to look into is how the keys 93 00:07:26,160 --> 00:07:27,920 are generated, stored, and transmitted. 94 00:07:28,380 --> 00:07:31,840 So in that sort of scenario, we're just trying to see 95 00:07:31,840 --> 00:07:35,560 if the key's going to be lying either in memory, 96 00:07:35,800 --> 00:07:39,540 hard-coded within the binary, or transmitted in the clear 97 00:07:39,540 --> 00:07:42,100 where we can obtain it and kind of replay it. 98 00:07:43,280 --> 00:07:45,940 So going through dynamic analysis and reverse engineering, 99 00:07:46,500 --> 00:07:48,040 as we've noted, everything, 100 00:07:48,800 --> 00:07:51,160 with the ransomware, we're going to apply those lessons 101 00:07:51,160 --> 00:07:54,280 learned eventually to development of our decryptor. 102 00:07:56,060 --> 00:07:58,460 So for these walkthroughs, what we're going to focus on 103 00:07:58,460 --> 00:08:01,900 is walking through ransomware encryption schemes 104 00:08:01,900 --> 00:08:04,900 that have already been defeated and have been publicized. 105 00:08:05,060 --> 00:08:09,120 So I didn't want to spend time working on any brand new ransomware 106 00:08:09,120 --> 00:08:11,200 that's out there and kind of publicizing 107 00:08:11,200 --> 00:08:12,660 exactly what's wrong with it, 108 00:08:12,740 --> 00:08:16,040 because actually when I originally submitted this talk 109 00:08:16,620 --> 00:08:17,860 to the Crypto Village, 110 00:08:18,800 --> 00:08:21,820 I had the idea that I was going to get a lot more background 111 00:08:21,820 --> 00:08:24,800 on what some of these ransomware variants were doing 112 00:08:24,800 --> 00:08:27,620 and how their encryption was implemented and how it was defeated. 113 00:08:28,180 --> 00:08:30,000 But in a lot of those descriptions, 114 00:08:30,180 --> 00:08:33,680 it was really described in an abstract manner. 115 00:08:33,860 --> 00:08:36,500 And I think there's a couple of reasons for that. 116 00:08:36,560 --> 00:08:40,040 I think that for certain AV companies or security companies, 117 00:08:40,180 --> 00:08:42,320 they're trying to just get you to download their software 118 00:08:42,320 --> 00:08:43,480 in order to do the decryption. 119 00:08:43,680 --> 00:08:44,540 It's free, whatever. 120 00:08:45,660 --> 00:08:47,900 But on the other side, it's more of an offset concern 121 00:08:47,900 --> 00:08:48,780 where they don't want to do that. 122 00:08:48,780 --> 00:08:50,480 They don't want to point out exactly what's wrong 123 00:08:50,480 --> 00:08:51,700 with the crypto implementations 124 00:08:52,140 --> 00:08:55,700 that the ransomware authors screwed up. 125 00:08:55,920 --> 00:08:57,480 So they're just trying to say, 126 00:08:57,720 --> 00:09:00,100 hey, we have that capability, we can decrypt it for you, 127 00:09:00,200 --> 00:09:02,380 but we're not going to point out exactly what's going on. 128 00:09:02,540 --> 00:09:08,240 So kind of going through that research phase for this talk, 129 00:09:08,660 --> 00:09:10,020 I then kind of turned around and say, 130 00:09:10,140 --> 00:09:13,860 okay, well, I know that these encryption schemes are defeatable, 131 00:09:13,900 --> 00:09:16,840 so how can I actually build more of a how-to 132 00:09:16,840 --> 00:09:18,760 or walk-through guide for doing this? 133 00:09:18,780 --> 00:09:20,580 So that's more the focus of the talk now. 134 00:09:21,580 --> 00:09:23,680 So yeah, as I mentioned, these are older variants, 135 00:09:23,820 --> 00:09:25,300 no longer in circulation. 136 00:09:25,520 --> 00:09:28,280 These are all mostly from like 2016, 2015. 137 00:09:29,100 --> 00:09:31,540 We're going to be doing some high-level reverse engineering, 138 00:09:32,100 --> 00:09:37,000 and we're going to focus on detailing the crypto implementations 139 00:09:37,000 --> 00:09:40,800 and noting any differences between the ransom note and reality, 140 00:09:40,980 --> 00:09:43,980 because as we'll see, the ransom notes are definitely 141 00:09:43,980 --> 00:09:45,720 a little detached from reality sometimes, 142 00:09:45,820 --> 00:09:48,600 and they're trying to really just scare people, you know, 143 00:09:48,780 --> 00:09:53,800 into paying the ransoms by just using a lot of technical-sounding jargon. 144 00:09:54,380 --> 00:09:58,960 And we'll focus on devising proof of concepts for carrying out our decryption. 145 00:10:00,720 --> 00:10:03,280 Okay, so we'll start off with PowerWare. 146 00:10:03,440 --> 00:10:07,040 So PowerWare is a PowerShell-based ransomware, 147 00:10:07,220 --> 00:10:13,520 one of the first, if not the first, ransomware family that's based in PowerShell. 148 00:10:13,640 --> 00:10:15,980 And so here's a ransom note that we can see here. 149 00:10:16,520 --> 00:10:18,680 And so this says that it's not only, 150 00:10:18,680 --> 00:10:21,540 it's not only using RSA 2048, but it's using AES-128. 151 00:10:21,840 --> 00:10:24,720 So it's doubly encrypting your files. 152 00:10:24,820 --> 00:10:25,700 So that sounds pretty bad. 153 00:10:25,840 --> 00:10:28,320 And they even provide links to Wikipedia because they're so nice. 154 00:10:29,380 --> 00:10:30,100 So yeah. 155 00:10:31,340 --> 00:10:35,180 And of course they provide instructions for accessing Tor 156 00:10:35,180 --> 00:10:38,560 in order to get to their site so you can pay off the ransom payment. 157 00:10:38,780 --> 00:10:40,680 So they're, you know, very nice guys. 158 00:10:43,000 --> 00:10:47,680 So now the advantage of PowerShell is that, you know, 159 00:10:47,680 --> 00:10:48,400 as a scripting language, 160 00:10:48,680 --> 00:10:54,580 we get access directly to the source code that's deployed with PowerWare. 161 00:10:55,440 --> 00:10:58,080 But the flip side of that is that, of course, 162 00:10:58,100 --> 00:11:03,280 they can run it through an obfuscator and it might be pretty hard to see from this, 163 00:11:03,440 --> 00:11:04,400 you know, kind of mile high view. 164 00:11:04,600 --> 00:11:10,100 This is all of the source code for this variant of PowerWare. 165 00:11:10,800 --> 00:11:14,940 But the very real names are, you know, kind of screwed up. 166 00:11:14,980 --> 00:11:16,320 They're not very easy to read. 167 00:11:16,420 --> 00:11:18,660 It's a mix of alpha and beta. 168 00:11:18,660 --> 00:11:21,880 They're numeric characters, upper and lower case alphabet characters. 169 00:11:22,940 --> 00:11:27,880 So one thing we'll end up doing is deobfuscating it a little bit just to help us make sense. 170 00:11:28,180 --> 00:11:31,420 But as you can follow the arrows and the red text here, 171 00:11:32,060 --> 00:11:35,360 you know, they can be chopped up into a few different pieces. 172 00:11:35,600 --> 00:11:38,360 There's the initial like preamble that includes the crypto setup. 173 00:11:39,020 --> 00:11:44,020 There's the actual file and directory enumeration where we're looking for specific file types. 174 00:11:44,480 --> 00:11:47,280 Like as you might be able to see, like docx, xls. 175 00:11:48,860 --> 00:11:56,140 Essentially walking through the file system and trying to match the file path with one of the extensions that's in that list. 176 00:11:56,360 --> 00:12:00,780 And if it matches that, then it runs it through the encryption routine and I point out the file right. 177 00:12:00,980 --> 00:12:05,220 And, you know, in the bottom there's a file clean up routine as well that's going to delete the script afterwards. 178 00:12:07,080 --> 00:12:17,660 So looking more at the crypto setup portion, as I said before, the variable names are, you know, a mix of upper, lower case and numeric characters. 179 00:12:17,720 --> 00:12:18,140 So. 180 00:12:19,020 --> 00:12:26,400 Going through this, we can actually provide a little more context in terms of what those variables mean. 181 00:12:26,620 --> 00:12:31,920 So if we just walk through and relabel things, it'll help provide a clearer picture. 182 00:12:32,140 --> 00:12:36,640 And so things look a lot better after going through doing a little bit of light deobfuscation. 183 00:12:37,100 --> 00:12:40,660 We can kind of see, you know, how certain variables are being used here. 184 00:12:42,160 --> 00:12:43,640 So what can we find here? 185 00:12:45,440 --> 00:12:47,980 Well, we're utilizing symmetric encryption. 186 00:12:47,980 --> 00:12:51,860 Utilizing the Randall Manage class, which is basically AES. 187 00:12:53,500 --> 00:12:56,260 Using a 256-bit or 32-byte key. 188 00:12:57,680 --> 00:13:00,480 We have an initialization vector that we're specifying. 189 00:13:01,880 --> 00:13:05,020 We're padding with zeros and we're using cipher block chaining. 190 00:13:07,320 --> 00:13:13,700 Now, if we move on to the portion of the code that's contained within the file and directory enumeration, 191 00:13:14,960 --> 00:13:17,960 one thing that sticks out right away is the use of this. 192 00:13:17,960 --> 00:13:22,000 This integer value, 2048, or 2 kilobytes. 193 00:13:22,240 --> 00:13:29,440 And what that basically is saying right here is that only the first 2 kilobytes of the file are going to be read in and decrypted. 194 00:13:29,620 --> 00:13:34,360 And for any files that are less than 2048 bytes, it's just going to completely skip. 195 00:13:37,120 --> 00:13:47,900 And looking on the code section directly below that, we're not making any further modifications to the crypto object that we previously initialized and configured. 196 00:13:47,960 --> 00:13:50,980 So, just something to keep in mind. 197 00:13:52,240 --> 00:13:59,200 Okay, so now going back to the crypto setup, do we see anything in here that's bad with their implementation? 198 00:14:00,960 --> 00:14:02,860 So, there's a few things here. 199 00:14:03,900 --> 00:14:07,300 So, they're utilizing symmetric encryption. 200 00:14:07,540 --> 00:14:09,160 They're using basically AES. 201 00:14:09,680 --> 00:14:11,400 So, in itself, that's not bad. 202 00:14:12,080 --> 00:14:17,440 As long as they're doing key management right and handling the IVs right. 203 00:14:17,960 --> 00:14:24,900 But, as we can see, yes, it's utilizing a 256-bit key, but it's completely hard-coded. 204 00:14:25,340 --> 00:14:27,520 They're not doing any sort of unique key generation. 205 00:14:27,960 --> 00:14:36,240 It's going to utilize the same key for every single file encryption that this script runs, no matter what system it's on, no matter what time of the day, anything. 206 00:14:36,560 --> 00:14:37,760 Same key everywhere. 207 00:14:38,380 --> 00:14:40,460 And the same thing for the initialization vector. 208 00:14:41,320 --> 00:14:44,540 They utilize the same value everywhere, all the time. 209 00:14:46,000 --> 00:14:47,940 So, with a hard-coded key... 210 00:14:47,960 --> 00:14:52,920 And a hard-coded IV, they're utilizing CBC mode. 211 00:14:53,600 --> 00:14:59,120 And those four things combined, that's not good. 212 00:14:59,260 --> 00:15:01,940 That's basically a very, very huge vulnerability. 213 00:15:02,340 --> 00:15:12,800 And the CWE, if you're familiar with the CVE database, actually provides a little bit of background to prove that I'm not just making things up here. 214 00:15:12,880 --> 00:15:17,940 But non-random IVs and hard-coded crypto keys aren't bad. 215 00:15:17,960 --> 00:15:18,140 Bad news. 216 00:15:19,440 --> 00:15:24,420 Okay, so, taking what we know, let's try to build our own decryptor. 217 00:15:28,840 --> 00:15:33,800 Okay, so I simplified things a little bit here in this version of the Power Script. 218 00:15:34,040 --> 00:15:40,720 I just cleaned up the file enumeration just to target a specific text file that's going to be on my desktop. 219 00:15:41,600 --> 00:15:43,040 And so I'll click over here. 220 00:15:43,380 --> 00:15:46,940 It just says hello a bunch of times, so nothing too sensitive, I suppose. 221 00:15:47,960 --> 00:15:51,700 And I'll run my modified version of the PowerShell script. 222 00:15:54,640 --> 00:15:56,620 And it looks like that data's been encrypted. 223 00:15:56,880 --> 00:15:58,500 I have no idea what it says now. 224 00:15:59,680 --> 00:16:01,360 And so, let's see. 225 00:16:01,520 --> 00:16:02,840 So we're looking through the code here. 226 00:16:02,960 --> 00:16:10,920 What can we do knowing that all the characteristics we saw earlier, how can we decrypt this? 227 00:16:12,140 --> 00:16:17,940 Wait, can it really be that easy that we change two characters in the PowerShell script? 228 00:16:17,960 --> 00:16:20,120 And we're going to decrypt everything? 229 00:16:22,500 --> 00:16:23,400 Yes, it is. 230 00:16:24,040 --> 00:16:29,840 Yes, it is. 231 00:16:31,000 --> 00:16:34,180 I wish it were that easy every single time, but, you know. 232 00:16:35,660 --> 00:16:37,600 Okay, so moving on to Nemucod. 233 00:16:38,880 --> 00:16:40,200 Here's our ransom note. 234 00:16:40,720 --> 00:16:46,380 And here they're touting that they're using strong RSA 1024 algorithm with a unique key. 235 00:16:46,680 --> 00:16:47,820 Okay, all right. 236 00:16:47,960 --> 00:16:48,500 We'll see. 237 00:16:48,700 --> 00:16:48,960 We'll see. 238 00:16:52,000 --> 00:16:52,780 All right. 239 00:16:52,800 --> 00:16:55,280 So we jumped ahead a little bit in this case here. 240 00:16:55,840 --> 00:17:05,380 What you're seeing here is a pseudocode representation of what is essentially the enumeration and the encryption function. 241 00:17:06,620 --> 00:17:14,000 And for this specific binary, this wasn't going to even take a big level of reverse engineering. 242 00:17:14,480 --> 00:17:16,940 This was literally the first function that's called. 243 00:17:17,960 --> 00:17:18,620 By the binary. 244 00:17:18,840 --> 00:17:25,480 So, you know, popped it into IDA Pro, went to the first function that's called, and then utilized X-rays to decompile it. 245 00:17:25,560 --> 00:17:29,080 So I don't have to, you know, show a bunch of ugly-looking disassembly up there. 246 00:17:29,820 --> 00:17:33,080 You know, just to give you, you know, a high-level view of what's going on here. 247 00:17:33,200 --> 00:17:38,920 But as we can see, it's only going to encrypt the first 2048 bytes again. 248 00:17:38,980 --> 00:17:45,860 So two kilobyte file size limitation, or at least buffer limitation for the encryption. 249 00:17:46,520 --> 00:17:47,540 Then it's XORing. 250 00:17:47,540 --> 00:17:51,300 And then it's XORing by a static key, which I've highlighted there. 251 00:17:51,600 --> 00:17:57,740 So there's no sign of using anything even close to RSA 1024, AES, whatever. 252 00:17:58,340 --> 00:18:04,220 So, yeah, that is their, you know, that is their encryption scheme. 253 00:18:04,480 --> 00:18:06,380 So let's go over what we know. 254 00:18:07,660 --> 00:18:09,320 We're not using asymmetric crypto. 255 00:18:09,680 --> 00:18:11,500 There is no RSA code in here. 256 00:18:12,220 --> 00:18:13,780 It is utilizing XOR. 257 00:18:14,980 --> 00:18:17,160 And there is no unique key generation. 258 00:18:20,720 --> 00:18:23,900 It's utilizing a hard-coded 255-byte key. 259 00:18:25,860 --> 00:18:27,260 It's the same for every file. 260 00:18:29,000 --> 00:18:32,580 And it's only going to cover the first 2048 bytes. 261 00:18:33,880 --> 00:18:36,580 And on top of that, this is a simple encryptor binary. 262 00:18:37,580 --> 00:18:38,020 Okay. 263 00:18:38,300 --> 00:18:42,200 So knowing all that, what can we do to decrypt our files? 264 00:18:46,000 --> 00:18:46,440 Okay. 265 00:18:46,480 --> 00:18:46,800 Okay. 266 00:18:46,800 --> 00:18:47,440 So here's... 267 00:18:47,540 --> 00:18:49,680 Here's my very sensitive data again. 268 00:18:51,740 --> 00:18:54,400 And so we run through... 269 00:18:55,000 --> 00:18:56,440 Hold on, we'll pause it real quick. 270 00:18:57,120 --> 00:19:02,180 So the way the encryptor binary works is you just have to pass it on the command line, 271 00:19:02,240 --> 00:19:06,600 the path to the specific file that you want to encrypt. 272 00:19:07,660 --> 00:19:12,500 So knowing that, we pass in the path to our test.txt. 273 00:19:13,180 --> 00:19:16,520 Looks like it goes through and encrypts the first two kilobytes. 274 00:19:17,780 --> 00:19:20,780 And then, hey, well, maybe I'll just try running this again. 275 00:19:20,920 --> 00:19:21,980 Let's see what happens. 276 00:19:23,400 --> 00:19:24,460 And our file's... 277 00:19:25,060 --> 00:19:25,960 Our file's back. 278 00:19:26,180 --> 00:19:26,960 The plain text is back. 279 00:19:27,180 --> 00:19:28,520 That was pretty miraculous. 280 00:19:30,200 --> 00:19:33,300 You know, so hopefully I'm not blowing any of your guys' minds, 281 00:19:33,480 --> 00:19:37,100 but if you XOR plain text with the same value twice, 282 00:19:37,220 --> 00:19:38,680 you're going to end up with the plain text. 283 00:19:42,600 --> 00:19:43,000 Okay. 284 00:19:43,160 --> 00:19:45,340 So moving on to TorrentLocker. 285 00:19:45,520 --> 00:19:46,420 And so the... 286 00:19:46,420 --> 00:19:48,960 While the first two cases were pretty easy, 287 00:19:49,360 --> 00:19:51,580 the last two ones are a little more complicated, 288 00:19:51,740 --> 00:19:54,740 and there's a little more work that goes into developing the encryptors. 289 00:19:54,900 --> 00:19:56,160 So bear with me here. 290 00:19:57,260 --> 00:20:00,340 So here's another nicely worded ransom note. 291 00:20:00,400 --> 00:20:04,000 This one actually takes advantage of the Windows API 292 00:20:04,000 --> 00:20:06,760 for drawing a nice window for us instead of just a plain text file. 293 00:20:08,120 --> 00:20:10,960 So it's using AES-256. 294 00:20:11,080 --> 00:20:11,920 It claims to be. 295 00:20:12,800 --> 00:20:15,700 And then they're also saying the encryption key is encrypted 296 00:20:15,700 --> 00:20:16,400 on top of the... 297 00:20:16,420 --> 00:20:17,560 So that with RSA 2048. 298 00:20:19,920 --> 00:20:23,340 So now jumping ahead a little bit with this example, 299 00:20:25,400 --> 00:20:28,340 if we go in through a debugger, 300 00:20:28,400 --> 00:20:30,280 like we're using all the debug in this instance, 301 00:20:30,940 --> 00:20:33,040 and we're just kind of stepping through 302 00:20:33,040 --> 00:20:37,200 and, you know, looking around the encryption function 303 00:20:37,200 --> 00:20:39,280 to see, you know, 304 00:20:39,600 --> 00:20:41,360 well, not even the encryption function itself, 305 00:20:42,200 --> 00:20:43,480 literally just going through 306 00:20:43,480 --> 00:20:46,060 and we found calls to... 307 00:20:46,420 --> 00:20:47,420 write file, 308 00:20:47,480 --> 00:20:48,680 the Windows API, 309 00:20:49,100 --> 00:20:51,060 and then we kind of backtracked a little bit 310 00:20:51,060 --> 00:20:53,600 to see if there was any sort of crypto setup before that. 311 00:20:53,820 --> 00:20:56,160 And what we see are hard-coded references, 312 00:20:56,640 --> 00:20:57,880 or hard-coded strings 313 00:20:57,880 --> 00:21:01,280 that seem to reference this library named TomCrypt, 314 00:21:01,830 --> 00:21:06,280 and specific file paths for C files 315 00:21:06,280 --> 00:21:08,620 that, you know, seem to be named CTR-encrypt, 316 00:21:08,680 --> 00:21:09,980 and AES.C. 317 00:21:10,080 --> 00:21:11,780 So looking at that, 318 00:21:11,820 --> 00:21:13,460 okay, AES counter mode. 319 00:21:15,320 --> 00:21:16,400 To do a little bit of research, 320 00:21:16,400 --> 00:21:17,160 a little bit of a sanity check, 321 00:21:17,420 --> 00:21:21,300 we can decompile the function 322 00:21:21,300 --> 00:21:24,080 that contains the reference to CTR-encrypt, 323 00:21:24,160 --> 00:21:26,000 so we can see that all nicely written out there. 324 00:21:26,440 --> 00:21:28,960 And since LibTomCrypt's an open-source library, 325 00:21:29,160 --> 00:21:30,380 we can go through and compare that 326 00:21:30,380 --> 00:21:33,140 to the exact source code that's available out there. 327 00:21:33,380 --> 00:21:35,000 And so you can see, you know, 328 00:21:35,000 --> 00:21:36,720 some sort of similarities there, 329 00:21:36,920 --> 00:21:38,300 but, you know, 330 00:21:38,320 --> 00:21:39,360 mostly we're just trying to see 331 00:21:39,360 --> 00:21:41,040 if we're within the same ballpark. 332 00:21:41,220 --> 00:21:43,460 And that's generally what we're seeing, 333 00:21:43,560 --> 00:21:44,880 and we don't really need to get, you know, 334 00:21:44,880 --> 00:21:45,640 too deep into that. 335 00:21:46,400 --> 00:21:48,620 We don't really need to do source code analysis here. 336 00:21:50,820 --> 00:21:53,120 So from very limited reverse engineering, 337 00:21:53,380 --> 00:21:55,500 we know that, you know, 338 00:21:55,500 --> 00:21:57,980 it appears to be using AES in counter mode, 339 00:21:58,720 --> 00:22:01,720 and their implementation's based off of LibTomCrypt. 340 00:22:01,780 --> 00:22:03,440 We don't know if they've actually modified anything, 341 00:22:03,680 --> 00:22:06,300 but, you know, ransomware authors tend to be pretty lazy, 342 00:22:06,380 --> 00:22:08,180 so they probably just copied it. 343 00:22:08,760 --> 00:22:10,720 So could this potentially be vulnerable? 344 00:22:11,120 --> 00:22:12,320 And, you know, 345 00:22:12,320 --> 00:22:14,960 as with a lot of other encryption algorithms, 346 00:22:15,540 --> 00:22:16,800 symmetric encryption algorithms, 347 00:22:17,160 --> 00:22:21,900 yes, they can be subject to implementation flaws. 348 00:22:22,280 --> 00:22:24,080 And I provided, you know, 349 00:22:24,080 --> 00:22:26,100 a little bit of an excerpt from, you know, 350 00:22:26,100 --> 00:22:30,160 this very nicely written paper about counter mode security 351 00:22:31,700 --> 00:22:35,920 and basically ways to properly implement AES counter mode 352 00:22:35,920 --> 00:22:37,140 along with ways not to. 353 00:22:37,300 --> 00:22:40,540 And so this gives us a little bit of a hint to say, 354 00:22:40,620 --> 00:22:42,840 okay, well, if they're reusing the key, 355 00:22:43,380 --> 00:22:44,940 then that'll give us a little bit of a hint to say, 356 00:22:44,940 --> 00:22:44,960 okay, well, if they're reusing the key, 357 00:22:44,960 --> 00:22:45,260 then that'll give us a little bit of a window 358 00:22:45,260 --> 00:22:47,060 into what's going on. 359 00:22:47,200 --> 00:22:48,740 So we'll keep that in mind, 360 00:22:48,880 --> 00:22:50,840 and we'll try to prove that. 361 00:22:51,640 --> 00:22:55,420 Okay, so how can we test for a flawed AES counter implementation? 362 00:22:56,080 --> 00:22:58,920 Well, all right, so here's a little bit of math here, 363 00:22:59,080 --> 00:23:00,640 so hopefully this goes over okay. 364 00:23:02,020 --> 00:23:04,300 So we're going to want two plain text files. 365 00:23:04,540 --> 00:23:06,660 We're going to want one large plain text file 366 00:23:06,660 --> 00:23:08,620 that's going to consist solely of null bytes. 367 00:23:09,640 --> 00:23:12,860 And our goal here is that if there's a file size limitation, 368 00:23:13,180 --> 00:23:14,520 we want to exhaust the key stream, 369 00:23:14,520 --> 00:23:15,620 and we want to find that out. 370 00:23:15,780 --> 00:23:19,120 As we saw with the two previous examples, 371 00:23:19,580 --> 00:23:20,900 there were file size limitations. 372 00:23:21,280 --> 00:23:23,200 So we're going to take a stab at that. 373 00:23:25,000 --> 00:23:26,840 For B, our second plain text, 374 00:23:27,080 --> 00:23:28,520 it's going to be a non-null plain text, 375 00:23:28,780 --> 00:23:32,440 just something that's an arbitrary size that's less than A 376 00:23:32,440 --> 00:23:35,860 that we can hopefully use our key stream that we devise 377 00:23:37,480 --> 00:23:41,140 to decrypt the cipher text and generate the plain text. 378 00:23:41,580 --> 00:23:44,500 So what we're going to do is have the ransomware 379 00:23:44,520 --> 00:23:48,820 encrypt file A, resulting in A prime, or the cipher text. 380 00:23:49,260 --> 00:23:52,880 And then if we take that result, A prime, 381 00:23:53,040 --> 00:23:55,980 and we XOR it with A, that should yield the key stream. 382 00:23:56,360 --> 00:23:58,480 And since A in this case is null bytes, 383 00:23:59,120 --> 00:24:03,740 if we XOR A, or I mean if we XOR anything by null or zero, 384 00:24:04,380 --> 00:24:05,340 it's redundant. 385 00:24:05,620 --> 00:24:08,560 So what we have in this case, we're supposing, 386 00:24:08,560 --> 00:24:10,320 is A prime will be our key stream. 387 00:24:11,400 --> 00:24:13,720 And then we go through and we encrypt 388 00:24:13,720 --> 00:24:14,500 the second plain text. 389 00:24:16,100 --> 00:24:19,100 And then we take that and we XOR it by the key stream 390 00:24:19,100 --> 00:24:21,040 that we generated from A, 391 00:24:22,340 --> 00:24:25,520 and that should result in our plain text for B. 392 00:24:25,900 --> 00:24:28,820 So that's what we're proposing. 393 00:24:29,000 --> 00:24:30,620 So let's see if this actually holds true. 394 00:24:35,240 --> 00:24:37,880 So as you can see, A.txt is just null bytes. 395 00:24:38,040 --> 00:24:39,000 Not going to go through there. 396 00:24:39,280 --> 00:24:40,520 Let me pause this real quick. 397 00:24:40,820 --> 00:24:44,420 So I wrote up this quick little dirty Python script. 398 00:24:44,520 --> 00:24:48,960 Basically just XOR A prime with B prime. 399 00:24:49,240 --> 00:24:51,920 So all we're trying to do is see if that's going to yield 400 00:24:51,920 --> 00:24:54,400 the plain text for B. 401 00:24:55,520 --> 00:25:00,580 And for B, B is actually the decryptor. 402 00:25:01,380 --> 00:25:05,860 Then in this separate tab, you'll see that I actually saved 403 00:25:05,860 --> 00:25:07,600 a separate copy of the decryptor. 404 00:25:07,600 --> 00:25:08,940 It's called decryptor.exe. 405 00:25:09,360 --> 00:25:12,580 And because it's still just a Python script, 406 00:25:12,800 --> 00:25:14,140 but I just changed the file extension, 407 00:25:14,520 --> 00:25:16,160 so when I launch the ransomware, 408 00:25:16,240 --> 00:25:18,900 it's not going to overwrite that file to you. 409 00:25:18,960 --> 00:25:21,260 So I can just preserve that copy and go from there. 410 00:25:23,860 --> 00:25:24,500 Hold on. 411 00:25:25,040 --> 00:25:25,620 Let's see. 412 00:25:29,920 --> 00:25:30,320 Yeah. 413 00:25:36,780 --> 00:25:38,240 Let me get that over here. 414 00:25:44,520 --> 00:25:44,880 Okay. 415 00:25:45,580 --> 00:25:46,280 That's better. 416 00:25:50,840 --> 00:25:51,360 Okay. 417 00:25:52,300 --> 00:25:53,800 So going back a little bit, 418 00:25:54,500 --> 00:25:56,480 there's our B.py again. 419 00:25:58,280 --> 00:25:59,520 Nothing looks too crazy. 420 00:25:59,680 --> 00:26:00,840 Just XORs and bytes. 421 00:26:02,940 --> 00:26:05,620 And there's our fake executable. 422 00:26:07,460 --> 00:26:10,540 So we'll go through and launch locker.exe. 423 00:26:11,680 --> 00:26:14,080 And we'll see pretty quickly the files get encrypted. 424 00:26:15,600 --> 00:26:18,140 And it dropped the ransom note that we already saw earlier. 425 00:26:21,080 --> 00:26:24,620 So we'll pop these two files into a hex editor. 426 00:26:24,820 --> 00:26:25,740 And what do we see? 427 00:26:25,860 --> 00:26:31,480 We see that, so this is the cipher text that just generated from A. 428 00:26:32,460 --> 00:26:33,600 So we kind of scroll down. 429 00:26:33,840 --> 00:26:36,680 And at a certain point, all we see are null bytes. 430 00:26:38,060 --> 00:26:40,740 So either they just start XORing by null, 431 00:26:40,940 --> 00:26:44,240 or we actually have a, 432 00:26:44,240 --> 00:26:45,960 a limitation to the, 433 00:26:46,000 --> 00:26:46,720 to the encryption. 434 00:26:48,400 --> 00:26:51,380 Now, if we go over to the cipher text for B, 435 00:26:51,580 --> 00:26:53,180 we can see that it looks like, 436 00:26:53,200 --> 00:26:55,080 you know, everything in there has been encrypted. 437 00:26:55,260 --> 00:26:55,820 So nothing, 438 00:26:56,460 --> 00:26:57,800 you know, nothing too crazy. 439 00:26:58,000 --> 00:27:00,560 So now we go back. 440 00:27:01,600 --> 00:27:04,080 And we take our decrypter.exe, 441 00:27:04,120 --> 00:27:06,100 and we rename it to decrypter.py. 442 00:27:07,540 --> 00:27:10,580 So we've successfully evaded the ransomware. 443 00:27:14,620 --> 00:27:16,620 It takes a while for the rename for some reason. 444 00:27:17,480 --> 00:27:19,360 Then we launch our decrypter. 445 00:27:20,960 --> 00:27:22,480 And everything looks fine, right? 446 00:27:24,540 --> 00:27:26,100 You know, we have pretty much every line. 447 00:27:26,280 --> 00:27:30,240 But what we can see at the bottom is that instead of saying print output, 448 00:27:30,420 --> 00:27:31,280 it says print out P, 449 00:27:31,460 --> 00:27:33,400 and then there's two characters that look garbled. 450 00:27:34,600 --> 00:27:36,060 So what do we think happened? 451 00:27:37,080 --> 00:27:39,060 So we revisit the cipher text. 452 00:27:39,460 --> 00:27:42,340 And we actually see that the two, 453 00:27:42,880 --> 00:27:44,100 the two last characters, 454 00:27:44,100 --> 00:27:45,660 U and T for output, 455 00:27:46,360 --> 00:27:47,600 are still within the cipher text. 456 00:27:48,340 --> 00:27:49,840 So what do we think happened? 457 00:27:50,120 --> 00:27:52,800 Well, what they probably did in this case, 458 00:27:52,980 --> 00:27:54,940 and, you know, this is without reverse engineering 459 00:27:54,940 --> 00:27:57,260 the encryption algorithm or anything, 460 00:27:57,860 --> 00:27:59,560 what we're supposing is that the, 461 00:28:00,600 --> 00:28:03,620 actually that view helps a little better. 462 00:28:04,080 --> 00:28:05,660 What we're supposing is that 463 00:28:05,660 --> 00:28:10,480 the encryption operates on specific block sizes. 464 00:28:10,820 --> 00:28:12,940 And if they're using a block size 465 00:28:12,940 --> 00:28:14,080 that's, you know, 466 00:28:14,080 --> 00:28:17,880 you know, like four kilobyte or four bytes or eight bytes, 467 00:28:18,020 --> 00:28:19,940 that's something that's going to be left out. 468 00:28:20,000 --> 00:28:22,280 And that's going to be an extraneous chunk. 469 00:28:22,480 --> 00:28:23,660 That's not part of the, 470 00:28:23,660 --> 00:28:27,020 that want to be part of the last block that's encrypted. 471 00:28:27,180 --> 00:28:32,300 So it's just going to be left unencrypted within the cipher text that's generated. 472 00:28:32,940 --> 00:28:37,580 So that's an edge case that you'd have to take into account with a lot of the decryptors that you're writing. 473 00:28:37,680 --> 00:28:38,820 You want to be able to test, 474 00:28:39,580 --> 00:28:42,920 you know, a lot of different file sizes so you can make sure that, 475 00:28:42,940 --> 00:28:43,740 you know, yes, 476 00:28:44,080 --> 00:28:47,640 if you write one decryptor and it works for this one test case, 477 00:28:47,740 --> 00:28:48,220 that's great, 478 00:28:48,380 --> 00:28:51,180 but you want to test it across multiple file sizes, 479 00:28:51,320 --> 00:28:53,860 multiple file types in order to cover all your edge cases. 480 00:28:54,040 --> 00:28:55,900 So if you write something and you release it to the public, 481 00:28:55,980 --> 00:28:56,180 you know, 482 00:28:56,580 --> 00:28:59,200 you want to be able to make sure it's actually going to reach, 483 00:28:59,220 --> 00:28:59,540 you know, 484 00:28:59,540 --> 00:29:00,500 the audience that you want it to. 485 00:29:02,660 --> 00:29:02,980 Okay. 486 00:29:05,300 --> 00:29:06,260 And let's see. 487 00:29:08,020 --> 00:29:09,640 How can I get that out of there? 488 00:29:11,920 --> 00:29:12,240 Okay. 489 00:29:14,080 --> 00:29:14,480 All right. 490 00:29:14,520 --> 00:29:15,220 So moving on, 491 00:29:15,280 --> 00:29:17,420 our last example is Apocalypse. 492 00:29:18,800 --> 00:29:20,300 This one sounds pretty cryptic. 493 00:29:20,380 --> 00:29:21,780 They're saying all your files are encrypted, 494 00:29:22,080 --> 00:29:22,560 everything, 495 00:29:22,800 --> 00:29:23,580 you know, 496 00:29:23,580 --> 00:29:24,720 the world's coming to an end. 497 00:29:27,280 --> 00:29:29,500 And just by doing some dynamic analysis, 498 00:29:29,860 --> 00:29:32,460 we launched the ransomware and we pull, 499 00:29:32,680 --> 00:29:33,180 you know, 500 00:29:33,180 --> 00:29:37,140 multiple ciphertexts in order to compare them a little bit. 501 00:29:37,380 --> 00:29:42,460 And what we can see right here is that we have what appears to be a watermark, 502 00:29:42,460 --> 00:29:48,020 a magic byte sequence that consists of the first four bytes there. 503 00:29:49,460 --> 00:29:51,800 So that's something to go off of for us. 504 00:29:53,680 --> 00:30:00,360 Now if we use the same plaintext that consists solely of null bytes that we'd used for our 505 00:30:00,360 --> 00:30:01,000 previous example, 506 00:30:02,460 --> 00:30:05,000 let's see if this actually generates a little bit more for us. 507 00:30:05,180 --> 00:30:08,600 And actually looking through the file just through like these, 508 00:30:08,620 --> 00:30:09,140 you know, 509 00:30:09,160 --> 00:30:10,940 those first few hundred bytes, 510 00:30:11,080 --> 00:30:12,300 we can see that, 511 00:30:12,300 --> 00:30:15,360 that there does appear to be some sort of repetition in the ciphertext. 512 00:30:16,920 --> 00:30:17,520 You know, 513 00:30:17,520 --> 00:30:18,480 it still doesn't exactly, 514 00:30:18,660 --> 00:30:19,420 you know, 515 00:30:19,420 --> 00:30:20,660 reveal everything to us, 516 00:30:20,720 --> 00:30:21,720 but you know, 517 00:30:21,740 --> 00:30:21,920 it's, 518 00:30:21,980 --> 00:30:22,260 it's, 519 00:30:22,260 --> 00:30:23,300 it's something to go off of. 520 00:30:23,440 --> 00:30:23,540 It's, 521 00:30:23,580 --> 00:30:24,260 it's something to note. 522 00:30:26,400 --> 00:30:28,100 So what do we know so far? 523 00:30:28,260 --> 00:30:29,820 We have what appears to be a magic byte sequence. 524 00:30:30,100 --> 00:30:33,920 There's repetition in the ciphertext when we provide a null plaintext. 525 00:30:35,300 --> 00:30:36,320 The ransom note, 526 00:30:36,420 --> 00:30:37,440 if we actually go back to that, 527 00:30:37,860 --> 00:30:39,820 it doesn't seem to mention encryption type. 528 00:30:39,920 --> 00:30:42,220 That's kind of odd because all the other ones that we've seen so far, 529 00:30:42,220 --> 00:30:46,760 mention some sort of industrial grade RSA 4096 and you know, 530 00:30:46,760 --> 00:30:47,320 AES, 531 00:30:47,380 --> 00:30:48,060 you know, 532 00:30:48,060 --> 00:30:48,300 256, 533 00:30:48,580 --> 00:30:48,860 whatever. 534 00:30:49,200 --> 00:30:52,660 So it's kind of curious that they don't mention that they're using some sort of, 535 00:30:52,680 --> 00:30:53,380 you know, 536 00:30:53,940 --> 00:30:54,500 high-grade encryption. 537 00:30:55,960 --> 00:30:58,180 So let's proceed with reverse engineering from here. 538 00:30:59,240 --> 00:31:00,440 So for this case, 539 00:31:00,460 --> 00:31:02,720 we're actually going to utilize IDAPRO. 540 00:31:03,220 --> 00:31:05,360 And one thing that you can do right away, 541 00:31:06,300 --> 00:31:09,300 this is definitely a little bit more of a cheat and it's not always going to work, 542 00:31:09,840 --> 00:31:12,200 but you can do a simple string search. 543 00:31:12,200 --> 00:31:12,520 Again, 544 00:31:12,680 --> 00:31:18,260 it's a binary literally for like instructions in the x86 instruction set. 545 00:31:18,400 --> 00:31:25,560 So you can do a text string search for XOR and that'll result in finding the XOR operations. 546 00:31:26,960 --> 00:31:31,200 So if we look through the table of the results on the right, 547 00:31:31,840 --> 00:31:35,040 we can see that multiple XORs are just clearing out certain registers. 548 00:31:35,320 --> 00:31:36,160 So nothing, 549 00:31:36,260 --> 00:31:37,140 nothing big there, 550 00:31:37,280 --> 00:31:39,260 but the two results at the top, 551 00:31:39,360 --> 00:31:42,100 those are the ones that we're going to be interested in and they both, 552 00:31:42,100 --> 00:31:45,520 seem to be included in the same function, 553 00:31:45,760 --> 00:31:46,380 right? 554 00:31:46,500 --> 00:31:49,640 So a pretty easy way to look into a binary, 555 00:31:50,000 --> 00:31:51,020 not always going to work, 556 00:31:51,120 --> 00:31:52,720 but it's a good place to start and it's, 557 00:31:52,720 --> 00:31:52,980 you know, 558 00:31:53,020 --> 00:31:53,520 it's worth a shot. 559 00:31:55,100 --> 00:32:02,200 So if we actually get into the disassembly of the function that contains those XORs, 560 00:32:02,200 --> 00:32:07,300 we can see that those two XORs are included within that block towards the top. 561 00:32:07,540 --> 00:32:10,440 And as denoted by the, 562 00:32:12,240 --> 00:32:14,700 the green line that's going back and forth, 563 00:32:14,900 --> 00:32:16,820 those two XORs are going to be looped over. 564 00:32:17,020 --> 00:32:18,340 So that sounds, 565 00:32:18,560 --> 00:32:19,300 I mean, 566 00:32:19,320 --> 00:32:23,480 that sounds like it's probably going to be our crypto algorithm. 567 00:32:24,940 --> 00:32:26,680 So moving on from there, 568 00:32:26,800 --> 00:32:28,160 there's two write file calls. 569 00:32:29,080 --> 00:32:29,360 The, 570 00:32:29,500 --> 00:32:38,400 the first write file includes the previously ASCII representation of the previously identified byte sequence for the magic byte sequence. 571 00:32:40,120 --> 00:32:41,620 The second write file, 572 00:32:41,620 --> 00:32:47,160 it appears to write out the transform buffer that's affected by the XORs that we saw from earlier. 573 00:32:47,860 --> 00:32:48,380 Okay. 574 00:32:49,660 --> 00:32:53,600 And here's a decompiled view of that same code section. 575 00:32:53,820 --> 00:32:56,740 We extrapolated out to cover more, 576 00:32:56,880 --> 00:32:58,680 more code within that function. 577 00:32:58,940 --> 00:32:59,460 And, 578 00:32:59,540 --> 00:33:00,080 you know, 579 00:33:00,080 --> 00:33:02,540 this gives us a little bit more of a sanity check to determine, 580 00:33:02,660 --> 00:33:02,880 okay, 581 00:33:03,000 --> 00:33:03,340 all right, 582 00:33:03,360 --> 00:33:08,340 this really does look like we're reading in file contents and we're just transforming them. 583 00:33:08,400 --> 00:33:09,520 And there's, 584 00:33:09,900 --> 00:33:10,320 you know, 585 00:33:10,320 --> 00:33:11,460 one specific line, 586 00:33:11,460 --> 00:33:12,400 within the, 587 00:33:13,100 --> 00:33:15,660 within the decompilation that we're going to focus on. 588 00:33:18,020 --> 00:33:19,540 So as we can see on the right, 589 00:33:19,560 --> 00:33:20,680 I've narrowed it down to, 590 00:33:21,540 --> 00:33:22,200 you know, 591 00:33:22,200 --> 00:33:24,660 just the nuts and bolts of the encryption. 592 00:33:25,200 --> 00:33:26,760 And in this case, 593 00:33:26,780 --> 00:33:28,060 it's using a hard coded key, 594 00:33:28,200 --> 00:33:29,300 which we've identified there. 595 00:33:30,340 --> 00:33:34,140 And all it really looks like it's doing is it's utilizing those two XORs, 596 00:33:34,140 --> 00:33:36,340 but there's a little bit more math involved here. 597 00:33:36,700 --> 00:33:37,540 But it's, 598 00:33:37,540 --> 00:33:37,860 you know, 599 00:33:37,860 --> 00:33:39,740 just looping over that until it's, 600 00:33:39,740 --> 00:33:41,220 until it's exhausted. 601 00:33:41,220 --> 00:33:42,300 You know, 602 00:33:42,400 --> 00:33:43,620 all the contents within the buffer. 603 00:33:44,280 --> 00:33:44,720 Now, 604 00:33:44,820 --> 00:33:45,720 if we look on the left, 605 00:33:45,860 --> 00:33:50,000 there's a Python script that I wrote to essentially mimic everything that we see here. 606 00:33:50,900 --> 00:33:52,600 There's nothing too special about it. 607 00:33:52,780 --> 00:33:54,180 I first read in the, 608 00:33:54,260 --> 00:33:56,000 the first four bytes. 609 00:33:56,140 --> 00:33:57,360 I save that off to the, 610 00:33:57,440 --> 00:33:57,940 the header. 611 00:33:58,240 --> 00:33:58,680 And, 612 00:33:58,740 --> 00:33:59,140 you know, 613 00:33:59,160 --> 00:34:01,180 we could do a little bit more of a, 614 00:34:01,200 --> 00:34:03,740 of a sanity check to make sure it matches up with the, 615 00:34:05,660 --> 00:34:08,760 with the previously identified magic byte sequence in order to, 616 00:34:09,340 --> 00:34:10,940 in order to confirm that we're working, 617 00:34:10,940 --> 00:34:12,260 working with a encrypted file. 618 00:34:13,320 --> 00:34:14,000 You know, 619 00:34:14,020 --> 00:34:14,360 so, 620 00:34:14,480 --> 00:34:15,740 but as I said earlier, 621 00:34:15,920 --> 00:34:16,640 proof of concept, 622 00:34:16,880 --> 00:34:17,260 you know, 623 00:34:17,260 --> 00:34:18,640 this doesn't have to work for every single file. 624 00:34:20,360 --> 00:34:21,320 Then from there, 625 00:34:21,400 --> 00:34:27,420 we're just individually reading in bytes and transforming them according to the set of operations that we specified there. 626 00:34:27,600 --> 00:34:29,140 And we're writing it out to a, 627 00:34:29,680 --> 00:34:31,120 write it out to a separate file. 628 00:34:32,760 --> 00:34:33,240 Okay. 629 00:34:33,280 --> 00:34:33,660 So, 630 00:34:33,680 --> 00:34:34,640 let's test out this script. 631 00:34:41,740 --> 00:34:42,220 Okay. 632 00:34:42,580 --> 00:34:43,060 So, 633 00:34:43,140 --> 00:34:45,040 we start out with our script on the left. 634 00:34:45,120 --> 00:34:46,000 On the right, 635 00:34:46,060 --> 00:34:47,800 I just have the, 636 00:34:47,800 --> 00:34:49,920 the output file already created, 637 00:34:50,040 --> 00:34:52,820 but it's just set to null data. 638 00:34:52,960 --> 00:34:53,120 So, 639 00:34:53,200 --> 00:34:53,620 just to, 640 00:34:54,700 --> 00:34:55,460 you know, 641 00:34:55,460 --> 00:34:57,320 just show you that there's nothing in there already. 642 00:34:58,660 --> 00:34:59,140 So, 643 00:34:59,260 --> 00:35:00,300 the readme.txt, 644 00:35:00,480 --> 00:35:04,540 the original plain text that we're using is just a readme file for Alidebug. 645 00:35:04,860 --> 00:35:06,120 That was our crypt text, 646 00:35:06,220 --> 00:35:07,500 our cipher text to the left. 647 00:35:08,040 --> 00:35:09,960 And we run it through our script. 648 00:35:09,960 --> 00:35:12,400 And it looks like everything is good. 649 00:35:12,880 --> 00:35:13,520 So, 650 00:35:13,620 --> 00:35:16,160 we've generated our plain text again. 651 00:35:20,140 --> 00:35:20,780 So, 652 00:35:20,940 --> 00:35:21,960 research in the field. 653 00:35:22,980 --> 00:35:27,680 Despite the overall proliferation of ransomware within the last few years, 654 00:35:27,860 --> 00:35:30,040 researchers have managed to keep pace. 655 00:35:30,580 --> 00:35:32,480 And it's pretty impressive considering, 656 00:35:32,820 --> 00:35:33,380 you know, 657 00:35:33,380 --> 00:35:36,820 how much money is going around and is involved within ransomware. 658 00:35:36,920 --> 00:35:39,640 I think there's been estimates that in 2016, 659 00:35:39,640 --> 00:35:41,340 over a billion dollars was, 660 00:35:42,080 --> 00:35:42,760 you know, 661 00:35:42,760 --> 00:35:45,420 was successfully solicited from, 662 00:35:46,040 --> 00:35:47,560 from victims of ransomware. 663 00:35:47,880 --> 00:35:48,400 So, 664 00:35:49,120 --> 00:35:52,200 new variants and new families are popping up day by day. 665 00:35:52,400 --> 00:35:54,620 But there are researchers that are out there that, 666 00:35:54,620 --> 00:35:54,940 you know, 667 00:35:54,940 --> 00:35:56,340 we're really working hard towards, 668 00:35:57,200 --> 00:35:57,840 you know, 669 00:35:57,860 --> 00:35:58,860 reverse engineering and, 670 00:35:58,900 --> 00:36:01,860 and analyzing all these samples. 671 00:36:02,240 --> 00:36:02,760 And, 672 00:36:02,960 --> 00:36:03,380 you know, 673 00:36:03,400 --> 00:36:03,940 more importantly, 674 00:36:04,040 --> 00:36:08,120 developing and releasing decryptors to the public for free in order to, 675 00:36:08,160 --> 00:36:09,400 for victims to get, 676 00:36:09,400 --> 00:36:10,600 get access back to their data. 677 00:36:12,100 --> 00:36:16,360 The Bleeping Computer Forums are a really good source to start with, 678 00:36:16,480 --> 00:36:18,760 if you're trying to research decryptors. 679 00:36:19,260 --> 00:36:21,800 Blood Dolly is one of the very active members there. 680 00:36:22,620 --> 00:36:23,600 Malware Hunter Team, 681 00:36:23,740 --> 00:36:24,180 Malware Tech, 682 00:36:24,420 --> 00:36:25,100 Demon Slay, 683 00:36:25,780 --> 00:36:32,320 those guys are all very intricately involved in developing decryptors and reverse engineering ransomware. 684 00:36:33,160 --> 00:36:36,580 Malware Tech is pretty famous for his WannaCry kill switch. 685 00:36:36,780 --> 00:36:39,160 That saved people quite a bit of time and pain. 686 00:36:39,820 --> 00:36:41,960 And there's definitely several others. 687 00:36:42,200 --> 00:36:42,540 And, 688 00:36:42,620 --> 00:36:42,880 you know, 689 00:36:42,920 --> 00:36:44,460 there's a lot of companies also involved in, 690 00:36:44,460 --> 00:36:47,320 in developing and releasing these decryptors to the public. 691 00:36:47,500 --> 00:36:48,180 And it's, 692 00:36:48,180 --> 00:36:49,980 it's something that definitely should be noted because, 693 00:36:50,520 --> 00:36:51,180 you know, 694 00:36:51,180 --> 00:36:51,880 you know, 695 00:36:51,880 --> 00:36:52,840 as I said last year, 696 00:36:52,940 --> 00:36:53,480 you know, 697 00:36:53,480 --> 00:36:55,480 over a billion dollars was collected from people, 698 00:36:55,540 --> 00:36:56,140 but, 699 00:36:57,300 --> 00:36:58,060 you know, 700 00:36:58,060 --> 00:37:01,560 people are releasing these decryptors for free to the public. 701 00:37:01,660 --> 00:37:04,080 And it really is a nice service that they're providing, 702 00:37:04,840 --> 00:37:05,360 you know, 703 00:37:05,360 --> 00:37:06,940 not only to the security community, 704 00:37:07,140 --> 00:37:08,780 but to users in general of the internet. 705 00:37:10,640 --> 00:37:12,160 So to wrap things up, 706 00:37:13,200 --> 00:37:18,100 crypto implementations are very prevalent in ransomware. 707 00:37:18,180 --> 00:37:18,720 Crypto is hard. 708 00:37:20,240 --> 00:37:26,460 Ransom notes are definitely not the most trustworthy source for crypto implementation technical specs. 709 00:37:26,740 --> 00:37:30,260 So don't believe the hype if you see a really bad ransom note. 710 00:37:30,420 --> 00:37:31,420 It's not always going to be truthful. 711 00:37:32,760 --> 00:37:35,800 And as with just normal malware analysis, 712 00:37:36,100 --> 00:37:38,400 the reverse engineering and cryptanalysis of, 713 00:37:38,400 --> 00:37:41,220 of ransomware and decryptor development, 714 00:37:41,500 --> 00:37:42,060 they're not, 715 00:37:42,060 --> 00:37:43,380 they're not linear processes. 716 00:37:44,220 --> 00:37:45,620 It's going to be a lot of trial and error. 717 00:37:46,520 --> 00:37:50,360 You'll want to utilize chosen plain text attacks when you can, 718 00:37:51,420 --> 00:37:56,620 in order to try to leak out more information about the encryption algorithm without having to fully reverse engineer it. 719 00:37:57,240 --> 00:38:00,680 And you'll want to focus on sections within the code, 720 00:38:01,240 --> 00:38:01,840 you know, 721 00:38:01,840 --> 00:38:04,000 whether it's the disassembly or running through debugger, 722 00:38:04,020 --> 00:38:04,220 whatever, 723 00:38:05,080 --> 00:38:07,020 where modifications are going to occur. 724 00:38:07,640 --> 00:38:08,080 Then, 725 00:38:08,080 --> 00:38:08,500 then from there, 726 00:38:08,580 --> 00:38:12,760 you can use that as a base to dig deeper for more clues in order to, 727 00:38:12,820 --> 00:38:13,340 you know, 728 00:38:13,340 --> 00:38:16,400 help get a better idea of what's going on with the encryption. 729 00:38:17,320 --> 00:38:17,720 And, 730 00:38:18,240 --> 00:38:18,820 you know, 731 00:38:18,840 --> 00:38:21,020 initially focus on building out a proof of concept, 732 00:38:21,260 --> 00:38:21,900 you know, 733 00:38:21,900 --> 00:38:25,620 do a lot of stress testing so you can cover all the edge cases like we saw with a torrent locker. 734 00:38:26,400 --> 00:38:26,800 And, 735 00:38:27,020 --> 00:38:27,440 you know, 736 00:38:28,040 --> 00:38:28,920 so you stress test, 737 00:38:29,040 --> 00:38:35,220 you harden and you cover all the edge cases and hopefully you have yourself a fully working decryptor that's going to work across the board. 738 00:38:35,220 --> 00:38:38,660 And that's all I've got to say. 739 00:38:39,580 --> 00:38:40,280 Thank you. 740 00:38:45,660 --> 00:38:46,240 All right. 741 00:38:47,420 --> 00:38:48,520 Time for questions. 742 00:38:54,780 --> 00:38:55,340 Hey, 743 00:38:55,400 --> 00:38:56,640 thanks for, 744 00:38:56,720 --> 00:38:57,480 wait, 745 00:38:57,540 --> 00:38:58,120 the mic isn't working. 746 00:39:00,640 --> 00:39:01,180 . 747 00:39:03,580 --> 00:39:04,140 . 748 00:39:04,140 --> 00:39:04,560 . 749 00:39:04,560 --> 00:39:05,200 . 750 00:39:05,200 --> 00:39:05,700 . 751 00:39:09,140 --> 00:39:10,140 . 752 00:39:20,100 --> 00:39:21,100 . 753 00:39:21,100 --> 00:39:21,600 . 754 00:39:21,600 --> 00:39:21,860 . 755 00:39:21,860 --> 00:39:21,940 . 756 00:39:21,940 --> 00:39:21,960 . 757 00:39:21,960 --> 00:39:21,980 . 758 00:39:21,980 --> 00:39:22,000 . 759 00:39:22,000 --> 00:39:22,620 . 760 00:39:25,100 --> 00:39:26,100 . 761 00:39:26,100 --> 00:39:26,120 . 762 00:39:26,120 --> 00:39:26,780 . 763 00:39:26,780 --> 00:39:32,840 because there's definitely a lot of cases where you can tell by reverse engineering the code 764 00:39:32,840 --> 00:39:40,060 that it really doesn't reach that level of complexity that's typically seen in more like an 765 00:39:40,060 --> 00:39:51,380 APT sort of scenario. So what we're seeing a lot lately is the rise of ransomware as a service 766 00:39:51,380 --> 00:39:59,140 and ransomware kits that are developed by more seasoned developers and they offer it up to 767 00:39:59,880 --> 00:40:04,200 budding cyber criminals who want to launch their own ransomware attacks and get some of that 768 00:40:04,200 --> 00:40:12,680 sweet Bitcoin. So I see that being as more of a cottage industry that's going to develop a little 769 00:40:12,680 --> 00:40:19,960 bit more. But mostly the cyber criminals that are developing their own ransomware, I would say 770 00:40:19,960 --> 00:40:21,040 right now, the complexity. 771 00:40:21,380 --> 00:40:26,420 Complexity isn't where you would kind of expect it to be with the profits that have been 772 00:40:26,420 --> 00:40:43,280 generated so far. I do have plenty of examples but then I wouldn't have been able to decrypt them so 773 00:40:43,280 --> 00:40:51,360 I wouldn't think it's good. But with a lot of the ransomware that doesn't have a lot of 774 00:40:51,380 --> 00:40:53,760 size, the complexity is a problem. It's a barrier that does the encryption right. They're 775 00:40:53,760 --> 00:41:00,620 utilizing asymmetric encryption so they're doing some sort of key exchange with a C2 so they have a 776 00:41:00,620 --> 00:41:05,020 little bit more network infrastructure involved. But right as long as they're doing the key 777 00:41:05,020 --> 00:41:11,240 exchange correctly that seems to cover most of their bases. And in that case then you're kind of 778 00:41:11,240 --> 00:41:16,060 left with just hoping for some sort of side channel attack or some artifacts being left on disk 779 00:41:16,060 --> 00:41:17,520 for finding and recovering a key. 780 00:41:21,540 --> 00:41:26,040 Any other questions? All right. Thanks for your time.