Author Archives: ch1kpee

About ch1kpee

I hack for Cthulhu, sweet Hexley (OSX/Darwin mascot) avatar by @datapacke7

Taking A (Password) Hint

UPDATE: As of macOS 13.0 Ventura, it seems that password hints are no longer visible in dscl, unless you use the -u flag to authenticate as the user or else run it as root.

Recently on a red team engagement, I was given access to a customer environment via a MacBook Pro set up inside their corporate environment. To simulate a compromised machine, the customer ran my payload on this Mac (in this case, a JXA-based Mythic Apfell payload) and it phoned home to my C2 server. This is what’s commonly known as an “assumed breach” scenario.

In this case, the infected laptop was plugged into the office LAN, had the sleep function disabled, the screen locked, and was left sitting on a desk. From simple enumeration on the device itself, I knew the account whose context I was running in had sudo privileges (in macOS world, it was a member of GID 80, the admin group), but my customer point-of-contact hadn’t told me the password. I’m sure they would’ve told me the password had I asked, but I decided to go for realism and try to escalate privileges myself.

As this was basically a computer left by itself with no victim interacting with it, I wasn’t going to get the password via keystroke loggers or fake password prompts. There also wasn’t much in the way of user-created documents on the system to search through for credentials and it was running the latest version of macOS, with no publicly-known privilege escalation exploits either. I even tried some light brute-forcing via Apfell’s test_password function with common passwords to no avail.

One thing that did stick out in my mind was that the username of the compromised account I was running in was just the client company’s name, so it was a good bet this was a shared account, and employees usually don’t commit these sorts of credentials to memory. A feature of both the macOS and Windows GUI login screens is the “password hint” function, to jog a user’s memory. And while both OS’s are configured to not allow you to just put your plaintext password in that field, users often cheat and just give it away with slight modification. In the example below, the John Doe user has a password of simply “password”, and to get around the OS restriction, the hint is in pig Latin.

But I wasn’t sitting physically in front of this victim laptop and I otherwise had no access to the GUI, so I googled furiously for a way to see the user’s password hint from the command line. I actually came up empty-handed in my search, but ended up finding the answer almost by accident while enumerating other info on the system

Viewing Password Hints in macOS

By default, macOS uses its own LDAP implementation to store all user and group data, even just local accounts. The dscl utility can be used from the Mac terminal to interact with this directory service. One of the things you can do with it is view the LDAP data of any account on the system. And one of the values stored in users’ LDAP profiles is their password hint!

You can easily read it with the following command: dscl . -read /Users/[USERNAME] AuthenticationHint

Just to reiterate, as an unprivileged user, you can via the LDAP data of any other user on the system, so this also could be useful for lateral movement.

Sure enough, the account I was using had a password hint that made guessing the real password trivial, and I finally had root-level privileges on the machine!

Viewing Password Hints in Windows

Windows has also had a password hint system since Vista, but (unfortunately for pentesters and red teamers) it’s much better protected than it is in macOS. The password is stored as part of a Windows user’s data in the SAM hive and is only accessible by the NT AUTHORITY\SYSTEM user.

If you have SYSTEM-level access to a box, password hints could still be useful. Maybe its a shared account that doesn’t have administrator privileges (so you can’t just pass-the-hash with the user’s NTLM hash you could otherwise steal out of the SAM), but the same username/password might be reused on different machines that have RDP or SMB file share access enabled.

To view a user’s password hint, you can enter the following into a SYSTEM-level cmd.exe or PowerShell prompt: reg query HKLM\SAM\SAM\Domains\Account\Users\[USER ID] /v UserPasswordHint

The user ID will usually start with “000003” and then two additional hexadecimal numbers. The hint itself is stored as ASCII hex, padded with 00’s in between letters. In the above example, the hint decodes to “the usual”.


In macOS, administrators can disable password hints from showing at the GUI login screen, but unfortunately this information is still recorded in users’ local LDAP information if they’ve set a password hint for themselves. Also, as far as I can tell, there isn’t any way to disable local password hints in Windows either.

But this is mostly a problem with local accounts. In both macOS and Windows, network logins, such as to an Active Directory domain, won’t even offer the option of password hints. For IT staff that might have local-only shared accounts on systems, it’s important to educate them on the dangers of using password hints and encourage them to use more secure solutions for sharing credentials instead, such as a password management platform.


My Red Team Everyday Carry (EDC)

I was inspired by a few past videos done by such YouTube physical security personalities as the Lock Picking Lawyer, DeviantOllam, and the Not So Civil Engineer and thought I’d share some of the things I tend to have in my pocket every day that can be used for red teaming/physical security types of activities.

The goals of my everyday carry (EDC) are roughly:

  • functionality: things I’ll actually use
  • lightness: things that don’t take up a ton of pocket space and don’t weigh a lot
  • TSA and government facility friendly: things that aren’t illegal to take on a plane or into a courthouse, so that rules out anything with a knife in it
Almost everything I carry on me, minus a face mask, wristwatch, and my wedding ring. Key bitting redacted.

Gerber Shard

