The objective, visible.
Captures the authorized objective and displays the proposed plan, evidence and approval state.
PENTESTING / KALI CONTROL MODE
An engagement, not a terminal. A proposed control mode that brings intent, scope, selected Kali workflows and inspectable evidence into one Windows-facing experience.
IN DEVELOPMENT / CONTROL EXPERIENCE PROPOSED
What’s better than a little Blue Team vs. Red Team security exercise with Kali Linux?
Automating the hell out of it through WSL on Windows.
The intended loop is repeatable: baseline, challenge, evidence, harden, retest. Budgets, scheduling, pause/resume and drift-triggered checks—not blind command loops.
Blueprint · p. 18Explore the proposed engagement lifecycle. Switch the lens or review a stage. Nothing executes, no approval is granted, and no targets are contacted.
Interface and lifecycle · pp. 19–22Record assets, authorization, objectives, exclusions, the testing window, allowed techniques and recovery contacts.
Use the approved snapshot to define the engagement scope. A discovered asset is not automatically an authorized target.
Six distinct responsibilities between a goal and an outcome. Intelligence proposes the work; deterministic policy and execution boundaries decide what is permitted.
Blueprint · p. 20Captures the authorized objective and displays the proposed plan, evidence and approval state.
Checks the exact action, environment, asset scope, time window, risk class and remaining budget.
Builds argument lists from reviewed templates. Model-generated shell strings are not the default execution path.
Runs a pinned tool with restricted mounts, credentials and network paths in an explicitly provisioned runtime.
Retains raw artifacts and separates tool failure, parsing ambiguity and evidence gaps.
Corroborates conclusions and binds limitations and results to the authorized plan and execution record.
A dedicated Kali WSL 2 profile is the proposed everyday lane. Mounts, Windows interoperability, network reachability, privileges and resources need explicit inspection and acceptance evidence. Higher-risk or hostile-code jobs belong in a separately hardened, tested VM—or remain unavailable.
WSL installation alone is not a blanket isolation guarantee.A capability ladder, not a claim to support every Kali tool. Prove a small tool set first. Expand when the next adapter produces a useful end-to-end outcome.
Blueprint · p. 21Review supplied logs, configurations, artifacts and existing inventories. Artifact-only work need not contact a target.
Bounded service and asset discovery within an explicit scope. New discoveries do not automatically expand authorization.
Selected application, host, identity and network controls, with declared versions, privileges and expected impact.
Corroborate a suspected weakness through separately approved, bounded methods and a recovery plan.
Correlate events, organize evidence and explain uncertainty without treating one alert as a confirmed compromise.
Hand verified findings to SRAOSHA for a reviewed, reversible hardening plan and separate change approval.
Repeat the relevant controlled checks. Close the finding only when the defined retest supports closure.
Dual-use by nature; operator-directed in practice. The name is not a moral guarantee. Targets, consequences, authority and evidence remain visible in the engineering contract.
Source status: the supplied review reports Kali catalog, WSL inventory and planning—not live target execution.
Assurance requirements · p. 23Changed addresses, redirects and new hosts outside the sealed scope must be blocked and recorded—not silently admitted.
No new work should dispatch. Active-worker containment must be attempted and measured; a stop cannot undo packets already sent.
The finding stays unverified. Missing artifacts, parser failures and changed data are not replaced with a plausible narrative.
End the job truthfully, preserve evidence and quarantine the environment when a worker crashes, stalls or loses connection.