Reverse Engineering Ransomware Protocols

reverse engineering ransomware protocols dharma now you're you're going to dance right okay okay anyway here we go cool so i'm going to start out quick intro who am i why does anyone care about what i'm saying right so i'm kyle nieman uh my email is up there if anybody's got any questions about anything feel free to reach out i'm product lead at cyber crucible local cyber security company but not going to talk about that too much i'm a little bit of a self-proclaimed ransomware expert one of those things where uh you know i start talking i call myself an expert someone else calls me an expert now uh that's what i am right so my background is a little bit of threat

hunting malware analysis low-level kernel development back-end development things like that lots and lots of encryption kind of leads you right into ransomware right so a quick kind of intro to the talk is that it's very technical um it's a lot of like staring at hex editors type of thing uh i call it dynamic analysis as opposed to static analysis because for those familiar with the two terms static analysis refers to like uh using ghidra idapro something like that to look at like functions that are in executables this is not that this is looking at the protocol itself especially on disk right so it's going to be insight into dharma ransomware specifically and kind of the discovery a little bit

of the story of like how you go from oh crap i was hit with this ransomware to understanding what happened on your disks right it's definitely not the secret to free description or anything like that obvious but i kind of got to say it because otherwise someone's going to say okay well you can save me millions of dollars right we'll see but you know probably not so uh you know in the why do you care of course is you can figure out how bad your situation is if you're involved with this ransomware you get a little bit of insight if the attacker is kind of manipulating you trying to get more money for no reason all that kind of

thing you can figure out if you can even decrypt if it's even possible and how much it'll cost you all sorts of things like this so again it's going to be pretty technical but hopefully everyone can get a little bit of insight out of it so first question should be what is dharma uh it's a windows-based ransomware it's c plus though that doesn't matter at all it's exactly compiled which means that we can't just look at dlls um you know see what it's doing there's no like api monitoring because it's all built right in uh it's very strongly encryption encrypted it uses like the best encryption standards out of any ransomware you know many of them use

good standards but it's up there with the best uh it's aes encrypted for all the files which is very fast of course and then rsa encrypted if you don't know what those are at all it might suck but i'm going to explain them quickly i don't want to spend too much time though um and the ransomware itself uses a two-step process so you scan your system you send the output to the attacker you pay the ransom and then they're going to send you back a decrypter if you're wondering why there's javascript on the right-hand side uh me too that was the first image result uh on google when i search for ransomware it kind of doesn't make any sense but

you know that's part of the problem no one understands what's going on when they're searching for answers um so you know something more relevant might be like a ransom note for this ransomware you probably can't see it too well but it's you know it's just all your files are encrypted uh send bitcoin to this address type thing right so quick explanation of aes um this is it uses cbc which is a type of block chaining or block cipher so it just kind of goes through one to the next to the next and you keep looping in uh 128 bit blocks all you need to know if you don't care about the implementation of it is it's

symmetric means that uh both ends have to use the same key it's a 256-bit key which is really secure it's very fast and all we need is like the key the padding the iv basic information rsa on the other hand asymmetric encryption the two parties involved have different keys private and public also super secure but much slower so if you ever see people say that ransomware uses rsa it probably does but it doesn't encrypt every file with rsa it's way too slow right it's going to use aes something fast uh maybe cha cha whatever and then come back and encrypt the keys for the first algorithm with the second algorithm right so getting into the really dry technical stuff a little

bit a lot a bit actually what does it look like so i've opened here in a hex editor you can see this is an encrypted file it means absolutely nothing to anyone right you're looking at random data but if you can see and this is the beginning uh file on the left and the end of the file on the right you can see on the right hand side there's english readable words it's actually the file name right driver installation log.txt and this is everything here is real sample data it's you know been changed a little bit so that there's no sort of like concern about client data being leaked but it's a real ransomware sample real data

so we can look at the file name and we can say great that's the file name who cares it doesn't get us anything what's after the file name because we have to start somewhere there's some zeros it's a delimiter right doesn't mean anything by itself either and then you can kind of keep looking and say uh you know let's compare two files do they do the same thing is the file name in the same place what what follows let's really compare and contrast so you know same thing open a separate file favicon.ico same thing file names there and we don't know anything else about it but we can see you know here's where the similarities