The Gerber Shard is a great little tool to keep on your keyring, even if you aren’t into physical security or locksport. It can function as a:

  • Pry bar
  • Small flathead screwdriver
  • Large flathead screwdriver
  • Philips screwdriver
  • Wire stripper and puller
  • Bottle opener (probably what I use it for the most)
  • Bonus: the pry bar side can also be used to cut open the seals on boxes and other things

And since there’s no knife blade or saw on it, it won’t get confiscated by TSA. I’ve had one on my keyring for years. I only recently replaced one I’d used for close to ten years because the bottle opener was getting worn out. I have an unpainted metal one, but it’s also more commonly available in black.


I feel like this is a pretty obvious one. Besides being a communications and Internet access device, modern smart phones come pre-equipped with plenty of useful apps that can make your phone function as a flashlight, level, measuring stick, distance finder, camera for light surveillance, and much more.

While my daily driver is an iPhone, a rooted Android phone or even one with the Kali NetHunter tool suite installed would offer tons of red teaming functionality on the go. If you’re really simulating an adversary and trying to do zero-attribution, it could even be a prepaid burner phone.

One iOS tool that not a lot of people know about is the old AirPort Utility app. I’m not sure how much longer it’s going to be around, since Apple discontinued its AirPort line of Wi-Fi routers in 2018, but it offers a simple Wi-Fi scanning tool you can use from a non-jailbroken iOS device!

While it’s not as feature-filled as something like Kismet or some of the Wi-Fi scanning tools available for rooted Android (for example, it can’t sniff and unmask hidden SSID’s), it’s great in a pinch if you’re trying to hunt down an AP’s physical location. It can even export a text file of the scan results.


I have a very light Bellroy Note Sleeve wallet that I’ve been using for years. It offers a great balance between being able to carry a lot of stuff, but a nice slim profile so my butt isn’t sore after sitting on it for a long time. It has three slots for the cards you use most frequently (for me, my drivers license and two credit cards), plus an inner sleeve where you can throw your less-used cards, such as my insurance card, Sam’s Club membership card, etc. Though I don’t have any on me at the moment, if you’re going zero-attribution, it’s not a bad idea to carry around some prepaid credit or debit cards, and of course cash, for clandestine purchases.

I don’t own a ProxMark or do RFID attacks very frequently, but if you do, it might also be worth carrying common RFID card blanks or even a diagnostic card like the Not So Civil Engineer does.

Lock Picking Tools

In the aforementioned inner sleeve, I have a small vinyl holder where I keep an assortment of various lock picking and bypassing tools.

At the moment, I’m carrying around:

As trendy as Bogotรก picks are, I honestly pop locks way faster with the traditional snake rake, which is why it’s a must-have for me. It’s come in handy on more than one real-life occasion, such as one time when my wife and I were locked out of an old rented condo, or when I used to teach a pentesting course at a local community college and they never unlocked the door to my classroom before I arrived.

I could probably strip this down even more, or swap out some of the tools for different ones, but it fits fine in my wallet so far without adding too much bulk. If you’re asking where the hooks and half-diamonds are, I leave those out in favor of rakes because I’m going for speed. If it takes more than a minute to rake, it’s probably not worth pursuing further. Plus, I suck at single-pin picking anyway.

Door Shim

I got this idea from the Not So Civil Engineer. I have a set of oversized super mica door shims in a fancy pouch that I bought off Sparrows years ago. One of the sheets I cut in half and folded over to make a roughly card-sized door shim that I stuff into the banknote pocket of my wallet. The corners are super sharp and I highly suggest you also use scissors to round them off, so you don’t accidentally slice your fingers the next time you’re reaching for your cash.

What this tool is used for is sliding between the doorframe and a locked door and popping open the latch, assuming it either lacks a dead latch or the door isn’t properly installed. The doorframes in my house are very tight, but this shim can still manage to easily slide in between and pop latches open. It does scratch mine up a bit, but these shims are cheap, easy to make, and made to be disposable.

Using the Sparrows mini jim as a guide, I also cut a little notch in one side of my shim so it can double as a jim for external-opening doors as well. I’ve considered making a larger notch, to approximate a Sparrows “hall pass” or “flex pass” jim, but I’m usually quicker and feel I have better control with the small notch. I might also just buy a flex pass, or make my own out of another piece of super mica shim material, in the future. Though I prefer a traveler hook, a shim with this modification is much more portable.

I hope you enjoyed seeing my EDC and I hope it gives you some inspiration for figuring out what tools you could be carrying with you on a daily basis!

My AWAE / OSWE Experience

**UPDATE 7/17/2020**: OffSec has just updated the AWAE with a few more modules and lab machines, but at the same price point.

Back around Christmas, I took advantage of a rare sale to sign up for Offensive Security’s Advanced Web Attacks and Exploitation (AWAE) course, which is the training for the Offensive Security Web Expert (OSWE) certification. Just last week, I got my congratulatory email letting me know that I’d passed the exam and earn the cert!

This is a course I’ve been wanting to take for a very long time. Previously, it was only available as in-person, which usually meant you had to race everyone to sign up for it at Black Hat in Vegas or you had to pay a hefty premium to bring OffSec trainers in-house. I tried to get them in-house several years ago at a previous employer, but the price tag was too high for my management then. I do know of several lucky bastards at another consulting firm who got to take it privately in the US Virgin Islands years ago. But thankfully for the rest of us, the long-standing rumors finally proved true and OffSec decided to offer it as an online course last year.

