 Welcome everybody to APT's Love Power Show and Why You Should Do. I'm Anthony. I'm here with Jake. We're going to be going over some of the interesting things that APT's do for Power Show. And here we go. So once again, I'm Anthony. I go by Coin. That's my handle. I got a master's in electrical engineering. Same with my bachelors. Some interesting things about me. I'm a lockpicking hobbyist. We followed some of my work. I did some Bluetooth lockpicking hacks over the years. As well as some wireless stuff. And then a lot of my focus recently has been building up Empire and Starkiller. And then I got Jake here as well. Yeah. Hey guys, I've got my background's a BS in astronautical engineering and I have an MBA. I actually ended up getting into cybersecurity while I was in the Air Force because I showed up at a new unit. And they've been told they had to have a cybersecurity person and I was volatile that I was the new person. So after that, I ended up as a doing some cyber testing for fighter aircraft for the Air Force. Then went on to a red team where I was a red team lead for about a year and a half, two years. And then I got out of the Air Force and now I'm currently focused on embedded systems security. And I'm kind of our Power Show off use case and expert for BC security. So I spend a lot of time on that too. So we get told this all the time and ask this question, you know, aren't Power Show attacks dead, you know, offensive power shows dead. Why don't you just move to C sharp script blogging to, you know, is makes Power Show attack completely impossible. You know, all these sort of things everybody always brings up. We're constantly being told this, you know, why, why use Power Show isn't it dead. Yeah, and just kind of a fun, fun story about the, that bottom line about AMSY is going to catch offensive scripts is we gave a webinar back in February that was actually a workshop we taught at DEF CON last year. We had a Microsoft security guy show up with and gave us the challenge a couple of days beforehand that he was curious to see if we'd actually be able to get AMSY or past AMSY on a fully patched machine. Whether it was intentional or not, they actually rolled out some updates to AMSY like the day before we started our, our course, like they added some additional detections when you're using like invoke expression and that kind of stuff that did throw a little bit of a loop but by the end of the class, the Microsoft guy was a little bit blown away by the fact that we could still get default empire payloads past fully patched AMSY stuff just using off use case and some other and some of the tactics and techniques will talk about a little more going forward. So obviously, PowerShell is really, really dead. Can't be used for offensive secure offensive PowerShell anymore. So this is just a quick poll that you can just go into Google and look over the last couple months. What you can see is just APTs and threats are using offensive PowerShell pretty regularly for all types of things, not only just for breaches, but for ransomware attacks for lateral movements, gaining initial access. It's being used for all sorts of things. Okay, so just a quick primer in case everyone's not fully aware of PowerShell. Why PowerShell and how it became a popular offensive tool in the first place is that it gives us full dot net access to Windows, which is kind of really the underlying architecture for being able to do a ton of lower level stuff in Windows. It gives us direct access to the Win32 API, which also gives us low level access to operating system functions. We can operate entirely out of memory for the most part and then installed by default Windows and admins typically leave it enabled because it is a huge efficiency in terms of their jobs and that kind of stuff. And, you know, the theme of the day is going to be why PowerShell is still relevant and how we still see it being used by red teams. So this is just another tweet on the side about how Microsoft and red teams talk about PowerShell being totally played out. Meanwhile, APTs and criminal groups are using PowerShell every day. They might not be using it for the full attack chain, but almost every APT is using PowerShell in some way, shape, or form during a breach. So now we're just going to do a quick timeline of PowerShell like what it was released, when offensive tooling started coming out and when defenses were incorporated into it. So PowerShell version one came out in 2006. It was released for XP, service pack two, service 2003 and Vista. When it was first released, it didn't have a ton of capability. It was kind of more of a novelty thing. And PowerShell version two is when we really saw what started getting widely adopted. It was fully integrated into Windows 7 and server 2008. And it introduced a bunch of new features such as PowerShell remoting and background jobs. PowerShell version two was like when we saw the real adoption by CIS admins and that kind of stuff. To the point that many, there are CIS admin tools that you will encounter on live networks still that run in PowerShell version two because that is what they were written in and they don't want to take the time to go port it to a different version. And so you'll find networks that still have PowerShell version two enabled because they want to be able to use their automation scripts. And so version two and version five that we'll talk about in a second are kind of the big delineators of what's going on in PowerShell version two. If we can run in version two, that's where we want to be as offensive people. And version five is where we got the full Gucci set of defenses. It had a few protections, but it had essentially no protections and then trusted security. David Kennedy and Josh Kelly gave their PowerShell it's time to own talk in 2010. And that was when we saw the beginning of the wave of offensive use of PowerShell. They were really kind of the initialization of the movement for offensive PowerShell tooling was their talk that they gave in 2010. So that's when we started seeing people begin to adopt things. PowerShell version three came out two years later in 2012 introduced module logging, which we will talk about that more. I actually think it's one of the more powerful logging capabilities in PowerShell and it was introduced all the way back in version three. But PowerSploit was first published in 2012. A lot of people don't realize just how old PowerSploit is at this point. And then Metasploit also introduced its execute PowerShell capability in 2012. And 2013 PowerShell version four came out. This was where rudimentary strip block logging was introduced. It's more akin to what PowerShell version five referred to as transcription logging. So it did do some script block logging but it's not nearly as powerful as the one introduced in version five. And then 2014 is where we start seeing like the just overwhelming wave of offensive tooling and everyone adopting it. PowerView gets published, PowerUp gets published. Cobalt strike incorporates PowerShell execution into its tooling. And that just kind of starts the major wave of offensive PowerShell. PowerShell version five was introduced in 2015 slash 2016. It's got two dates because it was officially released in 2015 but there was a major bug in it that required it to be re-released in 2016 so it sort of has two release dates. But in 2015 PowerShell Hearts the Blue Team was published and it was a article published by Microsoft that introduced this whole host of PowerShell defenses to combat the offensive movement of malware through PowerShell. So it introduced what they call deep strip block logging, transcription logging, talks about module logging some more, and then the big game changer was the introduction of AMSI, which we'll go to in more depth in a second. That's also where PowerShell Empire was released as well as PowerPick. So now that we kind of gone through that timeline, we can see that who's still using it today. Because we hear about people moving to C sharp and the PowerShells, you know, as we said played out and that kind of stuff. But these are all the APTs that are currently still using PowerShell. So pretty much everyone they use it. That's not to say that they're operating entirely in PowerShell, but they're using it in some way shape or form. That's how we'll just said like just about every threat and every APT is using PowerShell in some sort of capacity. And when you're trying to go out as a red team and try to emulate those threats, you want to know what they're doing. I know we're focusing on a lot of PowerShell during this talk, but there are other tactics, techniques, procedures or TTPs that people use. So be able to do that research. You want to be able to research what those behaviors of the adversary is doing and kind of build that cyber threat intelligence based on whatever the threat is that we're looking at. And this is important because this is something that a lot of industry is going to be using governments do as well as some of the open source community. You can use things like FireEye if you want to pay for some of that threat intelligence info. Otherwise, another option is always go on to MITRE's page for the attack framework. And you can do some research there to see what techniques certain APTs are using. Maybe get some more info if they're using PowerShell specifically and then see what sort of lateral movements or what sort of privilege escalation techniques they're leveraging when they're focusing on PowerShell. So just a nice thing to mention because we're talking a lot about APTs and being able to go back and kind of do some more research to them is pretty important. So when you start doing some of that research on APTs, you'll find that they're using PowerShell for a lot of different reasons. Obviously command and controls is a big one. There's a lot of different C2 frameworks out there that are being used. You'll see some of the APTs using things like Empire or other C2 frameworks to kind of control whatever they're doing for their implants. PowerShell can be leveraged for their DLL hijacking if we do use for key logging. One of the really big ones that's used for is lateral movement and privilege escalation. Lateral movements specifically for the PS exec, you have PS remoting, you have WIMI. All those things are all leveraged using PowerShell. And then privilege escalation specifically for InVay. So really everybody's still using a lot of offensive PowerShell. These are some numbers that we pulled pretty recently. Most of these are within the last couple months. These were when these reports were published. Carbon Black put out that about 90% of targeted attacks are using PowerShell. So it's a very big, significant number as well as McAfee for this last quarter put out there was a 689% increase in targeted attacks using PowerShell. So not only is PowerShell still being used a lot, its use is increasing significantly by each quarter and every year. And the last one, CrowdStrike's most recent report said about 50 to 70% of targeted attacks. They observed PowerShell. So pretty wide range when you're talking about how many attacks are actually using PowerShell out there. One of the examples that we're going to talk through is APT33. Do some research out there. You can see that they rely pretty significantly on PowerShell to be able to do their stuff. They are a suspected Iranian threat group. So they are state sponsored and they're really going to be focusing on aerospace and energy industries. So a lot of defense contractors is what they're really aiming for. So trying to hurt the industrial base of a country when it comes to defense is really what their target is. And they're typically employing things like Empire, PowerSpoight and Mimi Katz, focusing mostly on the PowerShell side of things. They have been seen to use things like CoboStrike or other things for some of their beacons, but they're trying to stick mostly with a lot of the open source stuff that's put out there. So this is just an excerpt of one of their malicious files that they use that FireEye did a report on a couple of months ago. And what they did was they used a malicious HTA file, which is an HTML executable. And what that does, it has just a regular HTML on the top part that may point to a certain person. In this case, it was this aircraft company. And then after all that HTML, the they embed a script. So the script that they're running launches a PowerShell hidden window with a Base64 encoded payload attached to that. And this launching method is actually very similar to how Empire does a lot of their things. So you're talking about emulating what the threat does. Empire emulates this threat pretty well, especially with the HTA file. Next is Wasted Locker ransomware. This has been pretty popular in the news recently. This is from the EvilCorp group or Drydex. And what this does is it leverages a few different things to be able to launch the ransomware. First, it leverages a CoboStrike beacon and PowerView. Kind of get that initial foothold. And it contains both PowerShell, JavaScript, and .NET. So it's really leveraging everything when you look at how they go about launching this ransomware. And once they get that initial access with that CoboStrike beacon, what they're going to do is they're going to run PSExec, which is going to launch PowerShell and run the Wasted Locker ransomware. And once that ransomware is in place, that's really where they're going to make their money. They're going to lock down companies, individuals, whatever they can, their machines. They're going to put out a Bitcoin address or whatever other cryptocurrency they want to get paid in. And they're going to then hide those keys until you guys pay the fees. And they've been very, very successful with this. The numbers being reported at the moment is they've made at least $100 million using this sort of ransomware. So it's a very profitable business for a threat to be able to use. So being able to see how they do it and then emulate what parts we can is very, very important. Yeah, and then this comes from a case study that Microsoft did on a breach that happened to Nipon, Telegraph, and Telephone. They actually didn't have enough indicators of compromise or enough access to the NTT findings to do like a direct analysis of all the techniques themselves. But what they were able to do was build a lab that restructured the representative architecture of NTT and then kind of theorize how they would do it, which ended up using a decent amount of PowerShell. And we just included this one because we thought it was highly representative of like these major corporations that we're seeing being attacked now because they use hybrid infrastructure of on premise servers as well as cloud servers, and then Active Directory and just it's a very complex attack surface that they still ended up utilizing PowerShell through several of the steps to pivot through. So they used phishing to get an initial foothold. Once they had that initial foothold, they were able to gain domain information, then they scraped social media. In addition to add to the information they had from the domain information to start building like what people's emails might look like or their user names and that kind of stuff. Once they did that, they started password spraying to get access to the cloud server, which they designated server B is part of their case study. Once they got access to server B we start seeing them use a lot more PowerShell because PowerShell in the cloud is still very effective. And what they ended up doing was building a brute force attack on user accounts on server A because server A was a privileged production server. And what they were looking for was accounts that had both cloud privileges as well as local privileges because those users don't always overlap. So they first use PowerShell to start trying to identify users that had had synced accounts between the local network on server A as well as the cloud network that was in server B. Then they were able to brute force those accounts to start trying to get access to server A. Once they got onto server A, they were able to extract passwords from LSAS and remote sessions to get remote access to the active directory server. Once the active directory server was compromised, they added a backdoor into it to maintain persistence. And if you look at these images, those are just showing some of the PowerShell they used. And again, we're just showing how this was used to target a major international telecommunications company that had servers in multiple locations as well as cloud and local based. One of the last ones for our case studies that we just wanted to show, some PowerShell usage in the wild is one that we were contacted about a couple months ago. There was a very large international hotel chain that reached out to us and said that they detected some malicious activity on their network and they were downloading payloads from our GitHub specifically. And what was going on here was they were getting an initial foothold inside the network. They were trying to stay as lean as possible. They were going out through the web, reaching out to our GitHub, which we hosted Empire. They went specifically to one module, which was our Invoke Mimicats module. Since we keep that pretty up to date, they were downloading that right onto the network so they can run it locally. And that way they could run Invoke Mimicats completely locally. This technique of downloading things like from like Githubs and other destinations is a pretty popular technique among APTs. And you can find in the CrowdStrike report for 2020. It's pretty widely used. One of the interesting traits about this though that really stood out to us was the fact that they were running things completely unobfuscated. They were running it just without any obfuscation or if they had any invasion at all, it was very, very basic techniques. Normally, you wouldn't see this from a threat, but it actually had some really interesting results from it. First, the defenders on this network waved it off initially because they thought it was the internal red team practicing. Since a lot of those weird obfuscation techniques really make things stand out in the logs, their blue team didn't think anything of it because they just thought it was the red team testing internally. So being unobfuscated in this case actually worked to their advantage. They still ended up getting caught eventually, but it really was a benefit for them. Yeah, and just to add to that, the hotel chain did stop them from compromising anything before they lost any user data or anything like that. It was just a, initially they thought they waved it off the activity. So the defenders did have some extra time while they were trying to de-conflict that it actually wasn't the red team that they thought it was. Now that we've talked about all those case studies, we've mentioned some of these logging techniques and that kind of stuff that have created when fully implemented, created an environment that's actually fairly difficult to use PowerShell in. If you use the full capabilities of strip block logging and module logging and AMSI, you know, combined with EDR, like that does make PowerShell pretty hard to get through. But our point, especially we've specialized in working with smaller to medium-sized businesses and you just don't see them using this fully. Like maybe they do have strip block logging enabled or module logging enabled, but they're not ingesting it properly into their scene because it's producing so much data. And so, or they don't have good signature, they don't know how to build signatures that would flag on malicious data, but not on their admins. So it's not the protections that we often see it portrayed as in the offset community. They're just oftentimes you see the limitations of real-world implementation, don't meet what the full capability can be achieved in a lab. And also just something else to note is that, you know, AMSI has already been incorporated into .NET, so C-Sharp now has to deal with AMSI and Microsoft is, you know, constantly innovating and looking at ways to start to improve the defensive .NET now that we're seeing a lot of people doing that. So the advantages that C-Sharp have today have already began shrunken from what PowerShell has and will probably continue to shrink into the advantages that it has over PowerShell as Microsoft implements more and better defenses into .NET. So now we're going to talk about AMSI in a little more in depth. We hear about it a lot, but often people don't really fully understand exactly how AMSI is working. So AMSI is the Windows anti-malar scan interface. I'm going to go ahead and read off the Microsoft definition for you guys. It's a versatile interface standard that allows your applications and services to integrate with any anti-malar product that's present on a machine. AMSI provides enhanced malware protection for your end users and their data, applications, and workloads. So that's great, but kind of what does it mean? What that means is that AMSI first of all doesn't work with just PowerShell. It works with VB script, it works with J script, as well as other applications that we want to send information to. It's built to be kind of this all-purpose lower-wavel layer that you can tell it has predefined interfaces that can then be connected to an antivirus. You know, traditionally that's Windows Defender, but also McAfee and others tie into AMSI and rely on its detection capabilities for seeing malicious things going on in memory. And it's also processing, the big advantage of AMSI is it's processing the commands at as low a level as possible before it enters into the script engine. So a lot of obfuscation that is put in place is removed before AMSI even looks at it. And this is just a diagram of how that data flows through those layers. So as I said, it evaluates commands at runtime. So like if you were to use like XOR encoding or secure string or some of those other obfuscation techniques that you might see out there, that obfuscation has to be removed before it can go into the scripting engine doesn't know how to translate a secure string or an XOR encoded string into commands that it knows how to read. So it helps us identify fileless threats. And as I mentioned previously as well, as a net 4.8, it is integrated into the common language runtime, which is what PowerShell and all these scripting languages are actually decompiled into the common language infrastructure that's ran in the common language runtime. So they actually all end up running in the same area. And now C-sharp also uses the common language runtime. And so the AMSI has been integrated at that lower level to account for some of the other languages that it didn't initially account for. So AMSI is actually pretty powerful. And we'll talk, we've got a couple of examples that we're going to go through here. One that Anthony will talk to more when we get to the obfuscation stuff, but this is just what a standard empire implant looks like when you put everything in. And if we just make some changes on the structure of the code, it still goes through AMSI, like it's still very, very heavily dependent on static signatures. So this is just our modified script. You know, we changed some variable names and changed some locations of where things are being done because some of the code was positioned independent. It just had to be ran before the end of the script. So we moved it around. And now it runs without issue. Well, this did run without issue. They are constantly updating signatures. And this one, this specific implementation probably will not pass AMSI anymore. But when new AMSI signatures come out, it typically takes me about 30 minutes to an hour to be able to come up with a workaround for whatever they changed for the detections. It's worth us also pointing out that we get a lot of questions all the time since we do a lot of work on empire of, you know, why don't you keep the signatures up to date constantly? So that way it's always avoiding AMSI and Microsoft and all the defenses that are out there. That's really just a cat and mouse game at the end of the day. So if we go and update it, it's going to take them, you know, hours to get the new signatures updated and then whatever all the work that we just did is now worthless. So for us, it's easy for us to easily make these changes and do it but not publish it out there. So that's just something that we see a lot and we get a lot of questions asked of just why we're not making these changes on the releasable stuff for empire. And if you're interested in learning more about the obfuscation stuff, we do have like a YouTube video up on that goes like, this is about three and a half hours of how to bypass AMSI and avoid it. So there's plenty of information out there. So now we're going to talk about script block logging. It was first introduced in PowerShell version four, but it was fairly arbitrary at that time. Version five introduced with Microsoft calls deep script block logging. What that means is that it follows the execution down through multiple levels, which we'll talk through in a second on these images. And then it's event ID 4104 if you go look at the PowerShell operational log in event viewer. I'm during our demo I'm going to go over a little more how you can find like the event viewer and what's in those logs and how we can look at them and that kind of stuff. But for now if you look over on the image on the left. We for the first six lines there are defining a function called super decrypt that is taking removing the X or encryption of a string, and then returning that string in Unicode. Now if we go down to the to the next line. It's going to decrypt that string there store it into a variable and then they're going to use invoke expression to execute that decrypted string. And we won't see it on the transcription log where just we just see what is entered into the command line. But if we go over and look at the script block logs on the right over here, we can see the first one where we defined our our function. The next one down is your running that decrypted equals super decrypt to run our function walk down to the next line, where you see invoke expression of the decrypted variable. And then this is where that kind of deep strip block logging and following the things down becomes powerful for AMSI. After all of that we see that the what was actually executed from that encrypted string is that right host pond. So that's that is like why NZ is powerful is, even though we had this function that we didn't really know it was going on with like bytes and counter and all that stuff. And decrypting this X or string that we couldn't see into, we still see what's executed by invoke expression at the end. And that's what makes AMSI power or script block logging powerful, but we'll talk about some ways that you can actually obfuscate the script block logging. And it'll a little bit later. So module logging. It was introduced in PowerShell version three. And I think it is the most powerful part of the PowerShell logging capabilities. It does have some issues in implementing and building proper signatures because it does report each module individually. But it's nearly impossible to hit the, to hit the log without being unobfuscated. I say nearly impossible because maybe someone knows a way of doing it, but I have never been able, I've never seen or been able to figure out a way where you can not hit this log on obfuscated. And if you look over at that image on the right in the, that kind of center block, the first line will say like command execution or sorry command invocation new objects and it shows new objects. So that's telling us what module is being ran, which commandlet. And then the next line down, you know, says parameter binding and then if you go all the way over to the right it says value. And that is what is being passed to the commandlet. And that value is always unobfuscated from what I've seen. If someone knows of a way of obfuscating this I'd be really interested in hearing it, hearing about it afterwards. But that's why it's so powerful is the values being passed in as arguments for commandlets are always unobfuscated, but it produces a whole lot of alerts. FireEye went and did a study when some of this came out and running invoke me cat's just that nothing else going on on the network run just invoke me cat's produces 2200 events, generating seven megabytes of logs from just running that one script. And as you can see that generates a lot of data and a lot of events that we have to sort through into our to be able to build efficient signatures and not just have this data for after the fact. PowerShell logging would make for a bad day for red teams if organizations actually use it properly. But unfortunately we have a bunch of things that are in the operational world that are, you know, making that more difficult you see alert fatigue, you know, administrators using sketchy scripts, I've been to a Fortune 500 company where when we went and looked at the local logs on the machines. Their EDR was interfacing with AMSI. And they were each individual machine was producing like 100 like alerts every two or three hours because the admins had a script they were using for automation. It was running every couple of hours to make sure all the baselines for everything was staying but it was doing something sketchy that was triggering the EDR to say it was bad. And so basically they had every all the work set to information only, and the EDR wasn't doing anything to kill the, the PowerShell when it was being flagged as bad because they did the administrators didn't want their scripts being killed. And you now have your SOC dealing with just, you know, thousands of alerts every day that they know are like not really alerts because it's just the admin guys, and you know the admin guys update their stuff so they don't necessarily have a good way of automatically knowing they're automatically filtering out those admin scripts, although in an ideal world they would be able to do that. And then deep script block logging can result in multiple alerts for a single script execution. Again, FireEye was testing with InvokeMimiCats and it produced 116 events totaling five megabytes when you use just the standard script block logging settings. Script block logging actually has an additional setting that you can turn on that it has it record start and stop events for loading different modules and executing pieces of code and that kind of stuff. And when you enable that your logs jump to 96,000 events totaling 50 megabytes of logs for running one script. And then on top of all of that bypasses are still effective because things like script block log bypasses or AMSI bypasses that we'll talk about in a little bit are not considered as crossing the security boundary by Microsoft because it's all operating on its own process and since it is the owner of that memory space for the process that it's working in, it's not breaking any boundaries because if it turns it off for itself then there's no way to prevent it from doing that. So this is just a quick overview of like kind of what Mandiant says, should they recommend for doing logging. They say if you can to enable module logging, script block logging and transcription. We didn't really talk about transcription because it's fairly straightforward all it is is recording what is written out on the command line. And it doesn't include it. That's all it includes is just the, it's a replay or a text version of what was typed into what you see as you're typing into the command line. Now they say the unique data is recorded by each source. And then this is kind of the takeaway I like to point out to people when we, when everyone says like a blogging is like, you know, the end all be all for PowerShell. They say where log sizes cannot be significantly increased only enable script block logging and transcription logging, because it will cover most data you and module logging only buys you some. But as I talked about, we have some ways of obfuscating transcription and script block logging so that even if you do record that data without bypassing script block logging, you can't tell what's going on in the scripts. And then module logging is basically impossible to hit an obfuscated so it provides much better insight in my opinion, but it does produce a whole bunch of data and because events are individual correlating them becomes harder. So now we're going to talk about why it's still really effective for red teams and APT still go after this stuff, you know, mitigating the mitigations. We'll go over a little bit of AMSI bypasses some obfuscation, like standard obfuscation. What we refer to as keyword obfuscation, which is kind of doing some minimal obfuscation to bypass AMSI because heavily obfuscated. Scripts can be a flag in and of themselves. We'll talk a little bit about script block logging bypasses and then event tracing bypasses. Those will be primarily in the demo. So reflective bypass. It's the simplest bypass that currently works. It's grabs the system management automation to AMSI utils DLL it grabs a reference to it, and then changes a field that says, AMSI init failed and sets it to true. So why this works is when they were incorporating AMSI into PowerShell, they decided that if there was an issue with AMSI starting up rather than just killing PowerShell not allowing PowerShell to run if AMSI couldn't run, that it was better to basically fail safe and just have AMSI ignored by PowerShell so the PowerShell tools could keep working. So when we're reflectively setting this field, we're saying that the initialization of AMSI failed. So just go ahead and return a clean finding regardless of what was actually done. And it doesn't even bother scanning the code. It just says there's something broken with AMSI. So we're just going to tell Defender that everything's fine in terms of malicious content because we don't know what's broken and we don't want to stop PowerShell from running. And then it's also just kind of cool because Matt Graber originally posted this in a tweet all the way back in 2016 and still works. So a more complicated bypass we can look at and there's a bunch of different implementations floating around. This is one I wrote based off of Tal Lieberman's work that he published at Black Hat. Ross and Malus has a very similar one implemented as well as there's a few other places you can find ones that are based off of this patching of the actual AMSI DLL in memory. So this is using some C sharp to export DLL functions to allow us to access some areas of memory. And then we are patching when AMSI goes to return the results. There's actually a numeric value that it measures to define your risk rate. And if it's over X amount that's considered bad, if it's under X amount, then it's considered mostly good. And then if it's a zero, it's considered good. You basically never see zero returned in real life. And you actually never see the different values with the actual value of your script rose because when it returns the value it defaults it to one of those three. There's actually a couple others for policy implementation issues, but those are the three returns if it's just scanning your code without outside influence. What this does is it patches it to always return that the that the code was good regardless of what the comparison finds of what the value actually came out from AMSI. It says just return a good value from from the comparison and say that the script is fine. So all of these work because AMSI is loaded as part of the memory space that our process is in, which means that we have unrestricted access to the memory space that we're in, we can modify it however we please. And so the reflective DLL tells AMSI to return a clean result prior to scanning it and as I mentioned the patched one tells it to return after it being scanned. So the use case going kind of a different direction with that is, you know, taking that code that we've established and, you know, adding, you know, some more noise in there to kind of hide what we're doing. It's still very, very effective, but it does come with some costs. One of those being, you know, the complexity of your payload, your payloads will become really, really complex, and they'll add a lot of size to them, because you're going to be running a lot of different techniques. You may be encoding it on top of changing variable names and splitting things up so you can easily exceed limits that are put in place by PowerShell on the size of a command. It also takes a lot of time to be able to encode these. So if you're running every command that's being sent across your C2 framework as obfuscated, there's going to be a delay there. Now that may not be a big deal to some people, but depending on what you're trying to emulate that actually could be a big deal. And then, as Hubble talked about, some of the defenses that are in place, if they take all that obfuscation and they wait until the very end, they may be able to detect whatever you're trying to do at the very end, because obfuscation helps you in breaking up signatures and dividing things up so that way they might not be identified, but if they're waiting until the end to run their analysis, you may get caught. I hear just an example of some unobfuscated and obfuscated code for a launcher for Empire. The left one just shows the basic payload without any obfuscation in it. The right one has just the standard token all obfuscation set in place. And what it does, you can see here, it starts breaking things up. It starts encoding things. This right here actually won't get past AMSI the way it's currently implemented, just because of the way token all does some of its things. My sure Hubble will want to chime in a little bit on that. But the important part though is really seeing how it actually encodes this and the big red flags that defenders would actually see if they saw this in their logs. Yeah, so token all is the way it's implemented in voc obfuscation is a pseudo randomized implementation of a bunch of various different obfuscation techniques, and it has kind of two issues. One it's pseudo random. So at this point in voc obfuscation has been out for a very long time, and all the randomization, or all the combinations for those like six techniques that it has are fairly well known at this point. And then there's also some issues with certain techniques interfere with each other if they ran in the wrong order. So sometimes you run into issues with that and invoke or invoke obfuscation running token all is it might run like the you see some of the stuff where it's like broken things up into like a bunch of string numbers. And when it when it does that it then can't search for like commands to replace the name of the command because that's already been broken up so can't find it. So some of these things work better if you run them in specific orders and invoke obfuscation token all doesn't always do that. So that's just some of the limitations on it. And just having those those custom cocktails of different obfuscation techniques make a big difference. I know we have a couple that we keep for ourselves that that seemed to work almost all the time. So the obfuscation really does get you about 90% of the way there. Like I said, those custom cocktails that we have really do get us most of the way there. But there's some things that you just can't get rid of when you're obfuscating and those are just like those common signatures that are require you to like restructure the code or eliminate certain keywords. One of the really good examples was something that we saw last year with the original Empire project prior to version three. There isn't actually a mistake inside of the code where it double appended one of the headers. This allowed signatures to be based off of that issue because it couldn't be obfuscated away. So any virus and amsy and everything was detecting off of this specific mistake in the code. So just removing that and then rerunning the obfuscation with a slightly different technique allowed the payload to get through completely undetected. So really read that restructuring and making sure that those signatures are broken is really, really important. So now we're going to talk a little bit more about what we kind of call keyword aliasing amsy can search for in memory for specific terms and that kind of stuff that are automatically flagged is like bad or raise your threat level really high. These can be triggered even when not ran directly by amsy. For instance, if you run a power shell script is base 64 encoded and amsy does not flag it as malicious. It still sees that as like a very suspicious activity so then to start searching strings in memory or defender and specifically, it'll actually do this even when amsy has been disabled because defender is seeing that as an inherently suspicious activity and defender goes and looks for it as well. So getting rid of these strings in memory becomes really key to getting our code through, especially in allowing us to not like heavily obfuscate everything all the time which increases our size and even out data we have to transfer and all that kind of stuff. So some of these strings to keep in mind are actually like invoke me cats invoke empire power exploit. It's not in here but like another one that doesn't necessarily get you flagged as malicious but generates like a warning level event in your logs which is like a means that it thinks it's highly suspicious and would like be a trigger for some of the potential things to go look at is if you're using like an assembly and use dot get field get field is in is in and of itself a string that gets triggered as as a warning level event and will go cause higher level logs to be produced. Even if script block logging is off like that string will cause a script block log to be saved even when script block logging is disabled. So if we change those terms, then we can make it really hard to detect us because if we change all the references in our script there is nothing to be obfuscate it from it just becomes that is the value that we are using so like in the example over on the right we're using invoke me cats to QAD 45 and invoke empire to DLX Z nine. This is how it's done an empire now on startup it automatically makes entries to obfuscate those strings. If you really want to be even stealthier instead of changing it to just kind of these random letters and numbers because if you looked at a log that would be kind of something that someone's using a function name this like completely random because what legitimate programmer would be using a completely random name. You could make these something like you know invoke file search or invoke organizer. So that would look even less suspicious than just a random string. We don't do this to everything for a couple of reasons. You could do it but it's time consuming to pick which values to alias, and then it also requires us to put in a lot of entries into the database, and that makes it, you know just hardest track because everything we want to alias has to be tracked individually. I'm not sure it's being applied across all of our scripts because if we had a reference and a script in one place and ran it outside an empire. And it was looking for something that empire alias or read alias by hand, and those don't match anymore than your stuff's going to break so there's just some complexity added in the aliasing. And then, as we mentioned, heavy obfuscation can be a flag in of itself so we want to minimally obfuscate what where we can. I have not seen this on open source stuff yet that I've been working on that's pretty fun to play with. You can actually import to avoid script logs, as well as the transcription transcription log as well import aliases the one I've been playing with the most. What happens is when we import our aliases for those don't know, let me take a step back aliasing in terms of PowerShell allows us to set whatever function name we want for any command width so like the get command or like get printer right alias like any of those we can say set alias and change it to you know print instead of get printer. And then whenever you type in print into the into PowerShell it knows that that is the same as doing get printer. You can then save those aliases using export alias. And then when you import alias that those terms and different names for your command widths never get seen by the by the log they just get imported into memory. You can now run the command with the name that you gave it and on the script block log. That's all it sees it'll see print instead of get printer. If you have module logging enabled then it will still it will still see the module you're using. And so import alias does not get you around module logs, although the module logs will not see the values in import alias which is kind of interesting. But as we said it's basically impossible to avoid hitting the module logging initially. This is kind of what it looks like to change things up on the right is if I want to do invoke expression new object system dot net web client. That's what it would look like that's what it would look like in the in the logs instead to run that I went and did some aliasing by hand. And we can embed further commands into the alias description. And if you look at the bottom down here you'll see I ran import alias dot a dot alias dot CSV that imported all of my alias commands. Now I run this, you know, completely non sexical commands to someone looking at it that says I print CCA dot description. And then that caused another execution that was be CB dot description. So as we, in this case, I was was invoke expression and be was that new objects, and then the description for new object was system dot net web client. And so I ended up achieving the same thing with this totally nonsensical strip block log that it there's no way for a defender to go figure out what that actually means. Because as soon as you close the PowerShell session, the aliasing is gone, it is not saved saved permanently anywhere so you have to import if you want to use aliases consistently you have to import them each time you start a new PowerShell session that's why the the function was built so as soon as we kill our, our PowerShell session or aliasing is gone and the key to what the strip block log means is gone as well. Now we're going to go into demo where I'll talk a little bit about more the event viewer and how to look at the PowerShell logs as well as show the strip block, strip block log bypass and the, the event tracing bypass that is used by the disables module logging in conjunction with all the other power show logging. First things first how you get to the operational. Log for PowerShell is you're going to use event viewer, you're going to come down here and type in event viewer, you want to make sure you run it as an administrator that just makes it easier to clear the logs and you're doing testing and that kind of stuff but you can usually view it even as an unprivileged user you just can't modify it. You'll then click on Microsoft, then Windows, then come down here to PowerShell. Open PowerShell and then click on operational right now I cleared the logs prior to starting this so that we can make it easier to see everything. So if I go ahead and click on PowerShell and open it. It's actually just starting PowerShell generate some logs. As you can see here we get these event IDs showing startup, as well as it looks like my computer was a little slow so if I refresh it again we should get a few more yet there we go. If you see this verbose prompt in script block logging that is just a default that always gets generated when PowerShell starts up and after each command, then we'll see this strict mode that gets used throughout when you're running PowerShell. But as you can see this one's 4104 which is our script block logging and we have 4103 is our module logging. So if I go up and run just this right host test is our kind of test subject. We can come back over and refresh our logs. And we'll see a couple of new entries in here. As I said prompt comes up after every execution. But if we go down here we can see this right host test for our script block log and 4104. And then we can see this module logging where we get the command invoke invocation for right host, as well as the value that was passed which was our string of test. So now we're going to go over here now that we've seen that. And the first one we're going to talk about real quick is script block logging. This was published by Matt Graber. There's a lot of modifications from his original one, but this was this comes from a default empire implementation. All it's doing is it's creating a new dictionary that gets added to our group policies or cache a group policy settings we access that reflectively, and we're just telling it that strip walk logging has been turned off. So when PowerShell goes to check if it's supposed to be recording it sees that the value is set to zero which means it's not supposed to be recording strip walk logging. We're able to do this because just like the MZ bypass, this is all in our process memory so we have complete access to it can manipulate and essentially whatever way we want. So if I go drop this in here. Like so and we hit enter. So generate a bunch of new events, because we haven't disabled it yet so all of that code that we just ran is going to hit our script block logging. And so we go up here. We can see that our script block was ran with all of our different values, then we get our out default which is a module when output is sent to the command line. And some other ones and since strip walk logging is using an assembly that doesn't actually generate any module logging because it's obviously not a module. But now if we go back up to here, I do our right host test. We will still generate a new event because module logging is on and we haven't bypassed that. But as you go if you go look here as you can see the last script block log that 4104 was our disabling a script block logging. And now all we have is module logging, which occurs here with our right host in our test string. So now this the other nice part about this is that only affects our local process if I just close out PowerShell and clear our logs. We will reset everything. So we're going to go ahead and clear. And then when we go if I open it again, we're now going to use a event tracing bypass that was published about the same time actually is the script block logging one. It just never really got a lot of traction. It's I believe it's linked in our, in our slides if not I have the link for everyone that I can share. And all we're doing is it's very similar to that script block logging bypass where we're getting access to a table that PowerShell is checking to see what it's supposed to be doing for logging. But instead we're disabling event tracing which happens at a lower level. This event tracing actually disables our module logging as well. So we run this and we go look at our logs. And we'll see that we get a warning level event. This is because of some of the strings that we mentioned during the briefing like the get field string as well as some of these like non public static and those kinds of things will automatically generate a warning level event which means this would actually produce a log even if the script block logging wasn't explicitly enabled. So we ran this but as you can see we don't have any of those standard, like the prompt logging or this out default that's normally there. And if we go run that, that get, or that right host test again. And then the last thing that we have had produced no log so we still have viable ways of totally disabling PowerShell logging. And like I said it's there are ways to get this down so it won't produce a warning level event. And then the last thing I was going to show you guys real quick is just that import alias thing we talked about I was just going to show it to you in real time so we'll go ahead and clear the log. Let's go back up again. We're just going to go ahead and import our alias.csv. I'm going to go ahead and run this nonsensical looking thing. As we can see it gives us an output that a new web request object was was created. So if we go look at our logging, we can see we can see a couple of different script block logs recalled so I called this ICA.description initially that, and this is where we can see that it's still hitting our module logging even the log logging can't see it. It appears that, that, that C is a is aliased to get command, as we can see here. I'm looking through that but as you can also see it's a little hard to correlate exactly what's going on and figure out what called this module without like some in depth analysis of what's going on. So we have this value a that gets passed to it, then we see it execute this BCB.description, which again is a get command. And then we also see that we're executing a new object that was being passed a system.net web client. Like module logging is kind of effective at bypassing this import aliasing thing, but the import aliasing totally obfuscates logs in a way that you can't really undo it. And the other nice part is when you import aliased the whole reason that you can import and export aliases is that they are not persistent between sessions so when we close out PowerShell all of our aliasing key is gone so they can't go look it up. So it just another level of obfuscation and it also makes it really hard for AMSI to see what's going on. So that's just something kind of fun to play with. But that's all I got so I'll toss it back over to Anthony. And we should have just a little bit of time left. Thanks for having us at the Red Team Village. We're going to be in the channel for a little bit to answer any questions.