Upskilling Without the Yawning | How a Network Engineer Learned to Make Labs Fun - Sabastian Hague

Oh, perfect. I'll put timer on just in case. There we go. Oh, hello. Um, so I'm Seb. I'm going through upskilling without the yawning today and how I learned to make labs fun. Um, I guess disclaimer. Um, I submitted this talk a little while ago. I got to like seven days ago. Completely forgot what I submitted. I check on I have the abstract. Um, but I put something together I think is very relevant and the abstract did make sense. It turns out I have a 2-year-old child, so I've slept a lot since then. Okay, who am I? Um, I'm Seb or Seth H24. Um, I am director of content and training at Security Blue Team. Um, hopefully some

of you heard of us. If you haven't, please put your hand up. Okay, perfect. I'll sell to you afterwards. I'm also a district counselor on West Lindseay District Council. Um, very young to be doing that. It's very frustrating and thankless, but I'll go a bit as how that has influenced some of the content that I built today. Um, I reside in sunny Lincoln, um, which isn't quite as sunny as Bournemouth right now. My dog on there is called Rex, and a big thank you to the organizers. I love Bournemouth. I look for any excuse to come here. What we'll cover, um, my journey in 90 seconds, it's probably more like 100ish. Um, but we'll get through it as fast as

possible. Um, I guess what I see is the problem statement when I entered the industry like many, many years ago around labs and accessibility, just how frustrating it was to learn and how lucky I was to learn where I was. um the outliers. It wasn't all frustrating. There were some pretty pretty cool OGs back then. Um and then just commonalities of the OGs. Um and then a big question mark here, politics and packet tracer and why those two things have influenced me probably more than anything else. Um and then how we sort of build a simple approach now at SBT and how I make sure every content engineer in my department builds content that's relevant to all of you. Um and

then some lessons from the content engineering floor. So it's a bit of a journey sort of how I started in content engineering and how I learned to make hopefully labs fun for all of you. Okay. So my journey in probably what is more like 120ish seconds after I did a run through earlier today. Um so I joined the air force I think back in 2013. Um I feel very old since then as a network engineer. Um essentially the goal the job was just tearing up and tearing down networks that deployed across the globe. Um I was at a unit called 90su. Um, and the way I entered cyber security was potluck, very random. Like I'll be really honest with you,

there's no kids in the room. Like I was dog [ __ ] at networking when I first joined the military. I would went to cost, didn't get Cisco at all, didn't really listen. All the lessons theoretical and I figured out whilst I was sort of learning at cost in the military like I just don't learn theoretically like I just don't take it in at all. Um and I went to up at leing. I had passed thankfully by skin my teeth and I went to leing and when I started to work on equipment and started to sort of learn how to fail, break things, fix them again and again and again and again. I ended up picking things up and

like understanding networking and the jobs much more comprehensively. That much so that I actually started learning more about computing itself and specifically Linux. And then the way I entered cyber security I I do not joke today was my sergeant approached me and said hey Seb he's called Richie I went how do you fancy going to Cosford and I was like oh maybe no not cost I was like oh maybe we'll see how it goes they went Linux I was like I guess kind of we were shipped down to caution for two weeks and handed over a massive like server stack on wheels which had a firepower sensor in it [ __ ] tons of resources

um it had end for packet sort of packet analysis and he said you're going to build a sock. I never worked cyber security never worked in a sock and from that day on uh within the air force we essentially built the first deployed security operations center up at 90su and that was with no cyber security experience prior to that. So it's very much a baptism of fire. Um we broke a lot. We actually ended up breaking the large portion of the Royal Air Force's NATO secret network um due to pushing Splunk out and getting a load of scripts to run on endpoints. Um so yeah, we learned a lot. We broke a lot and Lord

knows if I had done that at Vodafone instead I'd have been sacked. So thankfully you're unsackable in the military. Where's it gone? There we go. Oh no. Okay. So uh anyway after a bit of time um I figured out complete transparency that the money is not that good in the Air Force. So I decided to leave. Um I went to Vodafone as a search specialist. Worked on some pretty high-profile instance. They're all quite fun. HSSE ransomware attack was one of them. went to trustwave as a consultant and just spent my life writing reports and just going through the billable hour churn. Um but in between those phases I learned quite a lot. Um I took the skills from