So What Was AWAE Like?

The course is a very different experience from PWK / OSCP, I’m assuming that PWK hasn’t changed that much since the big update recently. In PWK, you’re put into a shared lab environment with many other students, given minimal guidance, and told to go nuts. It’s very much a “throw you into the deep end of the pool” approach to teaching you how to swim.

By contrast, AWAE is much more guided. You get your own lab environment via VPN, no having to share with other folks and worry about screwing up someone else’s work or having someone reset the machine you’re working on mid-exploit. Your lab consists of a small number of VM’s hosting web apps, all of which you have root credentials to right off the bat! That might strike you as strange, but the point here is to teach you how to do code-assisted web app pentesting, and the easiest way to do that is to give you an application where you can read its source code and debug it as it’s running. The VMs represented a fairly diverse range of web apps and technologies, including PHP, .NET, Java/Tomcat, MySQL, PostgreSQL, and Node, with both Windows and Linux web servers represented.

The course PDF and videos will run you through each application, showing you exactly where the flaws are in the code, why they work the way they do, how to debug them, and how to build a proof of concept script to exploit them. You’ll learn about using an editor to set breakpoints, decompiling applications to see the original source, turning on logging in the relevant SQL engine so you can see just what’s happening on the backend when you send an SQL injection payload, and more. The end goal of each module/machine is to get remote code execution (RCE) and a shell on the box. Along the way, they cover a pretty good gamut of common web vulnerabilities, including XSS/CSRF, code injection, bad crypto implementations, lots of blind SQL injection, and deserialization.

But it isn’t all easy step-by-step instruction-following. While the PDF and videos will show you exactly how to write a proof of concept (usually in Python or sometimes JavaScript) to exploit the main vulnerability being taught, every module has various “Extra Mile” challenges scattered throughout. The “Extra Mile” challenges provided some additional difficulty, and will ask you to do such things as find additional vulnerabilities in the code and exploit them, rewrite your proofs of concept to take advantage of a different technique, etc.

Because of the much more guided nature, and probably because I’ve already been doing web app pentesting for several years now, I only signed up for 30 days of lab time and I found it very doable in that time frame. You can, of course, sign up for longer lab times or extend your time at any point. But whereas I’d tell anyone doing OSCP to just go ahead and buy the full 90 days, this one can be done in 30 days if you have time every evening and weekend to devote to it.

So What Was the Exam Like?

I was done with the labs by February, but I had to schedule all the way out into May to find a block of days that I liked. The exam/lab access time is 48 hours (ok, technically 47 hours and 45 minutes, but whatever) long, plus an additional 24 hours to write and submit your report. I chose a block starting at 8 AM on a Thursday, so I could have that day and Friday to do the exam, Saturday for report writing, and Sunday to rest before having to go back to work.

Like PWK, this exam is now proctored. This means you’ll have to use a webcam so they can see you and the room you’re in the whole time (though they aren’t listening to you, so a microphone isn’t required). About fifteen minutes before your exam starts, you should login to the proctoring website with the credentials OffSec will provide you, install a browser extension, and share your screen with them the whole time. As you’re probably using a Windows PC or Mac and just running Kali in a VM, you’ll need to do this from the host OS. You’ll share all your screens and they’ll be watching to make sure you aren’t cheating or violating the exam rules. Whenever you need to take a break, you just have to send them a message in the chat of the proctoring website when you leave and when you return. It’s a little weird knowing you’re being watched the whole time, but it didn’t really bother me that much or impact how I would’ve done the exam otherwise.

Before you start, you’ll also have to show them a government-issued photo ID via your webcam and they’ll probably ask you to slowly pan the room so they can see and make sure no one else is in there with you helping you cheat. I hope you buy a better webcam than I did; the cheap Logitech one I got on Amazon to sit over my external monitor couldn’t focus on my ID, so I had to open the lid on my docked Macbook Pro and use it’s webcam in order to prove my identity and get started.

Once you start the exam and connect via the VPN, you’ll be in a private lab network with your challenges, much like in the OSCP exam. The challenge VMs are there for you you to break into and find flags to prove you breached them, also like the OSCP exam. But for each challenge VM, there will also be a debug VM with the same software that you’ll be given SSH/RDP credentials for; these are for you to review the code on, debug, develop your POCs, and eventually use against the challenge VMs to hack them for real. You’ll also be given access to a spare Kali VM inside the exam network. If your VPN connection is really slow or you run into any latency issues with your exploits, you can run them from this spare VM instead. One important caveat: the spare Kali VM in the lab has the default collection of Kali tools, but it doesn’t have an internet connect. So if your POC is using any exotic libraries or packages, you’ll have to SFTP them over and install them yourself.

Each challenge has a means of bypassing authentication/authorization to allow you to access it as a privileged web app user. Doing that will reveal a local.txt hash value that you can submit for points. After that, there is an RCE vulnerability somewhere in the app that will allow you to get a shell on the box, at which point you’ll be able to dump the contents of a proof.txt file for more points. There’s a total of 100 points available in the exam lab, with 85 points considered passing. In addition to submitting the hash values, you have to write a detailed report showing your work and explaining how you found and exploited the vulnerabilities, the source code for your exploit proof of concept, and screenshots showing the proof hashes. Your exploit code can be in any language you like, but realistically most people are going to be using Python, as it’s the script most commonly used in the course material itself. I did all of my exploit code in Python for the course and exam.

