trilwu/secskills

# Analyzing Binaries

Reverse engineering is hypothesis testing against a program you cannot read.
The cost of the job is dominated by how much code you look at, so the whole
discipline is about narrowing: triage first, find the interesting few percent,
then read that carefully.

## When to Use

- Understanding what an unknown or undocumented executable does
- Recovering an algorithm, file format, or wire protocol from a binary
- Locating a vulnerability in a closed-source target
- Firmware analysis for embedded and IoT devices
- Reversing challenges in CTFs

# Analyzing .NET Assemblies

.NET compiles to IL with full metadata, so an unobfuscated assembly
decompiles to near-original C#. That makes the interesting question not "how do
I read this" but "what is in the way" — a packer, an obfuscator, a runtime
loader, or a publish mode that hides the managed code inside a native host.

## When to Use

- `file` reports a PE and the binary contains a CLR header or `mscoree.dll`
- ILSpy or dnSpy opens the assembly but names are mangled or bodies are empty
- Analyzing .NET malware, loaders, or red-team tooling
- Reviewing a Windows desktop or service application without source
- Recovering logic from a PowerShell or C# in-memory loader

# Analyzing Firmware Images

Firmware is a frozen Linux (or RTOS) image, and its security froze with it.
Hardcoded credentials, command injection in CGI scripts, unsigned update
packages, and debug interfaces left enabled are not edge cases -- they are
the baseline. The work is extraction, orientation, and then asking the same
questions you would ask of any system, with the knowledge that nobody has
patched this one since it shipped.

## When to Use

- Extracting and analyzing a firmware update file (.bin, .img, .chk, .trx)
- Reviewing IoT device security posture from a firmware image
- Looking for hardcoded credentials, keys, or secrets in device firmware

# Analyzing Go Binaries

Go binaries look hostile — statically linked, tens of megabytes, no imports
you recognize, and "stripped" in a way that makes tools show thousands of
`sub_` functions. They are not. Go ships its own symbol table for runtime
reflection and panic traces, and `strip` does not remove it. Recover it and
the binary becomes one of the easiest targets there is.

## When to Use

- `strings` shows `runtime.main`, `go:buildid`, `go.buildinfo`, or
  `runtime.gopanic`
- A "stripped" binary is 5–50 MB with almost no dynamic imports
- The disassembler shows thousands of unnamed functions and unreadable strings

# Analyzing iOS Binaries

App Store binaries are encrypted at rest and decrypted by the kernel at load
time, so every static tool fails on a downloaded IPA until you dump the
decrypted image from memory. That single step gates everything else, and it is
the reason most iOS analysis stalls before it starts.

## When to Use

- You have an IPA or `.app` bundle and need to read the binary
- `class-dump` returns nothing or garbage
- `otool` shows `cryptid 1`
- You need to enumerate Objective-C classes, Swift types, or exported symbols
- Analyzing embedded frameworks, app extensions, or dynamic libraries

# Analyzing macOS Binaries

macOS reverse engineering is Mach-O plus a specific security model: code
signing, entitlements, the sandbox, TCC privacy, and XPC between processes. The
binary tells you what the code does; the entitlements and load paths tell you
what it is *allowed* to do and where an attacker could get in. Read both — most
macOS findings live in the gap between the two.

## When to Use

- Analyzing a `.app` bundle or a Mach-O executable/dylib/framework on macOS
- Reading entitlements, hardened-runtime flags, notarization, and Gatekeeper
  quarantine state
- Auditing an XPC service or privileged helper for an authorization bug

# Analyzing Rust Binaries

Rust binaries are large, statically linked, and full of inlined generic code —
but they leak more than most people expect. Panic sites embed the source file
path and line, symbols carry crate and module structure, and the standard
library's formatting machinery is instantly recognizable. The job is knowing
which parts are yours and which are the 90% that is `core`, `alloc`, and
vendored crates.

## When to Use

- `strings` shows `rustc version`, `core::panicking`, `/rustc/<hash>/library/`
- Symbols begin with `_ZN...17h<hex>E` (legacy) or `_R` (v0 mangling)
- A stripped binary is 3–30 MB with minimal dynamic imports

# Auditing Code for Vulnerabilities

Finding real bugs in source code is a different job from running a scanner. A
scanner matches patterns; an auditor builds a model of what the code is
*supposed* to guarantee and then hunts for the paths where that guarantee
breaks. This skill is the methodology for the second job.

## When to Use

- Auditing a repository, service, or library for security defects
- Reviewing a diff, branch, or pull request for introduced vulnerabilities
- Hunting for a specific bug class across a large codebase
- Validating whether a scanner finding or a reported vulnerability is real
- Building an audit plan and coverage report for a client engagement

# Auditing MCP Servers

