Active Directory Assessment and Privilege Escalation Script 2.0


I take absolutely no credit for the modules used in this script. A massive thanks to Tim Medin, Kevin Robertson, Marcello Salvati, Will Schroeder and the rest of the team at Specter Ops for the modules used in this script. Finally, thanks to Daniel Bohannon for writing Invoke-Obfuscation, which was used to obfuscate all the modules in this script. I’m just the guy that paired it all together.

In my engagements and assessments, I often run a few powershell scripts that help identify next targets, check for bad group policy settings, AD misconfigs, missing patches, etc. This script combines the ones I use routinely and autoruns the functions I use in those scripts, outputting the results into a zip file.

This script will do the following:

• Gather hashes via WPAD, LLMNR, and NBT-NS spoofing

• Check for GPP password (MS14-025)

• Gather hashes for accounts via Kerberoast

• Map out the domain and identify targets via BloodHound

• Check for privilege escalation methods

• Search for open SMB shares on the network

• Search those shares and other accessible directories for sensitive files and strings (Passwords, PII, or whatever your want, really). By default it’s looking for the term “password”. If you wanted to search for CVVs for example, you’d just add it next to ‘password’, e.g. password,cvv

• Check patches of systems on the network

• Search for file servers

• Search attached shares

• Gather the domain policy

This script will completely run on it’s own, without using the internet at all. All the scripts needed are obfuscated powershell and included, so it should bypass AV completely. VirusTotal

It uses the following modules:

Inveigh –

Kerberoast –

Bloodhound –

Get-GPPP –

PowerUp –

PowerView –