This exam felt very different than the OSCP exam. For one thing, the 48-hour time limit felt a little less imposing than OSCP’s 24 hours. At least for me, I didn’t feel as bad about taking breaks to rest, eat, sleep, de-stress, etc. Another thing that felt different is just the nature of code-assisted pentesting. When you’re doing an OSCP-style network pentest, you’re basically feeling around blindly in the dark, looking for a secret passage to treasure. You’re scanning and enumerating everything, trying to find what kind of software is there, what the version is, if that software/version has a known exploit against it, if it has default credentials enabled on it, etc. A lot of “black box” testing ends up being throwing shit against the wall and seeing whether it sticks or not. In a code-assisted test, all the knowledge is right there in front of you, nothing is hidden…it’s up to you to put the pieces together, find where the flaw is, and exploit it. In that respect, it feels much more like it’s your own fault if you don’t find the holes in the code.

My first day of exam-taking was stressful. I’d already told myself I’d switch to other challenges after a few hours of looking at one and getting nowhere, and that I would take regular breaks and not burn myself out. I followed my own advice, but by the evening I had no points and no clue how to progress. I’d actually resigned myself that I was probably going to fail. But I wasn’t just going to give up and quit right there, I decided I would still try to learn something from it, even if I failed. Strangely, this embrace of the possibility of failure cleared my head and lifted some of the stress of me. I approached the challenges more clearly and calmly, and by about 1 AM, I’d made some serious progress!

At that point, I crawled into bed and set an alarm for the morning. The next day, I kept grinding at, still feeling certain I wouldn’t get enough points to pass. To her credit, my wife always believed me and kept reassuring me, “You’re going to ace it!” By the late evening, I’d actually solved enough to get a passing score. I was still a little nervous about just getting the bare minimum, so I decided to look at it a little longer. To my delight, the RCE route for the final challenge jumped out at me immediately and my first attempt at a payload worked! I spent the next few hours cleaning up my exploit code, running it several times against the freshly-reverted challenge VMs just to make sure it always worked, taking all the necessary screenshots needed for the report, double-checking the proof hashes and that I’d submitted them on the control panel page correctly. Around midnight, certain I’d done everything I needed to while I still had VPN access to the exam lab, I packed it in and went to bed.

I spent the next day writing the report. I feel like this report took longer to write than the OSCP one, despite having fewer overall challenges, as I went into a lot more detail on them, showing how I deciphered the code and traced it to find the various vulnerabilities and exploit them. That evening, I zipped it up and submitted it, as per the exam instructions.

Several days of nervous email-checking later, I finally got the congratulations email!

Was AWAE / OSWE Worth It?

Unequivocally, yes! Even for someone who’s been doing web app pentesting for years, I got a tremendous amount of value out of it and it’s really inspired me to approach my own code-assisted pentests differently.

At my current job, it’s maybe 50/50 whether a client will give us source code access or not on an engagement. When we do get source, I don’t think I’ve ever seen anyone ask for actual SSH or RDP access to the web server that the test instance is running on. A lot of the times, our source access is via being added to a client’s Github repos. I have noticed there that many clients’ repos have Dockerfiles, docker-compose.yml files, and instructions for spinning up containers to run the applications.

This course has inspired me, going forward, to start asking clients for either access to the actual servers or help with building a container of the application, so I can do the sort of hands-on debugging and testing I was able to do in the AWAE course. It really makes a difference when you’re trying to build exploits for frustrating stuff like blind SQL injection.

For someone who isn’t as experienced in web app pentesting as me, this is a great introduction to doing code-assisted tests. However, one thing it doesn’t teach you is a methodology for searching/fuzzing for vulnerabilities when you don’t have source code access. So if you’re interested in doing closed source bug bounties, this course might not help you out that much.

AWAE/OSWE also covers such different ground than PWK/OSCP that having that certificate isn’t really a prerequisite for taking it. There was one part of my exam where I felt like my previous OSCP and network pentesting knowledge helped me out, but otherwise the knowledge needed for the exam is all in the domain of what you’re taught in the course.

Tips for AWAE / OSWE Success

To be honest, I didn’t really do a lot of extracurricular reading. I read the course PDF, watched all the videos, and did all the “Extra Mile” challenges, and that proved to be enough for me. But I might be a different case because I do have a few years of web app pentesting under my belt already. If you’re coming into this extremely new, I’m not sure what to recommend. Wetw0rk’s GitHub repo and Z-r0crypt’s blog are the only two outside resources that I saw recommended and I briefly looked at, so you might want to check those out too. Other than that, here is some advice I’d offer to anyone wanting to take the AWAE course and OSWE exam…

Do all the “Extra Mile” challenges: this is probably the best way to push yourself further and get ready for the sorts of challenges that the OSWE exam is going to throw your way. The AWAE forums are really helpful here if you get stuck, because the “no spoilers” policy means people won’t give away the answer, but reading posts usually gives you just enough clues to figure out whether you’re heading in the right direction, if you need to read a little more on specific subject to finally grasp the answer, or if you’re likely off on a wild goose chase and need to change your approach.