An MCP server is a privilege boundary — it translates model-generated requests
into real actions (database queries, file operations, API calls, shell
commands). The model's output is shaped by user input, which makes every tool
parameter an indirect injection surface. The security question is not whether
the MCP server is well-coded, but whether an adversarial input to the model can
cause the server to do something the user did not intend.

## When to Use

- Reviewing an MCP server implementation for security issues
- Assessing tool definitions for injection risk or description manipulation
- Auditing the trust boundary between an AI agent and MCP tools

# Auditing PHP Applications

This is the PHP-specific layer on top of `auditing-code-for-vulnerabilities`.
Take the methodology from that skill — context → attack surface → bug-class
hunt → variant analysis → the four-question verification gate — and apply the
PHP sink catalog below to it. This skill exists because PHP has footguns no
language-agnostic methodology carries: features that turn a file read into
remote code execution, and comparison rules that turn `==` into an auth bypass.

The collection deliberately has no per-language audit skills except this one.
PHP earns the exception because it dominates the legacy-web and
WordPress/Magento space where critical bugs actually live, and because its
dynamic features fail in ways a reviewer must be primed for specifically.

# Auditing Supply Chain

Your build pipeline runs more untrusted code than your application does. A
single unpinned action, a postinstall script, or a workflow with a writable
token is a path from a stranger's commit to your production artifacts and
your signing keys.

## When to Use

- Assessing risk from third-party dependencies in an application
- Reviewing CI/CD pipelines, GitHub Actions, and release automation
- Investigating a suspicious or malicious package
- Producing or reviewing an SBOM
- Hardening build provenance and artifact signing

# Devirtualizing VM-Protected Code

Virtualization obfuscation replaces native instructions with bytecode for a
custom virtual machine embedded in the binary, then runs that bytecode through
an interpreter. The original logic is not gone — it is expressed in an
instruction set you have to recover first. Devirtualization is a fixed pipeline:
find the VM, understand its handlers, extract the bytecode, and lift it back to
something readable. The obfuscator changes every build, so the pipeline, not any
one tool, is the durable skill.

## When to Use

- A function turned into a large `fetch-decode-dispatch` loop with a handler
  table instead of ordinary control flow

# Diffing Binary Patches

A security patch is a description of a vulnerability written in the vendor's own
code. Diffing the binary before and after the fix turns a one-line advisory into
the exact function, the exact check that was added, and — reasoning backward —
the input that reached the bug before the patch. This is the core of 1-day
analysis: the fix tells you where to look, the diff tells you what, and the
pre-patch reachability tells you how.

## When to Use

- Comparing two versions of the same binary (DLL, ELF, driver) to find what a
  security update changed
- Turning a CVE advisory or Patch-Tuesday bulletin into the specific vulnerable

# Hunting Web Backdoors

This is not a vulnerability audit. You are looking for code an attacker
**already planted** — a webshell, a one-line eval backdoor, a fake plugin, a
malicious line appended to a legitimate file. The weakness that let them in is
`auditing-php-applications`' job; this skill finds what they left behind.

Two things make it hard. The malicious code is deliberately hidden — obfuscated,
split, or buried in a tree of thousands of legitimate files — so a naive grep
misses it. And the tells (`eval`, `base64_decode`, dynamic calls) appear in
plenty of benign code, so a naive grep also drowns you in false positives. The
work is the discrimination.

## When to Use

# Maintaining Engagement State

An engagement lasts weeks. A session does not. The gap between those two facts
is where work gets repeated, findings lose their evidence, credentials become
unattributable, and artifacts get left on production because nobody wrote down
that they were placed.

This is not administrative overhead bolted onto the real work. **Provenance is
what makes a finding reportable, and the artifact register is what makes
cleanup possible.** Neither can be reconstructed afterwards from terminal
scrollback.

Assume everything not written to the record is lost: not merely forgotten, but
*silently* lost, so the next session confidently redoes it or contradicts it.

# Mapping ATT&CK Techniques

ATT&CK is a shared vocabulary, not a methodology. Its value is that offense,
detection, and response can name the same behaviour — which makes this skill a
router, not a technique catalogue. It resolves a technique to the skill that
holds the actual procedure, and it runs the loop that connects the two sides.

## When to Use

- A request names a technique ID (`T1003.001`), a technique name
  ("Kerberoasting"), or a tactic ("we need lateral movement coverage")
- Converting a threat intel report or an adversary emulation plan into work
- Planning or reporting coverage against the matrix
- Running a purple team exercise: emulate, detect, validate, close the gap

# Orchestrating Vulnerability Research

One agent hunting one target rationalizes. It finds a "probably exploitable"
path, writes a confident paragraph, and grades its own paragraph as a finding.
The paragraph is not the bug. This skill is the harness that stops that: give
the hunt a bar it cannot talk its way around, split the target so pieces are
worked in parallel, and never let the agent that built a candidate be the one
that decides it is real.

It is a *loop*, not a pass. You run it until findings are proven or the target
is genuinely exhausted — not until the first plausible writeup appears.

