Offensive Security Certified Professional

Certified Red Team Operator

CompTIA Security+

eLearnSecurity Junior Penetration Tester

Offensive Security Experienced Penetrator

Lena Marsh

Offensive Security Engineer

<h2>Context</h2><p>The platform handled customer accounts, checkout and a small staff back office. Testing ran over two weeks against a staging environment seeded with representative data.</p><h2>Key finding</h2><p>Three medium issues chained into one critical: an insecure direct object reference on the order API, a predictable password-reset token, and a staff endpoint that trusted a client-supplied role field. Individually each looked minor. Together they allowed a path from an anonymous visitor to an administrator.</p><h2>Outcome</h2><p>Every issue in the chain was fixed before go-live. The broader lesson for the team was to enforce authorisation on the server for every object reference, which became a review checklist item.</p>

A grey-box web assessment of a mid-market retail platform that surfaced a full account-takeover and privilege-escalation chain.

Retail web platform: from guest to admin

<h2>Context</h2><p>The engagement simulated a post-phishing foothold on an internal network of roughly 400 hosts. Detection and response were in scope, so I tracked which actions were noticed.</p><h2>Path to domain admin</h2><p>A Kerberoastable service account with a weak password gave the first escalation. From there an unconstrained delegation misconfiguration on a server allowed capturing a privileged ticket. The whole path was visible in BloodHound before I ran a single exploit.</p><h2>Outcome</h2><p>The client prioritised tiered administration and delegation cleanup. A follow-up engagement six months later found the primary path closed.</p>

An assumed-breach internal engagement that reached Domain Admin from a single standard workstation in under a day.

Internal network: one phish to domain admin

<h2>Context</h2><p>The estate spanned three AWS accounts with a mix of managed services and self-hosted workloads. The review was time-boxed to a week.</p><h2>Key findings</h2><p>A customer-export bucket had a public policy left over from an early prototype. Separately, a service role carried a wildcard permission that allowed privilege escalation to administrator. Neither was being actively exploited, but both were trivially reachable.</p><h2>Outcome</h2><p>The urgent exposure was fixed immediately. The IAM cleanup became a longer project, and the startup passed its security due diligence without findings in this area.</p>

A configuration and privilege review of a growing AWS estate that found a data-exposure path and an escalation to account-wide access.

Cloud estate: the public bucket and the over-trusted role

<h2>Context</h2><p>Scope covered the companion mobile app, the pairing flow and the cloud sync API. Physical device tampering was out of scope.</p><h2>Key finding</h2><p>The pairing endpoint accepted a device identifier without binding it to the authenticated account, so a user could sync a device that was not theirs. Health readings are sensitive, so this was treated as critical despite needing a valid account.</p><h2>Outcome</h2><p>Server-side ownership binding closed the gap. The engagement also prompted the team to add authorisation tests to their release pipeline.</p>

A focused API assessment of a connected health device that found an authentication bypass on the pairing flow.

Connected device API: auth that was not

<h2>Still here</h2><p>Insecure direct object references are not glamorous, but they remain one of the most common high-impact findings in web assessments. Modern frameworks make injection harder; they do almost nothing for authorisation.</p><h2>A repeatable hunt</h2><p>Map every object the app exposes, note the identifier each uses, then replay requests as a second user. Sequential identifiers are a gift, but even opaque ones fall when the server never checks ownership.</p><h2>The fix</h2><p>Authorise every object access on the server, keyed to the authenticated user, not to what the client sends. It sounds obvious and it is still the single most common gap I report.</p>

IDOR: the simple bug that keeps paying off

<h2>Enumeration</h2><p>Lame is one of the oldest retired boxes on HackTheBox and a great first target. An nmap scan shows FTP, SSH and Samba open.</p><pre data-language="bash"><code class="language-bash">nmap -sC -sV -p- 10.10.10.3</code></pre><p>The interesting service is Samba 3.0.20, which is vulnerable to a well-known command-injection flaw in the username map script.</p><h2>Exploitation</h2><p>The vulnerability lets you inject a command through the username field during authentication. A crafted login runs a reverse shell as root, because the Samba daemon runs with high privileges.</p><h2>Root</h2><p>The shell lands directly as root, so there is no privilege escalation step. Lame is a reminder that unpatched legacy services are still the shortest path on real networks, not just in labs.</p><h2>Takeaway</h2><p>Keep an eye on legacy file-sharing services. The fix here is simply keeping Samba current and segmenting the hosts that must run old versions.</p>

HackTheBox: Lame, a gentle start with Samba

<h2>Why</h2><p>Running attacks is only half the picture. I wanted to see the telemetry each technique produces, so I built a lab where I play both sides.</p><h2>The build</h2><p>A small domain with one controller, two workstations and a logging pipeline feeding a SIEM. Sysmon on the endpoints, Windows event forwarding, and dashboards for the noisy techniques.</p><ul><li>Domain controller plus two joined workstations</li><li>Sysmon with a tuned configuration</li><li>A SIEM for search and dashboards</li></ul><h2>What I learned</h2><p>Kerberoasting and unconstrained delegation abuse are far louder than they feel from the attacker side. Seeing the events they generate changed how I write the detection notes in my reports.</p>

Building a detection-focused home lab

<h2>The landscape</h2><p>Macro-based payloads are mostly dead; attackers moved to container files, shortcuts and legitimate cloud services. The social-engineering layer matters more than the payload.</p><h2>What helps</h2><p>Attachment-type controls, strong authentication that resists phishing, and user training that focuses on the one or two realistic lures rather than a generic awareness module. None of it is exciting, all of it works.</p>