system administration in the military and then put them into place as a sort of instant responder specialist. Um one of the big things I learned during that period was that like being a network engineer and admin and learning how to fix things and break things in a past life definitely helps when responding to cases. Like you can level with the people you're speaking to and that's really important. Um, I was then approached by Hat the Box. I'm sure you all know who they are. Um, and I stood up their defensive content team um, whilst I was there. And then not long after that, I won an election on Western District Council. So, I was a counselor

in my spare time. And I'm now back at Security Blue Team as their director of content and training doing pretty much what I did at Hack the Box um, but at a company that's focused on defense as it stands. So that's my journey and I think I'll go into a bit more detail now about how that's helped me and what the point of the talk today is. >> So the problem I guess when I entered industry um man death by PowerPoint it's I don't learn that way like theoretical learning for me is just absolutely not the one um engagement due to death by PowerPoint was just was really poor. Um, there's people I know in industry. There's a guy

on my team called Dave who's like a wizard, like an absolute unicorn, and he'll just pick up like a SIS internals book, just read it end to end. And I just don't learn that way. Um, and then the only companies that were out there that I guess provided like some kind of practical learning were SAMs. And as we all know, they're like expensive. Like I think like £8,000 going right now for a SAM course. I was really lucky. I did five whilst I was in RAF. And that was very lucky for myself. But if I wasn't, I don't know how how I'd have managed practical training back then. Um, and again, even the really good content,

really good courses with really good instructors back when I first entered industry were highly theoretical exams, multiple choice, not really a true test of competency. It's just going through an index. Um, and again, that didn't hit home for me. Um and what we actually found was that at SPT people who pass SANS exams who I know often will struggle with for example an exam that we build which is more practical but seems like simple material. So that was a problem a few years ago. Essentially content I guess for myself is boring but there were a few outliers I guess. Can anyone tell me what the top left is? >> Packet trace. There we go. Um I remember

when I used packet tracer I guess in my spare time whilst in the air force up at leing trying to understand networking that's probably because I was thinking about this seven days ago and putting my slides together that was probably the first time that it sort of hit home. I was like [ __ ] I learn by doing like I learn by actually configuring things and breaking things and the most important bit there was I learn better by doing it in a fault-free stress-free environment like I don't want the pressure of losing my job. So, Packet Tracer was definitely sort of an outlier of that, definitely an OG. It somewhere I I learned how to I

guess build labs as we speak now. Um, then there was obviously DAM vulnerable web application. Um, something that I assume a lot of us have used in the room. Um, Hack the Box where I eventually worked which is quite nice. And over the wire, I think anyone who's at Linux probably knows about that. Um, and then the one outlier here is this that I want to I guess cover I guess at a high level because it's influenced the career and the journey I've gone through today and the content that I now build or plan to build. It's called like exercise red flag or cyber red flag um out in America. Essentially like it's mock cyber war between lots of countries

within NATO. So you get a full range environment. You get like actual live attackers. You defend a network. So the combination really of red flag and packet tracer and like learning in a practical environment and just learning by doing the job is what probably influenced me to end up at SPT and hat the box and the companies I've been at since that day. So just a big shout out to the outliers and if you haven't used any of those I highly recommend it. Even if you are an instant responder, please learn networks. I beg you. So yeah, what do all these have in common? They're practical. They're free. I think for the most part I think packet

trace is still free. there are alternatives if not um and you learn by doing and that's the one sort of thing I want to push today like learn by doing the job because you learn much more than you would if you just read through a book read through material or take a multiple choice exam okay so the big question today really I think from my abstract that I'm trying to highlight again is how did how is politics relevant to this like what has politics possibly taught me that I could speak to you about today with labs well it's really good building environments um or building network. What that doesn't have is context. And one thing