Use a good text editor that can open and search whole folders: examples of this would be Notepad++ or Sublime Text. With either of them, you can open the folder containing your target web app’s source code and search it all simultaneously for things like SQL queries, page names, functions, and other pieces of text to help you find vulnerabilities and piece together how the application flows. Both have or offer plugins with the ability to do things like hover over a function name in a file and get a link to other usages of it, the file it’s defined in, etc. For me personally, Sublime Text was probably the single most valuable tool I used for the course and the exam.

The exam guide notes that the search functions in some tools, like dnSpy and JD-GUI, aren’t great and could lead to you missing things, so don’t rely on them. You could use an IDE if you really want, like Visual Studio Code, but I find text editors less distracting and better suited for searching, with stuff like regex support. Hell, if you’re really hardcore, you could just use grep or vim, I guess. I do tend to just use vim for writing actual exploit code.

Save all your scripts from AWAE and reuse them for your exam: when I went through AWAE, I would make separate script files for each exercise in a module, even though they mostly just build on one another, just so I could have that progression documented. It’s also good insurance if you change stuff too much from one exercise to the next and need to go back to a last known good script.

They saved me a ton of time on the exam too, because I could just reuse the snippets I’d already wrote and not have to reinvent the wheel when it came to some complex nested loop for enumerating this or that. Even though you have two straight days to complete it in, your time is still precious and the less time you have to spend writing and debugging your own exploit code, the better.

When I did the course, all of the code examples were in Python 2. Of course, that version has been officially retired as of 2020 and everyone has been urged to migrate to Python 3. For the sake of simplicity, and not having to waste time porting scripts, I just stuck with Python 2 for the course and the exam. I’m not sure what this is all going to look like for the course going forward. The Kali Linux team has already made a statement regarding Python 2’s end-of-life and how it’ll affect the Kali distro, so hopefully the course material will be updated and examples ported to Python 3 soon.

Get comfy with debugging, databases, and reading logs: reading the code is one thing, seeing how it actually operates is another. I find that set breakpoints, stepping through the code’s execution, and seeing how variable values change with a debugger is invaluable when trying to break down complex code, especially when it comes to stuff like encryption functions. I would advise any AWAE student to get comfortable using Visual Studio Code for debugging, as it’s cross-platform, supports multiple languages, and has tons of helpful plugins. It’s very easy to debug an interpreted language, like PHP or JavaScript, on the web server with VS Code installed. Also make sure you understand how to use decompiled code and attach to a running Java or .NET application in order to debug it in realtime (hint hint, I wasted some time struggling with that on my exam).

Also, understand how to use logs to your advantage, especially database logging. You’ll cover it in depth in the course, and it’s the key to successfully figuring out a payload for something like a blind SQL injection vulnerability. Turn on logging in the database engine so you can see what your injected queries are looking like on the other end, which part of the overall query they’re being inserted into, what characters are getting filtered, etc. Also, don’t be afraid to use the database’s command line tool to play with the DB directly and test out your queries. I personally like to make sure I have a working query there before I start complicating it by having to replace filtered characters with alternatives, nest it within something else, or any other transformations that might introduce other errors into the mix.

Get comfy figuring out SQL injection payloads by hand: you’re not allowed to use sqlmap on the exam, so make sure you understand all the various ways you can evade filters, substitute different characters for others (like comments instead of spaces, double dollar signs for single quotes, etc.), pick out substrings, use logical operators, etc.

As always, RTFM: in this case, I mean read the exam guide carefully and make sure you’re doing everything you’re supposed to. You wouldn’t want to make it all the way through the exam only to find you missed some important step you can no longer go back and complete.

It’s a marathon, not a sprint: I’ve seen several other folks say this about the exam, and I’ll reiterate it. You might’ve gotten away with plowing through the OSCP exam with no sleep (but I hope not); you cannot attack this one full-on for two days straight. You’ll go nuts, exhaust yourself, and start hitting a point of diminishing returns. Take breaks, get enough sleep, eat meals, and clear your head out from time to time. If one of the challenges is driving you nuts, go look at another challenge.

It’s OK if you it takes you multiple attempts: there’s a reason why OffSec’s training and certificates are much more revered among pentesters than a lot of other infosec certs. Their exams are hard! I had to take OSCP twice and I feel like I was kinda lucky that I got OSWE on my first try. Of all the folks I know who’ve taken OffSec’s various exams, I’ve known brilliant people who got it on the first try and I’ve known brilliant people who’ve had to take the exams four or five times before they got it. Sometimes it’s just the luck of what challenges you get on your attempt and whether they line up with your knowledge and skills. It’s OK to fail, as long as you learn from it and keep trying. OffSec’s motto is, after all, “Try Harder!”

Good luck on the course and your exam!

Derbycon 2019: Ending on a High Note

As most of you know, this year was the ninth and last Derbycon security conference in Louisville, KY. It was especially bittersweet for me, since it’s my hometown conference…and I just moved back to the area last year, hoping to save some travel money by having a major infosec con right in my backdoor.