start right they both got this kind of weird identifier after them also english readable might be coincidence who knows but it's there in both so we know there's at least a similarity it's not just complete randomization which is good because we're trying to find a solution if we keep looking um you know we'll notice that it's actually not just the english readable part it's actually this big string of bytes what they are and why they were generated by what algorithm not important right what's important is that they're the same in both they're serving as kind of like an identifier uh something here is telling us more about what's going on you know we can start to

say okay if these parts are similar is are there other parts that are similar maybe you can start to get an inkling of like reusing keys something like that that's jumping a little forward but that might be what's running through your mind when you're trying to actually you know save your client here you're like oh maybe there's hope and then you know your hopes are dashed because immediately you notice that after that you know 20 bytes or whatever it was they completely different again and nothing's the same so you know the questions that you're asking here the whole point of looking at these files again is like how bad is the damage is it actually encrypted

because sometimes you know you get hit with ransomware and it's not really encrypted it's like xored or zipped or something stupid or they change the file name in this case you know you're trying to figure out is it encrypted what kind of encryption all that kind of stuff and you know we've run out of things to look at here there's nothing more right it's all random data except for the file name so i mentioned a file scanner earlier with it being a two-step process the way this works is dharma infects my machine i can't open any of my files they're all encrypted the hacker has given me generously of course a file scanner and they say scan your pc

paste me the output from scanning your pc and then you know pay the ransom and i'll give you the data back so now we're going to start looking at the file scanner because looking at the files by itself totally not useful again not stacked analysis here but so we're going to look at the outputs that click scan pc see what the output is and this is a sample output of file scanner again you know some of you are going to recognize this hopefully base64 it's just encoded data so then we can actually just spit it into a base64 decoder cyberchef a tool if you're not familiar with i super recommend it um it can do tons of stuff

and it's really useful as just like a notepad kind of thing to do encryption decoding manipulation of bytes all kinds of stuff you know in a web ui cyber chef's not the point though right so paste into base64 you can see i'm converting from base64 to hex and the output's on the bottom i'm just going to blow it up same output same exact thing so again more bytes right we don't we don't know what's going on what we're looking at um the important thing here though is that like we're we can start to look for some identifiers and some things that like you know you might recognize and to me the first thing that's obvious here is

that these are kind of little endian integers and just give another brief explanation of what that means because some people are going to be different levels of technical uh little endian is kind of when the bytes are stored in reverse order so this first one zero two zero zero zero is actually just a two because you kind of read it in reverse and we know they're integers we suspect they're integers because it's 32 bits right it's four bytes um so what we're trying to do here is just gleam some sort of structure out of this data we know obviously if the attacker needs it it's not just random it's not just a key it's not you know whatever so

we want to know what kind of information we're providing to them for one because how are they going to use it uh two how are they going to manipulate it and three can we get some extra value out of it or are we going to lose data you know like are we you talk about um you know getting hit twice with double extortion and things but are we you know making our situation even worse by sending them even more data we want to know what it is right so like i said we know it's four bytes it's little endian no idea what they are are they integers are they counters they look like they're kind of evenly spaced

right um i mean the first one aside the second two the they're kind of evenly spaced same amount of data after them so if we just kind of split it apart same data just formatted now i put some new lines in there um you know you can kind of almost start to see patterns but it's still like what is going on i don't know what i'm looking at and if you just almost you know start to peel back the layers a little bit you can say okay the section in blue is the same size as the section below it they're both eight rows of 16 bytes that doesn't mean anything by itself but it's really useful to just start getting

a count of your information uh each blob if you want to call the blue a blob has some integer in front of it uh prepending it in this case the green correlates to the blue we have no idea what the yellow is uh and the red is like two we you know it's who knows so if we keep you know kind of thinking through this we could say okay well the two probably chord uh correlates to the number of blobs right um you know and this is my thought process as i'm actually reverse engineering this because this is like i said like client data from an infection client data has been changed obviously but this was the real story so i'm like

