Six (or so) Quick Wins for Security

October 9, 2017

The majority of clients that my company does pentesting for tend to be smaller businesses with perhaps 150 to 1000 employees, so most of them do not have a dedicated team focused strictly on “security.” It may be a small part of one or two people’s jobs, but generally there isn’t someone tasked with overseeing the security plan or day-to-day details.

Sure, the CIO or IT Director is technically in charge, but they have a million other things to worry about. But one thing that I hear frequently on pentests is “…but you didn’t find anything major, right?” Usually this follows a discussion of how I, or someone on my team was able to escalate to domain admin and pillage their network at will.

While no, perhaps one finding on its own isn’t earth-shattering, a few low to medium findings can easily lead up to a compromise. Take LLMNR and NBT-NS for example…there hasn’t been a pentest yet where I’ve found that either was disabled. You then walk the client through how you managed to capture/crack hashes or get plain text credentials via WPAD poisoning and you see their interest peak a bit.

Then, you explain how you took those user credentials, connected to their sysvol share, and because they had a password stored in a GPP file, you were then able to get DA access (because of course it was a DA password) and went about your business of finding the important stuff (because you didn’t just stop once you got DA, did you?)

So after reviewing other findings with the client, that’s usually when I hear the “…but you didn’t find anything major, right?” This consistently baffles me. What qualifies as major? My typical response is something along the lines of “Well, getting domain admin access isn’t really a good thing…but let’s talk about it.”

None of this is really new or earth-shattering news, but I guess the point of all of this is that we need to constantly be aware of “all the little things” that go into securing our environments. Yes, that’s what clients are paying us for…to find these things and to make recommendations, but death by a thousand paper cuts is still death.

With that said, here’s a list of quick (generally easy) wins to help tighten things up a bit. (In no particular order)

  • Disable LLMNR and NBT-NS
  • Disable SMBv1
  • Configure a DNS entry for WPAD that points to your current corporate proxy
  • Verify Null Sessions are not permitted to your domain controllers
  • User education (easier said than done, I know…)
    • Password length >= 15 characters
      • No complexity requirements
      • The longer, the better…but at least 15 characters.
    • Encourage the use of password managers, and how to properly secure them
  • MFA/2FA (also easier said than done, but worth the headache)

I’m sure there are other tasks that are relatively easy, but this isn’t intended to be a comprehensive list, just a basic list of quick wins. None of them alone will stop someone with the knowledge and determination, but can make it more of a challenge.

My PWK/OSCP Review

September 16, 2017

Since all the cool kids are doing it, I figured I would try and offer some input on the PWK/OSCP course and certification. There are, of course, already a ton of great reviews out there, but perhaps you’ll find some value in mine.

I signed up for the Penetration Testing With Kali Linux (PWK) course in May, which ultimately leads you to the Offensive Security Certified Professional certification once you pass the lab exam. The registration process was simple and straightforward, but note that you may not be able to start the course immediately upon registration. There is some waiting period before you will be given your course materials and lab access, but it’s seems to be usually not more than 2-3 weeks.

A few things to note:

  • You must sign up under a corporate email, otherwise there is an ID verification process (no gmail, etc.)
  • For what it’s worth, Outlook/O365 kept marking Offsec’s material as junk, so adjust your filters accordingly

Training Materials

Once the time came for the class to begin, the email arrived with a link to download my materials. Included in a 300+ page PDF, as well as videos in mp4 format. All of the course material in the PDF was very well written, and mostly straightforward. The buffer overflow section is enough knowledge to get your feet wet, but one that I feel could use a bit more content. Either way, I really enjoyed working through each exercise and the videos really help clarify points that the PDF may have glossed over…if there are any of those!

Lab Access

