The offensive role layer — recon → exploit → evasion, on a Kali/WSL2 base.
Explore the docs »
Red ↔ Blue
·
Report Bug
·
Request Feature
Table of Contents
dotfiles-Kali is the offensive Role layer — the one node in the fleet that
stacks three layers instead of two. The shared Core (zsh, tmux, Neovim,
git, starship, mise) is vendored under core/ via git subtree; on top sits the
Kali OS layer (Debian-family apt, built for WSL2); and on top of that sits a
unique offensive stage — engagement scaffolding and workspace workflow for
authorized engagements.
The one rule that matters: this is a public showcase repo, so engagement and client data never live in it. Everything goes under
~/engagements/(outside any git tree); the paranoid.gitignoreis only a backstop. Every tool here is for authorized work with written rules of engagement — the scope-first scaffolding exists to keep that discipline mechanical.
The full docs live on the documentation site; the defensive mirror is
dotfiles-Defense.
The system is three layers; Kali carries all three:
| Layer | Lives in | Owns |
|---|---|---|
| Core | dotfiles-core, vendored under core/ |
zsh, tmux, nvim, git, starship — identical everywhere |
| OS-native | os/kali.* (Debian-family apt, WSL2) |
package manager, clipboard, paths |
| Role (offensive) | offensive/ — unique to this repo |
engagement scaffolding + workspace workflow |
Kali on WSL2, and Git. WSL2 is NAT'd by default, so a listener / reverse
shell / C2 in Kali isn't reachable from your LAN until you enable mirrored
networking in the Windows-side %UserProfile%\.wslconfig (networkingMode=mirrored,
Win11 22H2+) — not /etc/wsl.conf.
git clone https://github.com/dotgibson/dotfiles-Kali ~/dotfiles-Kali
cd ~/dotfiles-Kali
./bootstrap.sh # apt base + offensive tools + Core/OS/offensive symlinks
wsl.exe --shutdown # from Windows, after dropping windows.wslconfig.examplecore/ is a vendored subtree and is already present in a clone — there is no
submodule step. Flags: --no-offensive (base + symlinks, skip the heavy tool
install), --links-only (just re-create symlinks).
The offensive stage loads after os and before local (… os offensive local),
so OS paths/clipboard resolve first and a machine override still wins:
offensive/offensive.zsh— the role-stage helpers (mkengagement,eng,logshell,nmapsweep,bhce, …), eachHAVE_*-guarded — no exploit codeoffensive/hacktheplanet,ippsec,exploitdev,evasion— the vim-folded field references (htp/ipp/xdev/evade)offensive/companion/— the ATT&CK-tagged red↔blue corpus, a vendored subtree of htpx (browsed withhtpx)PURPLE-TEAM.md— the defensive mirror ofhacktheplanet(Splunk/Sentinel)core/— vendored fromdotfiles-core(read-only here; edit upstream)
The tradecraft — the phase → ATT&CK → tool map, the OPSEC hygiene, and the tools
that bite (nxc/NetExec, BloodHound CE) — is written up on the hub:
This is a Role layer stacked on Core + an OS layer, so two vendored trees are off-limits and the rest is the offensive stage:
- Never hand-edit
core/oroffensive/companion/. Both are vendored subtrees (dotfiles-coreand htpx), overwritten on the next sync. Fix them upstream, then re-sync. - Offensive config goes in the
offensivestage, not incore/. If it's identical everywhere it's Core; if it changes with the OS it's the OS layer. - Keep the discipline. No payloads, loot, or targets in the repo; scope and
authorization come first. Green the lint gate (shellcheck +
bash -n/zsh -n; vendored trees excluded).
Bugs and ideas: open an issue.
Distributed under the MIT License. See LICENSE for more information.
Garrett Allen - @gerrrrt - garrettallen2@gmail.com - LinkedIn
Project Link: dotgibson