okay there's a two it's probably the number of blobs what's the yellow and you kind of have to have a little bit of knowledge here in uh protocol analysis of some sort network file doesn't matter encryption to but you you start to pick up on these patterns like okay if i'm sending data the the two pieces of data next to each other probably correlate to each other and there's probably like a checksum something involved right and it actually turns out that that's exactly what this yellow is it's a crc32 uh it's a cycle redundancy check it's very similar to a hash checksum something like that so what happens is if we paste the whole blob

following the yellow portion into cyber chef and we say give us a crc32 it gives us this output and because we're little endian which again means reverse right if we kind of swap the bytes so that the first is now last the second is now third blah blah blah you follow the yellow lines a little bit you can see it's it's the same output so that's that's your yup check that's a crc so you know you're kind of starting to understand things a little bit more and say okay well if the red is a a blob counter and the l is a crc then the data that follows the yellow must be important that's what the hacker

actually needs and you can figure out that you know by speculation and then you can run some ransomware on some vms a little bit more and get some confirmation of this which is exactly what i did the green is actually the file counter per blob so the number of files that's affected by a blob is that green counter in this case it will be in hex 1 2b right and then the blobs pure speculation at this point but we can confirm it is rsa 1024 keys which means that you know these are actually um this is the data we care about right and we can go back and you know confirm all this and that's what i'm going to walk

through so we need to confirm it's rsa because it's just a wild guess i totally pulled that out of nowhere right what we can look at is on the left the same thing you're just looking at the blobs and on the right that initial driver installation file right so you can see the blue on the left matches the blue on the right there's a little bit of an offset there but they're identical right it's the same exact information now why do we know it's rsa besides it could be anything right it's just there's the same data who cares but it's the exact same blob and we can think just by you know wondering through how ransomware works

that we know sometimes rsa keys get reused uh it's a unique aes key but what about the other stuff in the file right if we're calling this an rsa blob what is everything else well let me get to that but so i'm going a little bit out over here sorry about that jumping around but it's rsa so what do we know what do we care right it's our say that means there's no free decrypter that means this isn't zipping this isn't xoring this isn't like oh i can make a universal decrypter it means there's actual rsa keys at play and if one of you guys has like an rsa breaking decryption algorithm please tell me about it you can make a lot of

money but um you know it's it's unbreakable it means this if the attackers are at least somewhat sophisticated right you're dealing with like real players here in a sense uh and do we have to pay the ransom is always the next question especially when you talk to the client you could tell them i i broke the encryption or that i know what they're using and i figured out the algorithm i spent 40 hours doing it and it's great and i know all this stuff now they're gonna say okay but did i save money right so the answer is like obviously yes you have to pay because it's rsa we can't break it but there's some information that we've

gleaned and that we can use and that is actually super super useful if you're willing to pay the ransom which might you know you might have to let's assume you have to since we know each key has a uh counter we know that we need every key to decrypt right that's common sense you you can't unlock a lock without the key if picking it is out of the question um but do does the hacker need to know the counter there's no reason right it doesn't correlate to anything we could decrease the counter might save money if it's like a sliding pay scale um you know we could put one file instead of one million files affected

they're probably way more liable to charge you money if it's a million files because they think they've hit a data center rather than like a personal hard drive right um so we know we need every key but we can probably change that and then there's this big question of like do we cheat do we manipulate the data what if we're wrong all this kind of stuff right so the what if you're wrong can be pretty easily alleviated by doing tons of tests here you can make sure it's the same output that you expect every time all that kind of stuff there's not really an ethical consideration here being that they're hackers and you got hit with ransomware

it's you know who cares about them they're going to get paid less but you know they deserve it so the kind of you want to say yes decrease the files be careful but there's other things that can happen too and for one it's are you sure that you modifying the files is actually getting all the keys are you sure that you're not accidentally like changing something you've made sure that the file counts that are original line up because if you did have a data center affected and a million files are encrypted but you actually this counter only says 10 then you've you don't want to mess with that because you've screwed something up you know