that's really important in building content and something that I've realized in the many years I spent building content built is that context is king or queen. Like in any lab environment you build, it's really easy to go away and I know run mimikats on a Windows machine, take a memory dump and technically investigate that. But that's not realistic of how it would look in real life. In real life, there's applications running. In real life, there's a user on the endpoint. In real life, the hay stack's really, really, really big. So, what politics has probably taught me in the brutal world of local politics is spin matters, context matters, and plain English stories matter. So, the hardest bit

about I guess content and content building and everything we build at SBT or the box in the past has never been the technicalities. Like, that's our bread and butter. Like, we're engineers. That's what we do. The hardest bit is how to make that [ __ ] look realistic. That's the hard bit. How do we manage that? And but if if politics has taught me anything at all is that a good story resonates with your end user. Whether it's constituent in the area I present or whether it's a user playing in our labs, context absolutely matters to the end user and definitely affects the feel of the environment. So coming up with lab ideas, I'm going

to try and bring this all together towards the end of the talk. I think I've got a while left. Oh yeah, loads of time. So, how does it work? It's pretty complex and the only way I can think about it is this here because there's so much you can do and there's a lot of um I guess restrictions in place around licensing commercial tools. We try and use open source. We've actually in the past and I won't go into too much detail today. I guess had to figure out how to grab commercial tooling and grab the logs from them and then create scripts that output that log format in a way that might look realistic. how we create

how we get the actual logs themselves we won't go into too much detail about today but the approach that I think essentially I've tried to build in the simplest way possible and the approach that I try and push across every content engineer we have are just three pillars um funny enough we had some management training at a company long ago and they spoke about like building pillars or foundations of what you do and turns out we were doing this anyway which is quite nice um but everything we build on top of this and the key pillars that I want to make sure content fits. Is it's number one, is it realistic? Like, can you take the memory dump we provide you,

analyze it, and does it look like what you what exists in your company right now? Like, in the day and day, is it engaging? Um, is the storyline relevant? Are we talking about Space Invaders? Are we talking about an actual company that's been compromised with actual files that look realistic and actual content in those files? You can see it start to sort of span out quite a bit. And then, is it relevant to your day-to-day job? like from the analysis you do, from the questions you're asked, could you go away the next day and apply that to the workplace? And if all these three pill all three all these three pillars exist in the content you're

building, then usually if you're checking those boxes, you can guarantee the content's pretty pretty good. And there are some obvious outliers to that. So a good example of this, and as an FYI, I don't want to sell our platform. There's a lab that's free right now that I built that long ago called Becky. It's a BEC. Recommend playing it on BTL if you get a chance because I went through this process not long ago and it gives you an idea of how much effort as a content engineer I guess you try and put in to build environments are realistic. It gives you a bit of I guess an idea as to how my background in engineering

administration definitely helps in the day and day and it also gives you a bit of an idea as to how the context from cases I've handled in the past and adding a story definitely helps with this as well. I had an idea and are there any consultants in the room or default? No. Okay. BEC is like bread and butter. So business email compromise they're often really boring. Um often turning through a lot of data and with identity sort of based authentication now a lot of that exists in places like what they call it now as your entra whatever Microsoft decided to call it tomorrow. So I had a BAC idea and I was like crap

I never actually managed anything in Azure or Entra. Um so I was like okay I'll set this up. This should be quite easy because back in the Air Force it was all exchange piece of piss that all sits on the actual posts. Man, Microsoft isn't easy. That's what I learned that day. Um, so I set up the licenses um and decided to pay the extortionate license fee. Um, I got a message from my CEO asking why I paid it not long after. Um, but we did it anyway because we want to create content that you guys can play. Um, so okay, let's set it up, pay the extortionate fees. Okay, I got mail services up eventually

sort of end of day one. I was like, now I need to create users. And then you realize, oh crap, I need all these users to actually authenticate day in day out, open documents, go into one drive, create more documents, make sure there's contents in those. They need to email each other. They need to team each other because all of these logs exist in the audit data. And what I don't want to do is provide yourselves with some really small audit data. That hastack needs to be really big. So I then spend a wealth of time emulating users, but not just in Exchange, in every other app you can think that exists now, which in

