 Welcome back everyone. Today, I'm reading robust bootstrapping memory analysis against anti-forensics by a couple of Korean researchers in South Korea, so I thought it was interesting because I know some of them. This was at the DFRWS USA 2016 research conference. If you haven't been to the Digital Forensics Research Workshop before either in the US or Europe, I highly recommend it. It's a very very good conference. This was published in Digital Investigation Journal in volume 18, 2016. So I'll have a link below if you'd like to like to read it. So this paper obviously talking about memory analysis and specifically anti-forensics in memory analysis. And the premise of the whole paper is that if we're analyzing a system, if we're either collecting memory or if we are doing memory analysis in a live system, we have to be aware or we have to be aware of anti-forensics going on because there are potentially tools running in an untrusted suspect system. If we're analyzing a system, there could be programs running inside that system. And if we're trying to do some sort of memory acquisition or analysis, those programs can detect that we're running different software or different tools and change the output. So that's kind of the premise of this, is that in live systems we can't trust the programs that are currently running and there might be some anti-forensics applications. So they go through and basically one of the things they say is we show anti-forensic techniques and the limitations of modern analysis algorithms. So they do in this paper prove that anti-forensics techniques are possible. They've developed their own anti-forensics tool to be able to do it. And they show when current tools, current memory analysis tools, fail against their anti-forensics drivers that they built. They also propose a novel memory analysis algorithm based on KI Initial PCR, which assures the bootstrapping analysis. So their claim is that the issue with memory analysis is in the bootstrap phase or basically the phase where you're first off collecting data but starting to work with data. And that could be the point at which you're trying to fingerprint the operating system, for example. So you need to know about the operating system if you want to get information about the memory structures that are in your memory image or in the system that you're analyzing. Okay, so they talk about anti-forensics. Yeah, they basically anti-forensics different types of attacks. So the three attacks that I saw here were one byte abort factor attack and apparently I actually didn't know this attack before but apparently it stops memory analysis. Either it causes it to crash or it just stops the analysis. I'm going to have to look into this paper from 2012 a little bit more to see what one byte abort factor attacks are. But basically they say here it shows that important signatures are easily overwritten by malware in such a way that memory analysis can fail to find it. Now this doesn't really explain a lot. It's just you know signatures or traces of something are overwritten in memory by malware. Okay, we know that that's possible, but I think one byte abort factor attack is a little bit more. It's not just the fact that memory analysis tools can't find something. It's the fact that it actually causes the analysis to abort or it is in such a way that the analysis itself can't go forward. So I think there's a little bit more to it than that. It wasn't really well explained here, but they did have a reference to a paper that I'll look up later. Okay, another type of attack they were talking about is semantic value manipulation and basically this is just again value manipulation by a piece of malware changing essentially codes or values within the memory image. So semantic value manipulation is the malware intentionally changing some data to try to either make the tools miss something, well yeah basically make them miss something or think that something is innocuous or not be able to analyze the real malware. And then they also talk about attention deficit disorder attacks. They call it yeah, so here attention deficit disorder attacks or ADD technique creates fake objects to lead investigators down a wrong path or increase analysis time. We've seen this before, right? So this is essentially just creating a lot of things that look like they could potentially be real, but they're not real. So if an analyst is going through, they might see all of these different things that look real and waste their time analyzing those to find out that they're actually not real later. So then you actually have to go through and find the real values that are interesting. And this isn't just for memory, malware and memory, it's for lots of different, basically every type of investigation is somewhat vulnerable to something like this. So this was interesting that they talked about this. So those are the three different types of attacks that they really focused on. Yeah, so one bite abort factor attacks, semantic value manipulation and attention deficit disorder attacks are creating fake objects. And then they also, once they talked about the attacks went through and talked about the basically three different memory analysis frameworks that they use. And those are volatility, memorize and recall. So they were using those three tools or three frameworks as their kind of baseline analysis toolkit, which I think most people are at least most people that I know are using probably those three. Okay, let's see. Next, they were talking about different analysis methods. So within the tools themselves, excuse me, within the tools themselves, they were talking about how the tools are doing memory analysis at a very, at a very high level. They do give references to all these things, but they were focusing specifically on OS fingerprinting and extracting process lists. But how the tools how each of the tools do different types of analysis, what data is required for that type of analysis and what memory basically malware what malware could do to hide itself from these analysis tools. Right, so getting kernel structures. Yeah. Okay. Next, they were looking at right, memory structures. Okay, different types of analysis assessments of anti forensics. Yeah. So next they developed a proof of concept driver that implements the anti forensic techniques. So basically they identified all of the different types of analysis that the tools currently do the different types of analysis that the those at least those three frameworks do. And they developed a proof of concept driver that implements anti forensic techniques against the type of analysis that they've identified in this. Well, I mean, that's, it's actually realistic, right? Because, you know, people who are trying to get away with crime or people who are writing malware, some of them at least also keep up with, with digital forensic tools. So they probably have access to all at least those three very common ones. So whenever they would write anti forensic tools for it, they would probably do the same thing. They would look at the way that these tools are doing analysis. And then they would write a driver that they would write some sort of feature into their malware that tries to subvert at least the common types of analysis tools that we we tend to use in digital forensics. Okay, so I think this process is completely justified. Look at what the tools are doing, see if you can find a way to get around it basically. So then they go through and this actually this was one of the most important or one of the most interesting things for me. Once they implemented their driver, then they used the framework's volatility memorize and recall to do analysis. And then they get this table, this table at the, at the end, and I'll show you here. Okay, so you can see memory memory modification target. Basically, this table lists the different frameworks that they were using or the different analysis techniques, I should say, but basically frameworks they were using. And the X's are where the tool failed because of their their driver, basically. So where the tool where the driver, let's say beats the tool, essentially, because of some type of anti forensic techniques. Now, the most interesting thing here is, first off, none of the tools completely failed, right? Actually, most of the tools did pretty well. We see here that really the most they failed at were kind of two points here. So idle process, volatility, for example, the idle process, and KDBG, KDBG, they failed where system process RSDS, P signatures and comparison points didn't fail, right? And memorize did actually really well against everything except system process. So the, I think the interesting thing to me, this this table was was one of the, I guess, coolest things, because we can see that actually our tools are working pretty well, they are vulnerable, of course, to some to some anti forensic techniques. But even whenever people wrote a custom driver, specifically to do anti forensics or kind of attack the frameworks that we currently use and I can currently have available, it still did pretty well, not not too bad. Now, this to me is is actually excellent, because whenever I'm teaching, I constantly say, you can't just use one tool, right? One tool is going to have some problems. So think about it in this way, like if we used volatility and looked for idle processes, idle process, for example, and then memorize, and we looked for idle process, well, we would get two different values, volatility would probably show us nothing here memorize would show us something. And we would be like, okay, something is wrong here, right? And then that would make us investigate more the same with system processes, volatility would show us correct system processes memorize would show us incorrect data, right? So then we would find out that something is wrong and then we would get maybe recall here. So recall 4.1 RSDS or recall 4.1 NT index. And then we would basically run to or if we ran two tools, then we find out that something is not right. Something is going on. And we might be able to actually determine just with currently available tools that anti forensics was taking place. And that by itself is actually really interesting for this paper, the fact that they wrote a driver targeted these tools. And if you're using multiple tools, you will see something suspicious. If you're not using multiple tools, you won't see something suspicious. I mean, that brings home basically what we've been saying for a very long time. Okay. Now, again, you might have a problem. So imagine that you're using volatility and recall. Well, you would still see a problem or a difference in KDBG. Okay. And you might, you might investigate further and say, well, why is that? So actually, the, the, this table to me is great. Because it clearly shows that if you're using more than one tool, or you're actually verifying your findings with a different tool, then you, you are very likely here to find that anti forensics at least has been used. And you can probably still recover information that, that would have been lost if you were only using one tool. So I thought that table was excellent, not necessarily for the reason that they wanted it to be excellent. They wanted to show that there are problems with current techniques and then propose their own technique. But I thought this table was, was fantastic for the fact that our tools that we already have are working pretty well now. That being said, they are still vulnerable. So let's see what they're actually proposing to, to improve this situation. Well, what they are proposing is basically this KI initial PCR is a data structure. Yeah, it's just a data structure in memory. Specifically, I, yeah, I think it's, yeah, it's Windows. It's a Windows data structure. Let me see. Yeah. Okay, it's a, it's a Windows data structure. It has a couple different, well, a lot of different information in it. I've seen it used for other types of analysis. I've seen it used, I've seen malware actually use it to find like, locations of buffers and things like that. So basically, they're proposing KI initial PCR data structure as a method or as a data structure that is robust, which means that there are, it contains multiple pieces of information that we can use to compare against each other to see if there's been any type of tampering. And if you actually tamper the tamper with this data structure, if you modify it, then it tends to cause the system to crash. Okay. So the idea of them proposing this data structure is that the, basically if the attacker is attempting to modify this thing, it's very difficult to change without causing the system to crash or somehow fail. Okay. So they talk about carving KI initial PCR, carving the data structure and then going through the different fields. Yeah, going through the different fields and then using it to do operating system fingerprinting. And then they basically go through and they look at all of the different structures that are in there and their patterns that they have. And then they calculate the distances or the differences between different Windows operating systems and the locations or the, yeah, locations of two different data structures in 32-bit and 64-bit Windows for 7, 8, 8.1, and 10. Let's see. Right. And then they describe their system for actually kind of locating, well, here I have locating KI initial PCR, setup machine bits. Is it a valid KI initial PCR? If it is, then do operating system identification with the self and idle thread fields, acquire data and morph in another field and then basically go through and get the process list. Yeah, get the process list or at least the location with that. Okay. Yeah. So here basically they go through and they just incorporate KI initial PCR into the analysis or investigation process. And because it's difficult to change and because there there's multiple sources of data for this, they claim that it's more difficult to modify, more difficult to tamper with, should I say, and we can validate it against other data structures a little bit more than currently available, currently available data structures that are analyzed in current tools. Okay. They have this offset DB management. So basically they have signatures for the types of Windows. Yeah. So they have signatures for the types of Windows and they keep a database that way they can do some type of profiling analysis against it, kind of similar to I guess the way that volatility works. Okay. And then in their discussion, so basically they show that they can with this signature database and analyzing this data structure, they can do some operating system fingerprinting and process list extraction, which isn't, as far as I understand, it's not everything that they tested. But maybe it is. Okay. Right. And then they talk about some issues. And what do I have here? Yeah. So description of KI initial PCR and how it can be used for bootstrapping the memory analysis process, specifically operating system fingerprinting and process list extraction. So the idea is that they are trying to get rid of this around this bootstrapping issue whenever you're starting your analysis of data structures in memory, whenever there's a malicious program also running, how can you get around that? And the way that they propose is find a data structure that you can't really change without hurting the system. And that has a lot of extra data that way you can validate whether it's correct or not. They go through and describe the weaknesses of the system as requiring known GUIDs and OS versions. So basically, you have to have this knowledge beforehand. You can't just pull out operating system information without having some prior knowledge, which yeah, okay. Yeah. So I think there's some, there's some other methods that you also have to have some prior methods prior knowledge for. But some methods you can potentially just pull out the operating system information directly or at least yeah, basically pull it out directly malware can move k initial PCR. And this I think was the biggest issue that I was thinking of before we actually got to the issues is I know that k initial PCR is not at a fixed location. And if it's not at a fixed location, then you if you're analyzing memory in a live system, then you could potentially or the piece of malware could potentially wait until you've read some part of memory and then move k initial PCR to a different location that you've already read. If that's the case, then you'll never find it, right, because you're just basically searching from beginning of memory to the end of memory. And yeah, if it moves, that's that's pretty much it. And then they say that they're also vulnerable to make multiple K initial PCR. And then if multiples of those data structures exist, and, and they look valid, basically, then an investigator has to go through and manually choose which one is valid. So overall, they have, I don't think that they've completely guaranteed boot bootstrapping analysis. But, you know, they did find a data structure that is a little bit more difficult to modify. I'm not sure why people aren't already using that data structure, right? Maybe people didn't know about it, but most likely it's it's missing some information. And I don't know enough about this data structure to be able to to make any claims or recommendations about this. It seems to me that this work, I mean, they are they are contributing, you know, a data structure that is more difficult, and we can use it, you know, to help with anti forensics, but it seems to have some of the same problems as the prior methods that they were talking about. Yeah, overall, an interesting paper. I don't know currently a lot about memory analysis. I know basically how it works. And I know about parsing kernel structures and things like that. But I didn't know some of the stuff that was in here. And it was interesting to hear about this, this data structure, and I'll look into it more. Like I said, one of the most interesting things for me personally, was this table one talking about the different frameworks and where they where they worked and where they failed. This is if you have students or if you have colleagues, this is the table you want to show them to prove to them that you can't rely just on one digital forensics tool, you have to use multiple tools here. And then, of course, I'm not sure what tool they actually created, or if they've released their own their own tool for this to do this memory analysis. But this would be, I think, potentially an interesting volatility plugin or something like that. So I'm going to look into where this tool is and maybe a little bit more about how it works. Yeah, so overall, I think, yeah, the paper was interesting. I would have liked to actually see the talk at DFRWS. So this was a little bit about memory analysis, and specifically the bootstrapping process, trying to find data structures that are a little bit more robust and can, let's say, protect us a little bit more against anti forensics. So anti forensics in a live system, of course, is possible and we need to be aware of it. So overall, I think a very interesting read. Thank you very much. If you like this video, please subscribe for more.