## When to Use

# Reporting Security Findings

The report is the product. Findings that are not understood are not fixed, and
findings that cannot be reproduced are disputed. Most of the value an
assessment creates is destroyed or preserved in the write-up.

## When to Use

- Writing up a single vulnerability
- Producing a penetration test, code audit, or red team report
- Submitting to a bug bounty program or triaging inbound submissions
- Scoring severity and arguing priority with an engineering team
- Planning coordinated disclosure for an unpatched issue

# Reversing Browser Extensions

A browser extension is a small privileged program wedged next to every page the
user visits. Its security is almost entirely about a boundary: the content
script runs beside untrusted web content but can talk to a background context
that holds real permissions — cookies, tabs, the network, sometimes a native
process. Reversing an extension is reading that boundary and finding where the
privileged side trusts the unprivileged one.

## When to Use

- Analyzing a suspicious, over-permissioned, or unknown extension's behaviour
- Auditing an extension's manifest and message-passing for privilege leaks
- Investigating how a content script exposes background/native capabilities to a

# Reversing Flutter Apps

Flutter breaks both halves of the standard mobile workflow at once. Dart is
AOT-compiled to a native snapshot, so there is no dex for jadx to decompile —
and the Flutter engine ships its own BoringSSL with its own trust store, so it
ignores the system proxy *and* the user CA store, and your interception proxy
sees nothing. Neither failure is obvious from the symptoms, which is why
people burn hours on this before recognizing what they are looking at.

## When to Use

- `jadx` on the APK shows a near-empty `MainActivity` and little else
- The APK contains `lib/arm64-v8a/libflutter.so` and `libapp.so`, or
  `assets/flutter_assets/`

# Reversing Network Protocols

An undocumented binary protocol is reverse-engineered from two sides at once:
the wire, which shows you the bytes that actually flow, and the client, which
shows you the code that produced them. Neither alone is enough — the capture
tells you *what* varies, the client tells you *why* — and the deliverable is a
parser precise enough to decode, replay, and eventually fuzz the protocol.

## When to Use

- A proprietary or custom TCP/UDP protocol with no public specification
- Traffic Wireshark displays as raw `Data` bytes because no dissector matches
- Game, IoT, industrial, or C2 protocols you must decode from captures plus the
  client binary

# Reversing Obfuscated JavaScript

Client-side JavaScript ships the whole program to the reader — there is no
stripped binary here, only code deliberately made unreadable. That changes the
job: you are almost never recovering *missing* information, you are undoing a
transformation. Identify the transformation first, reverse it with the tool
built for it, and fall back to hand-written AST passes only for the custom
layer no off-the-shelf tool knows.

## When to Use

- A page or extension ships a large minified/bundled `.js` you need to read
- Code is full of `_0x1234` identifiers, a big string array, and a rotation IIFE
  at the top — the obfuscator.io signature

# Reversing React Native Apps

React Native apps are JavaScript wearing a native shell. That is good news —
the application logic ships as a bundle you can read — unless the bundle was
compiled to Hermes bytecode, in which case you need a decompiler and the
version compatibility problem becomes the whole task.

## When to Use

- `jadx` shows `ReactActivity`, `ReactNativeHost`, and little application logic
- The APK contains `assets/index.android.bundle` or `lib/*/libhermes.so`
- The IPA contains `main.jsbundle`
- You need to find API endpoints, secrets, or business logic in an RN app
- You need to patch or hook JavaScript-level behaviour

# Reversing Unity IL2CPP

Unity ships in two very different shapes, and identifying which one you have
is the entire first decision. A Mono build hands you decompilable .NET
assemblies. An IL2CPP build compiles C# to C++ to native code, and the C#
metadata lives in a separate file that you must recombine with the binary
before anything is readable.

## When to Use

- The APK contains `assets/bin/Data/Managed/Metadata/global-metadata.dat` and
  `lib/arm64-v8a/libil2cpp.so`
- The APK contains `assets/bin/Data/Managed/Assembly-CSharp.dll` (Mono build)
- The IPA contains `Frameworks/UnityFramework.framework`

# Reversing Xamarin and .NET MAUI Apps

Xamarin apps hide a complete .NET application inside an Android package. Once
you extract and decompress the assemblies you get near-source-quality C#, which
makes this one of the highest-return reversing jobs — but only if you get past
the container format, which changed twice and defeats naive unzipping.

## When to Use

- The APK contains `lib/*/libmonodroid.so`, `libmonosgen-2.0.so`, or
  `libxamarin-app.so`
- The APK contains `assemblies/assemblies.blob` or `assemblies/*.dll`
- `jadx` shows only `mono.MonoPackageManager` and Xamarin bootstrap classes
- An IPA contains `.dll` files or a `Frameworks/Mono*` layout

# Reviewing Code Changes