The Marriott was a little better prepared this year, though the bar and on-premise restaurant still seemed a little understaffed. I was a little afraid about getting enough tickets for all my friends this year, as I thought this being the final one would mean an even bigger interest in it. This really wasn’t the case, as I had enough tickets for everyone well before September and even knew people who were still trying to sell their spare tickets all the way up to the day of the conference.

Having already blown my corporate training budget on SpecterOps’s excellent Red Team Operations course early in the year (I highly recommend it), I didn’t have any money to buy training this time around.  Dark Side Ops 1 was the only one I was really interested in, having taken their also-excellent Dark Side Ops 2 at last year’s Derbycon.

Being the last year of Derbycon and having most of the Eversec crew in town, I once again reverted to being a CTF zombie.  The only talks I really went to were the keynote and one by Rindert Kramer, from NCC Group’s Fox-IT acquisition in the Netherlands, about his custom LDAP-based C2 channel.  I unfortunately didn’t get to see my friend and colleague David Tulis (@kafkaesqu3) give his presentation on COM hijacking, as it conflicted with my son’s Saturday morning soccer game.

After the keynote and a quick lunch, the CTF room was open for business and we staked out a big table for our ever-growing CTF crew.  Besides the core of former Fidelity Investments pentesters, we had some new friends joining the mix, like Ashley Templet from Avalara, Jack Halon (@jack_halon) from NCC Group, Jeff Macko (@jmacko) from Kroll, old friend but first-time Derbycon attendee Ping (@n0tl33t), and several new faces that our Virginian friend Erwin managed to recruit. If you’re trying to CTF with a big crew like this, communication and organization is absolutely key! Since you probably don’t want to discuss vulnerabilities and attacks too loudly in a room full of your rivals, you need an online means of doing all this. For us, we had a special Slack channel just for CTF discussions and a Trello board for organizing tasks, keeping notes, assigning stuff, etc. We’ve been using Trello for years on CTF’s (I think it was Ray who suggested it) and it’s crucial to sharing info and keeping from duplicating effort on the same challenges.

Like previous years, the first day or so is pretty miserable because of the initial flood of people and skiddies doing dumb shit.  The ESXi server that the CTF team was using to host the challenges even got purple-screened multiple times.  By Saturday, it was behaving much better and we managed to make a lot of progress.  In true CTF zombie fashion, most of us stayed up well past midnight banging away at challenges.  My friend and teammate Ray (@doylersec) was kind enough to let me crash in his room for the night.