The script will ask to run as admin, as it requires it. If you do not have admin access, it will only run the privilege escalation module. If you’re being blocked by UAC, I suggest running a bypass UAC script (

After running the .ps1, it will create the capture file in the same folder it’s being ran in and zips it. At the end of the script, it deletes all the folders it created (except the .zip file, obviously).

GPP password checking and searching sensitive files takes awhile, so don’t be surprised if this script takes a long time to finish depending on the number of domain controllers, open shares, and strings you’re searching for. Comment those sections out if they take too long to run.

Usage: PowerShell.exe -ExecutionPolicy Bypass ./ADAPE.ps1

Download here: 

Windows Privilege Escalation via Unquoted Service Paths

Windows PrivEsc has always been difficult for me but this method is pretty straightforward and very successful.

This already assumes you have a shell on the box. I start up Empire, start a listener and generate a Powershell payload



Then run the payload.


An agent then spawns on the target


I then select the agent


And then run the privilege escalation check module



What’s important in the results here is that the WebEx service is started by LocalSystem, but can be restarted by everyone. When some services restart, all they do is execute a binary/exe, in this case it’s ‘WebExService.exe’. This is a huge vulnerability because as a less privileged user, we can overwrite the existing WebExService.exe with our own, custom .exe, then restart the service. Since LocalSystem is the one that executes the restart, LocalSystem is essentially executing our custom executable.

To do this, I then create a malicious executable via msfvenom.


And replace the executable


I then start up my multi/handler


And then restart the service




And privileges have been escalated to SYSTEM. However, the attack isn’t over. Staying in the same process your shell was made in is a bad idea. For several persistance and opsec reasons, it’s necessary then to migrate to another process. Winlogon.exe is usually a great choice.



Now even if AV kills my initial shell process, I still remain on the target as I’m now operating out of winlogon.exe.

From here, I would then load kiwi and dump the credentials in LSASS via creds_all



AV Evasion

My job involves lightweight pentesting and vulnerability assessment and such is the nature that clients know what I want to accomplish and will happily white-list any script I ask them to, but what’s the fun in that? Researching methods to bypass AV and thinking of methods to just not write to disk, showed that AV catches common scripts (Inveigh in this example) even when in memory and not on disk. I came across this article  written by Black Hills Infosec that showed how easy AV evasion is and I thought that no way could this article written almost 2 years ago is still relevant.

I was wrong.

Particularly, I was trying to run Inveigh, which is the Windows version of Responder, but Windows Defender would constantly catch it. So I tried the methods in the Black Hills article.

I initially tried to just remove a line of code and rename the script, but that didn’t work.


So instead, I took Inveigh.ps1 and renamed it to Inv.psm1


Next, I made three changes to the script via ctrl+F & replace.

  1. I removed the comment section
  2. I changed the word “Spoof” to “Moof”
  3. I changed the word “Inveigh” to “Inv”


And sure enough…


It turns out that AV evasion really isn’t difficult at all and even as quickly definitions of AV are updated, it takes almost no time to re-edit a script.

Simple Buffer Overflows (x32)

Before I did PWK, I had a hard time wrapping my head around buffalo buffer overflows. Even after taking an Assembly course in college, I was still fuzzy on how they really worked. Eventually, after watching countless videos, asking a ton of questions on Reddit, and doing PWK, I wrote it out for myself with pictures. This example is taken straight from my tr0ll2 write-up, but it still applies to most simple buffer overflows. In PWK, you don’t really use gdb at all and instead use ImmunityDebugger which has a pretty GUI, but it all is accomplished the same way in the end.

Below we have a picture of what the buffer looks like.


ESP is pointing to the top of the stack and EBP is the bottom of the stack (even though EBP is a higher memory address). There are two registers here we care about: EIP & ESP. Stack & buffer overflows are all about controlling EIP. EIP is the instruction pointer, meaning it’s pointing to what instruction will execute next.

So the point is to get the address of EIP, then input the address of ESP so EIP then jumps to the location of ESP, jumping over the “Your Program Data” section (in the picture above), so now we’re at the start the stack. Then we input some NOPs (No operations; just go to the next byte of code), then input shellcode. So we want the buffer to look like this.


Why add a NOP sled? Why not just put in shellcode right after the ESP address? The reason for this is that due to the dynamic environmental variables and memory addresses, when debugging the program in gdb or whatever debugger you choose, the actual memory location of the everything in that program might be slightly off when you run it for real, so a NOP sled provides padding so that even if EIP lands a little after the start of ESP, it will land inside the NOP sled so it then “slides” into the shellcode. HOWEVER, it is very important that we stay within the boundaries of the stack and not go over EBP, or else we will get a segmentation fault, so it’s important that we know three things for this to work:

  1. Size of the buffer
  2. Memory address of ESP (to get the location of where the stack starts)
  3. Shellcode (Also need to know how many bytes long it is)

I’ll step through how it works.

So I used a python program to generate a pattern of 300 characters. The script I used can be found here. Metasploit also has some ruby scripts that can do this but they were not working for me, the Python one did though. If the buffer is smaller than 300, it will return a segmentation fault.


From here I copy and paste it as an input into the binary, while running the program in gdb. Luckily gdb was installed here otherwise this would’ve been a lot more difficult.


As I suspected, it gave a segmentation fault. What this means is that I wrote into memory I shouldn’t be writing into, as it went past the EBP. I take the memory address down below and paste it back into and it tells me the size of the buffer.


So I have 268 bytes to play around in. Next, while still in gdb, I get the location of ESP, which in this case is 0xbffffb70.troll23

Now to get some shellcode. is a great repository for already made shellcode. Since this is running on an intel processor and the OS is 32 bit Linux, I grab the shellcode from here:

Which is this:


With shellcode in hand, I now have the three components I need to craft my buffer overflow. My template looks like this now:

(Binary)(Print ‘A’s to the size of buffer until EIP)+(ESP Location in reverse) + (NOP sled) + (Shellcode)

The payload ends up being this:

./r00t $(python -c ‘print “A”*268 + “\x70\xfb\xff\xbf” + “\x90” * 10 + “\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x31\xc9\x89\xca\x6a\x0b\x58\xcd\x80″‘)

Here’s a diagram of it broken down:troll24

So you notice that memory address of ESP is backwards. That’s because of the endianness of the processor. I won’t get into that, but little endian reads memory “backwards”.

I then run my payload:


And privileges have been escalated.

Exposing Phishers via Bad OpSec

I got a phishing email at work forwarded to me and was surprised it got through our filter. Looking at it, it was an email with the subject line “Confirm your identity” with an .HTML attachment.


Opening the .html attachment up shows a pretty legit looking PayPal page.


I put in some bogus info and hit continue


Really? My SSN? If you say so


Hitting “Continue” then presumably submits the phished data and then redirects you to the actual page, so the entire thing seems legit.

Let’s dissect this a bit further.

I’ll use Burp Suite to see where this .html file is actually sending stuff to.

Immediately upon opening the .HTML file, it sends a connection request to what is presumably a compromised website. (Actual URL and names will be blacked out)


After filling out the .HTML form and clicking continue, I see it sends the data as a POST request to a PHP file


But going to that .PHP file redirects to, so I decided to look at the directory it was sitting in, /lm/


Oh boy.

So the attacker failed to practice good OpSec and indexing is allowed. I download the “Jokapo Team VBV Scam” .Zip file

Inside I find a few files


Including kapos.php, which is the .php file that takes the POST request data.


And now your .php code is exposed…

Looking further I see that it opens a .txt file and writes to it


But I swear I’ve seen that .txt file before


Oh no….



So he is storing the harvested, phished, data in a plain .txt file that is accessible to anyone. But wait, there’s more!

So, to test out their scam, the scammer used their real gmail account


So what do we do with any scammers email?

We sign them up for and



As well as signing up for free spam email


And then of course reporting him to Google.



Moral of the story: If you’re going to phish people, at least be good at it…

The owner of the compromised website was also contacted but the site looks like it was last updated in 2014, so I doubt anything will happen there.