you're missing keys what about network storage other mounts there's all kinds of questions here is the attacker aware of storage are these keys lining up with your storage there's always considerations with ransomware whenever you're trying to do any kind of manual recovery of attached storage devices because sometimes the attackers do really crazy things and you're not expecting it and you end up with corrupt data if you miss the files you're going to have to pay again so consider like i just completely get rid of the section in blue because i deemed that i don't need it i looked at all the files that use it and i don't want to pay for multiple keys that i don't need so i just get rid of

it and i send it to the attacker right if i missed it i can't email the attacker and say hey guy can you please give me my money back for those files you know you're going to have to pay again probably the same ransom probably more actually if they know that you are messing with things or they might just not want to deal with you if you know they start to smell law enforcement or something else or they think they do right missing files you know if you're missing keys you really need to reconsider this because just to reiterate it's really hard for you on the defense side to remap a destroyed network because you don't know

what's been corrupted what's been affected it's really easy for the attacker to shotgun blast their malware out right they could hit as many servers as you want they could spread it from one machine ten machines and they're corrupting things along the way maybe maybe not but it's easy for them to corrupt it's hard for you to rebuild so you need to be really careful about these things and of course they're not forgiving again um so you know just as an exercise you can look at the file count and say does it seem right is it 11 000 files infected is it 2000 files affected uh what if it said f right f is 15. so

that's just the things to think about so okay we've deemed what we can we paid now what right do you trust them probably not they're going to send you a decrypter next that's the next step right they're going to respond and say run this it'll decrypt your system you're good the problem with that is they already infected you with malware once so do you trust them not to do it again because uh you know i i wouldn't right um and i want to spend some time talking about this just because it's can they reinfect you of course um what's the alternative if you don't want to run their software right the alternative is to build your own

decrypter have someone build your decrypter you know whatever right um are they going to reinfect you who knows they might be ethical hackers in in the other sense of ethical right they're black hat but then they decide to be nice um you know and there's all kinds of really bad things that they could do like say for example i send my output of my scanner and it says okay um there's 20 keys 20 million files and i pay the ransom and the attacker sends me the decrypter for those 20 million files 20 keys but they lob off the bottom two keys because that's 18 out of the 20 million right if i haven't done this reverse engineering i'm not going

to know that i'm going to have no idea all i know is i sent them data they sent me back data what's going on right um them lobbing off the files corrupts it means i can't get those those files back and they can just come back and say like oh you sent me corrupt data and now the ransom is an extra bitcoin or an extra 10 bitcoin or whatever right um so that's kind of you know you still have to interact with them but at least you can be wise to their you know antics if you know what's going on um and this is something we've seen with a couple of people clients um even not clients you know just sometimes

you read about it online and blogs or whatever and people say well the ransom was 0.1 bitcoin and then they came back and they said another 0.2 bitcoin and they said another 0.5 and eventually i paid three whole bitcoin because i just had to keep going and going and going um you know it happens right so enough of the the kind of you know back to the technical a little a little less of the preachy-ness right but okay the output of what the attacker sent me back what is it so it's more base64 this part looks familiar you know it looks actually really familiar if you look at it spread out the same way we did before we

see there's a two at the top again because we sent two keys we got two back we can assume it's a crc in the same place and we can double check that and it is and then we know we can look at the the next blob that's not highlighted in blue this time but starts with the aaa at the top right after the yellow and it matches um the before and after right the before being what we sent to the hacker the after being what we got back it's the same exact data and you know this might cause you pause at first you might say okay why did they send me back the exact same

data um did i get scammed which is always a consideration but no in this case you didn't get scammed this is what you wanted because what's happening is this is the rsa cipher text of the encryption key they need to know just as well as you do what key associates with what file and there could be millions right they could be and it is in this case one key per one file um they do it automatically randomly doesn't matter them there's no master key anything like that so they need to associate that ciphertext in the encrypted file with the new key they've given you back right so they're going to give you the same data this is

what you want after that data you know after that same blob that we've already verified you can say okay well it's followed by 32 bytes um great right 32 bytes hooray but aes keys are 32 bytes you can make a pretty simple you know assumption here that these are aes keys i should say aes 256 keys are 32 bytes it's in the name but then you can say okay you know we have the key great now let's go back and look at the file again now we we know the files are using rsa to encrypt the aes keys and the files are encrypted and they have the file name in them that's great that's a ton of