Reviewing a diff is not auditing a codebase in miniature. The diff shows you
what changed but hides what the change *means* — the caller that now receives
untrusted data, the check that used to run, the assumption that no longer
holds. Reviewing only the added lines is the standard way to miss the bug.

## When to Use

- Security review of a pull request, branch, or commit range
- Pre-commit or pre-merge check on your own changes
- Assessing risk of a dependency bump or config change
- Reviewing an AI-generated change before it ships

# Reviewing Cryptography

Almost no real system is broken by cryptanalysis. They are broken by misuse:
a reused nonce, unauthenticated ciphertext, a comparison that returns early,
a key checked into git. Review for misuse, and leave primitive design to
cryptographers.

## When to Use

- Auditing code that encrypts, decrypts, signs, verifies, or hashes
- Reviewing key management, rotation, and storage
- Assessing TLS/mTLS configuration and certificate validation
- Reviewing JWT, session token, and API signature schemes
- Checking password and secret storage

# Securing AI Systems

LLM applications break the assumption every other security control is built
on: that instructions and data are separable. In an LLM, data *is*
instructions. Every design that reads untrusted content and then acts has to
be evaluated with that in mind, and no amount of prompt engineering fixes it.

## When to Use

- Security review of an LLM-backed feature, chatbot, or copilot
- Threat modeling an agentic system: tools, autonomy, memory, multi-agent
- Reviewing an MCP server, tool definition, or plugin surface
- Assessing a RAG pipeline for data leakage and poisoning
- Evaluating model, dataset, and dependency supply chain

# Unpacking Protected Binaries

Static unpacking is a trap for anything beyond UPX. The reliable method is to
let the program unpack itself, then take the result out of memory. Almost every
protector, however sophisticated, must eventually produce executable code in a
readable page — that moment is what you are waiting for.

Run protected samples only in a contained environment; see `analyzing-malware`.

## When to Use

- `binwalk -E` shows uniformly high entropy across most of the file
- The import table has a handful of entries (`LoadLibrary`, `GetProcAddress`)
- Section names are absent, random, or `UPX0`/`.themida`/`.vmp0`

# Vetting Agent Extensions

An agent extension is not a library you call — it is text and configuration that
your model *reads as instructions* and tooling your agent *runs on your behalf*.
A malicious dependency has to wait for you to call it. A malicious skill is
already in the context window, and a malicious MCP server may execute the moment
the agent starts. The trust decision happens before either runs, and it is the
decision this skill is about.

This is an adoption gate, not a code audit. The question is not "does this
server have a CVE" — it is "if I install this, what can it make my agent do, and
what can it read on its way out."

## When to Use

# Analyzing Disk Images

A disk image is a frozen crime scene, and the whole discipline is preserving
that. Work only from a verified, read-only copy, prove nothing changed with
hashes at every step, and remember that the deleted and the unallocated often
say more than the live file system — because that is exactly what someone tried
to remove.

## When to Use

- You have an acquired disk image (`.E01`, `.dd`/`.raw`, `.aff4`, `.vmdk`, `.vhdx`) to examine
- Recovering deleted files, or reconstructing what was on a wiped or reformatted volume
- Building a file-system timeline or a full super-timeline across the whole image
- Carving files and artifacts out of unallocated space, slack, and free clusters

# Analyzing Linux Persistence

Linux persistence mechanisms are spread across dozens of locations that no
single tool checks comprehensively. The attacker needs only one you miss. The
work is a systematic sweep of every initialization path the kernel and
userspace honor, in a sequence that catches the common before the exotic.

## When to Use

- Investigating a compromised Linux host to find how the attacker kept access
- Forensic analysis of a Linux disk image or live system
- Looking for backdoors, unauthorized services, or rogue scheduled tasks
- Determining the full scope of attacker modifications during IR
- Validating that eradication removed every persistence mechanism

# Analyzing Malware

The analysis is the easy part. The part that goes wrong is containment: a
sample detonated on a machine that can reach production, or an IOC published
that burns an active investigation. Get the environment right first.

## When to Use

- Triaging a suspicious file, attachment, script, or dropped binary
- Determining a sample's capability, persistence, and command-and-control
- Extracting indicators for hunting and blocking
- Writing YARA or behavioural detection from a specimen
- Supporting an incident with sample-derived intelligence

# Analyzing Memory Images

Memory is the only place certain artifacts exist — injected code, decrypted
payloads, credential material, and network connections from processes that have
already exited. Disk forensics misses all of these. The work is getting the
image before it is lost, then asking the right questions in the right order.

## When to Use

- You have a memory dump (raw, LiME, EWF, crash dump, or VM snapshot) to analyze
- Investigating a compromised host and need artifacts that exist only in RAM
- Looking for injected code, process hollowing, or reflective DLL loading
- Extracting credential material — hashes, Kerberos tickets, cached credentials
- Identifying network connections and listening ports from a point-in-time capture

