 All right, and hello. Welcome to Blue Team Village's Project Obsidian Reverse Engineering Malware Station walkthrough. This is fishing in the morning in abundance of malicious samples. And contrary to the title, we're not actually going to be looking at our fishing email. Unfortunately, when I made the title, that was before I had officially timed out this entire walkthrough, and I ended up not having time for the fishing email. So I'm going to briefly go over how to get that fishing document in case you want it for your own analysis. But right now, we're not going to be going over that. I'm hoping to do a mal doc walkthrough sometime in the future. But in the meantime, a little bit about myself. My name is Allison. You can just call me Scrabble. That's what I go by here. And I'm a fourth year cybersecurity major at a university up in the northeast. My background is mainly in incident response, reverse engineering malware, and cybersecurity engineering, which is a little bit all over the place. But generally speaking, I stay in the blue team side of things. And this is my second year with Blue Team Village. So last year, I helped out a little bit with the this station's walkthrough for Defcon. And we did a little thing on Excel-based malware looking into those macros. So it was really cool. That was an amazing experience. And this year, I had the opportunity to lead both of these workshops for the station, which is fantastic and really amazing coming from someone who's beginner. And so I highly encourage, if you're learning, if you're interested in stuff on the blue team side of things to join this community, because they're really excellent at uplifting people and overall community education. And I guess a little fun fact about myself is that I crochet. That's a new hobby I picked up. And I'm guessing by the time I'm in Vegas, it's probably what I've seen like 100 plus degrees every day. So I'm going to be suffering. If it's not extremely obvious, I've lived in the Northeast my entire life. So that's going to be pretty interesting. So moving on. Looking at the table of contents, you might see I've obfuscated it a little bit just so that I'm not making too many major spoilers. But what we're going to do first is we're going to backtrack a little bit. Because in the previous workshop going over PowerShell scripts, Jaffee skating them and so on, we encountered a binary in one of our PowerShell samples. And so we're going to today going to explore that binary and look at one information we can get from it. Additionally, before we do that, like I mentioned previously, I'm just going to quickly go over how to grab that phishing email document just in case you want it as a little apology for not being able to get to it in this whole workshop. And so after that, we're going to do a quick 101 on portable executable files. And then after that, we're going to just start whacking it with tools. So looking at all the tools available to us within Remnex that we can use to try to statically analyze this executable as best as we can. And then totally unrelated, but we're going to go into Windows real quick and do some further static analysis in there based on our results from what we could gather within Remnex. And then from there, we're going to kind of be looking at maybe potentially some C2 activities going on in there. And so without further ado, I'm going to go back to what we covered previously as well as my little apology to all. All right, so now in our demo environment, this is just a Remnex VM I have spun up that is host only. So like I mentioned, we're going to be doing my penance first, which is grabbing that malicious document within the email attachment for you guys, just so that if you're interested in it, you can take a crack at it on your own. In the meantime, though, we're just going to grab the constants of this real quick. And as we can see here, it's got your typical fishing thing. You violated a company policy. You know, this may terminate your employment. Please review the decision made. So on and so forth, some kind of way to kind of force the targeted user to attempt to open this file using a sense of urgency. So we're just going to copy this real quick and using Cybershift. You may be wondering why I'm not using Cybershift within Remnex for whatever reason my VM refuses to update. And this older version of Cybershift won't do what I need it to do regarding the base 64 conversion. But what I'm going to do now is I'm going to take everything up here until we get to down here. And you may be wondering what we're doing. You can see this content transfer encoding base 64. This is a pretty simple base 64 conversion in order to get our mildock that we want. So what I'm first going to do is I'm going to remove the white space here. And then I'm going to grab our lovely from base 64 here. And so this still may seem like nonsense to you, but worry not. If we go check with our detect file type operation here, it'll tell us that this is indeed a Microsoft Office document. So from here, what you can do is that you can just simply save the output. So on, give it a nicer name. And then obviously you'll be able to download it and analyze it later on. So that's how you go about this step. But going back to our PowerShell, which is what we want, we found our suspicious binary in this KC1 PID 7036 malware.txt file here. So I'm going to pop this one open as well. And for the sake of clarity, I'm just going to wrap it so you can see what's going on here. And so initially we can see this from base 64 string. So this has obviously been encoded with base 64. But we can also see this IO compression deflate string here, which tells me that this has also been compressed. And so we can convert this all in Cybershaft if we want, which is what I'm going to do real quick. And popping that open real quick, we're just going to put that there. That shouldn't happen. Interesting. Of course, weird things happen when I record. So we're just going to go back over here then for now, I guess. Wow. Oh, mustn't copy that weird. All righty, let's try that one more time. All right, let's just try and grab all this done, because obviously something is going on weird here. There we go. Copy. Doing this. All right, here we are back in business. Alrighty, so we know this is base 64. And we know additionally that this has been compressed. So Cybershaft has this nice raw inflate operation here that we can pop on there. And then boom, we've got our little binary situation going on here. And so this is a tell. I'll explain how so later. But if we want to double check and make sure that we're on the right path here, detect file type will tell us that this is a Windows portable executable. So what I'm going to do is I'm going to take that off real quick. And what you can do, if you can save that to file, I'm just going to call this PID. What was this called? 7036.exe for clarity. Hit OK. Not going to open it. Just going to save it. And there we go. We've got that now. So just to show you guys where I'm at, of course I'm going to use the file system here just for visibility. I'm going to pop this into demo for now. And so we've got our guy over here. And so what we're going to want to do now is we're going to try and see if this is known, if this is something that has been encountered before. So I'm just going to quickly grab the MD5 hash of this guy and pop it into VirusTotal. So over in VirusTotal now, just going to pop our hash in. And as kind of expected, we've got nothing here. So don't worry too much because we have other methods to analyze this as well. So very quickly, I'm just going to go over and explain because now that we know that this is a Windows portable executable, we should probably understand what we're looking at first. All right. So before we start doing our little digging into it, let's try and go over what portable executables are and as high level as we can. So what are they? So they're Windows executables. They're commonly seen as .exe.dll extensions. Less commonly, you can see them as SRV, SCP, and so on. But like I mentioned, these are Windows only. Their Linux equivalent would be ELF, executable link files. They're both based on the common object file format or COFF. So looking at what it looks like all stacked together, starting at the top with the DOS header here. Every portable executable file starts with it, which is about 64 bytes long, but that is what makes it an MSDOS executable. And then that DOS stub right underneath it is commonly identified by that error message. This program cannot be run in DOS mode. So you may have seen that when I pointed it out in Cybershaft, that's usually kind of a tell that this may be unexecutable. Obviously, you shouldn't use that as the only tell because, you know, maybe someone might throw that in as a way to try and obfuscate things or try to trick you. But generally speaking, you know, you get that idea. So what that DOS stub does is that's just here to make sure that the program is running in a compatible mode. So if you try and run it in DOS mode, obviously, it'll print out that error. Moving on to the empty headers there in Gloom, there's three main ones. There's the PE signature, which says that it's a portable executable file. So when we have those functions to try and check what kind of file it is, that PE signature will be the thing that they're looking for. Then there's the file header, which contains some info about the file. And then the optional header, which isn't quite optional. It's optional for things like object files. But for what we're looking at right now, it's pretty much necessary and provides important information to the operating system loader. Then going on down to the green, that section table, which contains the image section headers. So for each section within the lower content here down there, for each section of the PE file, there's a section header, and it's stored in that section table. And then finally, those sections down there, you know, one through N, are the actual contents of the file. And the amount can be variable. So we're going to look at the general big ones. So there's eight right here. Obviously, there is definitely some more. But looking at the big ones, we have the dot text, which contains the executable code. Skipping over to dot data, which stores the global program data access throughout the program. And then our data can kind of be a catch all. So if we see i data and e data, which at respectively store the import function information and the export function information, those can be stored in our data. But what our data is, it's the read only data that is globally accessible within the program. Going over to P data that's present in the 64 bit executables and stores exception handling info. Our source stores resources needed by the executable and relock contains information for the relocation of library files that the executable may be calling. So now that we've kind of gone over that little bit of a walk here, we're going to start putting that to work. And when we're using some tools available in Remnux to dig deep and see what we have going on here. So there's a few ways with portable executables that you can kind of get a glimpse as to what they may be doing and kind of going glimpse as to what our next steps might be when we're starting to analyze them. Alrighty, so now we're going to be able to start taking a look at this PID 7036 executable that we have. So we've already checked the hash. And what I want to do now is determine whether it's packed or not. Because if this executable is packed, that's going to make our lives a lot more harder. So if you're wondering what the difference with packed is, is that packed is compressed, as opposed to, you know, obfuscated where, you know, it's just in some manner difficult to read. It's still convertible. It's still, you know, we can do some operations to make it a lot more easier on ourselves to read obfuscated, you know, code or malware or whatnot. But in the case if it's packed, our jobs get a lot more harder. And in some cases, maybe even impossible. So we have this great tool called PE pack that we can use to determine if it's packed or not. And occasionally what it's packed with. So in this case, this is kind of, it says it's packed. This is technically really unpacked. But it's Microsoft Visual C sharp and basic dot net. So if you know what the next step should be, technically speaking, please silence your thoughts, please ignore what I'm going to be doing is kind of ignoring some really maybe to some obvious tells of what this is, what the next step should be in favor of just kind of going over, you know, the general approach of, you know, analyzing this statically from a redneck perspective. So we've got this, you know, Microsoft Visual C sharp basic dot net. So we're looking at something, you know, dot net based. Going on, I want to try looking at the strings of this. And the strings can tell us a lot. And there's two main string functions I like to use, just because one doesn't get everything, the other doesn't get everything either. So we're going to start with strings, and go from there. And so from the top down, and usually you should probably put this into something, but I'm just going to scroll down because this is relatively short. But we can see that additional, you know, DOS stuff, this program can't be run in DOS mode. We can see this dot text dot reloc, these look like sections. Going down a little bit more, we see this execute stator, that's interesting. But what strings can do is it can show us the functions that are called by the program. And so we can see some functions, some things that may suggest, okay, that's a little funky, that looks unique. In this case, sometimes what malicious programs will do is that they'll randomly generate names. As a kind of form of obfuscation, if you're trying to create alerts based off of names themselves, this will make it harder. As in this instance, it's called this, but if you were to do it elsewhere, or if you were to find it elsewhere, hint, hint, you'll find it under a different name. But we can see that there looks like there's some encoding going on, you know, some base 64 string conversion, looks like there is some downloading and uploading of strings. So that may be a suggestion of network connectivity with this. Going further down, we have a little bit more of, you know, string manipulation. I'm ignoring something big, don't look at that. We've got some network credential, which suggests that there may be some, you know, network calls going on. Again, we've got some hash algorithms going on, some cryptographic algorithms going on here. Interesting to note that. Again, RSA crypto service provider going further down, ignoring something else. We've got, you know, create, decryptor, create, encryptor. Okay, definitely having some encryption going on. But then set cookies. And if we go down a little bit more, we're going to start seeing some things that may suggest, you know, HTTP web requests, get web requests, that there definitely is some network activity going on here. So once we can, we see that weird string there. We see that system security cryptography. So the big takeaway is I'd say from this, you know, whole list is that there's definitely some sort of network connection going on here. And then there's definitely some cryptographic aspects to this program. So what I'm going to do next is if you can recall, we saw some like HTML code there, but that's definitely missing from this output. So we're going to use another tool, PSTR, which will show us the rest of what we're missing. So like strings, PSTR will show, you know, this whole batch of functions that this is calling. But in addition to that, we're seeing what we're missing from that we saw in Cybershaft, which is this, you know, malware of love XYZ thing, these weird little strings over here, this HTML down here. And then the, you know, strange formatting that appears to be going on over here. And so we can really get that full view by using these two tools. And that's why I always encourage, you know, even if it seems redundant or even if there appears to be overlap, do, you know, throw everything at it just in case you may miss something. Because if we didn't see this before, if we had just gotten the sample as is, we might not have known that this was there and we might not have been, you know, potentially able to grab this IOC pretty easily. So moving on, as a hint to NREMNX, if you forget these tools, you can just type PE double tab and you'll find pretty much all of the portable executable related functionality here that you can use. So for us, I think I'm going to next go to, let's go for PE dump real quick. And probably input the file name, which might be helpful. All right, there we go. So PE dump dumps will absolutely everything in here. It's a pretty robust dump of what's going on. I believe PE scan or something along those lines doesn't even more basically vomit of all the information that you can possibly get here. But we can see, you know, the header here, the DOS stub, you know, that, you know, infamous message there, the PE header, which we can see that, you know, we have that file header, that optional header there. More information we're going to skip. Some interesting things to note to that time date stamp there that says this was created or at least compiled on February 12th of this year. Not to say that this will always be accurate. Sometimes, you know, there's definitely ways to manipulate this, but, you know, if it seems pretty plausible, that looks pretty neat. Of course, take it with a grain of salt as you do all things. So moving down here, we can see that there's some things imported here. And we only have two sections, like we suspected. So just text and re-lock. So we just have our code and then the libraries potentially used. We also have, you know, things imported as well as the packer compiler that was used down here. So again, like I mentioned with these tools, there's a little bit of overlap in information, especially with PE pack. But, you know, this may not catch something that PE pack catches or this may catch something that PE pack may not catch. So some things like that. As a note too, I'm going through all of these pretty quickly and, of course, clearing my terminal between them. But you may want to save these outputs later on for later analysis if you want. But in the meantime, I'm going to go over to PE scan and kind of get a determination of what we're looking at if this is within a normal range. So we can see, yet again, overlap of information. We have only two sections, noted that the re-lock section is a little bit small. But looking at this though, we kind of have a pretty small little program going on here. And one thing to note is the file entropy. So file entropy is the measure of randomness within the file. And generally speaking, if you want the rule of thumb of it, it goes from a range of zero to eight. And typically speaking, something around in the four or five range to seven is considered usually non-malicious. And things in the seven to eight range tend to be more malicious than not. That's not, you know, a perfect way to categorize whether a file is malicious or not. But it's something to take in account, especially when you're eyeing the entropy. In this case, we're in the non-malicious range, but you know, obviously we're going to take that with a hefty grain of salt. It just might not be visible in that manner. All right. And last but not least, we're going to use PE check real quick. And this is the super verbose deep dive into all those section information and header information there. So once again, overlap, we can see the entropy. We can see all these hashes here. And we can see the entropy of each section as well. That might be useful too. So we get, you know, DOS header information, the NT headers, file header information, same daytime stamp, that optional header information. Moving down, we can see all the PE sections, as well as the hash for the section as well for the dot tech section and the reloc section as well. We can see some, you know, directories, some entry import, export, and so on, as well as of course some information that there is no signature for this or no known signature for this or, you know, the signature database is missing. Oh, I think that might actually be because this is host only, as well as some entry points. So this may be useful in more advanced static or dynamic analysis to know the entry points of this when you're doing section analysis. But, you know, in this case, we've kind of gathered a decent amount of what we can gather from purely these PE-related tools. But there's another capability that I'd like to show here. This won't work right now with this version of Kappa. But Kappa is created by Mandiant, but it detects capabilities and executable files. So you can run it against a PE and ELF, I think in version four, which should be coming out eventually, you can run it against .NET modules. And so this is pretty useful if you want to kind of get like a general grasp of what's going on. It also compares it to the MITRE attack framework, which can be helpful in trying to get an overall suggestion as to what you may be looking at. So we're going to cap at this and wait for that to look real quick. And as I mentioned, well, it doesn't quite work for .NET modules yet. And this appears to be a .NET module. And so it gives us a little hint here as to what we want to eat. It's going to expand us a little bit, so it's legible. But it's suggesting we should use a .NET decompiler like dnspy. And so we're at a point now where I think we've done a decent amount of what we can do within Linux right now. And I think we should probably start heading over to Windows to look at decompiling this thing. And so one thing I want to cover first is the difference between a decompiler and a disassembler, which I'm going to pop back over to slides to do right now. All right. So before we pop over into Windows, I just quickly wanted to clarify some differences between disassemblers and decompilers and why we may use one or another. So disassemblers convert the low-level code to assembly. It can be a little bit harder to read parts because it is assembly. So while it is kind of more accurate, I'm putting quotes there, but it's a pretty much as direct as you can translation from the binary to readable code. But there are ways to treat disassemblers and attempt to kind of make the code, obscure the code as much as possible, so it's not immediately readable. Then there's decompilers, which from that low-level code converted to a higher-level code, usually something like C. So it's easily digestible. There's less to model through. If you were to compare the output of the disassembler to decompiler, for example, a one-liner, maybe doing some addition and division between two numbers, would be just one line and C, but it may be 20 or 30 or however many lines to do an assembly. So however, decompilers kind of work on a best guess. Your mileage may vary basis, so there's plenty of ways to trick the decompilers, especially when it comes to malware. And sometimes images get things wrong. So as I like to say, if you're ever in the choice to choose one or another, consider both. So there's tools like Hydra, but I'd like to generally put that you may want to use both if you're looking to get the clearest possible answer. Disassemblers are really good for that nitty-gritty low-level searching for how certain routines may work, whereas decompilers may be better for that higher level, just a general understanding of what's going on. So I'd like to say, for all malware tools, malware analysis tools, to use as many as you can and to not try and stick with one too often, because you may be missing some things, and it's better to get the full view than to get a partial view. So moving on now, we're going to go over and check out DN Spy. All right, welcome to Windows. So I've got my little sample here. You may notice it's now called cleanup. If you want to recall back in Remnux, if you've done some poking around at the samples already, in the from disk zipped file, there is a collection of executables there. One of them is named cleanup. And if you do a comparison of them, they're pretty much the same thing to our PID 7036. So we can say that that is another source to get it. If you're not willing to take that step to do the whole PowerShell de-office cation, just grab cleanup and you're all good. So we've got cleanup working there. And I'm just going to open up DN Spy real quick. Let that load for a second. And there we go. That's a weird format going on there. All right. So I'm going to pretend like I've never seen any of this before and quickly open up cleanup right there. So we've got all this set and it sets us right to this over here, this really weird name. You may notice that this kind of randomly generates the name every time. I wouldn't be too worried about that. But we're going to pop over to this grunt stager here because this appears to be where the code is. Go down one more. And then we can start seeing functions. So I'm going to go into the main function just to see where we're starting off at. And you can see it's creating a new grunt stager. So I'm going to go up to grunt stager over here. And you can see it's, you know, getting me to execute stage. So let's pop this open. And from the looks of it, this looks like the main body of what we need to look at. I'm going to quickly go over to parse because we haven't looked at that yet. And from the initial inspection, this appears to be some formatting related functions. So back to execute stager. We're going to start looking for anything that looks interesting to us. So obviously this malware log.xyz at 443 looks to be a good IOC to grab. But something of notes that you may want to check out is this covenant dimension, covenant search hash, which tells us that we may be looking at a covenant grunt. And so I'm going to pop over to the slides real quick to kind of explain what covenant is to give you that background. All right. So before we start poking at this code some more, I just wanted to go over what covenant is so that we have the context of what's going on right now. So covenant is a .NET command and control framework with ASP.NET Core. It's a cross platform application, which means that we can use it in Windows, Linux, and Mac OS without much difficulty. It also includes a web interface and later on when we talk about grunts, that HTML that we saw earlier is going to start making a little bit more sense. So within the context of what we've seen thus far, we have a launcher, which is a pillar that executes an initial stager on the target host to establish a grunt connection. So our PowerShell script that we have is our launcher. It contains that binary, that initial stager that we want, and that's going to execute it onto the system in which that grunt connection, the threat actors or penetration testers, or whoever's on the other end, will have a listener set up in which the grunts will periodically get left. So what a grunt is, is just a little fella that runs on the compromised host. Think of it as a minion essentially that's kind of, you know, tap maybe test new things, maybe just pass to sit and wait, who knows. But it lies around in memory and occasionally we'll let the C2 server know that they're still alive. It can also run tasks. So Covenant has a bunch of pre-built capabilities that grunts are able to run, and grunts have templates to make things easier. And so in our case, as we can see, we have a HTTP stager. And so there's of course a bunch of other templates, but in our case, you know, it's great for the red team people because it's pretty much plug and play, just insert certain things. In our case, we may see some changed variable names to kind of obfuscate things a little bit more. But you know, in the case of threat actors actually using them, not so great, they have an easier time. So we're going to take a look. But if we want to go in that whole big walkie martin kill chain, looking at the PowerShell script that we have, that's the installation step. And now we're in the command and control section. And then those tasks that grunts can run is that final, you know, once you have copied my system and you're in it, you've got control of it, further tasks that you can do, further mischief or, you know, other bad things that may occur in that stage. And so let's go back to our friend and start poking out a little bit more. All right, so now that we have some context as to what Covenant is and how it's starting to look like on our end, let's first see if this is in fact a template that we're dealing with. So quickly googling grunt stager, we're going to see this grunt HTTP stager. So let's go check this one out and see what we're looking at here. And as we scroll down and start looking at this, this is starting to look a little bit familiar. We see this, you know, URL here, cert hash here. But you know, while these variable names may not match up, the general formatting of things is looking a little similar for it to pop this open once again over here. We can see following some, you know, base 64 encoded strings, we have this whole EES generation going on down here. And in fact, if you were to compare, you know, the entire file directly, you'll see that for the most part, these are largely similar, if not identical, save for the changes in a variable name, and of course, the things that were input particularly for this program. So I think with some confidence, we can say that this is the grunt HTTP stager. And with that, there are some things that we may want to grab from it. Of course, we have a URL, there's this HTTP header names, values, URLs, and so on and so forth. And so these are all just base 64 encoded. So if you want, you can just pop them into CyberChef and do that real quick conversion. So if you want, pop that in there. And we can see the start accept language user agent that pretty much tracks for what that is filling in there, as that, you know, a HTTP header names. So we're not going to go too deep into this. Obviously, I'll leave you guys to the obfuscate these sections on your own, since these are all just pretty simple from base 64 conversions, save for this one, of course, because this one isn't, that's a little trick there. But we can see some things that we've seen before, particularly this HTML script going on here. And also see some weird formatting things. This kind of makes sense now that we've seen this right here, and so on. And so while I want to do a deep dive, I'm going to recommend to you later that you do the same. Well, you do the deep dive, not me. Just for understanding, because this is publicly available, and it's probably pretty known what this does. Obviously, this is a grunt stager, now it does its whole communication thing, obviously some cryptography going on here, that we're pretty much safe in wrapping up for now. All right, so now that we know kind of what we're dealing with, which appears to be the grunt HTTP stager, a little bit of homework for you guys, which is without cheating, what exactly is going on in the back end here. So I'll define cheating as directly googling what the grunt HTTP stager does, but cheating would not be googling what sections of the code does, what you don't understand, and so on. And so my reasoning for this is that we've had the easy path here. Generally speaking, we were able to figure out pretty quickly what we were dealing with, and it's been well documented what we are dealing with. But sometimes, this may not be the case, we may not have something commonly used in our arsenal, we may just have code that we've never seen before. And so understanding how to read code and understand what it's doing is a really big part of understanding what malware is doing, especially if you are finding new malware out there in the wild that currently may not have it right up available to you. And so you have to kind of flex your skills and really understand what's going on to get that full comprehensive view of what stages the threat actors are taking in their actions. And so with that, I'm just going to wrap up the workshop now. So I'd like to shout a big thanks to the Blue Team Village red team and forensics team. The red team are the guys who made this whole kill chain, and the forensics team are the great people who got us these samples. And so definitely check out their talks as well. They're all fantastic, so totally worth it. I'd also like to thank Ryan Cobb for the confident. XeroxRick for a very great PE file right up. I definitely recommend looking into it if you're interested in taking a deep dive into how they work. The DN spy team, as well as all the really cool Remnux tool developers. So Deodor Stevens for PE check, the PEV team, the PE file team, Mandiant and more. And I'd also like to thank the VX and Paladin 316. These are the folks that worked with me for my first workshop last year. And they're really fantastic and really knowledgeable in the world of malware analysis. So I definitely reach out to them if you want to learn more or just want to chat. And thank you all for watching. If you want to contact me, I'm on Twitter as Ari Scrabble. I'm not super active on there, but you can definitely DM me. I'm also on Discord as Scrabble9731, so you're more than welcome to DM me there as well. But with that, have a lovely day and thank you.