information we don't know anything else about it we don't know what all this extra data is we don't know where the file starts and where it stops you know in theory you'd say okay it starts at the start and it stops at the end but that's probably not true because there's at least some extra data in there right so it could get manipulated in all kinds of weird ways we know where the file name is we know kind of what i'm going to call the header of the footer weird name but it starts with that bv0y um it the footer just the end and it's the header because that's it's the start of the end right

there's the header of the footer again just for clarity and then there's some weird counter and we're gonna i'm calling it 16 bytes because i don't know what it is it could be it could be whatever right um it's just 16 bytes in a row and the reason that i've kind of padded that 16 bytes off is because it stands it by itself when you start to compare it to the file name and the header of the footer and all this kind of weird stuff and then right after that 16 bytes is where the rsa key existed so you're kind of saying okay i know where the rsa key is i know presumably where the end of the file is because i know

uh the file name and it's probably before that and all this kind of stuff so this sum counter we don't know what it is it's another integer presumably right um i'm calling it a counter because it's very small normally if it's like some large integer that's random or crc something like that it's going to be large it's going to be you know have better entropy than 0. this one is just zero e it's 14 that's very small right so the the consideration is like what is this being used for what like what what's happening here right what is this counter and we can actually figure out that the first 16 bytes is the iv because we're assuming it's aes aes uses

16 byte block ciphers and they have 16 byte ivs and the counter is actually just padding because we know that we have to associate things back to the encryption algorithm because the goal for us and the attacker is to decrypt so we know that you know we need some number of padding bytes between 0 and 15 in this case happens to be 14 and we know the iv and we know the key so we can try to decrypt so there is a little bit still of uh extra speculation of like what is this you know what what is what about the end there's still four bytes on the end what is it important do i need to know about

it am i gonna like destroy my system um it's like maybe still a counter but it's kind of simultaneously small and big right 58 hex that's not a small number it's also not like a four byte number so you're like what is going on here it's not padding it can't be a file counter because it doesn't match the one that we looked at previously is it important can i throw it away there's tons of considerations right it turns out that you know it kind of matters but not really um and we we can figure out what it is this is pretty grueling actually for me to figure out because i was like really concerned i'm gonna corrupt some data

right so if we start to look at how big the footer is in general we know we have a 26 byte header 16 byte iv 4 byte padding 2 128 rsa and then for weird bytes um and honestly this is just counting by hand there's no like special magic going on here and if we add all those up we get 178. uh great 178. what the hell before those you have the file name and a bunch of weird stuff right so if this is before those meaning you start at the end go backwards 178. well you know some more quick math 5 8 hex is 88 178 plus 88 is 266. if we go back 266

that's the start of all these weird zeros so we don't know what any of those zeros at the top are either but you know now we know okay that weird counter at the end leads us before all this other weird stuff so that's where the file ended um you know we can cut off all this crap and we can say you know the file is the rest of it from zero to down um so you might say okay are we done and there's a couple reasons that the answer is no um you know yes you've found you've solved this part of the protocol there's actually a lot more to it you still have to write the decryption

though you have to really really really worry about writing that decryption because encryption is really hard to get right and what you have to consider is did the attacker get it right because if they messed up on their end and you do it correctly on your end that leads to corruption you almost need to mess up in the same way right you need you need to kind of replicate their encryption before you can decrypt it to be sure um you need to make sure that you catch any bugs or corruptions i've seen attackers that like accidentally delete data and it ends up kind of working out for them because they have some like weird off by

one error and it like replicates it's crazy but like somehow they've ruined their encryption and it ends up with the right data anyway because they have the bug in both the encryption and decryption stage you probably are going to want to support contract if you're doing this with your client and that's obviously like way more businessy than technical but you're going to want something in the works there because you're gonna have to keep supporting this if you're doing manual decryption for them there's no way it's like a one-time engagement you go on and say okay here you go guys you're done uh i'll never speak to you again because everything's perfect that's not the world we live in right um