The CTF was devilish as ever.  The overarching theme was a parody of Derbycon called “DerpyCon”…which is stealing valor from my buddy Kyle Stone (@essobi) and his old pre-Derbycon house party. There was another, even more expansive MUD than last year, that Ashley spent a ton of time getting flags out of (which can still be played for a few more weeks at

I was going to write up some of the challenges I personally participated in, but our old rivals “spicyweasel” (AKA Nettitude Labs) already posted their usual excellent write-up of the challenges…and they take many more screenshots and keep better notes than me.

But “spicyweasel” didn’t take home the top spot this time. After having chased them for years, Team Eversec managed to come out the winner! Like most of the competitors do every year, we once again donated our prize money to Hackers for Charity.

Thank you Derbycon for nine wonderful years! Thank you Derbycon CTF team for always putting on a great competition and inspiring all of us to put on our own CTFs at our companies and various local cons. And thank you to our rivals, like spicyweasel and SecureWorks’ “Illuminopi” team, for making every competition exciting, tense, and fun. We can only hope we can find another annual CTF as awesome as this one and play against all of you again.

How to Score Tickets to Your Favorite Security Conference (Now That Derbycon is Dead)

NOTE:ย For the last several years, I’ve been a master at scoring hard-to-get conference tickets, specifically for Derbycon.ย  I originally wrote this two years ago, but my Eversec teammates begged me not to post it.ย  I thought their fears of being outcompeted for Derbycon tickets were unfounded, but I honored their request.ย  Since Derbycon is over now, I’m going to reveal the secret to all of you!ย  These tips are easily applicable to any conference with limited and hard-to-get tickets, like Shmoo.

  • Follow the con’s Twitter account and turn on notifications for it: besides their website, Twitter is the main way most con organizers put out news. ย Following them, and especially turning on notifications for when they tweet,ย is one of the easiest ways to keep abreast of what’s going on, official sales times, etc.ย  Organizers will announce sales times and sometimes even extra sales or ticketing system tests, so you could always get lucky that way.
  • Submit something to the Call for Trainers, Call for Workshops, and/or Call for Speakers:ย I know this isn’t going to be the best option for everyone, but if you have some cool skill you think you could teach or some neat topic you can present on, submit it! ย If you get accepted, you automatically get a ticket and many cons will even give you an extra ticket for a partner/spouse/friend or even an honorarium. ย I’ve even gotten a ticket for Derbycon before just for being on their talk waitlist, in case someone didn’t show and they had to fill a slot.

Continue reading

Dark Side Ops 2 Review + Derbycon 2018


Being from the Louisville metro area (and recently having moved back with my family), Derbycon is one of the highlights of my year.ย  The general conference ran from Friday, October 5th, to Sunday, October 7th, at a brand new location, the Louisville Downtown Marriott!ย  Every previous year, the neighboring Hyatt has hosted it, but the move meant a bigger venue with more rooms for all the activities.ย  Despite more space, the Derbycon team actually decides not to significantly increase the number of tickets sold, in order to keep the smaller, more familial feel.ย  I really like this about Derbycon and the crammed, chaotic atmosphere is one of the reasons I haven’t been to DEFCON yet…though I think I’m going to finally make myself go to it next year, just to get one under my belt.

For only about a grand more than a con ticket, you have the opportunity to sign up for one of several excellent training courses that run on the Wednesday and Thursday before the conference.ย  And trust me, $1000 might sound like a lot, but this is a steal compared to what you’ll pay for courses like this at SANS or Blackhat.ย  Last year, I took @FuzzyNop’s Modern Red Team Immersion Bootcamp, which was very heavily focused on open-source intelligence (OSINT) gathering, selecting good spear phishing targets, and crafting convincing phishes.ย  This year, I went towards the more technical side of red teaming with Silent Break’s Dark Side Ops 2: Adversary Simulation.

Continue reading

NCC Con 2018 iOS CTF Solutions

I just returned from NCC Group’s internal North American conference, a nice respite from the cold East Coast to sunny San Diego.ย  I’m a remote employee, so it’s always a blast getting to hang out with my New York office coworkers and seeing awesome presentations from colleagues from across the country.ย  One of the highlights was the mini-CTF put on by Sid Adukia and Dean Jerkovich.

This CTF consisted of an iOS app bundle compiled to run on the iOS Simulator, thus able to run on any Mac with Xcode and not requiring a jailbroken device.ย  I’ve been doing iOS application pentests for years and it was really cool to see a CTF challenge using this!ย  This is the first one I’ve seen since DVIA came out years ago.

Perhaps the biggest challenge was the fact that this was a Simulator app.ย  Had it been an ARM-compiled iOS app that I could put on a jailbroken device, I would’ve solved a lot of these challenges in a few minutes.ย  Most of my time was spent googling for how to do stuff like dump the keychain or hook methods on the Simulator instead of on a jailbroken device.

I’ve been worried recently just what the future of iOS security is going to look like.ย  It seems we’ve been thrown a few bones in the last month, with Project Zero’s Ian Beer recently publishing the “tfp0” vulnerability and Jonathan Levin publishing LiberiOS, the first jailbreak for versions of iOS 11.ย  But fewer and fewer people are publicly releasing jailbreaks.ย  I don’t blame them either. Due to the enormous sums being offered by exploit brokers, many would argue you’re a moron for giving away million-dollar exploits for free.ย  Someday soon, those of us in iOS security testing might be forced to have our clients compile x86 versions of their apps for us and run them all in the iOS Simulator.ย  The good news is that a surprising number of the same tools and techniques you would normally use on a jailbroken device will also work with a Simulator app on macOS!ย  Some things don’t, but if you’ve ever chased the latest jailbreak and found that half the stuff on Cydia doesn’t yet work for your version of iOS, then you’re already used to life on the bleeding edge. Continue reading

BSides Raleigh 2017 CTF Write-Ups

Taking some inspiration from my friend, Ray, I decided I’d write up some of the solutions to the various challenges I saw at this year’s BSides Raleigh CTF (capture-the-flag) events.ย  And this time, I actually remembered to save some notes and screenshots!

This isn’t a record of every single challenge I saw, just a few that I thought were particularly interesting or noteworthy.


This was a simple one…which I like, because I suck at CTF crypto challenges.ย  The page was just these emoji spread out:

๐Ÿ˜ฎ๐Ÿ˜ฎ ๐Ÿ˜ฎ๐Ÿ˜ฎ๐Ÿ˜‘๐Ÿ˜ฎ ๐Ÿ˜‘๐Ÿ˜ฎ๐Ÿ˜‘๐Ÿ˜‘ ๐Ÿ˜‘๐Ÿ˜‘๐Ÿ˜‘ ๐Ÿ˜ฎ๐Ÿ˜ฎ๐Ÿ˜‘ ๐Ÿ˜‘๐Ÿ˜ฎ๐Ÿ˜‘๐Ÿ˜ฎ ๐Ÿ˜ฎ๐Ÿ˜‘ ๐Ÿ˜‘๐Ÿ˜ฎ ๐Ÿ˜ฎ๐Ÿ˜‘๐Ÿ˜ฎ ๐Ÿ˜ฎ ๐Ÿ˜ฎ๐Ÿ˜‘ ๐Ÿ˜‘๐Ÿ˜ฎ๐Ÿ˜ฎ ๐Ÿ˜‘ ๐Ÿ˜ฎ๐Ÿ˜ฎ๐Ÿ˜ฎ๐Ÿ˜ฎ ๐Ÿ˜ฎ๐Ÿ˜ฎ ๐Ÿ˜ฎ๐Ÿ˜ฎ๐Ÿ˜ฎ ๐Ÿ˜‘ ๐Ÿ˜ฎ๐Ÿ˜ฎ๐Ÿ˜ฎ๐Ÿ˜ฎ ๐Ÿ˜ฎ ๐Ÿ˜ฎ๐Ÿ˜ฎ๐Ÿ˜‘๐Ÿ˜ฎ ๐Ÿ˜ฎ๐Ÿ˜‘๐Ÿ˜ฎ๐Ÿ˜ฎ ๐Ÿ˜ฎ๐Ÿ˜‘ ๐Ÿ˜‘๐Ÿ˜‘๐Ÿ˜ฎ ๐Ÿ˜ฎ๐Ÿ˜ฎ ๐Ÿ˜ฎ๐Ÿ˜ฎ๐Ÿ˜ฎ ๐Ÿ˜‘ ๐Ÿ˜ฎ๐Ÿ˜ฎ๐Ÿ˜ฎ๐Ÿ˜ฎ ๐Ÿ˜ฎ๐Ÿ˜ฎ๐Ÿ˜ฎ๐Ÿ˜‘๐Ÿ˜‘ ๐Ÿ˜ฎ๐Ÿ˜‘ ๐Ÿ˜‘๐Ÿ˜ฎ ๐Ÿ˜‘๐Ÿ˜ฎ ๐Ÿ˜ฎ๐Ÿ˜ฎ ๐Ÿ˜ฎ๐Ÿ˜ฎ๐Ÿ˜ฎ๐Ÿ˜‘ ๐Ÿ˜ฎ ๐Ÿ˜ฎ๐Ÿ˜‘๐Ÿ˜ฎ ๐Ÿ˜ฎ๐Ÿ˜ฎ๐Ÿ˜ฎ ๐Ÿ˜ฎ๐Ÿ˜ฎ๐Ÿ˜ฎ๐Ÿ˜ฎ๐Ÿ˜‘ ๐Ÿ˜ฎ๐Ÿ˜‘๐Ÿ˜ฎ ๐Ÿ˜‘๐Ÿ˜ฎ๐Ÿ˜‘๐Ÿ˜‘ ๐Ÿ˜ฎ๐Ÿ˜ฎ๐Ÿ˜‘ ๐Ÿ˜ฎ๐Ÿ˜‘๐Ÿ˜‘๐Ÿ˜ฎ ๐Ÿ˜‘๐Ÿ˜ฎ๐Ÿ˜‘๐Ÿ˜ฎ ๐Ÿ˜ฎ๐Ÿ˜‘ ๐Ÿ˜ฎ๐Ÿ˜ฎ๐Ÿ˜ฎ ๐Ÿ˜ฎ ๐Ÿ˜‘๐Ÿ˜ฎ๐Ÿ˜ฎ

So I noticed right off the bat that there were only two emoji being used:ย ๐Ÿ˜ฎย andย ๐Ÿ˜‘.ย  My initial thought was maybe this was something in binary, but I was dissuaded from that because of the variable lengths of emoji strings.

The next thought was Morse code!ย  So I copied the emojis into Sublime, did a find/replace for each character, to get this:

.. ..-. -.– — ..- -.-. .- -. .-. . .- -.. – …. .. … – …. . ..-. .-.. .- –. .. … – …. …– .- -. -. .. …- . .-. … ….- .-. -.– ..- .–. -.-. .- … . -..

Running that through a Morse code translatorย yielded the message:


So naturally, the flag was TH3ANNIVERS4RY.

Continue reading

My Grand Tour of Pentest Interviews

Late lastย year, I began looking for a new job. ย Earlier this year, I finally got one! ย I was interested in branching out into the broader world of penetration testing and red teaming, with more external clients and more broadly-scoped sorts of engagements. ย This was something of a sell to prospective employers though. ย I do have close to a decade of infosec experience, but only a few years of that is pentesting and I’ve always been an in-house pentester doing mostly web app and mobile stuff. ย That means that I am something of a noob when it comes to breaking in from the outside; I’m familiar with a lot of the tech and methodology, just haven’t done a lot of it hands-on (outside of CTFs and stuff like that). ย I’ve been in the broader industry for a while, meaning my salary requirements are a little higher, and I absolutely wasn’t going to relocate again so soon after my last move for my old job.

All of this and extremely high demand for pentesters at the moment meant I went through A LOT of interviews. ย Some of them broke down over salary expectations. ย Some of them I quit early because I could tell it wasn’t what I was looking for. ย Some of them weren’t budging on relocation. ย One I completely hosed myself on because I bluffed too hard during the salary negotiation phase. ย At least oneย of them probably thought I was a complete dumbass.ย  But in the end, one employer won out and I’m now happily hacking clients, mostly from the comfort of my own home.

Besides having lots of experience beingย interviewedย for pentest jobs, I also have some experience inย interviewingย people for pentest jobs.ย  At one of my previous employer, I was involved in telephone screenings and in-person interviews of a dozen or so different candidates to join our team there.

Because I went through so many different interviews recently and have experience trying to assess pentest candidates, I figured that put me in a unique position to grade these different companies and throw in my own opinion on the best way to do it.

My intent is half to just be amusing for those who are curious about how different companies are interviewing people, maybe those trying to find out what to expect the next time they start looking for a new gig; but I’m also writing this and hoping that some recruiters and hiring managers will see this.ย  I hope this will give you some insight into how your competition might be assessing candidates, what you’re doing right in your own process, what you’re doing wrong, and how you could be doing it better. Continue reading