# Analyzing Network Traffic

Packet capture is ground truth the endpoint can lie about but the wire cannot:
every connection, DNS lookup, and byte transferred is recorded, whether or not
the host's logs survived. The analysis is turning a flat capture into a story —
who talked to whom, over what protocol, whether the pattern was human or
automated, and what left the network. You are reconstructing intent from
frames, not reading a verdict off a tool.

## When to Use

- A `.pcap` / `.pcapng` capture needs forensic review for intrusion evidence
- A suspected C2 beacon must be confirmed and its interval, jitter, and channel characterized
- Data exfiltration is suspected and you need to size it, time it, and name the destination

# Analyzing Phishing Emails

An email is a stack of claims — who sent it, where it came from, that its
links are safe — and phishing analysis is checking each claim against evidence
the sender could not forge: the Received chain, the authentication results,
and the true destination of every link and attachment. The From header is a
display, not a fact. Anyone can type any address into it; your job is to find
the evidence that agrees or disagrees.

## When to Use

- A user reports a suspicious email and you need a verdict and IOCs
- You have a `.eml` or `.msg` file to analyze offline
- You are handed raw headers and asked whether a message is spoofed

# Analyzing Shellcode

Shellcode is code with no container — no PE/ELF header, no imports table, no
fixed load address — so it must find everything it needs at runtime. That
self-reliance is exactly what gives it away: the PEB walk, the API hashing,
the position-independent GetPC trick are structural fingerprints you can read
even before you know what the payload does.

## When to Use

- A raw blob of position-independent code with no PE/ELF/Mach-O header
- A payload carved from an exploit, a macro, a loader, or a JS/HTA dropper
- A `\x`-escaped, `0x`-prefixed, base64, or XOR-obfuscated byte buffer
- A suspected Metasploit stager (reverse_tcp/https) or Cobalt Strike beacon stage

# Defending Kubernetes

Kubernetes is insecure in useful defaults, not in exotic bugs. The attacks that
land are RBAC that grants more than intended, pods that run privileged because
nothing stops them, a flat pod network, and mounted service-account tokens with
cluster-wide reach. Defense is mostly closing those, in priority order, and
being able to see when someone tries.

This is the counterpart to `attacking-eks-gke-aks` and `exploiting-containers`:
read those to know what the attacker does; use this to know what to enforce and
what to watch.

## When to Use

# Engineering Detections

A detection is a hypothesis about attacker behaviour, expressed as a query,
that a human will be paged for. Two properties decide whether it is worth
deploying: does it fire on the behaviour, and does it stay quiet otherwise.
Most rules fail the second test, and the cost is paid by whoever is on call.

## When to Use

- Writing a new detection rule from a TTP, a sample, or an incident
- Reviewing or tuning an existing rule that is noisy or silent
- Converting threat intelligence into deployable detection content
- Assessing detection coverage against ATT&CK
- Setting up detection-as-code: repo layout, testing, CI, deployment

# Hardening Cloud Posture

A CSPM scan returns a thousand findings. Almost none of them are the way in.
The job is not to close a thousand findings; it is to find the handful that
form an attack path and close those, then set guardrails so they cannot recur.
Posture work that treats every finding as equal drowns the real one.

The organizing principle: **identity is the perimeter.** In cloud, the attack
path is almost always a chain of IAM permissions, not a network hop. Rank by
"what does this let a principal reach?", not by a scanner's severity label.

## When to Use

- Reviewing an AWS/Azure/GCP account or organization's security posture

# Hunting Threats

Hunting starts from an assumption of failure: the controls are deployed, no
alert has fired, and the adversary may still be present. The output is not
usually a compromise — it is a detection, a telemetry gap, or a documented
negative result. Hunts that only count as successful when they find something
degrade into confirmation bias.

## When to Use

- Proactively searching for compromise that detection missed
- Testing a specific hypothesis about attacker behaviour in your environment
- Operationalizing a threat intel report against your telemetry
- Validating that a control or detection actually works in production

# Investigating AWS Incidents

In AWS an incident is reconstructed from logs the attacker usually could not
delete -- CloudTrail, VPC Flow Logs, and the control plane's own record of every
API call. The investigation is therefore a log-correlation exercise anchored on
the compromised principal: the access key or assumed role, and the sequence of
API calls it made. Find the principal, pull every event it generated, and the
rest of the intrusion falls out of the timeline.

## When to Use

- Exposed or leaked AWS access keys -- committed to a repo, in a pastebin, or flagged by AWS abuse
- Anomalous CloudTrail activity -- API calls from unfamiliar regions, IPs, or user agents
- A GuardDuty finding -- credential exfiltration, tor traffic, crypto-mining, or anomalous IAM behavior

# Investigating Azure Incidents

