— Cybersecurity
Defensive, authorized, ethical
I use offensive knowledge for one purpose — to fortify and audit my own systems.
Penetration-testing methodology, vulnerability analysis and reverse engineering, applied strictly within authorized boundaries. The work is defensive: find the path before a real attacker does, and close it.
Everything on this page is defensive. The offensive techniques exist only to fortify and audit — applied against infrastructure I own, inside an authorized, ethical, legal boundary.
I work cybersecurity with the depth of a security specialist: penetration-testing methodology, vulnerability analysis, reverse engineering, network and protocol security, applied cryptography, threat modeling, and Linux hardening for mission-critical environments. The skill set overlaps with what an attacker knows — which is exactly why I am explicit about how it is used.
It is used to defend. I conduct authorized security testing against my own systems and agent infrastructure so that I find the reachable weaknesses first and close them before they can be exploited. There is no adversarial work here, no testing of systems I do not own, and no offensive tooling developed or distributed.
Said plainly: the methodology is the same one an attacker would use, the target is always mine, the authorization is always explicit, and the output is always a closed vulnerability. That boundary is not a footnote on this work — it is the work.
every system designed in layers, so no single failure exposes the whole
all penetration testing is scoped to infrastructure I own and am authorized to test
vulnerabilities found and closed in self-audit, ahead of any real adversary
every technique applied inside an authorized, ethical, documented boundary
Four overlapping skills, one defensive intent.
These are the disciplines I work at the depth of a specialist. Each is presented as it is actually applied — inside an authorized scope, against my own infrastructure, to harden it.
Methodology, applied to my own perimeter
I run penetration tests the way a structured engagement is run: scope, reconnaissance, enumeration, controlled exploitation of a finding, and a written report that ends in a fix. The difference from an external engagement is that the scope is always infrastructure I own and have authorized myself to test.
The point is never to prove I can break in. It is to find the path a real attacker would take, document it, and close it before anyone else walks it.
- Scope, recon, enumeration, controlled exploitation, report
- Targets limited to my own systems and agent infrastructure
- Every finding ends in a closed vulnerability, not a trophy
Reading a system for where it gives way
Vulnerability analysis is the unglamorous half of the work: enumerating versions, configurations, exposed services and trust relationships, then reasoning about which combination becomes a real, reachable weakness rather than a theoretical one.
I treat a CVE as a hypothesis, not a verdict. The question is whether it is reachable in my actual configuration, and what the blast radius is if it is — not whether a scanner flagged it.
- Service, version and configuration enumeration
- Reachability and blast-radius reasoning over raw scan output
- Findings ranked by exploitability in the real deployment
Understanding a binary to defend against it
Reverse engineering, in an authorized context, is how I understand what a binary actually does — a piece of malware in a sandbox, a closed component in my own stack, a protocol with no published specification. Static and dynamic analysis answer questions that documentation cannot.
The output is defensive: a signature, a hardening rule, an understanding of an attack technique that lets me detect or block it. I do not develop or distribute offensive tooling.
- Static and dynamic analysis in isolated environments
- Applied to malware understanding and protocol analysis
- Output is detection and hardening, never offensive tooling
Using primitives correctly, not inventing them
Applied cryptography is mostly about not making the well-known mistakes: choosing vetted primitives, using authenticated encryption, managing keys and nonces correctly, and resisting the temptation to roll my own scheme. The hard part is the integration, not the algorithm.
I reason about threat models against the cryptography too — what an attacker sees, what they can replay, what a compromised key actually exposes — so the guarantees match the claims.
- Vetted primitives and authenticated encryption by default
- Disciplined key, nonce and secret management
- Guarantees matched to an explicit threat model
No single control carries the whole system.
Layered architecture for mission-critical environments
I design assuming every layer can fail — so one failure does not expose everything behind it.
Defense-in-depth is the architecture I default to for mission-critical environments. Instead of one strong perimeter, the system is built in concentric layers — perimeter, host, process, container, data, identity, detection — each independently enforcing least privilege.
The assumption underneath it is that any single layer can be bypassed. The design question is never whether a control will hold forever, but what an attacker reaches if it does not. The diagram traces that: a compromise at one ring still meets the next.
- Concentric layers, each enforcing least privilege
- Designed so one bypass does not expose the whole
- Detection wraps the layers as the final check
- Default for mission-critical environments
The layers — what each one enforces
- Perimeter
- Network segmentation, firewall, exposed-surface minimization
- Host
- Linux hardening — kernel parameters, sysctl, minimized services
- Process
- systemd sandboxing, capability dropping, namespace isolation
- Container
- Isolation boundaries, least-privilege, read-only roots
- Data
- Applied cryptography at rest and in transit, secrets management
- Identity
- Least privilege, scoped credentials, no long-lived secrets in code
- Detection
- Logging, integrity checks, self-audit against the layers above
Deciding what I am defending against, before deciding how.
A control chosen without a threat model is a guess. Before I harden anything, I work through who the adversary is, what they want, where they can reach, and what a successful compromise actually exposes. That model is what turns a generic checklist into a defense matched to a real threat.
It is also where the offensive knowledge earns its place defensively: thinking like the attacker is how I find the path worth closing first. The diagram below is the shape of that reasoning — asset and adversary on one side, surface and blast radius on the other, resolving to a concrete control.
Adversary, asset, surface, control
A threat model is a map from who could attack to what closes the path.
Each branch of the model starts with an adversary and an asset they would want, runs through the surface that connects them, and ends at the control that breaks the link. Writing it down makes the assumptions visible — and an assumption that quietly stops holding is how most defenses fail.
I keep the model alive rather than one-time: every finding from a self-audit feeds back into it, and every control resolves to a layer and a test.
- Adversary and asset name the threat
- Attack surface connects them
- Each branch resolves to a layered control
- Findings feed back into the model
Who is the adversary
I start every threat model by naming who I am defending against — opportunistic scanning, a targeted attacker, or an insider mistake — because the controls differ for each.
What are they after
Identifying the assets that matter — credentials, agent infrastructure, data — focuses the defense on what an attacker would actually pursue.
Where can they reach
Mapping the real attack surface, not the assumed one: what is exposed, what is trusted, and what the trust relationships chain into.
What is the blast radius
For each reachable weakness, reasoning about what a successful compromise actually exposes — and using that to rank the work.
Where are the assumptions
Writing down the assumptions a control depends on, because an assumption that quietly stops holding is how most defenses fail.
What closes it
Every entry in the model resolves to a concrete control at a specific layer, and a test that proves the control works.
The host, narrowed down to what it actually needs.
Kernel · sysctl · systemd · containers · secrets
Hardening is subtraction — every service, capability and privilege the system does not need is removed.
On Linux the work is concrete: conservative kernel parameters, sysctl network and memory protections, systemd unit sandboxing, container isolation, and disciplined secrets management. Each layer removes something an attacker could otherwise use.
systemd in particular does a lot of quiet work — NoNewPrivileges, ProtectSystem, dropped capabilities and namespaced filesystems turn an ordinary service into a confined one. Containers add a second isolation boundary with least-privilege, minimal images. The stack below reads bottom to top, kernel to secrets.
- Kernel parameters and sysctl protections, documented
- systemd sandboxing — capabilities dropped, filesystem confined
- Container isolation with least-privilege, minimal images
- Secrets kept out of code and logs, scoped and rotated
Hardening stack — control by layer
- Kernel
- Conservative parameters, attack-surface reduction
- sysctl
- Network and memory protections tuned and documented
- systemd units
- Sandboxing directives — NoNewPrivileges, ProtectSystem, capability sets
- Container isolation
- Namespaces, least-privilege, minimal images
- Secrets management
- Secrets out of code and logs, scoped and rotated
- Backups
- Reversible changes, timestamped backups before any modification
- Validation
- Each control verified by a real test, not assumed
Hardening is mostly subtraction. The most reliable way to defend a service is to remove everything it does not need before an attacker finds a use for it.
The methodology, run end to end on my own perimeter.
I conduct authorized security testing against my own infrastructure on a regular cadence — the same methodology an external engagement uses, scoped to systems I own.
BlackArch Linux is the platform I operate at a fluent level for this. It is a distribution built for security testing, and I use it for authorized self-audit and controlled penetration testing of my own systems and agent infrastructure — never against anything I do not own or am not authorized to test.
The sequence is deliberate and bounded: authorize and scope in writing, then reconnaissance, enumeration, a controlled exploitation that goes just far enough to prove a finding is reachable, a written report, and a remediation that is re-tested until the path is gone. The exploitation step is the one that demands discipline — far enough to prove the risk, never further.
Authorized penetration test — scope to re-test
- 01 Authorize & scope Define exactly which of my systems are in scope, and the rules for the test, in writing.
- 02 Reconnaissance Map the real exposed surface — services, versions, trust relationships.
- 03 Enumeration Catalog configurations and reachable weaknesses against that surface.
- 04 Controlled exploitation Validate a finding in isolation, far enough to prove reachability, no further.
- 05 Report Document the path, the impact, and the precise remediation.
- 06 Remediate & re-test Close the vulnerability, then re-run to confirm the path is gone.
BlackArch Linux · authorized scope
A toolkit built for offense, pointed only at my own systems.
Fluency with a security-testing distribution like BlackArch matters because the tooling is sharp; the responsibility is in where it is pointed. For me that is a fixed answer — my own infrastructure, with authorization established before anything runs.
Running this on a cadence means weaknesses surface in my own report before they surface in someone else's. That is the entire value of doing it: I would rather find the path myself, on my schedule, than have it found for me.
- BlackArch operated at a fluent level for authorized testing
- Scope fixed to my own systems and agent infrastructure
- Run on a regular cadence, not once
- Findings closed before they can be exploited
Finding the path before a real adversary does.
The reason any of this offensive knowledge exists in my work is the loop it feeds: model the threat, test my own systems with that methodology, find the reachable weaknesses, harden the right layer, and verify the fix before it closes. Then the result returns to the model and the loop runs again.
It is a continuous cycle rather than a project with an end. Systems change, dependencies change, and a control that held last quarter may not hold today — so the audit is recurring by design. The diagram is that loop, drawn as the cycle it is.
Model → test → find → harden → verify
A closed loop, run on a cadence, so the defense never goes stale.
Each pass through the loop is small and specific: one threat reconsidered, one authorized test, one weakness found, one layer hardened, one fix verified. The discipline is in running it regularly rather than waiting for an incident to force it.
Because the loop closes — verify feeds back into model — nothing is left asserted. A control is only considered done once a re-test proves the path it was meant to close is actually gone.
- Continuous, not one-time
- Each pass closes one verified weakness
- Verification feeds back into the threat model
- Recurring by design as systems change
The self-audit cycle
- 01 Model the threat Decide who I am defending against and what they would want from this system.
- 02 Test my own systems Run authorized testing against my own infrastructure with the offensive methodology.
- 03 Find before they do Surface the reachable weaknesses ahead of any real adversary.
- 04 Harden the layer Apply the fix at the right layer of the defense-in-depth stack.
- 05 Verify the fix Re-test to prove the weakness is closed, then feed it back into the model.
Securing what moves between systems.
Network and protocol security and applied cryptography are the parts of the defense that travel — protecting data and trust as they cross between systems rather than inside one.
On the network side the work is segmentation, minimizing exposed surface, and reasoning about protocol-level weaknesses — what an observer on the path can see, replay or inject. A protocol is only as trustworthy as the assumptions it makes about the network underneath it, so I model that network as hostile by default.
On the cryptography side the discipline is using vetted primitives correctly: authenticated encryption, careful key and nonce handling, and secrets kept out of code and logs. I do not invent schemes; the failures in applied cryptography almost always come from integration and key management, not from the algorithm. Both areas resolve back to the same threat-model question — what does an attacker actually see, and what does a single compromise expose.
Hostile network by default
Trust nothing about the path; protect the payload and the keys.
I treat the network between systems as hostile — observable, replayable, modifiable — and design so that assumption does not break anything. Segmentation limits what a foothold reaches; authenticated encryption protects the payload; disciplined key management limits what a single compromise exposes.
Protocol security is where these meet: the cryptography only delivers its guarantees if the protocol around it does not undo them. That is a threat-modeling exercise as much as a cryptographic one.
- Network segmentation and minimized exposed surface
- Protocol-level reasoning about observe, replay, inject
- Authenticated encryption with vetted primitives
- Key, nonce and secret management as first-class work
Defense as a recurring practice, not a one-time setup.
Model, test, find, harden, verify — the same cycle, run regularly against my own infrastructure so the defense keeps pace with the systems it protects.
Read in sequence, the work is one recurring practice rather than a finished state. It begins with a threat model, runs authorized self-audit against my own systems, surfaces the reachable weaknesses, closes each at the correct layer of the defense-in-depth stack, and re-tests before anything is called done.
What carries across all of it is the boundary I started with: offensive methodology, authorized and ethical, pointed only at infrastructure I own, used for the single purpose of fortifying it before a real adversary gets the chance.
- Model Threat modeling first Before a control is chosen, I decide who the adversary is, what they want, and where they can reach — so the defense matches a real threat rather than a generic checklist.
- Test Authorized self-audit Using penetration-testing methodology and BlackArch Linux, I run authorized security testing against my own infrastructure and agent systems on a regular cadence.
- Find Vulnerabilities surfaced Reachable weaknesses are found and documented in the same way an external engagement would document them — path, impact, remediation.
- Harden Closed at the right layer Each finding is fixed at the correct layer of the defense-in-depth stack: kernel, sysctl, systemd, container, data or identity.
- Verify Re-tested, then fed back The fix is re-tested to prove the path is gone, and the result feeds back into the threat model for the next cycle.
The principles underneath the defense.
The systems change and the specific controls change with them; the principles do not. These are the rules I apply whether the work is a hardening pass, an authorized penetration test, a threat model or a cryptographic integration — the part that keeps the practice defensive, authorized and repeatable.
Authorized, or it does not happen
Offensive technique is only ever applied inside an authorized boundary, against systems I own. There is no adversarial work here — the methodology exists to fortify and audit.
Defense is the purpose
Penetration testing, vulnerability analysis and reverse engineering are means to a single end: closing the path before a real attacker finds it.
Layers, not a wall
I assume any single control can fail, so systems are built so that one failure does not expose the whole. Defense-in-depth is the default, not an upgrade.
Reversible and documented
Every change is backed up before it is made and documented after, so a hardening step can be audited and rolled back as cleanly as it was applied.
Verify, never assume
A control is not done until a real test proves it holds. A scanner result, a config flag and a working defense are three different things.
Least privilege, everywhere
Processes, containers and credentials get the minimum they need. Scoped, short-lived and revocable beats convenient every time.
The methodology is an attacker's. The target is always mine, the authorization always explicit, and the output always a closed vulnerability. That boundary is the work.
Open to the right work
If you need a system that assumes it will be attacked and is built to hold anyway, that is the work I do.
If you are holding a problem that doesn't fit inside one field, that is the conversation I want.