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 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.

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.

Alpaka Gear 7venMessenger Bag


My friend Jin of Alpaka gear kindly sent me a prototype of his kickstarter project the 7venMessenger bag.

The 7venMessenger bag describes itself as “the only bag you will need” and aims to be suitable for everyday work & leisure usage and also for a short weekend away.

When I was working for IT consultancies there was a regular discussion around what is the best laptop bag which is very relevant when you are frequently travelling.

I have always favoured Samsonite Backpacks as found them comfortable and hard wearing so was interested to see the 7venMessenger bag and how it compares.

Here’s a picture of my bag – note this is the prototype and Jin tells me there may be a couple of changes coming so the final bag may be slightly different:


Well I am probably not the best judge of aesthetics (2 kids soon change your priorities to robustness of any clothing or gear) but the 7venMessenger certainly looks smart & wouldn’t be out of place at the smartest of soirees which er i’d never get invited to. The bag also receives a nod of approval from my wife (who knows a heap more about bags than I do) so this is a good sign.

The bag is constructed out of 1000D Ballistic Nylon – I don’t know what that is and what its bullet protection abilities are but it certainly feels tough, durable and looks smart. The bag is also water proof and easy to clean according to the website.

The bag feels reasonably light although is certainly heavier than some of my other bags. Its pyramid shape also means it stands on its own rather than collapses.

The attention to detail & quality on the bag is impressive. There is a massive amount of pockets, mesh compartments and storage (even on the strap!) which I love as there are always various cable chargers, USB sticks etc that need a storage location.

The bag can be worn in a number of ways such as over the shoulder, as a brief case or backpack – it also has a sleeve for fitting over a case handle that you might use at airports. The bag is very comfortable to carry using its leather handle and I find this is the preferred option standing on the train.

The bag has a magnetic clip on the front that looks like it would be released by pulling it up but is actually opened by sliding it sideways. It did confuse me at first and I spent a couple of minutes puzzled but I do like how the magnet pulls the clip together.

The bag is a decent size and easily holds my Dell XPS 13 inch in a padded section. I understand from Jin & his team that the final bag will hold a Macbook 15 inch comfortably. It does feel a little wider than the average messenger bag and I notice sitting on the train with it on my lap it expands slightly beyond my seat area but it’s not a huge issue.

In conclusion the 7venmessenger bag is an awesome product that I would highly recommend.

You can get this bag at a great price by backing the kick starter project at: what are you waiting for?


Building Resilient Systems

No one likes using unreliable computer systems.

There can be few things more annoying (in terms of 1st world problems anyway) than having an application freeze and losing a load of work.

Losing work is annoying but what if the system performed a more important function such as managing your bank account or maybe even helping an aircraft navigate?

  • How can we measure resiliency?
  • What are the best ways to ensure our systems are resilient?
  • How do companies such as Netflix approaching this?

Check out my post on this at