· Certification Training

SBT - Blue Team Level 1

Date Earned: May 17, 2021
Proof: https://www.credly.com/badges/9fec1b76-6012-48a3-a21c-866cf385dac0/public_url
Linky: https://securityblue.team/why-btl1/

Shiny gold coin!
Shiny gold coin

I was pleasantly surprised by this training. I’d had a few people reach out to me about what I thought about it, and I was lucky enough to be able to take this affordable course (£499 when I signed up). Having taken it, I’d highly recommend it to anyone wanting to jump into the trenches on the blue side of the battle. I have some commentary around the incident response material, and the exam itself, but overall think this course is absolutely worth the price tag, and have already recommended it to a number of colleagues.

Who’s it for?

This training is for anyone who’s been exposed to general computing, and wants to get into cyber security. It’s also for people in SOC roles who want to improve their skills, or bypassed SOC experience and want to see what they missed. It’s a super valuable course that I can’t recommend highly enough.It’s also absolutely perfect for people looking to pick up soft skills with a heavy cyber security focus. It has solid sections on report writing, teamwork, work from home and office etiquette, and mental health. I’d honestly recommend the course for this section alone.



The training provided by SBT is broken into 5 main domains, so this review will be too! Outside of the technical domains though, this course is somewhat unique in that it starts out with an overview of security roles and how they all tie together. This is magnificent in that new students to cyber security have a common understanding of these terms.

As a part of this common understanding, we learn about security (physical and cyber), as well as the technology and appliances that is used by cyber professionals to do our jobs. Naturally, an understanding of networking is critical, so SBT go into a good level of detail into how networking (TCP/IP and OSI are both covered) and common network protocols (ARP, DNS, HTTP, IP, etc). The foundational training provided is really great.

It also goes reasonably in depth into communication (written and oral), team building, problem solving, and general office etiquette (wear pants, even when working from home got a chuckle out of me). Again, the advice provided here is generally overlooked by training and is invaluable for new entrants into a professional workforce.

Possibly most importantly, this training covers mental health, including imposter syndrome, burnout, and alert fatigue. From personal experience, imposter syndrome can be crippling, and I only really learnt about it from a fantastic manager (and friend) at Mandiant. If I had have learnt about what it was and how to cope with it earlier, it would absolutely have been beneficial to me. So even if the rest of the course was rubbish, massive props to you Security Blue Team for implementing this.

Of course, the rest of the content isn’t rubbish, so let’s dive in.

Phishing Analysis

According to the Verizon Data Breach Report phishing is the most utilised initial infection vector used by threat actors. So it makes sense SOC analysts learn about this in depth. Through this training, we learn about the different type of malicious emails.

We’re taught how to read email headers and identify anomalies in both the header and body of an email to quickly determine if an email is phishing or legitimate. Even if the sending domain looks legit, we’re taught how to break through that and identify spoofing.

I know, you think malicious emails, you think malicious attachments. We learn how to pull these out of emails (manually, if we have to) and analyse them. We learn about the common phishing attachments (anyone shocked macro-enabled word documents is number one?), and how to analyse these safely too.

Given that phishing emails frequently lead to phishing web pages (commonly to farm credentials), we also learn how to analyse these pages. Tools like URL2PNG let us interact with these websites without accessing them directly, which I hadn’t heard of before and thought was cool.

We also learn how to analyse the domains behind the web pages, using things like whois to identify young domains. We also learn to use our brains to identify things like typosquatting or URL shortening services and how they’re utilised by threat actors.

As blue teamers, it’s critically important that we understand the defenses we can deploy to mitigate these attacks. SBT do a good job of describing configurations and technology that can be implemented to help protect our customers or employers.

Threat Intelligence

As we dive into threat intelligence (TI), we learn all about the different types of threat actors (hacktivists, cyber criminals, nation states, insiders, etc). We learn about different techniques different groups will use, and how that may inform our incident response engagements or investigations. There’s a good level of detail in this section about APT groups, and the MITRE ATT&CK framework.

We learn about different sources of threat intelligence, and the forms this intelligence may take. It may be open source intelligence (OSINT) that we can find ourselves, or hidden behind paywalls where you have to subscribe to a service to get access to the intel.

The intel itself may be in the form of a human readable report, or in a variety of formats designed for ingestion by intel or security platforms. We dive into indicators of compromise and the platforms that support them (STIX, TAXII, OpenIOC, Yara, etc), and how these can be leveraged by TI teams.

We learn about intelligence sharing platforms, and have a lab where we can set up MISP for use in our own engagements. Of course, we learn about information sharing within our local communities, or the global infosec community, and some considerations around each.

Finally, this discussion would be incomplete without coverage of the Lockheed Martin cyber kill chain. This kill chain informs how the rest of our intelligence can be used at strategic and tactical levels, and sets our organisation up for success.

Digital Forensics

In diving into digital forensics, we get down and dirty with the low level workings of various file systems and how they’re utilised by different operating systems. For example, the Windows layout of an NTFS drive is completely alien to an EXT4 drive used by a linux OS.

We also learn about hardware. What’s great (and not so great) about SSD drives for us as digital forensic practitioners. When and how to use write blockers and anti-static wrist straps. We are told about how to plan for various investigations, the importance of evidence preservation and chains of custody, and the criticality of solid documentation. Yep, we write down our mistakes - it’s almost more important than documenting the things that work!