Microsoft there's so many. And managing that became a real pain. And then I got to the end of that and I was like, I've not set up Oh, there we go. I've not set up a malicious domain yet that we can actually send an email from that looks a bit like the micious domain for the original user. So we go and create that. So you can see now we're creating attack infrastructure that is legitimate attack infrastructure. We're creating a legitimate like essentially a mock emulated company. And the scenario we're going for is that a partner of this company um that managed their finances or pensions can enable or allow withdrawals via email and there's an

email within the inbox that exists that the attacker reads, figures it out, add some inbox rules. So you have to manage then this other third party company and create an environment for them and a user and a persona and a profile and before you know it you're essentially managing three small company environments as a content engineer for the sole purpose of around 15 megabytes of blocks. So it becomes becomes pretty pretty time consuming. So you end up pinging a fishing email you manage to compromise the accounts add some inbox rules it all looks really good and then I need to figure out how to export the data. Now back when I was consulting it was eiscocovery I think that Microsoft

used I think I looked on it now couldn't find e discovery I'm rolling around trying to figure out what tool did Microsoft use now to export like audit log data perview is the name of it so that it's been it's changed since I used it. So then I have to export the log data and then and only at that point can you create questions that are relevant to actually add to your platform analyze the data and I got to this point and I realized I'd actually or to one of the accounts by mistake from my home IP address which went to the account of an office user. So I had to go back delete all the data and then do all of this

again. And if you get any of it wrong, there are some things you can do because the log data is so complex in the environments and it's like so much nested JSON. I can't just said like my IP address out and replace it with something else because there might be something I miss and I likely will miss that. And there's nothing that frustrates me more when I go through I guess content in like any platform or a CTF when the story line just doesn't match. Like it just doesn't fit. You're sort of going through it. It doesn't feel real, which is a Sorry, my laptop is going off. There we go. Yeah, it doesn't feel real. It's often

quite frustrating to go through. Um, so I find if you realism is what you want. People often ask me as a content engineer, as a background, as a CIS admin, architect, what have you done in the past? Like how do you make the content look realistic and which build real attacks, build real environments? It's as simple as that. So simplicity is very much key when building this content. So if any of you have any home labs and want to build something realistic that emulates a real environment like don't think about emulation just build that real environment that's all you need to do and then attack them and I guess the summary summary of that entire chain is there is absolutely no

difference between quantum quantum mechanics and Microsoft licensing is what I'd learned from that and that doesn't just apply to Microsoft but it applies to like every sort of license standard that exists um and the benefit and beauty of engineering thing is that you often figure out ways around things. So you often end up cracking certain bits offline so you can find out what log formats to have creating workarounds. But what we come back to every time is that there's nothing better than just creating the environment itself going through the time consuming task trying to automate that using things like Terraform if you can and then moving forward making sure that what you provide to the end user

like it is emulated it's not actual customers but it is just tap data that's all it is so I guess lessons from the C floor um so obviously we build the content we serve it we have loads of players playing it which is really really nice and I love Um, and I think what I've experienced is most people I encountered like learn by doing. But that's not all there is to it. Like just because you play Blue Team Labs online, hat the box, like C numerous CTFs, that doesn't mean like you have to do really really well and get a job because your technical skills are second to none. Like try and make sure you play content that gives you

those soft skills as well. That's what we try and do. So we try and give you when we build questions, the way we think about it is what, where, when, how. So instead of flagifying it, we flagify it by asking questions that's pertinent to seniors in your organization, which sounds really boring, but essentially just flags in question form. And then what I've learned through time, especially at the box, is man, there's some hobbyists at the box that just have all the time in the world to post content. Like so, and these hobbyists are [ __ ] hot and flat the rankings. Like they're always first blood. Um, always the same people. But what I've often seen as well and I won't

sort of name anyone is that some of these hobbyists like the best technicians in the world that I've seen like they can solve any challenges that we put forward in front of them often like can't find work. And I guess that what that sort of said to myself and what resonated myself then is that like people actually who are highly technical had to have soft skills as well. So maybe we can try and build content at SPT that is focused around both soft skills, communication and what you do in the real world. And that's where I came up with the term CTF focused content isn't content that I quite enjoy. I think it has a place for technical skill