In Azure the control plane logs almost everything through Azure Resource
Manager, so an incident is reconstructed from the Activity Log and the
resource/data-plane logs, anchored on the identity that made the calls -- a
user, a service principal, or a managed identity. The recurring trap is that
identity lives in Entra while the damage lives in the subscription: you must
correlate across both planes, because the Activity Log tells you *what* was done
to a resource but the Entra sign-in log tells you *who* held the token and from
where.

## When to Use

- Suspected Azure resource compromise -- a subscription, resource group, or VM behaving as though someone else controls it

# Investigating GCP Incidents

The completeness of a GCP investigation is decided before the incident, by
which audit logs were enabled. The single most damaging mistake is reading an
empty query result as "nothing happened" when the real answer is "that log
category was never turned on." Establish visibility first; conclude second.

GCP's audit model is not AWS's and not Azure's. Two categories are always on
and two are mostly off, and knowing which is which is the difference between a
scoped investigation and a false all-clear.

## When to Use

- Responding to a suspected compromise in a GCP project or organization

# Investigating M365 and Entra ID

M365/Entra investigations differ from on-premises DFIR -- there are no disk
images, no memory dumps, and no event logs you can collect yourself. Everything
comes from API queries against Microsoft's log stores, several of which require
E5 licensing or advanced audit to retain what you need. Knowing which logs
exist, which ones are missing, and how long they last is half the investigation.

## When to Use

- Business email compromise (BEC) -- unauthorized mailbox access, forwarding, or impersonation
- Entra ID account compromise -- suspicious sign-ins, token replay, credential stuffing
- Suspicious OAuth consent grants -- third-party apps with excessive permissions
- Mailbox rule manipulation -- inbox rules hiding attacker communications or forwarding mail

# Investigating Windows Endpoints

Windows records execution, persistence, and access in dozens of artifacts the
attacker rarely cleans completely. The event logs are only the surface -- the
registry, prefetch, amcache, and the file-system journals corroborate or
contradict them. The investigation is cross-referencing independent artifacts
into one timeline that no single cleared log can defeat.

## When to Use

- Triaging a compromised or suspicious Windows host, live or from an image
- Working through a KAPE, Velociraptor, or EDR triage collection
- Reconstructing what executed on a Windows machine and in what order
- Parsing EVTX / Sysmon / PowerShell logs to reconstruct attacker activity

# Managing Vulnerabilities

A scanner returns ten thousand findings, most rated High or Critical, and the
team can patch a few hundred a month. Vulnerability management is the function
that decides *which* few hundred — and the default of "sort by CVSS descending"
is close to the worst possible order, because CVSS measures theoretical
severity, not the probability that this vulnerability, on this asset, gets
exploited.

The whole discipline is turning an undifferentiated backlog into a defensible
order of operations that a limited team can actually execute.

## When to Use

# Producing Threat Intelligence

Intelligence is not a pile of indicators — it is analysis that reduces a
decision-maker's uncertainty. An IOC with no context, no confidence, and no
recommended action is data, not intelligence. Attribution is a claim you must
be able to defend from evidence, not a guess dressed in a threat-actor name.
The test of a finished product is simple: did someone decide something
differently because of it?

## When to Use

- Pivoting from a domain, IP, hash, TLS certificate, or registrant to related
  infrastructure
- Tracking a threat actor or campaign over time

# Responding to Incidents

Two questions drive every incident: **how far did they get**, and **are they
still here**. Everything else — the malware, the CVE, the root cause — is
supporting detail. Answer those two in order and the response follows.

## When to Use

- Suspected or confirmed compromise of a host, account, or cloud tenant
- Forensic analysis of a disk image, memory capture, or log set
- Reconstructing what an attacker did and when
- Scoping blast radius and deciding containment
- Writing a postmortem or a regulator/customer-facing incident narrative

# Triaging Security Alerts

Triage is the highest-volume work in security and the least written about. The
output is a **disposition you can defend later** — most often to someone asking
why an alert that preceded a breach was closed.

Three properties make it hard. The overwhelming majority of alerts are not
incidents, so the prior is against you on every single one. The cost of the two
error types is wildly asymmetric — a wrongly escalated alert wastes hours, a
wrongly closed one costs the breach. And the queue keeps arriving, so unbounded
care on one alert is care stolen from the next.

## When to Use

# Writing Sigma Rules

Sigma is the common language for detection logic -- write once, convert to any
SIEM. The value is portability and reviewability, but only if the rule is
precise: a Sigma rule that matches everything is worse than no rule, because it
consumes analyst time and trains the team to ignore alerts. The work is
specificity without brittleness.

## When to Use

- Translating a TTP, threat intel report, or incident finding into a portable detection rule
- Writing vendor-agnostic detection logic that converts to multiple SIEM backends
- Building or maintaining a detection-as-code pipeline centered on Sigma
- Reviewing or tuning existing Sigma rules for precision and false-positive reduction

# Writing YARA Rules

