Hello, and welcome this course in which we're talking about using Python to achieve persistence on a system. In this video, we're going to be talking about the Windows System PATH, and how we can take advantage of the PATH to maintain persistence. If you're not familiar, the Windows PATH is an instance of an environment variable. In this case, it's a list of directories that tell Windows where to look for particular files or folders. So, a simple example of using the PATH for everyday use is if I'm typing Python here, so I didn't specify the exact location of Python on the system. My Windows PATH has that particular directory included there and so Windows knows to look for Python there. If I type something that's not on the PATH, I'd have to provide the full directory path to that particular resource. And so, the reason why we're talking about the Windows PATH here where we're talking about persistence is the potential for search order hijacking. So, with the Windows PATH, we have a list of directories to search for a particular resource. And if one version of a program shows up higher on the PATH than another, then that first version is the one that gets executed. We can take advantage of this by placing a copy of an executable, for example, high up in the system PATH. And then if anyone tries to use the legitimate version of that executable, our version is going to be run instead. So in this video, we're going to be talking about modifying the system PATH to put a particular directory higher up in that PATH, which means that we could then put malicious programmes, etc in that particular directory. But first we need to talk about the structure of the PATH on Windows. So, going to open up over here, this environment variable section. So how you access this as you can if you're at the base directory of the Windows Explorer like My PC, if you right-click, you can choose Properties, which will open up a Window that looks like this one. You select Advanced System Settings, you get to this Environment Variable section. And so this is relevant here because it shows us something important about our PATH. Namely that the PATH that we see on our system. For example, if I type echo%PATH% to read the PATH isn't exactly how it's stored on our computer. So if we look here, we see that the first part of the PATH here starting talk about Java PATH shows up down here in the path under system variables. So if we add, click Edit, we get a nice clean view of what those system environment variables are in the PATH. We can add new ones, edit them, move them around, etc. Later on in the PATH, we see the contents of this local user variables. So we added these, we see a list of Python versions, mainly Windows apps and map here. And so when we're talking about editing the system PATH, we need to keep in mind that part of it's up the system variables level and part of it's specific to a particular user. And so if we wanted to edit the PATH on the system, certainly the most user friendly way to do it, is through this environment variables page. However, we might not have GUI access to a computer where we can access this, so we're going to be using a Python script to edit it. But we're not going to be using this particular Window. Instead, we're going to take advantage of the fact that the Window System PATH is stored in the Windows Registry. If you're not familiar to Windows Registry is essentially just a giant database of configuration information for Windows. And so, since we saw that the Windows PATH is stored in two different locations in that environment variables page shouldn't come as a surprise that it's stored in multiple locations on the registry as well. So currently if you look at the address up here at the top of the screen, we see that we're an Hkey Local Machine. So if the top level hive and then we're going through different layers, system, current control set, control session manager environment. And then finally we reach a variable in there or a registry value technically called Path. And so if we inspect this, we see that it looks like the System Level PATH. So this is where in the Windows Registry the system, part of the PATH is stored. If we want to access the user specific part, we need to take a look and Hkey current user. And then we can click on environment and see that it has a PATH variable as well. And so we see those Python installations that we saw in the other environment variable page. And so when we want to modify this PATH using our Python code to achieve persistence, we're going to be targeting these registry variables because those are things that we can change pretty easily and programmatically. So now let's take a look at some code to accomplish this. So this is an example of a program that's designed to read the PATH value and edit it for the different locations, and we handle the location information down here at the bottom of the screen. So the user path is as we saw Hkey current user environment, and then we're going to try to redirect that PATH to the current working directory. So it'll be the Downloads folder here. However, we could easily replace this with a location where we've got some malware installed on the system that we want to have run. For the System Level PATH currently got this commented out but we'll take a look at it in a second, is that we're going to be using Hkey local machine. And then we're going to need that longer list of locations to reach the PATH variable for the System PATH, so system current control session manager environment. So same thing that we saw on the registry page earlier. For both of these we've got a couple of functions defined just to make this process of editing easier. So we're going to start out by calling edit path value, provide the hive name of current user, the PATH environment in the directory that we want to change it to target there, which is where the variables that we have set it up here. And so the first step in the process is learning what the PATH is. Because if we're modifying the user PATH, we only want to deal with the user half of the entire PATH environment variable. And we know for a fact that this information is stored in the registry, that's where we're going to edit it. So we can take advantage of this to read those values from the registry as well. So we're going to call readPathValue providing the location of the value we want. And then once there we're going to use winreg to interact with the registry. We'll start out by connecting to the registry. We'll pass a variable of none and to say we want to the local registry. You can also access remote registries with winreg and then the base hive, so this will give us a connection to Hkey local machine. Then we'll use OpenKey to open a particular registry key, so we'll pass and that registry connection we've created. The PATH that we're trying to access in this case environment and then we want a read access to the key, because we want to be able to read that PATH variable out. Then we need to iterate over the values under that key to find the one that we care about. And there's not really an easy way to determine how many values are in a particular key. The best way to do it is to attempt to just iterate over until you find the one you're looking for, or you run out of values. So what we're going to do is use a while TRUE loop. We're going to use winreg.EnumValue, we're going to provide that key that we've opened and then the current index value. And we're going to be looking for a value labeled as Path, which will be in the first location within value. If we find that we want the corresponding value, which is the list of directories stored in the PATH. If the one we found isn't the right one, we can increment by one and continue. So technically all of this should be an error handling try catch block. If we weren't certain that this particular value existed in the registry, we'd use a try and then catch an OS error. But since we know that PATHs in there for simplicity, we're not putting that in. And so once we have that Path value, we can store that in a Path and then build our new Path. And so you may have noticed or known already, when we're working with the Windows PATH, it's delimited by semi colons. And so if we want to change the user PATH to include our target directory, we provide the target directory, add a semi colon and then append on the PATH. Once we have that we connect again to the same registry hive current user. In this case when we're opening the key, we want set value permissions, because we want to modify things unlike before. And then we're going to use the SetValueEx function, we'll provide the key that we've opened the value that we want to change in this case Path, a reserved value of 0. We want a type of reg_EXPAND_SZ, because this is the type that Path is in the Windows Registry. And then we finally specified the new value that we want. So our Path with our target directory prepended to it. And so when we're done executing this, we've successfully modified the user part of the System PATH. So let's take a look at that. And so we're going to open up our Command Prompt again and then we'll run this with python ChangePath.py. Hit Enter, nothing visibly happens, but if we take a look at the information stored in the Windows Registry, we don't see it now. But if we refresh the registry, we see that now the Downloads folder is at the top of the user Path. So notice what we haven't done, tried to do here, is modify the System Level PATH. And the reason for that is permissions on the system. So if we go over to our notepad ++ program where we have our Python code, we see that we had commented out the System PATH part of this. So if I uncomment this and then comment out the local user part because we've already modified that and we try to run it, we're going to see that it doesn't quite work. So I'm going to open up an instance of Command Prompt, go to the correct directory, and then run it with Python change Path. And we see that we get access denied and reason why here is that we're attempting to access and modify system level variables with a non-privileged account. However, if we have privilege, this isn't a problem. So, closing this out, let's open up an Administrator Command Prompt in the Downloads directory and run Python changePath. Again, notice that this works and runs very smoothly. And so, if we go back over here to our copy of the registry, scroll down to where the environment information is stored, we see that downloads is now the first item on the list. And so, at this point, we've successfully changed the System PATH for both the user and the environment in general. Now if we tried to run the program and tried to take advantage of this PATH change right now, it's not going to work out because this information is loaded in advance and then kept through the user session. However, if we underwent a reboot, then we'd find that the System PATH and the User PATH would remain changed. And that now anything in the Downloads directory would be the first version of an executable that would be accessed. And so again, the reason why we care about this for persistence purposes, is that by placing our Downloads folder or whatever our malicious directory is at the top of the list of folders to search. We can ensure that if someone tries to use an executable that we've created a copy of, that our version will be run instead of the legitimate one which can allow us to launch malware or do something else on the system. And then maybe handover to the legitimate version to a lay suspicion. And so this is an example of setting up search order hijacking to allow us to run a different executable on the system, then we should be able to, thank you.