sets and proving that but it's not something I enjoy. So what we learned essentially I guess from C floor is that story focused content scenario focused content tends to land much more than purely technical content especially in a CTF where they're all interlin. Context is everything when it comes to defensive content. Again, I think I've covered that in a fair bit of detail today. Um, and I mean, identity based access makes it much much easier at times to spin up environments and the management of those, but also much much harder because it's ever changing. Like Microsoft and AWS are always changing. Um, and again, keeping up is really, really tough, but keeping up enough to

teach others is even harder for us. Like we need to try and I guess I I speak about an arms race that exists between every provider man if log for J2 came out tomorrow you guarantee us hack the box try hack me like an arms race to get content out as fast as possible but make sure that's high quality. So we often try and get content out before a PC exists. So as a C you're often I guess trying to understand the exploit like how it's exploited prior to a PC existing in the wild to make sure it's out next day. So what that means is we have to be highly technical, understand how to teach it, how to write well about

that and get it out into platform super super quick. So that is really really difficult. So there are a few lessons that I think I've learned from the C floor. Um but the one benefit for all of you in the room is that unlike many many years ago when I enter the industry as a a learning network engineer which I really enjoyed in 2025 man you are spoiled for choice. There are so many ways that you can learn now that are so affordable which is why I'm really happy that companies like us like hat the box like try hat me are displacing your big f like s now because like training is now accessible to many many people and

often you'll find the people who spend time and put time into practical labs and learning they're the people often like landing jobs now because they can speak about it in interviews they speak about experience I think I saw someone on LinkedIn comment experience over something else there. But essentially, experience is the key to like landing roles. And I guess how much time do I have left? Oh, we've got perfect timing. Excellent. Um, what I want to summarize today, I guess, with is that the best way to learn and the fastest teacher is having somewhere where you can fail safe. So having some way you can break things safely, where you can break things without being fired, where

ideally, unlike myself in the Air Force, you can sort of take take down networks without worrying about what the repercussions of that are. I think that's something that we try and do in every piece of content we build, whichever organiz organization I've been at, isn't a sales pitch. Um, so my recommendation, I guess, to everyone here, hopefully learned something or taken something in, is that just break things. Like the best way to learn a new exploit for example would be to understand how it works, not just run the PC, understand the application, go into the logs, understand how they look in the log files themselves rather than just reading the blog post. And that's how I personally learn. I can't take

anything in when it's theoretical focused or reading through it. Okay, Q&A. I'm not sure there'll be any questions, but I mean I've got time for them anyway, and I'll be here probably 15 20 minutes afterwards. >> I do have one. You mentioned like when there's you want to get there before even the P. What are some of your sources to get yourself up to speed on how that tank works? Do you have some >> so resources or do you just every time you just search and find >> Yeah. So I have a [ __ ] a very very good team of content engineers sat on my team at the minute um who I mean their bread

and butter is like exploit building a lot of the time. So when it comes to offensive content I can sort of I describe like Dave or Gaz like hammer and nail like a point and shoot and they'll go away and just do until it's done. Um, so a lot of it can be like just reverse engineering how it works or what information exists on LinkedIn from the the little information there is. But then there are with defensive content. So for offensive content, you have to build something vulnerable and you have to be able to compromise it. So it's a little bit harder. But for defensive content, which we do, it's a little bit easier because what you can sort of get

from your contacts in industry who might be seeing this live like through your network are what IoC's have you seen? You sort of get a little sneak peek. I I'll phone them up. I'll like I won't say any names, but like hey buddy, are your socks seeing this? And they sort of won't say in detail. I say okay, what can give us a little bit like a little bit what IC's are you seeing? And if it is things like logs or web app logs that are standardized, we have got scripts that we can use to emulate those and then add in the actual indicators compromise. So what you can find is before sometimes even fully

understanding the exploit chain with just the IOC's that you can get through your network, you can start to build content so you can get others trade on that. So it's it depends on on the type of the type of sort of big news that it is. Oh, thank you. >> But yeah, more more often than not, it is people in my network. Hopefully that makes sense. Okay, any more questions around the room? No, I will be here afterwards, so feel free to speak to me. Um, but yeah, thank you for your time.