A few days ago I participated with a colleague in a Red Teaming exercise. I’m just starting out in this kind of exercise (I hope to get my Red Team Operator certificate before the end of the year), but my colleague is an expert who has been working on this for years and has spoken at many cybersecurity conferences.
The proposal was simple: the client gave us the credentials of the Microsoft account of one of his employees with less privileges, and we had to see how far we could get with that information without being discovered.
The client’s employees connected via Microsoft’s VDI solution, Azure Virtual Desktop, so we were able to connect via Remote Desktop.
Once connected, the first thing to do was to find a way to escalate privileges and become a local administrator. After that, we would check for possible configuration flaws in the client company’s Active Directory, and try to find a way to get to Domain Admin in order to have full access to the whole network. It was a really fun and interesting process, but in this post I want to focus on the local privilege escalation.
The vulnerability
After enumerating and analysing the system, we found a program that was running in a directory where we had write access. Furthermore, there were two reasons why we noticed this program: it was running as administrator, and in “Automatic” startup mode.
Therefore, we could change the exe to a malicious one that has a payload with a reverse shell, and the next time the system was rebooted, the payload would run and we would have access as administrator.
First option: msfvenom
When you think of modifying an executable to add a reverse shell, the first thing that comes to mind is the metasploit tool, msfvenom.
This tool can be very useful for CTFs or non-antivirus environments, but in real life, the signature left by msfvenom when modifying an executable is more than registered by all antiviruses. Therefore, it is not an option for us.
Second option: Code Caves
Thinking of a more realistic way to make the switch, I remembered the post I wrote some time ago about Code Caves. The executable met all the conditions: 32-bit file, no DEP or ASLR protection.
So I started looking for a code cave in the executable big enough to be able to inject my payload (see the linked post if you want to know more about the process).
But I was bitterly surprised to discover that there was no space big enough to inject the reverse shell code. Since the main goal was not to be detected by the antivirus, I couldn’t add extra space to the program manually (as I did in the Code Caves I post), and the Code Caves option was totally out of the question.
Third option: C code
Ultimately the simplest thing is what usually works. So I simply used the C programming language to make a script that creates an .exe file that executes two commands: create a new user, make that user an administrator.
I compiled it on linux with the following command:
i686-w64-mingw32-gcc -o script.exe script.c
And… again, the Windows antivirus detected it….
What could be the problem, what was the difference between my program and any other legitimate program?
The answer was given to me by my partner. The problem is that I compiled the executable with Linux. And that raises some alarms.
So I downloaded Visual Studio and compiled the program in Windows, and this time it finally worked. I was able to run the file, and I got administrator access to the system.
This exercise has taught me that you should not overthink problems and usually the simplest solution is the good one. I hope you liked the post and that you found my experience useful.
Lethani.
Be First to Comment