A good YARA rule matches the malware's *nature* — its code, its structure, its
unavoidable constants — not its *costume*, which is a filename or a mutable
string that changes on the next build. Match the nature and the rule survives
recompilation and catches the whole family; match the costume and you catch one
sample once. The entire craft is choosing strings and a condition that are both
specific enough to avoid false positives and durable enough to generalize.

## When to Use

- Writing a YARA rule to detect a malware family, tool, or capability
- Creating a signature for a file or in-memory artifact from a known sample
- Turning IOCs or a captured specimen into a portable, testable detection

# Abusing AD CS

A certificate authority in an Active Directory domain is usually the shortest
path from a standard user to domain administrator, because certificate
templates are permission objects that almost nobody audits. A single template
that lets the enrollee supply their own subject name is a full domain
compromise, and it is the default on more networks than it should be.

Only against domains you are authorized to test.

## When to Use

- The domain has a CA (`pKIEnrollmentService` objects exist)
- `certipy find` or BloodHound reports vulnerable templates

# Abusing CI/CD Pipelines and OIDC Federation

CI/CD pipelines are high-privilege execution environments, often with direct
cloud IAM access, deploy credentials, and signing keys. OIDC federation turns
a repository write into cloud credential issuance when the trust policy is too
broad. A single misconfigured workflow or a wildcard subject claim can bridge
the gap from "can open a pull request" to "has production cloud access."

## When to Use

- Assessing GitHub Actions, GitLab CI, or Jenkins for exploitable misconfigurations
- Testing OIDC federation trust policies between CI providers and cloud platforms
- Extracting secrets, tokens, or credentials from pipeline execution environments
- Evaluating self-hosted runner isolation and shared runner risk

# Attacking Active Directory

## When to Use

- AD reconnaissance and enumeration
- Kerberos-based attacks
- Credential dumping from domain controllers
- Lateral movement within domains
- BloodHound attack path analysis
- Domain persistence techniques

## When NOT to Use

- **Non-Windows / Linux-only environments** — use `enumerating-network-services`

# Attacking Bluetooth and NFC

Bluetooth and NFC share a property with early Wi-Fi -- the protocols were designed for convenience in a trusted physical environment, and the trust assumption no longer holds. BLE devices routinely transmit sensitive data in cleartext because the GATT characteristic was "internal", and NFC access cards rely on cryptography that was broken years ago. Physical proximity is not access control.

## When to Use

- Assessing BLE peripherals or IoT devices with Bluetooth interfaces
- Testing NFC-based physical access controls (badge readers, door locks)
- Evaluating contactless payment card or transit card security
- Pentesting Bluetooth Classic services (RFCOMM, OBEX, SDP)
- Sniffing or intercepting BLE communication between device and app
- Cloning or replaying NFC/RFID credentials

**Scope and authorization.** RF work has a legal profile the rest of pentesting

# Attacking Managed Kubernetes (EKS, GKE, AKS)

Managed Kubernetes is a special target because it operates across two
independent authorization planes: the cloud provider's IAM layer and
Kubernetes' own RBAC layer. Each plane has its own identities, policies, and
trust boundaries. The escalation paths live at the seams -- where a Kubernetes
service account maps to a cloud IAM role, where a pod inherits a node's cloud
credentials via the instance metadata service, or where a cluster-admin
binding was granted through a cloud identity mapping that nobody audits. An
attacker who understands only one plane misses the paths that cross into the
other.

Only against systems you are authorized to test.

# Attacking Entra ID

Entra ID (formerly Azure AD) is the identity control plane for Microsoft 365,
Azure, and thousands of SaaS integrations. Compromising it grants access to
everything those identities protect: mailboxes, SharePoint, Azure
subscriptions, and any application that trusts the tenant. Despite this, Entra
ID environments are routinely less monitored than on-premises Active Directory.
Most organizations lack equivalent detection coverage for cloud identity
attacks, and the attack surface -- OAuth tokens, application consent, service
principals, Conditional Access gaps -- is fundamentally different from
traditional AD.

Only against tenants you are authorized to test.

# Attacking GraphQL

GraphQL moves authorization from routes to resolvers, and most teams do not
move their access control with it. The REST habit of protecting `/admin/*` has
no equivalent when every operation arrives at one endpoint — so the recurring
finding is not an exotic GraphQL bug, it is an ordinary authorization failure
on a field nobody thought to guard.

## When to Use

- The target exposes `/graphql`, `/graphiql`, `/v1/graphql`, `/api/graphql`
- Request bodies contain `query`, `mutation`, `subscription`, or `operationName`
- Responses have the `{"data": ..., "errors": [...]}` envelope
- A mobile or SPA client posts GraphQL to a backend

# Attacking gRPC and Protobuf Services

gRPC breaks the tooling assumption that a request is readable text over
HTTP/1.1. Burp shows a binary blob or nothing at all, and without the schema
you cannot even name the methods. Recover the schema and it becomes an
ordinary API test — with the twist that gRPC services are frequently internal
services newly exposed, which means their authorization is often weaker than
the REST API in front of them.

