Tips for new (penetration testers) players

Suppose you’ve just started in the industry; congratulations and welcome to the shitshow. Here are some things to consider:

You are a consultant more than a hacker in this role; the computer side is essential, but you are ultimately attempting to play a game of explaining how wrong something is, while breaking that thing, and you get bonus points for actually breaking something of value.

Organisation

When dealing with your company/organisation/sweatshop:

They mostly all suck in different ways, but they’re usually in one of these flavours:

• Organisation size/headcount
  • A big place will have layers of policy you don’t want
  • A small place won’t have the budget you need for things
• Clientelle
  • Some shops will deal exclusively with different markets, and those markets can suck
• The work
  • Mostly a combination of clientele and your sales team (if they exist); some clients might want meaningful work, others may just want you to re-scan a website with Nessus.
  • A good litmus test is if the client base does their testing for compliance reasons or if they want to know if it’s secure.
• Culture / Incentives
  • Some shops are blatant sweatshops. Do not work at these unless you either a) they can pay you buckets of money and that’s what you want, or b) you don’t have other options, but you’re actively looking to make those options happen.
• The people *Figure out what everyone is like; the owners, the team you’ll be in, adjacent teams, sales, and management.
  • The sales team will almost always try to just sell things without understanding what they are selling. Sales teams like this are also ubiquitous.
• Average skill level
  • Most shops are interested in having a high body count over having more skilled people. These shops have odd incentives and can lead to some funky stuff - reports with alert(1) proof of concepts, vague executive summaries, etc.

Sometimes a large organisation will pretend it’s a small organisation when it comes to budget, but a large organisation when it comes to organising the smallest of things. This behaviour can be frustrating, but it is ubiquitous.

The best advice here is to realise that no matter where you go, your workplace will have silly things - different stupid things, but silly things all the same. Learn what silliness you can tolerate, learn what other shops are like, go where makes you the least unhappy.

Team

When dealing with your team:

• Don’t spam @general with hello/did everyone have a good weekend. Not only does this waste everyone’s time, but they’ll hate that interruption.
• When asking a question, don’t send ‘hi’ and wait for a response; ask upfront what you want to ask. (See: https://www.nohello.com/)
• Figure out what you’re trying to ask, look into it before you ask. There is value in understanding how to ask a good question.

Working in an office, working remotely

• Reject meetings with no agenda. Know what you’re going to, know why you’re there, only go to things you have or want to.
• When dealing with meetings involving too many people (I.e. All of them), consider the cost of the meeting.
  • Especially consider the average staff salary in the room, vs the topic *, I.e. 10 pentesters at 100k/year, for a one-hour meeting - vs the cost of just buying that tool that costs $100/year *, I.e. http://gorskecalculator.com/ can be helpful when calculating the actual cost of a weekly team meeting.

Know that you will get a lot more things done with fewer distractions; optimise to have the least number of distractions, context switches, and other nonsense.

To cite Aaron Swatz of http://www.aaronsw.com/weblog/officespace:

People are always asking me how I manage to get so much done. For a while, I tried to impress them with my pearls of wisdom but soon I just sort of gave up. I don't really feel like I do anything special — I worry about getting stuff done a lot, but mostly I just sort of do it.

It wasn't until I started working in an office that the question begun to make sense. Since I moved to San Francisco I literally haven't gotten anything done. I haven't finished a book (I finished three on the plane out here), I haven't answered many emails (I used to answer hundreds a day), I've written only a couple blog posts (I used to do one a day), and I haven't written a line of code (I used to write whole programs in the evenings). It's a pretty incredible state of affairs.

Clients

When dealing with clients:

• You are a consultant; you can ask what you want: Source code, architectural diagrams, admin accounts.
  • Often, pentesters won’t ask, which leads to less coverage on an engagement.
• If the client asks for something silly, tell them why it’s silly, and suggest a better use of time.
• Understand why they’re here, understand what they wanted - then consider if that’s worth disregarding.
• They are paying you to be an expert, act as an expert.
• Always push for a white box test. You want the best chance of finding cool stuff.

You probably can’t fix most of them, nor is it your job to fix systemic organisational issues - but you can fight hard to get a better scope for the engagement. Also, remember to be professional; however, to quote a prominent penetration tester at PyCon AU - “Being professional isn’t wearing a suit, it’s giving a shit” [1]

[1] https://www.youtube.com/watch?v=30whGoKOduA

Pointless tests

These come in many flavours:

Some tests are pointless and just for compliance. They’ve been looked at a million times; they don’t change; there might even be using good frameworks. You’ll get them; you’ll have to do them, get them done and then move on to something more exciting.

There is no credential / “see what you can do” tests - Sometimes, you can salvage these, but ultimately looking at a log in page won’t give you much coverage. Fight the client on getting a better scope.

The target just doesn’t matter - Getting a shell on a random VPS, which gets zero traffic and no adjacent access is technically deficient but isn’t motivating to test. Fight the client, get a better scope and understanding - you want to be sure this target is pointless before you deem it so.

Target

When dealing with your target:

• Know what the thing is, know why it’s important, know what the worst case is for this thing, and then make that happen.
• Make a threat model, get a whiteboard, draw the thing up, ask a colleague about it. Do this before you start the testing.

Some would call it “goals-based testing”, others would just say “doing your job” - The author fits in the latter camp.

Reporting

• Be aware that the stuff you raise will have a cost to fix; ensure your recommendations are suitable, are appropriate, fix the issue - and most importantly, are tailored to the client.
• Be aware of generic writeups and templates, these make people lazy, and without context, reports are meaningless.
• Write your report like it’s going directly to the client; pretend the people doing QA are asleep.
• Participate in peer review, early and often. Ask for feedback on a writeup, give feedback to others. It will make you a better tester.
• When doing QA, ensure you don’t let mediocre reports pass.

Misc

When doing anything:

• Know how things work. Look into frameworks, look at tech stack, deeply understand what is going on.
• Poc||GTFO. If you’ve got a bug, build a proof of concept, test it, dump that in the report.
  • If it’s XSS, don’t alert(1); do something funky in the app.
• Know the value in your work is from the report; give it the effort it deserves.