You can purchase either 30, 60, or 90 days of lab access with your order. I strongly recommend ordering the 90 day option, unless it is prohibitively expense in your situation or you have the ability to dedicate full-time study to this endeavor. I had a pretty broad background in development, systems, and networking prior to the course, and while that is not completely necessary, it does, of course, help. With a full-time job, and offspring to factor in, I managed to spend roughly 2 to 3 hours per evening in the lab, along with anywhere between 8-16 hours per weekend. If you are able to dedicate full-time hours to study/labbing, you might be able to knock it out in 30 days, but again, I recommend the 90 day option if possible.

You are emailed instructions on how to access the lab environment, along with your VPN connection information. Once you access the lab, you are given access to your PWK control panel which allows you to reboot the machine you are about to attack to ensure that it is not in a bad state from the previous attacker, or if you fire off an exploit and it fails, you might want to revert after that to ensure the service you were attacking is operational. It’s not always necessary, but something to consider if you are not getting the results you are expecting from your exploit.

The general consensus from what I’ve seen is that if the lab machine has been reverted in the past five (5) hours, as a common courtesy to your fellow labbers, pick another machine to attack for the time being. It’s more than likely that machine is being actively exploited. The intent of the lab is to mimic the real world as much as possible, so someone rebooting one of your machines while you are working on it can, and absolutely will happen…probably at the worst time as well.

Make sure you keep detailed and comprehensive notes to that in the event someone reboots the box you’re working on, you can easily replicate the steps to get back to where you were. More on note taking in a minute…

There will be some machines that can be directly compromised, and some that may require information obtained from other boxes in order to be broken. Enumeration, as well as post-enumeration is key. Yes, you will get sick of the E word. Someone will most definitely tell you to “enumerate more.” You’ll get sick of hearing it over and over. However…they’re right, as much as it sucks, they’re absolutely right.

Another quick note: do your best to not become dependent on Metasploit. Learn it, use it, but don’t let it become a crutch because you can only use it on a single host in the exam. I managed to root every host in the lab except one without using Metasploit. You can do it.

A Note on Enumeration

So you think you can enumerate? So did I. You can’t. I couldn’t. It’s very easy to overlook information on a server that could be valuable to further your attack, be it on the current box you are attacking, or a box in the future. Dig through each directory you find. Dig through the subdirectories, their subdirectories, etc. Have access to someone’s mailbox? Read every message. Who are they talking to? Did you check sent items? Did you find some odd looking file in a random directory? What does that file do? Is there valuable information in that file? What software packages and what versions are running on the box?

The object of enumeration is to learn as much about that box as you possibly can. Once you feel that you’ve done that, take a look at your notes, what you’ve found, and determine if there is  any vulnerable software on the box, or if there might be a hint buried in that text file you found on someone’s desktop. Keep digging, and don’t stop. I can count at least 5-8 servers that I could’ve easily at least gotten a low-privilege shell on very easily had I enumerated more thoroughly on previously compromised hosts.

You can automate as much of the enumeration process as you want, but I would suggest doing it manually at first to ensure you aren’t leaving any stone unturned. You’ll might want to automate some of it for the exam. I found that my preference was to do initial enumeration manually. There are very detailed enumeration guides available, such as this one, but I found that coming up with a smaller task list was better for me. YMMV. Take your time in the lab, and learn, then refine your process. You can automate later once you have a good enumeration process.

Here is my enumeration template that I used as a base:

[x.x.x.x is the IP of the host you’re attacking]

All Hosts:

  • NMAP: nmap -A -p- -oA hostname x.x.x.x #hostname will be the output filename that -oA uses to write the file to disk
  • Unicornscan: unicornscan -mU x.x.x.x

Web Servers

  • nmap -sS –script=http-vuln* x.x.x.x -p 80
  • nikto -host x.x.x.x -F txt -o hostname.txt
  • curl -I http://x.x.x.x
  • curl -v -X OPTIONS http://x.x.x.x/directory
  • davtest -url http://x.x.x.x/webdavdirectory (Do for each directory found – webdav might not be enabled on root directory)
  • gobuster -u x.x.x.x -w /usr/share/seclists/Discovery/Web_Content/common.txt -s ‘200,204,301,302,307,403,500’ -e
  • DirBuster using the /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt wordlist
  • curl http://x.x.x.x/robots.txt