## When to Use

- Traffic uses HTTP/2 with `content-type: application/grpc`
- A request or response body is opaque binary with no JSON structure
- The app is a mobile or desktop client talking to a backend over protobuf

# Attacking Hardware Interfaces

Physical access changes the game: the debug ports, flash chips, and boot process
the vendor assumed were private are all reachable. The work is finding the
interfaces on the board, using them to reach a shell or dump the firmware, and
judging whether the device's secure-boot and RF designs actually hold. Almost
everything here needs the device in hand and permission to open it.

## When to Use

- You have physical access to an embedded device or PCB and need to find its
  debug/serial/flash interfaces
- Getting a UART console or root shell, interrupting a bootloader, or halting the
  CPU over JTAG/SWD

# Attacking JWT

A JWT is not a credential you are meant to read — it is a signature-verification
decision the server makes on bytes you control. Every field, including the
`alg` header that tells the server *how* to check the signature, is
attacker-supplied. The classic failures all come from the server trusting the
token's own header to decide how to verify it, or from a secret weak enough to
recover offline.

Only against systems you are authorized to test.

## When to Use

- A request carries a token in three base64url parts joined by dots, typically

# Attacking Kerberos Delegation

Delegation lets a service impersonate users to other services. Every form of it
is a controlled way to become someone else, and each has a misconfiguration
that removes the control. RBCD in particular turns a common, low-looking
permission — write access to a computer object — into full compromise of that
host, which is why it is the delegation attack that comes up most.

Only against domains you are authorized to test.

## When to Use

- BloodHound flags `Unconstrained`, `Constrained`, or `RBCD` delegation
- You control an account with an SPN, or `GenericWrite`/`GenericAll` over a

# Attacking OAuth and OIDC

OAuth is a delegation protocol whose security lives entirely in parameters the
browser forwards — `redirect_uri`, `state`, and `scope` — so most breaks are the
authorization server or the client trusting one of those a little too much. The
token is the prize; the flow is the attack surface. Follow the redirect that
carries the code, and you follow the credential.

Only against systems you are authorized to test.

## When to Use

- A login page offers "Sign in with Google / Microsoft / GitHub / Apple" or any
  federated identity button

# Attacking SAML

SAML security is XML signature validation, and XML signatures are notoriously
hard to validate correctly. The assertion is signed — but which element is
signed, what the XML parser reads, and what the application ultimately trusts
can be three entirely different things. That gap is XML Signature Wrapping,
and it is the reason SAML breaks far more often than its cryptography suggests.

Only against systems you are authorized to test.

## When to Use

- A request or redirect carries a `SAMLRequest` or `SAMLResponse` parameter
- Base64 (plus DEFLATE for the redirect binding) decodes to XML containing

# Attacking Serverless

Serverless changes the attack surface from hosts to events. There is no SSH, no
persistent shell, no OS to enumerate in the traditional sense. The execution
environment is ephemeral, but the IAM role attached to it is not, and that role
is almost always the real target. A compromised Lambda function does not give you
a server — it gives you a set of AWS credentials that refresh automatically,
have no MFA, and were scoped by a developer who optimized for "make it work"
rather than least privilege. The same pattern holds across Azure Functions, GCP
Cloud Functions, and edge runtimes, with minor variation in where the credentials
live and how the isolation boundary is drawn.

## When to Use

# Attacking Wireless Networks

## When to Use

- WiFi penetration testing
- Wireless network security assessment
- WPA/WPA2/WPA3 cracking
- Evil Twin and rogue AP attacks
- Wireless reconnaissance

## When NOT to Use

- **Wired network attacks** — use `enumerating-network-services`
- **Cracking the captured handshake** — use `cracking-passwords`

# Bypassing Mobile Pinning

Most time lost here is spent bypassing pinning that was never there. An empty
proxy has at least six causes, and the fix for each is different — one of them
is not pinning at all but Android's default distrust of user CAs, and another
is that the app has its own TLS stack and never saw your proxy. Diagnose
before you reach for a bypass script.

Use only against apps you are authorized to test.

## When to Use

- Burp/mitmproxy/Charles shows a TLS handshake failure from a mobile app
- The proxy shows nothing while the app clearly reaches the network

# Bypassing Root and Jailbreak Detection

Detection is almost never one check. It is a dozen cheap checks scattered
across the app, plus — increasingly — one hardware-backed attestation that no
hook can touch. Hooking checks one at a time is whack-a-mole; the work is
finding the layer the app actually depends on.

Use only against apps you are authorized to test.

## When to Use

- The app exits on launch, shows "rooted device detected", or degrades silently
- The app works on a stock device but not on your test device or emulator
- Frida attaches and the process dies immediately, or `frida-ps` shows nothing