you're also going to obviously want to fill them in as much as you can on the technical details they're probably not going to go for it but you need to tell them the next consideration is network shares but what i actually want to do real quick is show a couple more slides that i have disabled so just bear with me for one second i've disabled a whole ton because i didn't think i was going to get to them and i've been talking really fast skip slides okay cool so there's another problem you might say what we just figured everything out the problem is that there's actually not just one protocol with dharma um there's two and it's

really different dharma actually treats bigger files way differently than smaller files smaller files or that's protocol that we just went over it's pretty straightforward it just says okay great encryption key find it decrypt it it's pretty straightforward anything that is 24 bit shipped at 16 and that might seem like a really weird number i you know whatever um anything larger than that file size they encrypted completely differently so here's a sample file this is the beginning of it um you might notice it's all zeros that's not encryption uh it's zeros right that like how do you recover from data being deleted so your first thoughts are panic and besides that you think okay is this

data corrupted because it's gone you can't like turn zeros into not zeros uh it's super low entropy obviously because there's nothing there so it's not aes encryption it's not compressed because compression wouldn't do this it wouldn't have this many zeros that's like the antithesis um what is it right well where you know the first question once you've calmed down because you're worried about your career being over uh when do the zeros end right how many zeros are there do we ever actually get real data and the answer is yes eventually at this like suspiciously round number of like hex four thousand uh or forty thousand we get you know data again which is great um

the suspicious number is kind of weird because why would it just happen to be like a perfectly round number like that um and what's even weirder is you know this is still not encryption if we look at it it's a little bit hard to tell in this example because i think this is like some like microsoft office product that they do like compression inside of the file but it's it's low entropy and you're thinking okay was it plain text is it corrupt what's going on uh and the answer is that it's actually plain text uh i found this out just by scrolling through a bunch of files like this and eventually i found english words because it was like a word doc and

you know you eventually get to the markup that's like the real part so if you keep scrolling through the file eventually the zeros come back and now you're back to panic because you're like oh god it's just corrupt the zero like for some reason the first part of it's gone then there's data and then there's not data you know um and then they stop and then they come back and you know there's just all these zeros so the question is what do we know about the zeros because we know they it they're everywhere there's like data in the file but it's also gone partially so the only things we know about them are their sizes uh they start at zero

they go down to forty thousand then they start back up at you know eleven fb five five which i hope doesn't mean anything to anyone because it doesn't mean anything to me and it's a weird number uh and then the same thing three one f 200 doesn't mean anything to anyone that's not like any range of numbers that anyone cares about um but if you you know do some subtraction and you realize that each range of number is actually hex 40 000 size each that gives you a little bit of hope because that tells you that it's specifically made this way and you know there's just always the same number of them if you look at the very end of the file

it's the same thing it's a ton of ciphertext once the zeros end there's it's encrypted it's not plain text in this case it's you know back to encryption so we have this weird situation where we're dealing with data being deleted data being encrypted and data just being left alone all in the same file um this sets alarm bells off for me at least and probably a lot of people because you're like what do i do in this situation it's not a decrypt it's not decompressed it's not a it's not anything you don't like know how to handle it right so what do we know again just reviewing uh there's a ton of ciphertext this is

nothing like the other protocol but let's look at the footer of the file again right let's let's go back to what we know uh we know where the file name was we know all that kind of identifier stuff and we can say that this part kind of looks the same it's still the same you know i'm calling it again the header of the footer but that part's the same there's still a file name you can see it kind of starts with png that's the end of the file name there's still an iv there's still padding there's all this stuff but the padding is zero bytes and that's possible in encryption sometimes it just happens that way but

it's pretty unlikely uh every file that has this protocol was always zero bytes that's the unlikely part so that means that every single time this happened there was never any need for padding which kind of leads you if you know about like encryption and why padding happens you'd say okay is it block aligned right so the answer to is it block aligned is yes because there's no padding that's by default you know the answer to that but it just so happens that that you know there's c000 bytes and that that 40 000 hex which is the number of zeros if you times that by three because it's there's three of them then you get the same

