 And give a great round of applause to Sebastian Eschweiler. So, hi everyone. So, I want to talk about how I defeated not Petya's cryptography. Some might say that not Petya would be Ukraine's scourge. And for those of you who don't know what the word scourge means, this guy right here doesn't know either, and quick trivia quiz. Does anyone know what this movie is? What's the name of the movie? So, in the next scene, Johnny Depp enters. Does it ring a bell? A movie by Jim Jarmusch. A soundtrack by Neil Young. Dead Man. Right. Great. So, a great movie. So, if you want to know what a scourge is, then you could watch the movie. So, let's begin with my talk. So, this is what actually the official Ukraine Twitter account tweeted some time ago at the end of June 2017. And there was an outbreak of a ransomware attack which was noticed mostly in Ukraine, but also all over the world. So, millions of users and also companies, large companies were affected. And the damage went into the billions of dollars. So, the problem there is, I mean, this is not the everyday ransomware outbreak you will have there. And I want to give you a short glimpse into the not-patia universe and also how I could decrypt all these stuff that actually was encrypted by this ransomware outbreak. So, first I want to begin my talk with a differentiation. I want to draw a demarcation line because all this not-patia universe, there is much subsummarized under this whole label. And I really am just talking about a small fraction of this whole universe. So, I will first distinguish between what my talk will be and what my talk will not be about. Next I will describe not-patia's cryptography and especially not-patia's cryptographic failures, which I then will be exploiting in the remainder of the talk and see how can the users get their vacation photos back. So, what was this whole thing? The outbreak started, as I said, in June 2017 and it started as a fake update or a malicious update from a software called Medoc. This is a text software, one of the two official text softwares in the Ukraine. So, almost every company has it installed on text accounts, on their computers. Many private persons have it installed. It was pushed and then side loaded. This file proceed that was then downloaded to the computers and it comprises several parts. And some parts are more interesting than others. So, one component after like half an hour time, it would start encrypting the files depending on the access level. So, if there wasn't any access to infect the computer with this MBR in factor, then it would just based on the current user level encrypt the files based on that current user. In lack of a better name, I would call this Misha component. I know it's usually somewhat different, something different. However, this was the best name I could find there. So, it's basically just a file encryptor with AES. My talk will not go about this part, this file factor. The next very interesting component was the spreader part. It's basically based on the eternal blue, eternal romans exploit that had been leaked by the shadow brokers. My talk will not go about this as well. This is a whole different universe as well. What my talk will be about is the actual not-patia component. And this is an MBR encryptor and I will show you in the next slide what it's actually about. So, the user will see something like this upon reboot. So, if the access rights are granted, so if there is some local admin installed on the computer or the correct password could be guessed by some attack, then this dropper, the perf seed that would infect the system by overwriting the master boot record with a custom boot loader. And it would reboot the system after a predefined time, usually being about 10 minutes. And then the actual not-patia component would kick into action. This infected MBR, this bootloader, shows this decoy check-disk screen and in the background would find and iterate the files on the file system and encrypt all these files. So, the main takeaways of this slide are that we are dealing with 16-bit code here. So, we're in 16-bit real mode. So, this means no proper file system. It means no 32-bit or 64-bit code. There are no Windows APIs. So, debugging all this and analyzing this is a tedious work. However, we have something on the plus side, which is a BIOS, you know, the basic input-output system. And with that comes a range of interrupts that are very well-described. And a really nice thing is having box and being able to debug all this in IDA. So, this was a really neat plugin that had been developed by the authors. So, let's analyze a bit and check the cryptography and why implementing crypto is really hard. So, I will start this part with describing in short words the theory of Salsa 20. And then check that, compare that against the not-patia implementation of this cipher. So, Salsa 20 is a stream cipher. So, basically, you will have a plaintext. It's about here. And then you will have some kind of random number generator or pseudo-random number generator. And then apply some operations on the plaintext and outcomes the ciphertext. And what you put in there are four different variables or four different inputs because there is the constant part which is obviously not variable. But we will see about that in a bit. So, you will have these key and the nonce. And then there is this really nifty thing called counter. What's so nifty about that is if you were to stream a Salsa 20 encrypted stream and you would lose some frames, then you could adjust this counter variable which would demarc the offset of the current stream in the current stream and then could continue needlessly with the decryption of the stream. So, this is a very nice feature. The size of the counter is 64 bits and the hash size here. So, what Salsa does is create a 64 byte hash for every different of these inputs and with that then apply to the input. If you want any more details about this Salsa cipher, the inventor of Salsa should be in this room and should be at the convention or he is at the convention. I just wrote the train with him. So, I guess you can ask him the gory details of Salsa 20. So, it's a really nice crypto cipher and you should hit him up and ask him. I shouldn't have said that, right? Sorry. So, basically what a very important thing is to note is for every invocation of this or for every instance of a not-patia encryption, you would have these three variables or these three inputs being constant. So, not-patia would patch during the infection process. The key, the nonce and the constants into a configuration sector. The constants not these are somewhat different. And then the counter would only change throughout every iteration. So, the interesting thing or the interesting question was first, what is the length of the key stream? So, the key stream you know the number of different outputs that would come out of this hashing function. And I mean for this implementation or this for the theory, this is quite clear. It's 64 bits here, 8 bytes times the 64 bytes of output. So, it would be about 2 to the 70 of a periodicity. One different about the actual implementation in not-patia and the theory would be that this constants thing here had been changed to a string reading out invalid sect ID. So, this would break the official implementation. So, the very first failure I saw at not-patia was something like this. So, I think I can skip to this slide because it's obvious for everyone that this is a failure, right? So, who sees the failure? So, not many hands. Okay, then I'll explain it. So, I was just kidding. So, I was not expecting for you to grasp that first. So, remember, we're in 66. We have here this shift left operation, which would shift a register by and bytes. The register width here is 16 bits. So, it only has 16 digits, so to speak. And you would shift it by 16, by 10 hex, 16. And this would effectively null the register. And even worse, it would actually null the register. And even worse is here. So, you would shift an 8-bit register for 16. So, this is something you wouldn't expect from a proper cryptographic implementation. And I was really intrigued why that is, because it wouldn't make any sense in source code. And did the not-patial or the patial authors really implement that on purpose or what was the gist with it? And I looked up the not-patial, the Salter20 implementation. I just Googled it and found a nice website that had a implementation of Salter20. And there you would see this code. So, you see here it's in the endianness conversion. And you see here these shifting of bits of registers. And you see here this UintFast16 or 32 type. So, it becomes quite clear that this is a broken implementation, right? So, everyone can see that, right? No, not right now, because you need to know some things more about this. There are two important facts that make this implementation broken. And the two facts are you need to compile this code for 16 bits and you need to look up what Visual Studio makes of these type definitions here. And when you look that up, this is from Visual Studio and it's in the standard int.h error file. And there you see it's interpreted or translated as unsigned int. So, this is the base type. And this base type unsigned int in 16-bit code is a 16-bit variable or a 16-bit register. And then everything makes sense. And this was somewhat of a failure here. The authors didn't really check if their code was actually working against the test vectors. And this guy who wrote the code here, this Salsa 20 implementation, made this mistake also. On this slide you see two bugs of the not-patia implementation of Salsa 20. And I quickly want to explain both to you because they are of somewhat importance throughout the remainder of the talk. So, both revolve around the counter variable. Just remember, this counter variable is the only dynamic input, the only variable input throughout all these Salsa 20 invocations. And the first error is so you read a sector, a sector number into the memory. So, a bit about the low-level aspects of a hard drive. A hard drive from the view of the bios would look somewhat like a bunch of different sectors. So, these are 512 byte chunks of data. And they come one after another. So, if you were to read a sector, you would actually read a 512 byte long portion of data. And this is obviously not the offset in the stream. And this is somewhat of a problem there. So, you see here the same variable is used to decrypt or encrypt the data. And, I mean, it isn't really apparent to the implementer of this Cypher. However, if you were to analyze it, it would look something like this. So, you would have the key stream of two different sectors, two different consecutive sectors here. So, it would start with FF and then continuous with D7 and so on. And the next sector would have almost all of the bytes identical. And this is, yeah, a really big failure because this really nice Salsa 20 implementation, this really nice Salsa algorithm would then be converted from a one-time pad to a many-times pad. And this is the first file I wanted to show you in these very few lines of code. The second part is, the second bug is here, this large keyword. Remember, we are in 16-bit code, so this large keyword here does not push a 64-bit variable as we would suspect to do it, but a 32-bit variable. So, only 32 bits of this nice counter variable are actually used in this case. So, these two failures are somewhat of a problem for this Salsa 20 implementation. So, in this slide, I took two different hex dumps and these hex dumps were within this expand key function. And they are basically two snapshots, one right before these bugs become apparent, so before this andiness conversion and right after on the lower half. So, you very nicely see the different variables being put into all, the different key inputs being put into this memory block. So, here it would spell out invalid sect ID, you know, the constants, not Patti, I use this. Here you would see the key and here, so it's broken into two halves. Additionally, you would see the nonce here. And what really sticks out is this bunch of the zeros here. So, this higher part of this 64-bit variable isn't even used. It's not even filled there. So, this is, well, the first problem here and after the andiness conversion, you see that it's not really an andiness conversion, but it's more of a nulling of bytes. So, the result would be that this initially 64-bit variable would be just 16-bit in length. And as I said earlier, the original source implementation would be 2 to the 70 as key length. And right now we have 16 bits times 64 bytes in key length, which would result in 26 bits in key length, which would be a measly 4 megabytes in key length. So, this was a very interesting observation I made there, and this would be possible then to decrypt together with the many times pad properties of this cipher, which make it really easy to break. So, to quickly summarize this part of the talk, we have a very, very short key stream of just 4 megabytes. It's highly repetitive. So, for each secondary progress, you would only have a progress of one byte at a time. So, only 26 bits remain of the whole stream. And as I said, the many times pad properties are a very nice thing to analyze. I couldn't come around to implement a small joke here, so this also implementation I would only call Lalsa from now on. Sorry, it's a bad joke, sorry. So, the main goal is to derive the key stream, and as I'm not really a crypto expert, basically the only attack I know would be a known plaintext attack, so this was my goal there, because it's so straightforward to do that. And in the remainder of the talk, I will tell you how I did that. So, without further ado, let's exploit these failures and see how much of the plaintext we can actually get from a not-patia infected drive. So, the modus operandi of not-patia would look somewhat like that. So, let's stop with the left-hand side of the slide and concentrate on the right-hand side. For those of you who are not really intimately familiar with NTFS, I wasn't before analyzing patia or not-patia as well, so no worries. It's quite simple. So, every NTFS partition has something called a master file table, MFT abbreviated. And it would contain some metadata about the file, for example the file name, the file size, and if the file is small enough, it would even fit the actual content of the file into this record. So, as I said, MFT is just a list of records, and if the file is larger, it would have a pointer, a so-called data run, which would point to a cluster or a sector on the disk, on the partition, which would then actually be the payload data. One of these MFT records is one kilobyte in size. So, now to the actual implementation. So, let's zoom out a bit and see how this LASA implementation is used in not-patia. So, it would basically just iterate over all of these MFT records, and then check if this record would point to a file. If that is the case, it would encrypt the first kilobyte of the file, and then would encrypt the record itself. This implementation is good for a bunch of reasons. It's very fast. You would only need to encrypt the first kilobyte, and this first kilobyte contains really, really important information. For example, headers or especially compressed files have these really important header structures there. Additionally, file recovery tools wouldn't be able to work anymore because most of them rely on this very header. The second thing is this MFT can be considered as table of contents. So, with no metadata, with no pointers to the files, you won't have anything there to work with to recover from. This is, I mean, from the implementation standpoint, it's very neat because it's fast and it's somewhat thorough. As the MFT is really important, my idea was to recover that first and then check what comes out from there and see how I can further progress there with the decryption of the files. So, the metadata would be of most importance there. I'm a visual person, and here I took two disk dumps from one of my test disks. So, I infected a clean system with not-patia and let it encrypt the hard drive. And on the left-hand side, you see the plain text. And on the right-hand side, you see the encrypted data to just get a better picture about the encryption process. On the far left-hand side, fancy PowerPoint, what's it, animation, you see some kind of indicator which would tell you at which offset how much of the data is actually being different. And you see how disk is more or less being encrypted. However, you see at the far bottom part here, it's more dark red. And this is actually the MFT, so the MFT is towards the end of the disk sometimes. But this might be a misconception. So, my idea was something like this. We have two input sizes, right? We have the encrypted MFT and we have encrypted files. And first, I would analyze the MFT and then derive the key stream from that. After that analysis stage had been finished, I would put the key stream back into this little box here and actually decrypt that. And then out comes the decrypted MFT. And with that and the key stream, I would be able to find the encrypted files on the disk and then be able to decrypt them and then be ready with it, right? So, this was my initial idea there. And so, let's start with the decryption of the MFT. No plain text attack, right? So, an MFT looks from the viewpoint of the key stream, somewhat like this. So, you would have here the first, the second and so on MFT records. And on the column, you would have the actual byte that is used as key to encrypt the key stream. Remember the operation that encrypts the key stream and the plain text. It's just a mere X or operation. So, you would have the key stream and the plain text. And it's plainly, so you can switch forth and back between plain text and cipher text and even the key stream with just applying an X or operation. So, what you see here is for the very first records, you only have very few key stream bytes or very few sample bytes. However, as you make progress with the analysis, then you will have more and more of these sample bytes to collect from. And this will give you more confidence in the result, in the maybe known key stream then. The question is, does the MFT hold enough plain text to do some kind of known plain text attack? So, let's look into the specification. The MFT record has basically two fields. There is this standard information, which is a well-defined structure and there's something else called attribute list, which is a quite dynamic structure. And this would be somewhat more difficult to glean plain text from. So, I concentrate on this first part and the first part quickly turned out to be quite constant for many or most of the MFT records. And you see it starts with file and then has some hex digits after that. And on the far bottom part of the slide, I added my certainty level. So, the certainty level would be the number of different sample bytes I would have multiplied by the confidence I would have in that sample byte being actually this plain text. So, you see for the very first record, it would have a quite low certainty. I mean, it's just one byte, right? Oh, the two byte skipping is quite straightforward considering you would have usually 512 bytes per sector on a disk and the MFT record is one kilobyte in size. So, the stream would progress two bytes. And for record 100, so for the 100th record, I would have a certainty of four because, you know, I would just assume these eight plain text bytes here divided by two would then result in two four. This wasn't really satisfactory. The problem there was towards the end, I would have many, many unknown records and it was concentrating on the very first parts of the header. So, the remainder of the key stream, the very end of the key stream wasn't being able to be analyzed and eventually decrypted. So, I thought of something different and that was something like I would call a byte histogram. So, for every offset of the MFT record, I would then calculate, create a histogram and check how many different bytes are there actually for plain text. You know, it's a plain text, non-plain text attack. So, I would need some kind of plain text there. I would do that for every offset, for every record. And so, the questions there are how to get many MFT records. It's quite easy. If you have some nice colleagues, you just need to hang them over the balcony and shake them a bit then more or less voluntarily they will give you some MFTs to work with. And the result of that is quite nice to you. I mean, for the very first, there's nothing much you can do. The very first record will always have very few sample bytes. But as the stream progresses, you will have a dramatic change there. So, from this relatively low certainty of four, I could increase that to more than 30. So, this is somewhat nice and after a bit of doing science, this table drops out from nowhere. So, I compared these two attack types. So, let's read that from right to left. On the far right, I have for the first approach about 98% of the MFT records being successfully recovered. You know, the good thing with science and with all this academic approach is you have a ground truth. So, I have a plain text, an unencrypted hard drive, virtually unaltered from something right after infection. And then you let execute the whole infection and encryption process. And then you can differentiate and take several snapshots throughout the infection, change different key values and all this stuff. So, this is a very nice thing about this academic approach I was taking there. So, I could exactly pinpoint how many of these records were perfectly recovered. So, for the byte histogram approach, I could decrypt almost all of the records, which is quite nice because then we have a high quality MFT to work with. What's also quite nice is that we have zero wrong key stream bytes. What's not so nice, however, is that I was only able to recover about 1.3% of the overall key stream. And remember, this key stream is about four megabytes in length and I was able to recover only 50 kilobytes of that. So, we cannot recover all of the files. Or is that so? This was my next question there. So, I draw another nice diagram. This is the MFT, sorry, in the key stream. So, the key stream is only filled in sample bytes at this two megabytes mark. And the question is, are there many files in this area being encrypted? Or is there some other bug I could exploit and I checked where the files would lie into the key stream. So, I would check how many files are at which location in the key stream being encrypted. And you see, the key stream is used all over the place. So, I mean, sometimes it's used more, sometimes it's used less. However, it's basically used all over the place. And so, this much of the key stream could in a perfect scenario be, I mean, perfect scenario being a perfect known plaintext oracle could theoretically be recovered. However, this is somewhat of a problem here. And in the next part of the talk, I will present you how I was able to solve this problem as well. So, remember, when the file system is actually encrypted by not-patia, the file system looks somewhat like this. So, you would have the MFT, which is totally garbled. So, you won't have any nice file pointers pointing or data runs pointing through those files. You won't have any nice file names and all the stuff. But with the first stage being finished, the MFT looks really nice. I mean, like almost 100% of the records could be recovered. So, it looks somewhat like this. So, you have a bunch of metadata you can now use to analyze the remainder of the files and the remainder of the encryption. So, all this MFT or almost all this actually decrypted. And for files, you would have the very first kilobyte being encrypted. The remainder of the file, I mean, most files are more than a kilobyte in size, right? All the rest is not encrypted. So, you would have all this data and metadata to collect information and to use to exploit as known plaintext as indicators for known plaintext. So, I thought of three different approaches to attack this problem. Basically, I was thinking about, okay, what different files are there? And I was quickly thinking about different file types. And I mean, the file type can be easily gleaned from this, right? Because you would have the file extension and that would be basically the file type. And you would have two different types of files. You would have structured files and unstructured files. So, I thought of these and you would have something like source code which I would consider as more or less unstructured. And I was calculating the histogram. So, this would give me some kind of prevalence towards different bytes in the key stream. So, it would be somewhat like a guest plaintext attack or something like that. The next thing for structured files would be to do the very same approach as with the MFT records. I would calculate the histogram for every offset of the first kilobyte. And then quickly see how many different bytes are there per offset. And the last approach uses somewhat more data. It uses some of the metadata and also some of the file data. I will go into this right now. So, what I basically have here, as I said, it's only this little portion of the file is encrypted. The whole remainder of the file is not encrypted, which is quite nice. And also the file name, the file size is not encrypted. So, what I would do here is create a database of known files, of known Windows system files, for example. You all might remember these nice background images, fonts, all this stuff. Plaintext is flying around everywhere if you just look for it. And I would have basically three different distinctors between those to know which is the correct plaintext. So, there is this key file name, the file size, and then the hash of this whole remainder, this whole tail. So, if all these three tuple would match, then I would consider this as a proper plaintext. However, there are some collisions, so this is not really something that is straightforward. So, the initial idea of only needing to analyze the MFT and then being able to straightforward decrypt files needed to be altered a bit. So, I added this database of known files there. I added another analysis stage in this nice box here. And then I would be able to decrypt the files eventually. So, let's do a bit of science and check if this approach would be worthwhile pursuing on a real-world scenario. So, let the science cat do its science. Let me have a drink. So, what I basically did do here is to create a database of known files. I collected a bunch of default Windows installations, which resulted in about 340,000 unique files in it. Then I calculated, you know, the different file type histograms I talked about. I prepared my test setup. I added their 1,000 different files. And you should note that these files were not part of this known files database. They were different from that because otherwise it would have been easy to do. Then I would infect this machine and then let it encrypt by not petia and then attempt the recovery. And these are the results there. So, I did this with four different runs. So, I tried every approach separately and then combined the three approaches. And the outcome was something like this. So, I would have only two files by the general histogram approach being able to decrypt. At least 8% were decrypted by the location histogram approach. And by the known files approach, over 90% of the files could be successfully recovered. And even better, the combined outcome would be almost all files being able to decrypt. So, so much about academia. So, the problem there is if you apply this to the real world, you could get into more trouble there. There was lots and lots of more to think about. So, there were, for example, non-default windows installations with the whole history of updates. So, this might be really interesting from a forensics perspective. Moreover, there's lots of installed programs to derive known plaintext from. For example, .NET yields a vast source of known plaintext or JDK installations. So, especially the JDK would result in about tens of thousands of different source code and HTML files. So, this was really quite nice. The drawback there was, so there was so much data to collect. The first attempts failed miserably because of the sheer amount of RAM I was using. And this would result in the admins constantly giving me more RAM in my VM. So, I would eventually end up with, I think, 120 gigabytes of RAM in my test VM. Also, you have a much larger master file table because of all these files that would need to be stored. So, to put that in comparison, so this nice working prototype, so this nice test setup, I mean, would have an MFT of about 26 megabytes. And for real world scenarios, you would have something like at least 500 megabytes. And even an MFT could be even like a couple of gigabytes in size. So, this means much more plaintext. So, for these really large MFTs, you could quickly recover the whole key stream, the whole four megabytes, just by looking at the MFT. And in summary, this means that the decryption of not petty encrypted drives is possible. So, for the file systems, the drives I have looked at, it was really, I mean, after having all these first bugs out of the way, I was able to decrypt and recover all the files there. So, there's a good chance the vacation photos can be recovered as well. And this will conclude my talk. So, quick summary. Not petty has some severe cryptographic failures and flaws. So, I would only be able to call this lol sign, not sol sign anymore. It might be possible to further look into this, you know, this expand key thing. It has a really, really a bunch of more cryptographic failures in it. I didn't look into that deeper, but I know some of you guys are professors, and this might be a nice homework for your students to look at this not petty implementation and check out some, you know, more advanced crypt analysis methods. And you should note that this whole not petty thing here I described, the whole cryptographic flaws there are not just in not petty. They are, you see the brackets there, they are in each and every version of petty. So, all of the drives that you potentially have saved can be decrypted. And so, my last point is if any of you or any of us falls victim to a ransomware, you really should keep the drives. You keep them untouched in a locker and wait for a talk like this basically and then hope that someone comes around and then be able to decrypt the drives and then you will have your vacation photos back. So, that's all folks. Thank you for your attention. Thank you very much, Sebastian. Now it's time for questions. Please queue up by the microphones. Microphone one please. Hi. Well, thank you very much for sharing your findings with us. I'm from Rotterdam, the largest harbor in Europe and as you might know, we were struck by Petia. Two terminals went down for a couple of days, a couple of hundred million euros of damage. Your approach is quite theoretically, so now the practice. If you were there in this summer with these findings, would you have been able to help us and decrypt the files and get all the companies up and running again or is this too academic? No, it's a practical approach. I work for CrowdStrike and we had some occasions where we were able to help the customers. So, it's a very practical thing to do so and I was trying to insinuate this with, you know, this slide here. So, I was talking about the real world in this scenario. So, I looked at about 50 different encrypted hard drives with a not Petia and I was able to decrypt all of them or most of them. Mostly, the ones not being able to decrypt were to some, well, let's say level eight mistakes. Awesome. Have you shared your findings with nomorensum.org too? No, I don't know about this site. They provide decryption tools for ransomware. Please do. Thank you. Thank you. Microphone 6, please. Thank you. In the beginning, you mentioned that basically the key was shortened to, what was it, 24 bits? 26, yes. Yeah, from that point, wasn't the brute force attack way faster and way more reliable? No, no, no. Don't get me wrong there. So, the key stream length was two to the 26. So, the key stream length was four megabytes. So, you wouldn't be able to brute force that. So, do you get that? So, the number of bytes was four megabytes. And you couldn't be able to brute force that. Yeah, but you already mentioned at the beginning that you basically shortened it down to the possibility of at most two to the power of 26. Yes, yes, yes. I get the question. But you're missing the point there. So, it's not the key space, two to the 26, but the key length is two to the 26, which would be something I'm not good at converting this to decimal would be something like, let me check, two to the, I mean here math guys, computer guys, two to the 26. How many bits is that? Say again? A lot. So, it's four megabytes of key length. And you couldn't just brute force that because you would have each of these four megabytes you would have to brute force. Got that? So, the key is not two to the 26, but the key stream length is that long. Got that? So, the key space would be longer than the Bible. You know, and you couldn't just brute force the Bible, the text of the Bible. I mean, given enough time, yes, but you know, we all know the stories with the monkeys and the typewriters. I mean, we can talk about that offline, but you're mixing up two different numbers there. Yeah, I guess. Thank you. Questions from the internet, please. Does the MFT encryption work the same for Petra and not Petra? Yes, the underlying mechanism is the same. The cryptography differs in such a way that the constants number is different. So, this little guy here, this is different. It would be usually like expand, key, something, something. And here it's invalid sect ID. So, it's somewhat different. But the MFT encryption, I mean, the bytecode and the algorithm is the very same. Thanks. Any more questions? Then please give a great round of applause to Sebastian. Thank you.