With each story of a new, brazen attack on an enterprise or government network by some “sophisticated” threat actor using “novel techniques”, the Twittersphere and public media outlets get whipped up into a fear induced frenzy. Questions about losing some kind of technology skills arms race and trendy new memes fly around the internet faster than any of us can keep up with. Let’s take a moment to look into a method these “sophisticated” attackers use to elevate and maintain access in their victims’ networks, then using this example, outline what we good guys need to do to make life difficult for those trying to exploit this attack vector.
Establishing a Foothold and Performing Reconnaissance
Attackers most commonly gain a foothold by abusing cloud services and pivoting to remote access, phishing, or just a good ole’ fashioned web drive-by. The method really doesn’t matter because the reality is, everyone clicks. Eventually, someone in your network will be lured into opening an attachment or clicking on a link and they will be compromised, and we can’t stop that.
Once the vulnerable user’s system has been compromised attackers will start to dig for information to discover the rest of the network and identify systems of interest. Once they gain access to one of these systems by exploiting a vulnerability or leveraging stolen credentials the real fun starts. What’s the big deal, right? They were able to RDP or gain terminal access to a server, but they don’t have elevated permission to actually accomplish anything there. We’ll see about that.
Let’s take a look at all services running on the machine and which executable those services actually run, focusing on anything outside of the system directory. The goal here is to identify software that might have been installed in a directory that you actually have access to.
Now that we’ve got a list of potential targets, let’s review the permissions on those executables to see if we have access to change them using icacls. In this particular case, the logged in user has FullControl (F) to the executable and we’re in luck!
Then, from our attack machine (running Kali Linux in this case) we’ll use msfvenom to create a payload that will run a reverse shell once executed. A few things to note here; msfvenom is part of the metasploit framework and simplifies creation of malicious payloads. In this case we’re specifying that we want a reverse shell, which malicious host to reach out to, on what port, and that we want the shell encoded with shikata ga nai to help evade modern detection:
Then we’ll move it over to the html directory to be hosted by the local Apache web server. Apache is installed by default in Kali so there’s not much magic here.
Then, using PowerShell we’ll download the malicious payload from our Apache instance. Note that we’re using powershell because it’s native to Windows and this method works because unfortunately, administrators often don’t restrict internet access to known good endpoints:
Remembering that our end goal is to abuse an insecure service to gain remote access and an elevated command shell, let’s take the known good executable run by the vulnerable service and rename it. We want to keep it around so we can clean up after ourselves later and hide that we were ever there!
And finally, we copy our malicious payload over to replace the original:
Great! Now, when the service restarts it’s going to execute our malicious payload and will reach out to the IP that we’ve specified to establish a remote shell, running with the permission that the service itself runs as… NT Authority\System!
And of course, on the other end, we need to have something listening to pick up the shell! Using Netcat we’ll open a simple listener, listening on the port that we specified when we created the malicious payload. With the Netcat listener in place, we’ll reboot the target machine to get the service to restart and for our payload to execute. With the shell established we can use ‘whoami’ to confirm that we’ve got elevated permissions on the target machine:
Finally, using our elevated access let’s create a little persistence with our remote shell before rolling back the changes to our vulnerable service and deleting the malicious payload to cover up and make it harder to see that we’ve been snooping around:
Why was this so easy and what can we do to protect from these types of attacks?
Well, the first and most obvious thing here is to make sure that our servers are only running software core to the functionality of the server. Leaving administrative tools in place leave a vulnerable footprint attackers can easily exploit. Tools like Wireshark or VMWare Tools can make administrative work more convenient, but often go unpatched and make our lives more difficult in the long run.
Obviously we need to patch our systems. But that doesn’t just mean Windows patches, that means EVERY piece of software on the system. Public exploit databases make software running on your servers a menu of juicy targets. Our vulnerable service may have been fixed in a recent patch!
Then finally, our servers should not be able to reach out to internet locations that are not explicitly trusted. Known public cloud services, windows update, threat monitoring tools, or any other cloud hosted management services should be the only place that servers are able to access. Initial access would have been significantly more complicated, and our reverse shell would not have worked at all in this case.