number so this is a little bit weird and then you kind of start to piece it together as you stare at the wall for like six hours straight trying to figure out what's going on you have c0000 whatever total uh bytes of zeros and you have the same number of bytes of ciphertext and you could say okay the zeros must line up with the ciphertext obviously they've just like relocated it somehow so the way this works the way that it ended up working once you figure it all out is that that 24 bit shift 16 to the left that's c000 as well same thing so any file that's larger than that takes this protocol up and when they

take this protocol up what they do is take that many bytes and they just encrypt that many bytes so rather than encrypt the whole file they only encrypt you know whatever it might be three megs i think uh or 1.5 i have it no three because it's 1.5 times two so what about the rest of the file you can say that it's plain text great we saw that earlier but it's corrupt so you know you're kind of asking questions now like why did they switch their protocol up in the first place at all if they were worried about people realizing how the first protocol worked they wouldn't use it they would have done something else and it was still

pretty weird so you know they're not probably worried about that um so what's the reason that they just like change things up in this obscure way and the answer is a little bit of obfuscation they're just trying to change it up make their own protocols and do cool things but really it's it's speed um this isn't any sort of amateur hour buffer overflow which might be the first thing that some people you know jump to is like oh whoops they accidentally zeroed all their data it's actually just that they you know they wanted to be quick so if they're encrypting a one megabyte file that's very fast obviously one megabyte is not a lot of data these days uh if

they're encrypting a two terabyte file or even smaller than that say like a 20 gigabyte file five gigabyte file that takes time and the more time they take the less files they get to before you notice and you know your data center might go down or something your sql server because they're encrypting it you're more liable to notice that you know and you're immediately going to go check the rest of everything out so really what they're doing is speed they want to get in and out encrypt everything on disk as best as they can and what they're doing is encrypting only part of the data and then rearranging it so you'll never notice it if you open this up in a hex

editor like i did you're going to notice a bunch of zeros and you're going to say oh the data's gone right the only reason that we find this out is because first we did the the easier protocol and the smaller files and then you know we we made it all the way here so okay are we done uh you know not quite still right we kind of know that the zeros represent encrypted data and we know we have the encrypted data and we know it uses aes but there's still a lot of questions like we don't know where the plain text starts and stops in this file we could say okay we found the bytes that it starts and stops at

but it's not the same for every file it's like almost randomized um it seems to depend on the file size like maybe but they're not evenly spaced there's no sort of you know it's always 5000 bytes in or anything like that it changes based on the file size and obviously the attacker has to know i mean they're not just pulling data out of thin air so there's an algorithm involved and just saying there's an algorithm doesn't tell you anything because everything's an algorithm right but there's obviously something to figure out here's something to re so it's it's kind of right in front of our faces um in again a super obscure way so if we look back at the ranges of

where the zeros were what's going on there we can try to figure things out we've got the ranges back up so my of course my red square is a little bit messed up but if you look at the first red square c 0 0 f 2 3 1 0 0. you can see it's you know i don't want to skip ahead again it's it's the same numbers as uh in the bottom left right the the red boxes the the guy the attacker has put the data in the file saying where the offsets are so you know this gives another problem of we have to be able to find the offsets in the file but it's at least a little

closer we don't need to recreate the entire algorithm and figure out any weird randomizations or shifts or seeds or anything that they used all we need to know is it's stored in the file right and of course it's stored in the file because the attacker needs it as well so again are we now are we done yes but no right um and i kind of talked about this stuff before the decryption has to be written it's really hard this one is even crazier because uh you know there's all kinds of you know problems like did i get the index right um is my file size calculation wrong is there another protocol there's not thank god but like

you know there could have been so there's all sorts of things you need to worry about because you're going to corrupt data did the attacker corrupt data was the file being written to while it was being encrypted all this sorts of stuff right so you know there's all kinds of problems so the last like i talked about network shares before but just to reiterate remember the missing files and that this is because uh if we consider the fact that like there's missing keys something's gone uh the sizes don't line up if you consider like your network you probably have if you're a corporate network tons of shares tons of mounts tons of i don't know you have azure cloud aws