Erasing files via the standard recycle bin and more challenging forensically sound techniques are covered in a good level of detail. Both Windows and Linux artifacts are covered both in what they are and how to analyse them in a good level of detail.

As far as tools go, we get hands on with Autopsy (for disk) and Volatility (for Memory).

We learn about what general legal proceedings look like, and how we can prepare both technically and non-technically for the interpersonal part of this work. Honestly, I’m probably missing a bunch here because I just sort of skimmed this section, as it was largely revision.

Security Incident and Event Management (SIEM)

The SIEM section was magnificently detailed. We learn about the history of a SIEM is, where it came from, and the problems it was intended to solve. We look into the challenges of data collection at scale, and when it makes sense (and when it doesn’t). There’s a pretty sweet section in the beginning covering different SIEM solutions (Arcsight, Greylog, LogRhythm, Splunk) complete with pretty pictures.

Then we get to the meat and potatoes of SIEMs, which is aggregation and correlation. These sections detail the true value of a SIEM in that it can unearth patterns, threats and compromises you wouldn’t otherwise be aware of. It goes into how SIEMs can ingestion the likes of SIGMA rules, so that we can ingest feeds from our MISP and perform retroactive searches against collected data - that’s right, rules aren’t just forward looking anymore.

Finally, we get a deep dive in Splunk, possibly the largest name in the SIEM game. We learn how to install Splunk in VM’s ourselves for learning, and try our hand against Splunks’ Boss of the SOC challenges, where we learn to dig through decent amounts of data to investigate an incident. This provides enormous practical value both for the real world, and practice for the exam (hint hint). Practically, we learn about both searching retroactively, and creating alerts for proactive detections.

Incident Response

The incident response process taught by BTL1 is pretty clearly based on the NIST SP 800-61. I was a little disappointed by this section, as it felt it was missing something, though I can’t quite enumerate what. I felt that it’s more heavily focused on (and possibly authored by) people more at home than a SOC than an incident response engagement.

It goes into a good level of detail regarding the incident response lifecycle (Prepare, Detect / Analyse, Contain / Eradicate / Recover, Post incident activity (PIR)). We go on to learn about the difference between CERTs and CSIRT teams, and look into a case study with the greatest CERT on Earth, the New Zealand CERT (I’m a kiwi, but I’m totally not biased…).

This section dives into the incident response lifecycle, and it covers the different phases well, but it’s all a little clinical. I would have loved to see a case study or some other form of, if not a practical section, at least some thought-based exercises. Maybe a student is provided a scenario with a lead and some initial investigation, and needs to decide if it’s appropriate to pursue containment or how to guide the next phase of the investigation. Keen to see how this looks in BTL2.

The report template provides a solid methodology for investigating the compromise. As the only part of the exam you’re actually marked on too, it’s a great mark of how ready the assessee is for the real world; writing reports like this for clients (either as a formal report or part of a ticketing system) is a critical skill.


Where I loved the training material, I was a little disappointed by the exam. The format of the exam is a hands on wee investigation, which I love. You get 24 hours in total to go through the exam process. For the first 12 hours, you’re in a small network investigating a compromise. While this investigation is fairly well led through the provided exam report template, it seems a touch arbitrary. There was no provided “this is why we think the network is compromised” as a part of the narrative scenario, and it broke my immersion a bit.

The exam environment itself is accessed via a remote access session through your browser. That means if you want to interactively access a machine you want to investigate, you’re RDP’ing through your browser to an investigation machine, then RDP’ing or SSH’ing or what have you through to a second machine. If you have internet (or bad luck on the lab environment’s internal connection) like me, you’re in for a bit of a rough time.

The lab has limited internet access, which makes sense. Threw a small spanner in the works for me, as I was planning on importing tools that I was more familiar with to perform analysis. Egg on my face there, the lack of internet access makes sense really. The downside here was that some of the tools I was taught about (and found to be awesome in the course) required internet access to become usable, so I couldn’t use those either, which was frustrating.

The approved / preinstalled tools also weren’t enumerated in what I’d consider a satisfactory manner. I spent a good chunk of my exam time using a subset of tools that had shortcuts on the desktop. Only near the end of my exam did I find a bunch of additional tools had been installed and could be accessed through the start menu. Pro tip for your exam, if you’ve been taught a tool and think it’ll be useful in the exam, when you get in, hit the windows key and search for it.

But enough of the bad, what’d I like? The intrusion we’re investigating uses modern tools and techniques that you’ll actually experience in the real world. No old CVE’s or Windows XP boxes here, the stuff you’ll see in the exam is the same stuff I’d expect a MSP SOC analyst to be running into on a super frequent basis.

Finally the feedback that I got from this exam is the best I’ve had in any assessment, ever. I got an email a couple of days after I submitted my report advising I’d passed with a pretty nice 90%. The feedback went on to include things that I’d done well with my investigation and report, as well as some things that I missed in the investigation or could have improved in the report. This was excellent, as it shows SBT are keen on helping you improve yourself even after the training engagement is done. (And no, I don’t share that feedback, it’s far too exam specific).