SMB Servers

  • enum4linux
  • smbclient -N -L \\x.x.x.x
  • nmap -sS –script=smb-vuln* x.x.x.x
  • smbmap -H x.x.x.x -d SMBDOMAIN -R -u anonymous

NFS Servers

  • nmap –script=nfs-showmount x.x.x.x -p111 #See what directories are presented
  • rpcinfo x.x.x.x -p | grep nfs

SMTP Servers

  • smtp-user-enum -M VRFY -U /usr/share/metasploit-framework/data/wordlists/unix_users.txt -t x.x.x.x

This was my basic enumeration. There are a thousand more things that I could add, but this was a good start for me.


A Note on Notes

Everyone has their preference on a note-taking app. Find what works for you, and use it. Make it work for you. I used OneNote…not the best, not the worst, but once you have a system/method for keeping and maintaining notes, use it and sharpen it. The point is, KEEP. THOROUGH. NOTES!

Here was my basic note-taking template:

Basic Info

  • OS/version
  • Webserver/version
  • Mods
  • Application Server/version
  • Sudo Version
  • SSH Version


NMAP Output

nmap results

Service Interrogation

Probe unknown services with nc and note the results

Nikto Output


Gobuster Output


  • What exploit did you use
  • How did you use it
  • URL?
  • Modifications to the code that were needed

PostEx Low-priv

Did you get  a low-privilege shell instead of a root shell? Dig around. ENUMERATE! Put that output here.


Similar info to exploit section

PrivEsc Root/Admin

Are you sick of enumerating yet? Yeah? Do it again!


Lab Exam

I won’t/can’t go into significant detail about the exam of course, but I have to say that it was completely fair. Difficult, but fair. They give you almost 24 hour access to a smaller number of boxes with specific point values each, and you attempt to compromise them. You get enough points, you pass. You all know how that works.

Take screenshots. Take more screenshots, then, take some more. No, you may not have to use all of them, and Offsec lays out their screenshot and documentation requirements quite thoroughly. By default, Kali saves screenshots with the date and time in the filename, so it helps that they are laid out in a chronological order. The last thing you want is to root the box, but forget to document the process, then you realize it once your VPN connection drops. I *thought* I did that, but it turns out I hadn’t. Major pucker factor.

Once you’re done (hopefully) passing the exam, then comes the lab report. You must document your attacks step by step, and meet very specific requirements. If you don’t, you’re kind of screwed, as once your VPN access drops, there’s no going back to get that screenshot you missed. Read and review the requirements thoroughly. Very thoroughly.

Don’t get bummed if you don’t get it the first shot. I didn’t. Many others didn’t. I pretty much guarantee that if you fail the first time, within a day , you will have a good idea of what you missed. Keep at it.

Closing Thoughts…

As many others have said, the PWK/OSCP was full of pain, but by far, one of the most fun and interesting courses/exams I’ve taken. You will need to put in extra work outside of the PDF and videos. I highly, highly recommend learning as much about privilege escalation as humanly possible. Getting a low-priv shell is usually relatively easy. Honestly, Windows privesc killed me. Coming into this, I would’ve thought that Linux would’ve been harder to escalate…not so. Again, YMMV, but that’s just my humble opinion.

I’m starting to get lab withdrawal now, which is apparently a pretty common occurrence! I signed up for OSWP, and am eagerly awaiting those materials…time to try harder, again.

Reference Material

Just a collection of links that I found useful during this process.

SUID/GUID explained:

Path Traversal Cheatsheet:

The famous g0tm1lk linux privilege escalation guide

The famous FuzzySecurity Windows privilege escalation guide

Breaking out of jail

Various tips/tricks/etc.

Big list of Windows privesc guides:

SecuritySift’s ReconScan (and OSCP review)

Good luck in your studies!