 Hello, and welcome to Bleecy Village's Project Obsidian Reverse Engineering Malware Station walkthrough. This is Long Walks on the Beach, analyzing collective power shells, and today we're going to be going over some basic power shell scripts obtained for us by our forensics team, and going over some tactics and techniques and understanding them, as well as a few basic deofascation techniques. This workshop is geared toward beginners and absolute newbies, so if you're looking for more advanced and in-depth analysis for power shell techniques on deofascation, we're looking to release content like that in the future, so keep an eye out for that. So a little bit about myself, my name is Allison, although I go by Scrabble. I'm a fourth year cyber security major at a university over the Northeast, and my background is mainly in incident response, reverse engineering, and cyber security engineering. It's a little bit all over the place, but generally speaking, I like to stay in the blue team side of things. This is my second year with Bleecy Village, so last year I was part of the Malware Station as well, I just wasn't leading it. This year I'm leading two workshops, which is a really amazing opportunity. 10 out of 10 recommend to join this community. There's really fantastic people in there with such a depth of knowledge, and totally recommend just, you know, even talking to any of the people involved in the stations, because really there's just such an amazing variety of knowledge here. Oh, and I guess a little fun fact about myself, I really love black cats. I have one of my own, and contrary to all the stereotypes I thought, like she's super, super clingy, so that's a little funny. But all right, so going on into the meat of this. So what we're going to be going over today is assuming from an absolute beginner perspective, you've never done malware analysis before or maybe the most you've ever done is just pop something in the sandbox. So what we're going to do is we're going to start with the basics of setting up a VM, what VMs you want to look for, so recommendations, and then some settings you should be on the lookout for when you're configuring your VMs. Secondly, taking precautions. So going over some things like OPSEC when analyzing malware samples. And then we're going to touch on some basic static analysis. So what is static analysis or the different forms of malware analysis? And then some particulars about PowerShell. And then we're going to be going into our demo one, which is going to be covering Kill Chain 3, which has five PowerShell samples that are all unoffice-skated, which may sound easy, but we're taking a pretty non-technical approach in trying to understand what's going on here and some limitations that we may have. And then we're going to be going onto our second demo, which is looking at Kill Chain 1, the two PowerShell scripts that are in there, taking a look at some ways to de-office-skate them, as well as some things to look out for when you're going through your analysis. And then finally, some takeaways from this whole workshop. Hopefully, take in and keep with you as you go on your malware analysis journey. All right, so we're going to start setting things up. And if you have your hands on the samples already, totally get those. But a thing you might have noticed, especially for the Kill Chain 3 PowerShell samples is that they've all been defanged, which is a fancy way of saying they're all text documents now. So if you accidentally double-click them, you're not accidentally running a PowerShell script, you're just opening a text editor and seeing, you know, whatever visible code is there. However, that's not to say that you shouldn't work with these in a safe environment, because you definitely should. It's good practice to, even if you believe something has been defanged, always be cautious with it. Like I say, it only takes one time, and then you learn your lesson the hard way. I had a fellow student, when I was learning malware analysis for the first time in college, who thought that he was on, you know, his host, his analysis VM, you know, totally safe, deployed some ransomware for dynamic analysis, and then didn't realize he was actually on his host, and he deployed ransomware on his personal computer, which isn't great. So definitely I would say good practices, double-check if you're, you know, in your analysis VM, making sure you're taking all precautions before you start playing around with things. So recommendations, you're going to want some kind of virtualization software, virtual box is free. I personally use VMware, because I just have that available to me. But anything that really works for you. Going on to the two things that I would recommend specifically for this workshop, but also in general, some sort of Linux distro, I would recommend Remnux, because that becomes preloaded with a bunch of really useful malware analysis tools. So definitely grab that. And then optionally, I will briefly touch on doing some things in Windows, so I would recommend some form of Windows VM. Flare VM, which is additionally free, comes from Mandiant, is a Windows distro where like Remnux, it comes preloaded with a bunch of really great tools for malware analysis. And then once you have that all set up, once you have, you know, logged in, get into your virtual machines, what you're going to want to do is that in your network settings, you're going to want to switch from whatever NAT, bridged, whatever option you have currently set to host only. This is to disconnect your VM from the external network, and to sort of protect your own host as well. So that, you know, in the case if you're ever running it dynamically, if you're not executing the actual malware, you're protecting yourself, you're protecting the outside world, you're just keeping it contained within that VM in that regard. So moving on to taking some precautions. Some things about OPSEC, especially when it pertains to malware analysis and beginners when you get samples. So I know if you have any experience in working in a SOC before, I did my previous internship. Standard practice is to usually, if you do have a sample or something malicious, you throw it into a sandbox. Typically this is, at least in the case of by company, a private sandbox that is not public. In that case, that was pretty safe to do because we're not really necessarily alerting people publicly that we're analyzing this. But generally speaking, when you're using public resources, you want to check the hash first. You don't want to submit the actual sample. And so in checking the hash, you're determining one or two things. Is this known, or is this unknown? And then basing your next steps off of that. So if it's known, then typically you'll come with, you know, the sandbox analysis. Maybe if it's something that's known that's really well known, say, you know, I got a want to cry sample once. Want to cry is really well known. It's really well documented as to what it does, what steps it takes. So when writing up your final report for that analysis, you'll be like, hey, you know, this is determined to be want to cry. Obviously double check. You know, don't just trust the hash. Make sure, make the necessary comparisons to make sure that this has all the, you know, typical ICs that, you know, want to cry or whatever you have might have. And then say like, okay, this is it. This is it. We have all that nice data and open source knowledge to kind of feed off of. But otherwise, if it's something that's not known, you want to start treating it carefully. So I wouldn't recommend to submit it into any sort of public sandbox, just because you run the risk of tipping off threat actors. And generally speaking, when it comes to malware analysis, you want to avoid that as much as possible. I would also say to try not to execute it immediately, just take a lot of precautions in doing so, you know, do very thorough static analysis beforehand. I'll explain what that is in a bit, especially if it's on a system with external network communication. Likewise, you know, you're again, potentially tipping off threat actors and you don't want to run it if you don't know what it's doing or what it will do. And another thing to consider is that it could be potentially unique to your environment. So depending on, you know, if you're doing this in an enterprise environment or something and you get something that's, you know, completely, you've never seen this before, you may want to sync up with your cyber intelligence team and try and see if there, you can get any attribution on this. If this is, you know, a result of someone directly targeting you and your company. So going on to static analysis, a little bit about what it is. So there's two forms, two general big forms of analysis when it comes to malware analysis. They're static and then there's dynamic. And so when I was TAing, I usually kind of used this dumb food metaphor, which is that malware or, you know, a suspicious sample is a tasty dish that may or may not be poisoned. And your job is to determine whether it's been poisoned or whether it's not poisoned. And if it is poisoned, what kind of poison is it? So you have two ways to do this, statically, which is typically the safest way. So you're just observing the dish, kind of smelling the dish, seeing what you can see. So, you know, you see like a long green thing that looks like a green bean. You're like, okay, that looks like a green bean. Chances are that might be it. This is what I should expect when I'm looking at this or eating this dish. Likewise, dynamically, you'd be doing things like poking the dish, tasting the dish, et cetera, but you're doing so at a slight risk. So, you know, maybe if you don't take proper precautions by poking the dish, oh no, you have a rash. Or if you just go ahead and start like eating the dish, you may be going like, oh God, wait, this is poisoned. You get poisoned. So that's not to say though that dynamic runs a ton of risks with no reward, but it's always a little bit more of a risk. Going on though, through dynamic analysis, you can learn a lot more than you can through static analysis. So some assumptions you made may be incorrect or some assumptions that you made, you may not have the full picture of. There's way to obfuscate information about the program from static analysis. And so the only way you can really figure it out may be through dynamic analysis. So back to actual programs in malware. Static analysis is usually regarded at the safest form. So it's doing everything except executing the program. So it can be things from like, what kind of file is this? Is this a Word document or Excel document? Or is it a PowerShell script? Or is it a portable executable, a Windows executable? What is it doing if it's code readable? So in the case of PowerShell, can we see what it's doing immediately? Do we have to do a little bit more de-officcation maybe to see what it's doing and so on? Maybe it's calling out to something, whatnot. And then likewise for portable executables, for example, sometimes if it's un-office-gated or unpacked, we can see what kind of functions it's calling and kind of get an idea of what it may be doing. So if it's calling like a download data function, then that gives you the idea that, okay, it's making external communication, grabbing something from some kind of remote server potentially, or if it's doing get process, create process, okay, it's doing some process manipulation. This is something I should look out for. And then going on from that is making external communication. So sometimes if it's un-office-gated, you might be able to see some URLs, domains, IP addresses, or even just the function that's typical for network communications. And so specifically into PowerShell static analysis, it's either obfuscated or de-office-gated. It's kind of not as common to see it completely un-office-gated. If that's the case, I've found it's usually something that's open source publicly available, but most of the time it's going to be obfuscated. And in that case, there's usually some pretty common ways to pretty easily de-office-gated, but sometimes malware author may have a few tricks up their sleeve, maybe a little bit more challenging to do some de-office-gation. So it's a mixed bag as it always is with malware. And so malware authors will often do fun little tricks to try and fool you or try to fool whatever defender that you have on your system. So it can try to hide calls to certain functions, either by kind of making it hard to read. So when you're going through it, you may be looking out for a certain function. They may be hiding it with some shorthand technique. Usually it's something involving Bay 64 encoding, that's pretty common. Some things like string concatenation, where it shortens, you know, if it's calling out to a URL or domain or something, it'll shorten all the individual components of that string to make it harder for detection and harder for YouTube to potentially read or just grab easily. And another thing to keep in mind is context of it. So sometimes partial scripts, you can just run the script itself, but sometimes it may require flags. And so you wanna make sure that you have the full context of the script itself, otherwise you're gonna be missing some vital information. And this is definitely not gonna come up in our next demo, but it might. And so moving on, let's move on to our first demo right now. Alrighty, so welcome to demo one. So right now we're in my cute little kill chain three folder. And all of these PowerShell examples are going to be in this PowerShell malware zipped file. So to unzip it for reference, I'm just gonna do seven Z, E, and then the name of the file, Enter. And then the password is infected, at least it is at the time of this recording. And then that'll get you all of your samples out. I like to keep everything clean and organized. So I usually keep the Zipped Malware in one folder just in case something happens to the samples that have been extracted. But for now, we've got all of our PowerShell samples and we've got five of them. So what we're gonna wanna do initially first is to grab the hashes of things and try and see if we can find any similar samples out there. So just going by order, I'm just going to grab invoke Kerberos. So defy the sum, invoke Kerberos, grab that and then let's grab that. So you may also want to use shot 256. I'm just using MD5 because that's shorter. But opening up VirusTotal, going over to search. Well, not MD5 sum. Let's go actually grab the right one there. There we go. It's popping this open and this has been seen before. So that may help us in trying to understand what this is. So we see that there is, you know, pretty malicious assuming we want to make sure also grabbing this PowerSploit is something we want to look out for. But in VirusTotal, we can get more information. We can get, you know, the various hashesums we can grab, you know, when it was first seen, when it was last seen, and so on. And some additional PowerShell info. So, you know, functions that are used here, there's any calls and so on and so forth. As well as some various names that it may be called in case you're looking for that. Under the Community tab, obviously take the information here with a grain of salt. But some sandboxes will kind of paste their analysis of it in here. Other times you may see other users paste what it is. You know, sometimes we'll see funny things like this isn't malicious and something that's pingy malicious. And well, you have to take that with a grain of salt sometimes. But we're getting that this is, you know, known malicious. And if we were to grab the hashes of all of these, all of these would come back, pinging as malicious. And so let's take a look at this one real quick. Open it up. And we can see immediately that this has no obfuscation on it. In fact, it's pretty well documented for what it is. And, you know, we have the whole author and stuff like that. But one thing I want to point out to you, and it's not in the simple, I think it's in this one. Yes, it is. All right, is that we see this called a powersploit function of import scan, invoke import scan. And so largely this is going to be trying to determine what these five things do here. So I'm just going to do a deep dive into port scan and maybe into invoke cover us and try to understand what these two things are doing. And then I'll cheat a little and let you know what the rest of them do. And then we'll try to determine what happened here purely based on these samples. So we have our port scanning one. We'll start up with that since that seems pretty basic, you know, recon activity, trying to determine, you know, maybe the sockets are open, ports are open and so on. So we have powersploit. And so if I were to search powersploit, we'd probably get this PowerShellMafia powersploit github that comes up. It's been archived. We'll just ignore that. But we can see from the documentation that it's a series of PowerShell modules used for penetration testing. And so, you know, there's a lot of legitimate uses for these. Sadly, in our case, our threat actors have used them for something a little bit nefarious. And from what we can see in this virus total, other threat actors have actually done that previously. But going into a little bit, there seems to be a lot of them. I think that port scanning is recon, so we're going to go into recon. We can see this invoke port scan script here. And there we go. That looks pretty familiar, doesn't it? And so if you want to, you know, double triple check that this is, you know, nothing has been changed from this. You can do a side-by-side comparison. Now copy this, compare it to the script that you found. I'll say this matches one-to-one, I believe. So that's not so much of an issue here. But what we may want to do, as we may want to see, is there any more information that we can glean from this? And in fact, powersploit has its own talks. So that makes our job pretty easy. I think for whatever reason, let me try invoke port scan. I know the search utility on this is a little funky. And yeah, it is. All right, that's fine. But I see the invoke Kerberos one, so we'll just skip ahead to that one and try to understand that real quick. But we can see a summary of it. So of course service tickets are Kerberos, Kerberostable accounts and returns extracted ticket hashes. I'll explain what Kerberosing is in a bit if you don't know what that means. But we can see, you know, there's a full description, how it works. You can see the whole syntax, you know, what several examples each parameter does. It's very like a man page. This is pretty well documented as to what it'll do. But you may start to see a problem here. Is that well invoke Kerberos is well documented. You see, you know, oh yeah, you know what it does. We know all the possible use cases of it. We know that, you know, how it can be used. We don't know how this was used. And that's slightly problematic because we were just given these scripts, nothing else. No logs, no command lines that were seen. And so all we have are these scripts to kind of connect the dots. And ideally in some sort of incident you would be able to link up with your forensics team, your IR team, be like, hey, you guys shot me some, you know, PowerShell scripts. Do you have, you know, the logs for them being run? No, maybe if there was any flags added so we can get a better understanding as to what they did. Because right now we just know that they might have done Kerberos thing and that's about it. Or, you know, for port scanning, we know that they might have done port scanning. We don't know what ports were scanned on what, you know, why, what information they might have cleaned from that. And so that's it. That's kind of where we're stuck. And obviously you should be able to get these logs, you know, real life, but sometimes you're not able to. And this is something that can occasionally happen. Is that when I was doing my whole stint in power analysis in a sock, I would get some samples and I would just get the sample and that's it. Or sometimes I would get really old sample, you know, it would have been submitted months ago and there was backlog. So when I finally got to it, I hit a wall. You know, there was no more logs for me to look at. There was no more, you know, information for me to clean. Maybe the domain that the malware was calling out to was no longer containing whatever secondary malware piece there was. And so this can happen from time to time. And then what you're left with when you're writing your report is kind of try and understand what's going on, give your best shot at it as to what it's doing, but obviously list out the facts first before you get your opinion. And so the facts are that these five things here do the following is that port scanning, obviously does port scanning using regular sockets kind of like Nmap does. So we have some sort of end map like utility here. Secondly, we have, let's go over to PowerView here, which is primarily used for network and error awareness, but it can also be used to do user hunting things like what networks users are logged into or whether the current user is a local admin on hosting the domain and so on. Going over to invoke MemeCats, this loads MemeCats into memory. So it can be used to dump credentials without writing to disk. So this looks like there may be some sort of exfiltration component to this. And invoke Kerberost. So a little bit background of what Kerberosting is, but what Kerberosting does is that it attempts to crack the password of an active directory service count by requesting a ticket which contains an encrypted password capturing the ticket granting service and then attempting to crack the service credential hash to potentially gain that plain text user credential. And then sharphound acts as a data collector for bloodhound which collects data from the domain controllers and domain joint window systems. So if you're starting to sense a theme here, there appears to be some kind of user credential harvesting. And so if you were to write a report, you'd obviously sum up what all these things do, what they're known to do, possible use cases and then say, okay, maybe based on both five of these in context, it appears that if ran, this may potentially be geared toward user credential harvesting or at least in attempts too. That being said though, that's pretty guessy because we don't really quite know what was going on here other than the usage of these scripts or the probable usage of these scripts. And so that's kind of not fun to start off with but it brings up an important skill to have in malware analysis which is essentially a lot of Googling and a lot of researching and looking up, in the case of these, these are all open source. So you're gonna be looking at that. You're going to be looking, if you don't know what cover roasting is, you're gonna be learning what cover roasting is or how it might be utilized and so on. So this is I would say a pretty good jumping point for getting into that research mindset. So if you're looking for any sort of homework, I would say look into what are the use cases of invoke cover roast, how can you use this? Maybe try it out yourself, try some a little bit of penetration testing yourself to kind of understand how someone might be using this. Obviously do so safely and don't do it on posts that you don't have permission or access, initial permission or access too. But definitely get a better idea of what's going on here and that'll really help you understand why threat actors do things a certain way. So we're going to move on back to the slides real quick and do a little summary of this demo. All right, so that may have not been like the sexiest example of PowerShell scripts, but I wanted to, at least for beginners, give them the understanding that malware analysis can't really happen on its own without the full context of what it's going on. So sometimes it may be given a sample, but sometimes that sample may be useless in trying to understand the full context of what occurred within that attack. And so in this, while we have the scripts used, we don't have the flags or any other information our attackers used. So all of those PowerShell scripts required certain parameters to be input in order to gain specific information. And we don't know what parameters were used, we don't know what specific information that our attackers wanted. And so we don't have the full context as to what happened other than based on what each script does, guessing that usually with all of these scripts together, this may point to some credential harvesting activities, primarily using Kerberoasting. So this is kind of what happens sometimes is that it's kind of like a box of chocolates as to what you get. Sometimes you'll get some really fun samples where you can get math the whole thing out and be like, oh yeah, this is, this PowerShell script spawns this executable which does this and so on and so forth. You can get a really nice cool report and write up out. And sometimes you kind of get like a, well, I mean, this might have happened, this is what I got, or here's the limitations of the sample that I have. And so in that case, it's to kind of make sure to note that that may happen sometimes. And doing the best you can with it and making sure that in a real incident, keeping communication open so that if this were a real-life thing and I was just handed those five samples without any context, I would definitely be going to the IR team or the forensics team and being like, hey, locks please. So going on, we have another thing to look at that may be a little bit more fun. And so this is going into Killchain 1 now and there are two samples that we're going to be taking a look at. A few ways to tackle these as well as some considerations when you're choosing how to de-office skate PowerShell scripts. So on to demo two. Alrighty, so welcome to demo two. We're now in Killchain 1 and we're going to be looking at the two samples that we can immediately find. This malicious PowerShell.txt and then this PID malware.txt. So this one will be just as is, I believe you can just grab it as the text document, no need for end zipping. But this malicious PowerShell one is going to be located in the for malware RE team.txt file. So once you've got all those unzipped, we're going to start with this malicious PowerShell one. And so opening up with a text editor, you can see immediately that this is not logable, at least not to us. And you may be wondering like, okay, oh God, where do we go from here? And the clue lies in this tag E and C flag here, which stands for encoded command. Now this means that PowerShell looks at base 64 encoded commands and be able to run them. So knowing that that's our first clue here, we can go ahead, grab this real quick. And then what I'm going to do is open up CyberChef. As a note, for whatever reason, when you just download a fresh install of Remnex, CyberChef comes two years out of date or that just might be something that happened to me. I don't know. Obviously you should keep it up to date, but for the purposes of this demonstration, that's not super necessary. But what we're going to want to do is first take out this PowerShell header here. We just want this base 64 encoding that's going to mess up our conversion when we make it if it's still in there. And so a little bit about CyberChef, if you're not familiar, it's a really useful tool for pretty much a lot of data formatting conversions. As you can see from this list here, I like to say that if there's an input and an output, CyberChef can typically do it or can handle a good chunk of it. A lot of what I use it for are data format conversions, specifically in the case of if I need to do several conversions stacked on top of each other, CyberChef is really useful for that. So for example, this won't work at all for what we're doing, but I can do all of this on top of each other. And if it's for whatever reason, a recipe that I use pretty frequently, what I can do is save it and then load it later in the future if I need to use it again. And it's something that I don't want to have to keep remembering how to do. But all we need to do right now is grab this from base 64 recipe, well operation, and pop it into our recipe here. We can see immediately that this is starting to look like PowerShell. You can see new objects, I have a stream reader, weird formatting, but there's some weird periods, spaces, weird capitalizations going on. So what I'm gonna do is I'm going to grab the regular expression operation and pop it over here. And without having to put any regex in, this is already kind of fixed itself. Now, what we can see is that you may be looking at this and seeing like, oh God, okay, maybe it's another base 64 string. This is maybe, you know, we have to pop this in here. And I'm gonna say that you're kind of there halfway, but to additionally consider this compression, deflate stream, you know, more compression stuff. This is obviously pointing to, well, this is base 64, it's also compressed. So there's two ways to tackle this. One, we can do purely in CyberChef, which is what I typically like to do as the first stage. And two is to do it in PowerShell, which is really easy. You don't have to really do much other than copy, paste it and pop it into PowerShell. But there's some additional considerations to be made when you do that technique. First of all, there's a function that you should be on the lookout for, which is invoke expression. That will, in fact, all of this, run it. And you probably don't want that, especially if you're doing static analysis first. And so what you wanna do is trying to find that invoke expression. The problem of it is, is that there's a lot of ways to hide it. So sometimes it may just be, you know, flat out there invoke expression. Other times it may go by its shorthand, i.e. X. Or in this instance, it's like this. And so you may be wondering what this shell ID thingy here is. And this is an environment variable. So if I were to go over to, say, our cute little PowerShell thing over here and ignoring VMware real quick, if I type in shell ID and hit enter, it's gonna bring us Microsoft PowerShell. And so going back here, we can see it's grabbing character from the first index and the 13th index and catnating it with the letter X. So popping back over character, the first index is i, character at the, I think this is the 13th index is E. So putting it all together, that's i.e. X, which shorthand again for invoke expression. So we wanna look out for that. So if you were to do this full little trick of copy-pacing it into PowerShell, you want to avoid this little fella at the end here. So we're gonna grab that. We're gonna go over here. Just gonna pop it in and enter. And there we go. There's our next step of the translation there. Coversely, if you want to do this purely in CyberChef, what you do is not that. There we go. So what you do is grab all of this and take out this ending piece here. There we go. And immediately we still have this from day 64 recipe. We can see that this isn't quite working, but we know it's been compressed. And so CyberChef has this operation called Ronflate, which she compresses data, which has been compressed. And what we could do is pop it at the bottom here and we get the same exact output down below. And so this next step, I'm going to additionally do in CyberChef, but I'd also like to note another instance of hiding that i.e. X. This is in this over here. And so if we grab this verbose preference here and once again, just pop it into PowerShell just to see what that is, what that's doing. It comes back as silently continue. And we know from this it's grabbing from the first and the third index, which once again is i and e, and joining X to it. So we have i.e. X right there. So being careful with that, of course, we want to avoid it, take that out. So if you're going to do another PowerShell, pop it into PowerShell once again, you're going to want to delete that and then put the rest of this in here. But if we're going to just do this in CyberChef, just to note as to what the next step is, as Char tells me that this is converting all these integers to characters, which tells me that this is CharCode. So I'm going to just grab these right here. I'm going to delete the input up in there. Obviously delete our current recipe. And what I want to do first is that if you take a look at the from CharCode operation, you can see that there's a delimiter that's needed. And with our current output input here really now, we can see that we're both using spaces and commas, which probably isn't the best. So what we're going to want to do is there's another formatting operation, remove white space, we'll just do that. And taking out the from CharCode, we can see our output has been normalized. So back to from CharCode, we're going to change our delimiter to comma. You may not be thinking, uh-oh, that's not right. But we need to remember that play around with the bases a little bit. There's different ones. And in this case, base 10 works for us and gets us to our endpoint. And so here, if you're just purely looking for IOCs, you can see this download data, this malware.love.xyz URL. And you may want to just quickly grab that and take it with you, use it how you may. In general, this appears to be creating a user agent, downloading data from this malware.love domain, and then loading it into the system. So that's kind of spooky. But for considerations then, you'd want to probably look at making some detections for this domain or any attempts to connect to this domain. And so here we are, we're at the end. And some other neat things to note about this too is how the strings have been kind of, I won't say manipulated, but they've been, you know, changed up in kind of a way to make it harder to detect. Obviously, these have been split apart as far as possible. Same up here with user agent, and you know, all of this up here has been split apart as to further attempt to obfuscate what's going on over here. And so that's it for this first one. So we're going to, let's leave this, because I think we're using Cyber Chef again. So we're gonna go back and to our cute little demo space. We're gonna go on to the next one, which is this KC1. You know, I'm gonna rename that because that's getting really difficult to say out loud. I'm just gonna call it Cool Cat 2. Probably keep things named the same way. In this case, I'm just getting tired of trying to figure out what to call it. So Cool Cat 2 works. We're going to open up this into our editor and it's a little weird, so let's wrap it real quick. And we can see that this is a little bit different from our first sample. Popping that open real quick for comparison. While this started with that pure base 64 encoding at the beginning, this has kind of skipped that step. We're already onto that compression, base 64 string type business. So I'm just going to grab all of this. And again, like I said, I prefer to do it. Cyber Chef is the first step. Of course, you can attempt to do it in PowerShell if you'd like, but it'll become clear why I like to do this at Cyber Chef pretty quickly. So we're just going to grab all that first. And what we're gonna do is we're going to do the typical formatting that we did for that base 64 compression. So base 64 and raw in spelling that correctly, run on plates. And we get, you know, maybe looking down here and maybe like, oh God, that doesn't make any sense. Oh no, but then you'll see this little sentence up here, which is this program cannot be run in DOS mode. And so if you're in the no, this isn't executable. This is a portable executable, a Windows executable. And if you're ever unsure as to what you may be looking at, you know, maybe you'll do something correctly or you think you do it correctly. You're like, wow, this isn't the output I expected at all. You know, this should be something else. What you can do is grab that detect file type operation, pop it at the bottom, and it'll tell you what you're looking at right now. So this is a Windows portable executable. And so we're gonna take this dude out real quick. And what we're looking at is pretty much a semi equivalent of if you were to run strings, strings is a useful tool to look at all the strings within executable. But if you were to run it in the terminal here, you'd get approximately a similar output here. Obviously a little bit different. Maybe a little bit more formatted better. But we can see all of the function calls here in this kind of text block that the program is making, you know, RSA crypto service provider, you know, validate search, decrypt, things like that, as well as this is really badly formatted, but this, again, malware.xyz at port 443 URL here. And what appears to be a little bit of HTML, that's kind of neat. So things like that you can see right there. And if you want it, probably should download this for further analysis. So what you're able to do is you can save this output file. And what you are doing is that you're downloading the binary itself. So I'm just gonna call this quackat2.exe, save it, do not run it. And now we have the executable that was hiding in this PowerShell. And if you want to take the next steps in looking at understanding what it's doing, then we can do so here safely. All right, we're gonna cut it right there just because this is purely for PowerShell analysis, but I'll be taking a look at this executable in my other workshop. So definitely look out for that. But in the meantime, that pretty much summarizes demo two. All right, so to finish this off, that wasn't too bad actually. And it may have seen that, like I was going through and I'm like some kind of wizard that knows what I'm doing, but in truth, a lot of it is Googling and understanding what's, trying to understand what's going on. And so a lot of that information, you can learn simply by just copy pasting into Google something that looks weird. And most of the time you'll be able to find out an explanation as to why that is. So if you recall that Shell ID thing or that verbose preferences where there were two techniques to try and get IEX into the script without explicitly saying this is IEX, those are things I found out from Google as to why that did that and why people would use that. Those little hidden ways and techniques that malware authors will do. And so trying to find those weird things and trying to find what the next step is if you're stuck really, really helps in your overall understanding of it because in malware analysis, you're kind of in the state of always learning. Your learning new techniques may not have experienced this specific method of utilizing XYZ thing. And that'll come across every single form malware can come and malware can come in a lot of different forms. And so pretty much staying on your toes, recognizing patterns and not being afraid to ask for help is a really good skill set to have when you're starting to breach malware analysis. And so some big takeaways is that I want you to have that sort of analysis mindset of understanding that being good at reversing is being good at always learning. There's always new malware out there, it's always evolving. And so you're constantly having to learn what the newest techniques are, what might be used, what's kind of in the past, maybe coming back again, things like that. And of course staying safe, keeping yourself safe, trying not to tip off threat actors and of course keeping everyone else safe by not accidentally releasing malware into the world unintentionally. And of course information sharing is vital. So things like in our first demo, when we were looking at, okay, we didn't have the full context, being able to talk to the people who may have that information for you or it may have it, be able to find it for you is really vital in addressing an incident. Likewise, with malware analysis in general, it's a really steep step up to start becoming proficient. And a lot of the information that helped me become more proficient or more knowledgeable in a certain type of analysis or tackling a certain problem was people who wrote up what they did for each thing. And so those little tricks and tips you might find within these write-ups. And so as you become more proficient, I would totally recommend giving back to the community when you were able to and showing how you analyze it, the tricks that you use to tackle certain problems or certain steps within analysis that you're facing. And additionally, Google is your best friend. It's not cheating, Google everything. PowerShell, Google each function. Google what's going on here. Again, if you see something weird, Google that. Find out everything you can about it because that information is all free. It's open to you. And it's kind of a waste if you're not utilizing it. So of course, take advantage of all the information that you have available to you. It's only serves to help you. And lastly, I'd love to give thanks to our red team and our forensics team over at Blue Team Village. Our red team was responsible for creating these skill chains and the forensics team were the folks who gave us these samples that we are using for these workshops. So definitely check out their talks. They're all really amazing. I'd like to also thank Lask. They brought up a Emotent PowerShell payload. Some skills and tactics that they used that I used for this presentation as well as some of their explanations that I also used because that was a little bit more clear than what I had initially. And also thanks to Hermjoy, Jocelyn Bilek, and Rich Lundin for their PowerSploit scripts that were used in Kill Chain 3. And then a special thanks to the Vioxx and Paladin 316. These were the guys that were with me last year on DEF CON 29 for our excellent Macros and Excel workshop. And so these guys really helped me in getting my step up and generating community content like this. And now here I am one year later creating my own workshops. So I'd really like to thank those two. They are amazing. They're really knowledgeable in the area of our analysis. So definitely check them out. They're fantastic people. And lastly, thank you all for watching. If you want to reach out to me, I'm on Twitter as Ari Scrabble. I'm not super active on Twitter, but you're more than welcome to DM me. And I'm also on Discord as Scrabble9731. So definitely reach out if you have any questions and have a lovely day.