local nas whatever you've got you've got tons of stuff it's mounted in different ways you might not even know the hacker doesn't know or care either and they might in fact servers one through three they might affect just server two they could do whatever and that's gonna blast out encryption everywhere how many workstations have access all this kind of stuff so these are really i mean less of the the encryption kind of questions you have to ask but more of the just normal use case questions like how much of my data is encrypted so i've had people that i know i don't want to say clients because they weren't but i've had people that i know that have done this sort of

thing and said okay i found a decrypter i want to run it but they don't back up all the data first because it's like 20 terabytes or something more than that and they run their decrypter that they found or wrote or whatever and now their servers are hosed they're completely gone um what are they gonna do right it's the data's gone you can try to decrypt it but it was corrupt so good luck and it's it's just those kinds of considerations that you have to you know think about because what you know what happens you go from a ransomware attack that potentially you could get double extorted you could have tons of problems with but you could

pay money probably a large large sum of money you could pay money and fix it or you come in here with your hammer and start smashing stuff and try to fix it yourself and now you're at a state where you can't even pay the money and you're just gone right so that's pretty much uh what i've got so i know i actually went way faster than i expected i talked really fast and about some really dry stuff so if anybody's got any questions please good timing and i'll throw my email back up also because people generally want to talk shop about things so shoot me questions please don't ask me to come to crypto ransomware for free i probably can't

uh that's it um does anybody have any questions before i kind of meander off

yeah so i threw my email up here also just if anybody wants it so it's mostly experience i did a lot of malware protocol analysis in the network side before i did any ransomware related stuff so there's a lot of correlation of like storing things for network traffic and storing things for files because it actually usually wraps back to like c structs and a struct nc just being mapped directly to memory or to disk so it's mostly um manual at this point just with experience you could you know write some algorithms and there's tons of tools that do things it's really similar to like if you've ever run strings on something it pulls out like encoded data to look for

certain patterns like finding integers for example if i can just skip through a million slides now um finding the integers like the two is really obvious because it's for one it's at the beginning uh but it also has three zeros after it and if you know you're dealing with little endian then you know those are actually like the upper bits of the integer bytes whatever so you could write something like that that's going to search for certain padded data that pulls out integers and then maybe says like okay this is probably an int and this is the blob that happened after it up until the next in that kind of thing and that could help expedite the process the problem is

that when you're dealing with ransomware or malware executables um just because they're the same type like these are two windows ransomware executables they're not necessarily going to do anything related to each other except the encryption so you can try to build tools that do things automatically in my experience with reverse engineering specifically it's really manual because it's hard to get a perfect generalization just based on how different you know different binaries act cool um does that answer i hope great uh anybody else see i can cheat i have the mic um would you would you say that the bad actors are adapting to the fact that we're getting better at this and if so how well are they adapting i mean yeah

absolutely so ransomware i mean just like any malware in my experience there there used to be a lot of really bad ransomware badly written bad tradecraft um and as that kind of got handled because people would come up with you know uh one decrypter one size fits all it decrypts everything for everyone they would adapt to that by saying okay now it's one key per file and then they'd say okay well now we're going to always scan your network first before we launch our attack because we want to get in there newer ransomware is actually newer ransomware families do things like disable security products unload drivers reboot your machine into safe mode i've seen ones that

they actually bring their own virtual machines and then they move your files to the virtual machine and do the encryption there and then move them back so they're definitely adapting it's a little bit of a cat mouse game but um you know they're already using like what's considered like military-grade encryption which is just using encryption properly and using like open ssl for rsa or something instead of doing it themselves so they're definitely adapting uh it's kind of a scary world out there but you know people the good side is adapting as well you know antivirus and edr's and all sorts of things are starting you're starting to see a lot more ransomware um protection specifically that's what i do

and i don't want it to turn into like a sales pitch type of thing but uh i work on a product that's like automatic ransomware prevention um you know detects the behavior stops it that kind of that sort of thing so definitely definitely a lot of advancement on the attacker's side though anybody else i'm not seeing anything so i'm just gonna hop off the stage here but um thanks everybody for listening and that's all i got

you