 Greetings, ICS Village. Thank you all so much for joining me today. I hope you are all doing well and your families are staying safe and healthy. I'm very excited to be here today to talk to you about living off the land and an ICS slash OT penetration test. So brief introduction on myself. My name is Aaron Boyd. I'm a senior industrial penetration tester here at Dregos. I live in Denver, Colorado. My background is mainly been in security architecture type rules and verticals such as oil and gas manufacturing and aerospace. I do hold a couple of cybersecurity certifications mostly in the offensive discipline. And let's just jump right into it. So talking about an example ICS environment is really difficult because as penetration testers, we never know what type of environment we're dropping into, whether remotely or on site. We have no idea what type of configurations we're going to be up against, what kind of architecture is in place, but there are typically two commonalities that we see more often than not. And the first of the commonalities is there's usually no internet access. At least we hope there's not any internet access. And with no internet access, we don't have a way to download our payloads or our scripts or establish connectivity to our centralized command and control infrastructure. In addition to no internet access, there's usually USB restrictions, whether USB itself is completely disabled through the machine BIOS, or there's group policy objects enforcing the restriction of removable media. So with these two things we have no real way to get data to the environment, get data from the environment. So, what do we do? We live off the land. And I'm going to be talking about one of these techniques today. But first, let's talk about what living off the land actually is. So living off the land is a broad term that describes the use of pre existing utilities on Windows operating systems or networks that are known and trusted with legitimate capabilities. So we flip that script and use it for various purposes. And there's a link here in the presentation to a Drago's white paper that talks a little bit more in depth about living off the land and ICS or OT cybersecurity. But as far as this presentation goes, I wanted to touch on four key points about living off the land. Living off the land is likely not going to be detected by any of ours. As most of us know some ICS environments may not have any of ours, if at all. And if there is any of ours, leveraging the existing tools and utilities on the machines or network prevents us having to download files to the disk, which prevents us from getting detected quickly. In addition to that these living off the land binaries are commonly used in a lot of environments. So if monitoring has been implemented. We do hope that the monitoring is tuned to your environment, because a lot of these things generate a fairly significant amount of logs. And with that those looking at those logs, the risk is increased for alert fatigue or false positives being decided. Additionally, a lot of these are trusted by default because they're Windows operating system binaries natively on the disk that are digitally signed by Microsoft. And if they're not natively in the operating system, they could be downloaded directly from the Microsoft website. So if you have any virus in your environment, or you have application whitelisting with a rule that blocks executables binaries or scripts from unknown or untrusted publishers. This gets around that defense mechanism. And another one that doesn't get a whole lot of attention when talking about living off the land techniques but it does happen is the trust relationship with vendors. So sometimes work is performed in an environment from a trusted vendor, and this can be done from either an implementation or support standpoint. So when we drop into an environment and we see tools of vendors leveraging a lot of times there is potential for us to use those tools. Because you're already accustomed to them, you trust them, you expect to see it, we can leverage it and it'll just look like normal behavior. So, as I mentioned, there's lots and lots of different living off the land techniques, and I was going to focus on one today. And it's one that I personally have had more consistent success with. And that is bits admin. Bits admin is a command line tool to manage the background intelligent transfer service and Microsoft Windows. So bits admin is used to either create jobs to either download upload copy or transfer files, and it can also be used to monitor the progress of our existing jobs. The native binary location for bits admin is your system 32 or syswow64 directories. And in addition to that, there's also some PowerShell commandlets for interacting with bits admin and the bits service. So talking about bits from a high level, I'm going to ask three questions. First, do you patch your systems? If you do, there's a strong possibility that whatever solution you use leverages bits to download and apply updates. For example, on your enterprise machines, you have Google Chrome browser of choice periodically checks for updates. If you look at your Windows Event Viewer logs for operational bits client data, you will see both these browsers periodically checking for updates. I'll get in the Windows Event Viewer a little bit later in detail, but because that behavior is expected and normal, chances are it's going to be successful. You have application whitelisting implemented. With a lot of application whitelisting solutions, it's not uncommon for there to be a default rule to either automatically trust, execute, or elevate Microsoft signed applications or binaries. Like I touched on, if you've got a rule to block unknown untrusted publishers, the fact that a lot of these living off the land binaries, bits admin, for example, signed by Microsoft gets around that defense mechanism. And just another homage to antivirus. A lot of times, or sometimes antivirus may not be installed in a lot of environments, or if it is, it has a lot of exceptions to not interrupt the process. And I will say that some antivirus providers are getting better with detecting abuse of a lot of these living off the land techniques. For example, I know the latest definitions and updates for Windows Defender. If you execute bits admin.exe to create a job, it's going to trigger on that in Windows Defender. There are ways around that. I'm not going to get into detail on that here, but the potential is there. So I'm talking about bits admin, you're probably asking me, do I have an example? Of course I do. So let's paint the following scenario. We have access to an operator workstation. This operator workstation could be running an HMI or DCS that's running in full screen view. There's not an easy way to get rid of it. If you are able to get rid of it, then you've got group policy objects applying at the machine level, applying other restrictions preventing you from traversing the file system on the machine, or other restrictions that we commonly see. I do have ways around a lot of this. Again, I'm not going to go into detail on any of these, but for the sake of time, let's just assume we bypassed all these restrictions, and now we have obtained a PowerShell prompt. At this point, we start enumerating the machine. We look at the host information. We look at the user information. We look for things like startup scripts. The machine is domain joined. Startup scripts, logon scripts, logon, logoff, startup shutdown are commonly configured through Active Directory, group policy objects with the scripts being located on their domain controllers. Depending on the importance of those logon scripts, there's a good chance that those scripts are also going to be locally stored on these machines. And that's just an extra set of redundancy in case the domain controllers or domain goes down for any reason, those scripts still run. The function of those scripts can vary greatly, but the more common ones I've come across are mapping network drives, checking the context of the user that's logging in, applying restrictions just to be an extra layer of security. So with those scripts locally on the machine, a lot of times there's access control lists or other whitelisting type mechanisms implemented on those directories where the contents are protected from non administrative users. So let's actually go through the process of discovering the startup script. So as mentioned, we've got the power shell prompt, and we can pass this get item command to enumerate the registry to look for items that run at logon. And in this case we find one called drago stop that located in the scripts directory on the C drive. So curious about what that script is and what it contains we pass the type command on it to see the contents. In this case is just a simple demo script that says this is a startup script demo for living off the land. Once we see the startup scripts, we look at the permissions on the script with icacals to see who's got permissions to either modify it make changes, etc. In this case, only the anti authority system of the machine itself and administrators on the machine have full access to the script. So, in wondering this operator user we have a power show prompt on, are they inadvertently added to the administrators group. And through using the net user command, we can see that the user is not a member of the administrator group. And therefore the account will unlikely be able to make changes to that script. I always like to do an extra set or just a second piece of verification, just in case there's something else running in the background to overwrite access control list. And in this case, that did not work. Because I opened the script in notepad. I tried to make a change just by appending a test before that pause command and attempting to save it, we can confirm we don't have permission to that file. However, we do have the permission to copy that file, save it on our desktop, and then make changes to it, which is exactly what I did here. I created that script, put it on my desktop, added those two lines to create a new local user and add it to the local administrators group on the machine. So now that I have this script on my desktop, the registry key says run the script in the scripts directory. So I need to find a way to take the contents of the script on my desktop, and have it be placed over writing the script and the scripts directory. Here's where bits admin comes into play. So bits admin, like, it runs in an elevated context on this machine. It runs as either administrator or system, because of those auto trust application white listing rules. So even though the context of the user I'm running the command doesn't have permission to that file, because bits admin runs in an elevated context, it should overwrite the permissions of the user. So in this case, I basically am telling bits admin created transfer job and call it drag us. If you're in an engagement, be mindful of the job you're naming it, because bits admin and bits client in general, natively stores these logs and windows event viewer like I mentioned earlier and like I'll mention again later, where if you're naming it something blatantly obvious, it's going to stick out like a sore thumb, if somebody is monitoring the logs. So once creating the job called drago switch, we can see that happened successfully. I'm adding a file to that job was sourcing destination. So I'm telling the drago spits admin job to add this file source file being that startup script on my desktop with the destination overriding what's existing in the scripts directory. So once we see it was able to add the source and destination file successfully, because we weren't presented with an access denied message. So, once I saw that happen. Now we can resume the job, which is our way of telling bits admin. We've got no further changes to the drago shop. Just go ahead and add it to the queue for processing. If bits is configured in the environment, it could either process it immediately or process it on a predetermined time frequency. In this case for the proof of concept in the demo, I wanted it to go right now. So I told bits admin just go complete this job called dragos, and we're able to see the job completed. Okay, there's no other jobs in the queue or just bits admin already did my bidding. I'm good. I'll pass bits admin reset just to clear the queue in case there were any other jobs hung up. In this case, there were none. So to really confirm this work the way I intended. I now type the output of the drago's batch script in the scripts directory. You can see those two lines appended to create a new local user and add it to the administrators group. Now, even though we were able to successfully overwrite this script using bits admin, we still have another hurdle to get over. So in order to add users to a machine and add them to the administrators group, we need to have administrative permissions on the machine, which our operator does not have. So for proof of concept, just assume and this is a penetration test. We would then reach out to our point of contact with the client and say something along the lines of, like, hey, something might not be working the way intended we're not sure if this is a restriction on our account, or something wasn't configured properly, would you mind logging in just checking, we have the access you intended us to have, and everything is working properly before we proceed with our engagement. A lot of times they'll say yes, you're not realizing that this request is part of the engagement, which happens a lot. So they log in with their administrative permissions, and the script executes successfully. As we can see with the image on the left. There's the context, you know it's a startup script demo, living off the land, the command completed successfully twice. So we can assume that drago's was the drago's user was created and they were added to the administrators group. Now to someone that's seen the output of the script, many, many times. It's safe to say they would either just minimize it or close it because they see it so many times, they expected no changes, they wouldn't notice command completed successfully in this prompts, if they weren't aware. So once that script runs, they do their thing, they check and make sure they tell us everything is working as intended. We say okay thank you for validating you know we're good to go from here we'll continue with the engagement. So we'll log back in with the operator account, achieve that PowerShell prompt again. Now we run the net users command to see the users on the machine, and we can confirm Drago's as a user. So now we can run PowerShell as the drago's user. And you can tell by the prompt below, we ran a who am I just to confirm and enumerated the local administrators group on that machine and confirmed drago's is an admin, we now have admin on that box. So assuming this machine is domain joined, we can now turn off a lot of those USB device restrictions if they were being applied through GPO and interact with the LSAS.exe process creating a memory dump of it, extracting it offline, then we can look into harvest and TLM hashes. Hopefully there's going to be a domain account, we're able to see for lateral movement that we can harvest for past the hash activities, or we can extract, you know, the SAM security system hives out of HKE local machine for impact it or we can enable W digest on the machine and reboot it and try to capture credentials and clear text for next logon attempts. So, as I mentioned, there are so many living off the land techniques. And what I demonstrated today with Bitsatman is just one example of the capabilities of using it for nefarious purposes. So assuming we're in an environment with internet access, we can also use Bitsatman to download files from the internet and execute them immediately. And another living off the land technique run DLL32, we can download our malicious DLL file, replace an existing legitimate one and execute it, achieving a callback to our centralized command and control server. So if you really wanted to get fancy with it, you can by creating one liners to either run a command or a sequence of command. And one of the common questions I get asked when presenting conversations like this is Aaron, why are you telling us all about your TTPs. You know, if it's successful for you why are you risking it getting burned. So as penetration testers at Dregos, we're not here to point fingers, we're not here to judge, we're here to raise awareness. And there's a lot of belief, especially me personally, that there's been so much attention put on the prevention of these things from happening and not enough on monitoring and detecting it. Because, as you saw, there was an access control list on that scripts directory, where an operator or owner would think only admins can make changes to this directory were good. I demonstrated pretty quickly. No, I was able to get around that. So with that, if something were to happen, if you weren't monitoring or looking for it, you'd have a tough time answering the questions, how did it happen, when did it happen, who did it. So with that, I want to jump into how you can detect this activity. And one of the ways to do that is monitoring Windows event logs. Because like I mentioned, this is enabled and turned on by default in Microsoft Windows operating system. And the event log captures everything related to the bit service. And these logs are located in this location of the event viewer applications and services logs, Microsoft Windows bits client operational. And there's five event IDs I recommend paying particularly close attention to. So event ID three is bit service created a new job. This is the equivalent of me doing bits admin.exe forward slash create Dregos. That's me creating the Dregos job. This would show up in event viewer event ID three, Dregos job was created. Event ID four transfer job is complete. Again, that's me forcing it to go ahead run it right now. Don't worry about the queue. There should be no user manually creating or completing job jobs with bits admin. Event ID five, the job is canceled. Like I had mentioned, if there's someone trying to get bits admin to work, it's not working the way they think they created numerous jobs. They're just sitting there hanging. They want to clear it all and do a clean slate. They do bits admin exe cancel to wipe out all the jobs from the queue. If anyone does that on a machine, something's going on right then and there. And then event ID is 59 and 60. We'll just word it as starting and stopping the job. But the interesting thing about both these IDs is they also contain the download or upload URLs that might be interesting. So if the machine does have internet access, looking at these event IDs will tell you where bits is going to download jobs. So if something is being downloaded from a source that's not normal, you'd be able to see that in the event viewer natively. If you're not capturing Windows event viewers assuming you've got some other type of log aggregator, whether it's sys log sys mon or you've got another sim like Splunk. Pay attention to the command line options like I demonstrated. So transfer is the transfer of a file from one location to another. And the example I did I just copied it. So it's still maintained on my desktop. But let's assume there's a DLL file and a trusted directory. And I don't want to have it anywhere else. I just want it there, or in another location. I can run bits admin transfer to physically move it from one location to another. Again, like I mentioned, there should be no users going in manually creating or adding files to jobs. And the set notify the set minimum retry set custom headers. Those are defensive Asian techniques. So if you've got community rules, snore, anything like that. That's looking for common headers found in IOC's attackers can pass that set custom headers to set a custom header to evade that defense mechanism and resume. Like I had mentioned, no user should be going in manually doing these jobs. Like I mentioned earlier, bits admin can also be interacted with through PowerShell. So also pay attention to your PowerShell logs or other admin type logs that could also contain information relating to bits activity. I know turning on those PowerShell logs can be super tedious. But at least you can just look for these commands that I've highlighted on the screen here as it relates to bits admin. Like I mentioned, there's tons of living off the land binaries and scripts. Bits admin is only one of them. We've used a handful of others, actually many others in our engagements successfully. So if you're leaving here curious what other types of binaries and scripts are out there for living off the land techniques. I will share this project with you. It's open source and community driven where they talk about other potential binaries or scripts used in living off the land techniques. And the site is interesting, not only because it talks about how they are and how they're leveraged, but they also post if applicable mitigation or detection strategies with them. So if you are curious and other living off the land techniques, detections and mitigation strategies for them, I highly encourage you to go visit the site, bookmark it, check it on a periodic basis, because it is being updated as new TTPs are discovered. So with that, I'd like to thank you for being here with me today. Hopefully I didn't ramble too fast for you. Please feel free to reach out to me with any questions you have. I can be reached by my dregos email, which is a boy to dregos.com, or feel free to reach out to me and connect with me on Twitter. My handle is at ICS underscore blitz, and I'd be happy to answer any questions that you may have. Again, thank you for being here with me today. Thank you to DEF CON and the ICS village for giving me the opportunity to be here. I hope you and your families all stay safe and healthy, and I hope to be able to meet with you all one day soon. Take care.