T09 · Insecure Skill Coding Practices
Error
- Location
references/qga-execution.md:76- Finding
Proxmox API token exposure with disabled TLS certificate verification
- Content
View full analysis
- Remediation
View remediation
Security audit
Proxmox Dc Lifecycle
Security checks for vulnerabilities and agentic risk
Overview
This is a disclosed domain-controller rebuild runbook, but it needs Review because some credential and Proxmox API examples can expose highly privileged access.
Install only for trusted administrators operating a controlled Proxmox and Active Directory environment. Do not use the documented curl -sk API-token pattern; require TLS validation, protect tokens from process listings, and scope tokens narrowly. Treat autounattend XML and ISO files as secrets, create them in a private 0700 work directory, delete every copy, and rotate any generated local Administrator or DSRM password immediately after use. Require explicit human confirmation before AD object deletion, forced demotion, promotion, or VM disk wipe.
Vulnerability Patterns
- Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
- Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
- Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
- Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
- Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)
T09 · Insecure Skill Coding Practices
Warning
- Location
references/os-reinstall.md:26- Finding
Plaintext Administrator credential artifacts created without mandatory host-side access controls
- Content
View full analysis
/template/iso/unattend-.iso ``` ```text The script puts `autounattend.xml` at the ISO root so Windows Setup auto-detects it. Generate the admin password as a throwaway random; show only its sha256 fingerprint; delete the ISO right after install. ``` ### Technical Analysis The workflow requires an Administrator password to be embedded in `autounattend.xml`. That XML is then copied into an ISO and placed on Proxmox ISO storage. Consequently, the credential may exist in at least three locations: - The original `autounattend.xml`. - `/tmp/unattend.iso`. - The ISO copy in Proxmox storage. The documentation says to delete the ISO after installation, but it does not require: - A restrictive `umask`. - Mode `0600` on the source XML and generated ISO. - A root-owned private working directory. - Explicit deletion of every carrier, including the original XML and `/tmp/unattend.iso`. - Exclusion of the artifacts from backups or storage snapshots. - Immediate post-install credential rotation. The password is random and intended to be temporary, which reduces its useful lifetime. However, it remains a plaintext privileged credential until it is rotated. Ordinary deletion also does not remove copies already captured by backups, snapshots, storage replication, or another local process. ### Attack Path 1. The operator creates an `autounattend.xml` containing the plaintext local Admini ...[truncated 1444 chars]- Remediation
View remediation
Vulnerability Patterns
- Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
- Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
- Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
- YARA SignaturesMalware Match, Webshell Match, Cryptominer Match
- MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Findings (30)
Tp4
High
- Category
- MCP Tool Poisoning
- Confidence
- 98% confidence
- Finding
The declared description presents a high-level skill for safely rebuilding and re-promoting a Windows AD domain controller on Proxmox, with extensive AD-specific checks and lifecycle actions. The supplied code chunk does only one narrow supporting task: package an autounattend.xml file into an ISO for Windows Setup. While this could be a component used during a reinstall step, the code itself does not implement the declared primary behavior or the stated safety-critical AD operations. Therefore the description materially overstates what this code chunk actually does.
- Content
Tp4
High
- Category
- MCP Tool Poisoning
- Confidence
- 97% confidence
- Finding
The declared description is a high-level, safety-sensitive Active Directory domain controller rebuild/remediation skill with explicit lifecycle steps and safeguards. The supplied code chunk does not implement that workflow; it is only a low-level utility to run arbitrary PowerShell commands in a Windows VM through Proxmox QEMU guest agent. While the description briefly mentions Windows AD operations through QEMU guest agent, this code is materially broader and more generic than the declared purpose, and it lacks the domain-controller-specific logic and protections central to the description. Therefore this chunk's actual behavior is not accurately represented by the declared purpose.
- Content
YARA rule 'info_stealer': Information stealer patterns (credential harvesting, browser data theft) [malware]
High
- Category
- YARA Match
- Confidence
- 75% confidence
- Finding
YARA rule matched a known malware signature (reverse shell, backdoor, ransomware, C2 framework, or info stealer).
- Content
md --- name: proxmox-dc-lifecycle description: >- Rebuild, replace, demote, reinstall, rejoin, or re-promote a Windows Active Directory domain controller VM on Proxmox: demote it, clean metadata from a healthy DC, reinstall via autounattend, then promote it again. Use for Proxmox-hosted DC rebuild requests and symptoms that point to rebuild: NTDS will not start, ntds.dit is missing, promotion fails with trust-relationship or "no computer account" errors, demotion hangs, dcdiag/replication fails on one DC, or a broken DC VM needs to come back. Also use for Windows AD operations through QEMU guest agent (qm guest exec). Rule: do not corrupt Active Directory; verify replication and FSMO before and after every lifecycle step, change one DC at a time, and never destroy or recreate a VM while AD still has NTDS Settings for that DC. --- # Proxmox DC Lifecycle Rebuild a domain controller that lives as a VM on a Proxmox hypervisor, one DC at a ti
YARA rule 'info_stealer': Information stealer patterns (credential harvesting, browser data theft) [malware]
High
- Category
- YARA Match
- Confidence
- 75% confidence
- Finding
YARA rule matched a known malware signature (reverse shell, backdoor, ransomware, C2 framework, or info stealer).
- Content
md --- name: proxmox-dc-lifecycle description: >- Rebuild, replace, demote, reinstall, rejoin, or re-promote a Windows Active Directory domain controller VM on Proxmox: demote it, clean metadata from a healthy DC, reinstall via autounattend, then promote it again. Use for Proxmox-hosted DC rebuild requests and symptoms that point to rebuild: NTDS will not start, ntds.dit is missing, promotion fails with trust-relationship or "no computer account" errors, demotion hangs, dcdiag/replication fails on one DC, or a broken DC VM needs to come back. Also use for Windows AD operations through QEMU guest agent (qm guest exec). Rule: do not corrupt Active Directory; verify replication and FSMO before and after every lifecycle step, change one DC at a time, and never destroy or recreate a VM while AD still has NTDS Settings for that DC. --- # Proxmox DC Lifecycle Rebuild a domain controller that lives as a VM on a Proxmox hypervisor, one DC at a ti
Ae1
High
- Category
- analysis-evasion
- Confidence
- 100% confidence
- Finding
Referenced artifact was not completely inspected
- Content
md - `scripts/run-guest-ps.sh` — wrapper that runs base64'd PowerShell in a guest via QGA, with stdin secret passing.
Tool Parameter Abuse
High
- Category
- Tool Misuse
- Confidence
- 80% confidence
- Finding
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
- Content
/sc ONCE /st 00:00 /tr "powershell -NoProfile -ExecutionPolicy Bypass -File C:\Windows\Temp.hdc\run.ps1" /f schtasks /run /tn HDC_Demote
text Poll for completion via a status/marker file the script appends to; then `schtasks /delete /tn HDC_Demote /f` and wipe the temp dir (its locked cred file should already be deleted as the run script's first action). ## Forced removal (only if graceful is impossible)
YARA rule 'info_stealer': Information stealer patterns (credential harvesting, browser data theft) [malware]
High
- Category
- YARA Match
- Confidence
- 75% confidence
- Finding
YARA rule matched a known malware signature (reverse shell, backdoor, ransomware, C2 framework, or info stealer).
- Content
md eduledTask` cmdlets. Consider bumping the DC's RAM if it recurs. ## NTDS won't start after a botched/interrupted demotion - **Signature:** box boots but AD is down. `net start NTDS` → error **1058** ("service disabled") OR error **3534**/"did not report an error". Other AD services may be fine. - **Cause:** an interrupted forced removal left NTDS (and ADWS) set to **Disabled**, and/or deleted `ntds.dit`. - **Diagnosis:** check the registry start type (`HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Start`: 2=Auto,3=Manual,4=Disabled) and whether `C:\Windows\NTDS\ntds.dit` exists. - If only Disabled (dit present): re-enable (`Set-Service NTDS -StartupType Automatic`) and start. Recoverable. - **If `ntds.dit` is MISSING:** the box was effectively force-demoted at the DB level. It can NOT come back as a DC by fixing services. Treat it as already-demoted locally and verify/clean the AD side (it may already be done), then rebuild the OS. This is good news for the rebuild path, not a dis
Chaining Abuse
High
- Category
- Tool Misuse
- Confidence
- 75% confidence
- Finding
Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.
- Content
5. Attach media, set boot, wipe-and-install ← DESTRUCTIVE (confirm first)
Confirm the Phase-3 gate is green (no
nTDSDSAfor this DC) and get explicit operator confirmation to wipe this specific<vmid>before running:bash sudo qm shutdown <vmid> --timeout 60 || sudo qm stop <vmid> sudo qm set <vmid> --ide2 <isoStorage>:iso/<server>.iso,media=cdrom sudo qm set <vmid> --ide0 <isoStorage>:iso/virtio-win-<ver>.iso,media=cdrom sudo qm set <vmid> --ide1 <isoStorage>:iso/unattend-<dc>.iso,media=cdrom
Sudo/Root Execution
Medium
- Category
- Privilege Escalation
- Confidence
- 92% confidence
- Finding
The skill assumes execution on a Proxmox host with passwordless sudo/root-equivalent access, which greatly amplifies the blast radius of any misuse, prompt injection, or operator error. In this context, commands can directly alter hypervisor state and privileged guest operations, so a compromised or overly broad skill could cause destructive infrastructure changes.
- Content
}
text - You run ON the Proxmox host with passwordless `sudo` and `qm` at `/usr/sbin/qm`. There is no separate SSH hop — "ssh root@host" collapses to local `sudo qm`. - VMs expose the **QEMU guest agent (QGA)**. You drive Windows guests with `sudo qm guest exec <vmid> ... powershell.exe ...`. This is the execution backbone — see `references/qga-execution.md`. WinRM/PowerShell-Remoting between DCs is NOT used (it fails between DCs — see Gotchas). - The reference files speak in terms of these names ("the FSMO holder", "isoStorage", "a DC's vmid"). To use this skill, fill the block above for your environment; change nothing else.
Sudo/Root Execution
Medium
- Category
- Privilege Escalation
- Confidence
- 95% confidence
- Finding
Using
sudo qm guest execto run PowerShell inside Windows guests creates a powerful cross-boundary command-execution path from the hypervisor into domain controllers. If abused or fed untrusted input, it could execute arbitrary administrative actions inside sensitive AD systems, including demotion, promotion, credential handling, or destructive reconfiguration.- Content
text - You run ON the Proxmox host with passwordless `sudo` and `qm` at `/usr/sbin/qm`. There is no separate SSH hop — "ssh root@host" collapses to local `sudo qm`. - VMs expose the **QEMU guest agent (QGA)**. You drive Windows guests with `sudo qm guest exec <vmid> ... powershell.exe ...`. This is the execution backbone — see `references/qga-execution.md`. WinRM/PowerShell-Remoting between DCs is NOT used (it fails between DCs — see Gotchas). - The reference files speak in terms of these names ("the FSMO holder", "isoStorage", "a DC's vmid"). To use this skill, fill the block above for your environment; change nothing else. ## The lifecycle, in order
Sudo/Root Execution
Medium
- Category
- Privilege Escalation
- Confidence
- 90% confidence
- Finding
This step performs privileged snapshot operations immediately before destructive domain-controller changes. Although snapshots are a safety measure, the same privileged path could target the wrong VM or be paired with subsequent destructive actions, making this dangerous in a high-value AD/virtualization environment if identification and approval controls fail.
- Content
md 4. **Gate:** replication shows `0 fails`, FSMO are where you expect, the target DC holds none. Record this — it's your "known good." ### Phase 1 — Snapshot the target `sudo qm snapshot <vmid> predemote_<date> --description "..."`. Confirm with `qm listsnapshot <vmid>`. ### Phase 2 — Demote the target DC Run the demotion **locally inside the target guest** via QGA (NOT remoting from another DC). See `references/demotion.md` for the script and the two gotchas that will otherwise hang or fail it:
Sudo/Root Execution
Medium
- Category
- Privilege Escalation
- Confidence
- 80% confidence
- Finding
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
- Content
md ## Credential & secret handling Secrets are radioactive. Follow `references/qga-execution.md` precisely: pass passwords to the guest over **QGA stdin** (`--pass-stdin`), never on a process command line or `-EncodedCommand`. If a `creds.txt` convention is used, `chmod 600`, read it silently, delete it the moment it's loaded. Any cred file written into a guest must be deleted as the *first action* of the script that consumes it. For scheduled tasks, use `schtasks /rp *` (password from stdin), never `/rp "<pw>"`. Never echo a secret into chat, logs, or task XML. Show a sha256 fingerprint, never the value. **Know the boundary:** this skill runs on the Proxmox host, which has no password manager. It can generate throwaway randoms (local Administrator, DSRM) and apply them, but it cannot store or later reveal them — and must not pretend to. After a rebuild, hand off to the operator to set known break-glass values (and rotate any exposed credential) from a machine that has their secret manager. Full detail: `references/credential-handling.md`.
Sudo/Root Execution
Medium
- Category
- Privilege Escalation
- Confidence
- 70% confidence
- Finding
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
- Content
1. Read the VM's hardware (decides driver + partitioning)
bash sudo qm config <vmid> | grep -E '^virtio0|^scsi|^scsihw|^net0|^boot|^bios|^efidisk|^tpmstate'- Boot disk
virtio0⇒ viostor driver. AscsiNdisk onvirtio-scsi⇒ vioscsi. Inject both to be safe. bios: ovmf⇒ UEFI/GPT partitioning (EFI+MSR+Windows). SeaBIOS ⇒ MBR.
- Boot disk
Sudo/Root Execution
Medium
- Category
- Privilege Escalation
- Confidence
- 70% confidence
- Finding
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
- Content
1. Read the VM's hardware (decides driver + partitioning)
bash sudo qm config <vmid> | grep -E '^virtio0|^scsi|^scsihw|^net0|^boot|^bios|^efidisk|^tpmstate'- Boot disk
virtio0⇒ viostor driver. AscsiNdisk onvirtio-scsi⇒ vioscsi. Inject both to be safe. bios: ovmf⇒ UEFI/GPT partitioning (EFI+MSR+Windows). SeaBIOS ⇒ MBR.
- Boot disk
Sudo/Root Execution
Medium
- Category
- Privilege Escalation
- Confidence
- 70% confidence
- Finding
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
- Content
1. Read the VM's hardware (decides driver + partitioning)
bash sudo qm config <vmid> | grep -E '^virtio0|^scsi|^scsihw|^net0|^boot|^bios|^efidisk|^tpmstate'- Boot disk
virtio0⇒ viostor driver. AscsiNdisk onvirtio-scsi⇒ vioscsi. Inject both to be safe. bios: ovmf⇒ UEFI/GPT partitioning (EFI+MSR+Windows). SeaBIOS ⇒ MBR.
- Boot disk
Sudo/Root Execution
Medium
- Category
- Privilege Escalation
- Confidence
- 70% confidence
- Finding
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
- Content
1. Read the VM's hardware (decides driver + partitioning)
bash sudo qm config <vmid> | grep -E '^virtio0|^scsi|^scsihw|^net0|^boot|^bios|^efidisk|^tpmstate'- Boot disk
virtio0⇒ viostor driver. AscsiNdisk onvirtio-scsi⇒ vioscsi. Inject both to be safe. bios: ovmf⇒ UEFI/GPT partitioning (EFI+MSR+Windows). SeaBIOS ⇒ MBR.
- Boot disk
Sudo/Root Execution
Medium
- Category
- Privilege Escalation
- Confidence
- 70% confidence
- Finding
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
- Content
1. Read the VM's hardware (decides driver + partitioning)
bash sudo qm config <vmid> | grep -E '^virtio0|^scsi|^scsihw|^net0|^boot|^bios|^efidisk|^tpmstate'- Boot disk
virtio0⇒ viostor driver. AscsiNdisk onvirtio-scsi⇒ vioscsi. Inject both to be safe. bios: ovmf⇒ UEFI/GPT partitioning (EFI+MSR+Windows). SeaBIOS ⇒ MBR.
- Boot disk
Sudo/Root Execution
Medium
- Category
- Privilege Escalation
- Confidence
- 70% confidence
- Finding
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
- Content
1. Read the VM's hardware (decides driver + partitioning)
bash sudo qm config <vmid> | grep -E '^virtio0|^scsi|^scsihw|^net0|^boot|^bios|^efidisk|^tpmstate'- Boot disk
virtio0⇒ viostor driver. AscsiNdisk onvirtio-scsi⇒ vioscsi. Inject both to be safe. bios: ovmf⇒ UEFI/GPT partitioning (EFI+MSR+Windows). SeaBIOS ⇒ MBR.
- Boot disk
Sudo/Root Execution
Medium
- Category
- Privilege Escalation
- Confidence
- 70% confidence
- Finding
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
- Content
1. Read the VM's hardware (decides driver + partitioning)
bash sudo qm config <vmid> | grep -E '^virtio0|^scsi|^scsihw|^net0|^boot|^bios|^efidisk|^tpmstate'- Boot disk
virtio0⇒ viostor driver. AscsiNdisk onvirtio-scsi⇒ vioscsi. Inject both to be safe. bios: ovmf⇒ UEFI/GPT partitioning (EFI+MSR+Windows). SeaBIOS ⇒ MBR.
- Boot disk
Sudo/Root Execution
Medium
- Category
- Privilege Escalation
- Confidence
- 70% confidence
- Finding
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
- Content
1. Read the VM's hardware (decides driver + partitioning)
bash sudo qm config <vmid> | grep -E '^virtio0|^scsi|^scsihw|^net0|^boot|^bios|^efidisk|^tpmstate'- Boot disk
virtio0⇒ viostor driver. AscsiNdisk onvirtio-scsi⇒ vioscsi. Inject both to be safe. bios: ovmf⇒ UEFI/GPT partitioning (EFI+MSR+Windows). SeaBIOS ⇒ MBR.
- Boot disk
Sudo/Root Execution
Medium
- Category
- Privilege Escalation
- Confidence
- 70% confidence
- Finding
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
- Content
1. Read the VM's hardware (decides driver + partitioning)
bash sudo qm config <vmid> | grep -E '^virtio0|^scsi|^scsihw|^net0|^boot|^bios|^efidisk|^tpmstate'- Boot disk
virtio0⇒ viostor driver. AscsiNdisk onvirtio-scsi⇒ vioscsi. Inject both to be safe. bios: ovmf⇒ UEFI/GPT partitioning (EFI+MSR+Windows). SeaBIOS ⇒ MBR.
- Boot disk
Sudo/Root Execution
Medium
- Category
- Privilege Escalation
- Confidence
- 70% confidence
- Finding
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
- Content
1. Read the VM's hardware (decides driver + partitioning)
bash sudo qm config <vmid> | grep -E '^virtio0|^scsi|^scsihw|^net0|^boot|^bios|^efidisk|^tpmstate'- Boot disk
virtio0⇒ viostor driver. AscsiNdisk onvirtio-scsi⇒ vioscsi. Inject both to be safe. bios: ovmf⇒ UEFI/GPT partitioning (EFI+MSR+Windows). SeaBIOS ⇒ MBR.
- Boot disk
Sudo/Root Execution
Medium
- Category
- Privilege Escalation
- Confidence
- 70% confidence
- Finding
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
- Content
1. Read the VM's hardware (decides driver + partitioning)
bash sudo qm config <vmid> | grep -E '^virtio0|^scsi|^scsihw|^net0|^boot|^bios|^efidisk|^tpmstate'- Boot disk
virtio0⇒ viostor driver. AscsiNdisk onvirtio-scsi⇒ vioscsi. Inject both to be safe. bios: ovmf⇒ UEFI/GPT partitioning (EFI+MSR+Windows). SeaBIOS ⇒ MBR.
- Boot disk
Sudo/Root Execution
Medium
- Category
- Privilege Escalation
- Confidence
- 70% confidence
- Finding
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
- Content
1. Read the VM's hardware (decides driver + partitioning)
bash sudo qm config <vmid> | grep -E '^virtio0|^scsi|^scsihw|^net0|^boot|^bios|^efidisk|^tpmstate'- Boot disk
virtio0⇒ viostor driver. AscsiNdisk onvirtio-scsi⇒ vioscsi. Inject both to be safe. bios: ovmf⇒ UEFI/GPT partitioning (EFI+MSR+Windows). SeaBIOS ⇒ MBR.
- Boot disk
Sudo/Root Execution
Medium
- Category
- Privilege Escalation
- Confidence
- 70% confidence
- Finding
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
- Content
1. Read the VM's hardware (decides driver + partitioning)
bash sudo qm config <vmid> | grep -E '^virtio0|^scsi|^scsihw|^net0|^boot|^bios|^efidisk|^tpmstate'- Boot disk
virtio0⇒ viostor driver. AscsiNdisk onvirtio-scsi⇒ vioscsi. Inject both to be safe. bios: ovmf⇒ UEFI/GPT partitioning (EFI+MSR+Windows). SeaBIOS ⇒ MBR.
- Boot disk