[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71GKTHKABX7KGVF2M4JMPZ9":3,"skill-same:01M71GKTHKABX7KGVF2M4JMPZ9":107},{"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":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":14,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":6,"ownerDescription":47,"updatedAt":48,"install":49,"resources":62},"01M71GKTHKABX7KGVF2M4JMPZ9","vulnerability-SKILL.md",null,">\n  Vulnerability remediation SLAs define mandatory timeframes for patching or mitigating identified vulnerabilities based on severity, asset criticality, and exploit availability. Effective SLA programs","DCx7C5\u002Fai-marketplace","DCx7C5","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42419559?v=4","01M71C01G2AZV3NTNGWAWSHJPP","DC","01M71C01GQW6G50S2BYMS7PP3E",0,"MIT","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fvulnerabilities\u002Fremediation\u002Fvulnerability\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],"vulnerability","vulnerability SKILL md","skill md","availability","severity","sla","for","define","remediation","exploit","vulnerabilities","asset","patching","2026-11-10 10:12:30",false,"---\nname: vulnerability-SKILL.md\ndescription: \">\\n  Vulnerability remediation SLAs define mandatory timeframes for\\\n  \\ patching or mitigating identified vulnerabilities based on severity, asset criticality,\\\n  \\ and exploit availability. Effective SLA programs\"\n---\n# Implementing Vulnerability Remediation SLA\n\n## Overview\nVulnerability remediation SLAs define mandatory timeframes for patching or mitigating identified vulnerabilities based on severity, asset criticality, and exploit availability. Effective SLA programs drive accountability, ensure consistent remediation timelines, and provide measurable KPIs for vulnerability management maturity.\n\n\n## When to Use\n\n- When deploying or configuring implementing vulnerability remediation sla capabilities in your environment\n- When establishing security controls aligned to compliance requirements\n- When building or improving security architecture for this domain\n- When conducting security assessments that require this implementation\n\n## Prerequisites\n- Vulnerability scanning program producing regular findings\n- Asset inventory with criticality classifications\n- Ticketing system (Jira, ServiceNow, etc.) for remediation tracking\n- Executive sponsorship for SLA enforcement\n- Cross-functional agreement from IT operations, development, and security\n\n## Core Concepts\n\n### SLA Framework Components\n1. **Severity Classification**: CVSS base score + threat context (EPSS, KEV)\n2. **Asset Tiering**: Business criticality and exposure level\n3. **Remediation Timeframes**: Maximum days to remediate by category\n4. **Exception Process**: Documented approval for SLA extensions\n5. **Escalation Procedures**: Actions when SLAs are breached\n6. **Metrics and Reporting**: KPIs for compliance tracking\n\n### Recommended SLA Matrix\n| Severity | Tier 1 (Critical) | Tier 2 (Important) | Tier 3 (Standard) |\n|----------|-------------------|--------------------|--------------------|\n| Critical (CVSS 9.0-10.0) | 24-48 hours | 72 hours | 7 days |\n| High (CVSS 7.0-8.9) | 7 days | 14 days | 30 days |\n| Medium (CVSS 4.0-6.9) | 30 days | 45 days | 60 days |\n| Low (CVSS 0.1-3.9) | 90 days | 90 days | 90 days |\n| CISA KEV Listed | 24 hours | 48 hours | 7 days |\n\n### SLA Accelerators (Reduce SLA by 50%)\n- Exploit code publicly available\n- Active exploitation observed in the wild (CISA KEV)\n- Internet-facing asset affected\n- EPSS score > 0.5 (50% exploitation probability)\n- Previous breach via similar vulnerability type\n\n## Workflow\n\n### Step 1: Define Asset Tiers\n```\nTier 1 (Critical Assets):\n- Customer-facing production systems\n- Payment processing infrastructure\n- Domain controllers and identity systems\n- Core network infrastructure (firewalls, routers)\n- Databases containing PII\u002FPHI\u002FPCI data\n\nTier 2 (Important Assets):\n- Internal production applications\n- Email and collaboration systems\n- Development\u002Fstaging environments with production data\n- Backup and recovery infrastructure\n- VPN and remote access gateways\n\nTier 3 (Standard Assets):\n- End-user workstations\n- Development\u002Ftest environments\n- Print servers and peripheral management\n- Non-critical internal tools\n```\n\n### Step 2: Establish SLA Policy Document\nKey sections to include:\n- Purpose and scope\n- Roles and responsibilities (RACI matrix)\n- Severity definitions and calculation method\n- Remediation timeframes by severity and asset tier\n- Exception request process and approval authority\n- Escalation procedures for SLA breaches\n- Metrics, reporting cadence, and governance\n- Policy review and update schedule\n\n### Step 3: Integrate with Ticketing System\n```python\n# ServiceNow \u002F Jira integration for automatic ticket creation\n# See process.py for full implementation\n\n# Key fields for remediation tickets:\n# - Vulnerability ID (CVE\u002FPlugin ID)\n# - Affected host(s)\n# - Severity (CVSS + contextual factors)\n# - Asset tier\n# - SLA deadline (calculated from discovery date)\n# - Assignment group\n# - Remediation instructions\n# - Verification criteria\n```\n\n### Step 4: Configure Escalation Chain\n```\nSLA Status          Action                          Notify\n───────────────────────────────────────────────────────────\n75% elapsed         Warning email                   Asset owner\n100% elapsed        SLA breach notification          Manager + CISO\n100% + 7 days       Executive escalation             VP\u002FCTO\n100% + 30 days      Risk acceptance required          CISO approval\n100% + 90 days      Compensating controls mandatory   Board report\n```\n\n### Step 5: Establish Exception Process\nValid exception reasons:\n- System cannot be patched without major downtime (scheduled maintenance window)\n- No vendor patch available (apply compensating controls)\n- Patch breaks critical functionality (require test results as evidence)\n- End-of-life system pending decommission (document risk acceptance)\n\nException requirements:\n- Written justification with business impact\n- Compensating controls documented and implemented\n- Approved by asset owner AND security leadership\n- Maximum exception duration: 90 days (renewable with re-approval)\n- Tracked in vulnerability management platform\n\n## Key Performance Indicators (KPIs)\n\n### Primary Metrics\n| KPI | Definition | Target |\n|-----|-----------|--------|\n| SLA Compliance Rate | % of vulns remediated within SLA | >90% |\n| Mean Time to Remediate (MTTR) | Average days from discovery to fix | Critical: \u003C3d, High: \u003C10d |\n| Vulnerability Backlog | Open vulnerabilities past SLA | \u003C5% of total |\n| Exception Rate | % of findings with active exceptions | \u003C10% |\n| Recurrence Rate | % of vulns that reappear after remediation | \u003C5% |\n\n### Trending Metrics\n- Month-over-month SLA compliance trend\n- MTTR trend by severity\n- Vulnerability density per asset (vulns\u002Fhost)\n- Patch coverage rate (% of assets scanned and compliant)\n- Time to first response (acknowledgment of finding)\n\n## Best Practices\n1. Start with achievable SLAs and tighten over time as maturity improves\n2. Use automated ticketing to eliminate manual SLA tracking\n3. Provide remediation teams with clear fix instructions, not just CVE numbers\n4. Track SLA compliance at the team\u002Fdepartment level for accountability\n5. Report SLA metrics to executive leadership monthly\n6. Include compensating controls as valid interim remediation\n7. Align SLAs with regulatory requirements (PCI DSS, HIPAA, SOX)\n8. Review and adjust SLAs annually based on threat landscape changes\n\n## Common Pitfalls\n- Setting unrealistic SLAs that teams cannot meet (creates SLA fatigue)\n- No executive enforcement of SLA breaches\n- Treating all assets equally without tiering\n- Not accounting for vulnerability context (EPSS, KEV) in SLA calculation\n- Missing exception management process (leads to untracked risk)\n- Measuring only compliance rate without analyzing root causes of breaches\n\n## Related Skills\n- prioritizing-vulnerabilities-with-cvss-scoring\n- implementing-patch-management-workflow\n- implementing-vulnerability-metrics-and-reporting\n- implementing-exception-management-process\n\n\n---\n\n## CyberSecSuite Integration\n\n```bash\n# Open a case before starting investigation\nmcp__cybersec__case_open --title \"vulnerability\" --type investigation\n\n# Persist findings to PostgreSQL\nmcp__cybersec__add_finding --title \"...\" --severity high --description \"...\"\n\n# Log IOCs\nmcp__cybersec__add_ioc --type domain --value \"...\" --confidence 0.9\n\n# Map to MITRE\nmcp__cybersec__suggest_mitre --description \"...\"\n```\n\n**Agent:** `@cybersec-agent` → delegates to appropriate specialist\n","# Implementing Vulnerability Remediation SLA\n\n## Overview\nVulnerability remediation SLAs define mandatory timeframes for patching or mitigating identified vulnerabilities based on severity, asset criticality, and exploit availability. Effective SLA programs drive accountability, ensure consistent remediation timelines, and provide measurable KPIs for vulnerability management maturity.\n\n\n## When to Use\n\n- When deploying or configuring implementing vulnerability remediation sla capabilities in your environment\n- When establishing security controls aligned to compliance requirements\n- When building or improving security architecture for this domain\n- When conducting security assessments that require this implementation\n\n## Prerequisites\n- Vulnerability scanning program producing regular findings\n- Asset inventory with criticality classifications\n- Ticketing system (Jira, ServiceNow, etc.) for remediation tracking\n- Executive sponsorship for SLA enforcement\n- Cross-functional agreement from IT operations, development, and security\n\n## Core Concepts\n\n### SLA Framework Components\n1. **Severity Classification**: CVSS base score + threat context (EPSS, KEV)\n2. **Asset Tiering**: Business criticality and exposure level\n3. **Remediation Timeframes**: Maximum days to remediate by category\n4. **Exception Process**: Documented approval for SLA extensions\n5. **Escalation Procedures**: Actions when SLAs are breached\n6. **Metrics and Reporting**: KPIs for compliance tracking\n\n### Recommended SLA Matrix\n| Severity | Tier 1 (Critical) | Tier 2 (Important) | Tier 3 (Standard) |\n|----------|-------------------|--------------------|--------------------|\n| Critical (CVSS 9.0-10.0) | 24-48 hours | 72 hours | 7 days |\n| High (CVSS 7.0-8.9) | 7 days | 14 days | 30 days |\n| Medium (CVSS 4.0-6.9) | 30 days | 45 days | 60 days |\n| Low (CVSS 0.1-3.9) | 90 days | 90 days | 90 days |\n| CISA KEV Listed | 24 hours | 48 hours | 7 days |\n\n### SLA Accelerators (Reduce SLA by 50%)\n- Exploit code publicly available\n- Active exploitation observed in the wild (CISA KEV)\n- Internet-facing asset affected\n- EPSS score > 0.5 (50% exploitation probability)\n- Previous breach via similar vulnerability type\n\n## Workflow\n\n### Step 1: Define Asset Tiers\n```\nTier 1 (Critical Assets):\n- Customer-facing production systems\n- Payment processing infrastructure\n- Domain controllers and identity systems\n- Core network infrastructure (firewalls, routers)\n- Databases containing PII\u002FPHI\u002FPCI data\n\nTier 2 (Important Assets):\n- Internal production applications\n- Email and collaboration systems\n- Development\u002Fstaging environments with production data\n- Backup and recovery infrastructure\n- VPN and remote access gateways\n\nTier 3 (Standard Assets):\n- End-user workstations\n- Development\u002Ftest environments\n- Print servers and peripheral management\n- Non-critical internal tools\n```\n\n### Step 2: Establish SLA Policy Document\nKey sections to include:\n- Purpose and scope\n- Roles and responsibilities (RACI matrix)\n- Severity definitions and calculation method\n- Remediation timeframes by severity and asset tier\n- Exception request process and approval authority\n- Escalation procedures for SLA breaches\n- Metrics, reporting cadence, and governance\n- Policy review and update schedule\n\n### Step 3: Integrate with Ticketing System\n```python\n# ServiceNow \u002F Jira integration for automatic ticket creation\n# See process.py for full implementation\n\n# Key fields for remediation tickets:\n# - Vulnerability ID (CVE\u002FPlugin ID)\n# - Affected host(s)\n# - Severity (CVSS + contextual factors)\n# - Asset tier\n# - SLA deadline (calculated from discovery date)\n# - Assignment group\n# - Remediation instructions\n# - Verification criteria\n```\n\n### Step 4: Configure Escalation Chain\n```\nSLA Status          Action                          Notify\n───────────────────────────────────────────────────────────\n75% elapsed         Warning email                   Asset owner\n100% elapsed        SLA breach notification          Manager + CISO\n100% + 7 days       Executive escalation             VP\u002FCTO\n100% + 30 days      Risk acceptance required          CISO approval\n100% + 90 days      Compensating controls mandatory   Board report\n```\n\n### Step 5: Establish Exception Process\nValid exception reasons:\n- System cannot be patched without major downtime (scheduled maintenance window)\n- No vendor patch available (apply compensating controls)\n- Patch breaks critical functionality (require test results as evidence)\n- End-of-life system pending decommission (document risk acceptance)\n\nException requirements:\n- Written justification with business impact\n- Compensating controls documented and implemented\n- Approved by asset owner AND security leadership\n- Maximum exception duration: 90 days (renewable with re-approval)\n- Tracked in vulnerability management platform\n\n## Key Performance Indicators (KPIs)\n\n### Primary Metrics\n| KPI | Definition | Target |\n|-----|-----------|--------|\n| SLA Compliance Rate | % of vulns remediated within SLA | >90% |\n| Mean Time to Remediate (MTTR) | Average days from discovery to fix | Critical: \u003C3d, High: \u003C10d |\n| Vulnerability Backlog | Open vulnerabilities past SLA | \u003C5% of total |\n| Exception Rate | % of findings with active exceptions | \u003C10% |\n| Recurrence Rate | % of vulns that reappear after remediation | \u003C5% |\n\n### Trending Metrics\n- Month-over-month SLA compliance trend\n- MTTR trend by severity\n- Vulnerability density per asset (vulns\u002Fhost)\n- Patch coverage rate (% of assets scanned and compliant)\n- Time to first response (acknowledgment of finding)\n\n## Best Practices\n1. Start with achievable SLAs and tighten over time as maturity improves\n2. Use automated ticketing to eliminate manual SLA tracking\n3. Provide remediation teams with clear fix instructions, not just CVE numbers\n4. Track SLA compliance at the team\u002Fdepartment level for accountability\n5. Report SLA metrics to executive leadership monthly\n6. Include compensating controls as valid interim remediation\n7. Align SLAs with regulatory requirements (PCI DSS, HIPAA, SOX)\n8. Review and adjust SLAs annually based on threat landscape changes\n\n## Common Pitfalls\n- Setting unrealistic SLAs that teams cannot meet (creates SLA fatigue)\n- No executive enforcement of SLA breaches\n- Treating all assets equally without tiering\n- Not accounting for vulnerability context (EPSS, KEV) in SLA calculation\n- Missing exception management process (leads to untracked risk)\n- Measuring only compliance rate without analyzing root causes of breaches\n\n## Related Skills\n- prioritizing-vulnerabilities-with-cvss-scoring\n- implementing-patch-management-workflow\n- implementing-vulnerability-metrics-and-reporting\n- implementing-exception-management-process\n\n\n---\n\n## CyberSecSuite Integration\n\n```bash\n# Open a case before starting investigation\nmcp__cybersec__case_open --title \"vulnerability\" --type investigation\n\n# Persist findings to PostgreSQL\nmcp__cybersec__add_finding --title \"...\" --severity high --description \"...\"\n\n# Log IOCs\nmcp__cybersec__add_ioc --type domain --value \"...\" --confidence 0.9\n\n# Map to MITRE\nmcp__cybersec__suggest_mitre --description \"...\"\n```\n\n**Agent:** `@cybersec-agent` → delegates to appropriate specialist\n",{"name":5,"description":7},"main","a91f1293287ffa9f4f1b8f486cd6e835a1568c84","skills\u002Fvulnerabilities\u002Fremediation\u002Fvulnerability","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace","https:\u002F\u002Fgithub.com\u002FDCx7C5","#Python","2026-09-01 11:21:00",{"source":8,"skillName":5,"commands":50,"prompt":60,"zipAvailable":61},[51,54,57],{"tool":52,"command":53},"npx","npx skills add DCx7C5\u002Fai-marketplace --skill vulnerability-SKILL.md",{"tool":55,"command":56},"bunx","bunx skills add DCx7C5\u002Fai-marketplace --skill vulnerability-SKILL.md",{"tool":58,"command":59},"pnpm","pnpm dlx skills add DCx7C5\u002Fai-marketplace --skill vulnerability-SKILL.md","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fvulnerabilities\u002Fremediation\u002Fvulnerability\u002FSKILL.md",true,[63,69,73,79,83,86,90,94,100,103],{"path":64,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":68},"assets\u002Findex.json","ASSET","资产文件",84,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fvulnerabilities\u002Fremediation\u002Fvulnerability\u002Fassets\u002Findex.json",{"path":70,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":71,"sourceHtmlUrl":72},"assets\u002Ftemplate.md",1187,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fvulnerabilities\u002Fremediation\u002Fvulnerability\u002Fassets\u002Ftemplate.md",{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"index.json","REFERENCE","参考文档",1525,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fvulnerabilities\u002Fremediation\u002Fvulnerability\u002Findex.json",{"path":80,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fapi-reference.md",4825,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fvulnerabilities\u002Fremediation\u002Fvulnerability\u002Freferences\u002Fapi-reference.md",{"path":84,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":67,"sourceHtmlUrl":85},"references\u002Findex.json","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fvulnerabilities\u002Fremediation\u002Fvulnerability\u002Freferences\u002Findex.json",{"path":87,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fstandards.md",1158,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fvulnerabilities\u002Fremediation\u002Fvulnerability\u002Freferences\u002Fstandards.md",{"path":91,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fworkflows.md",1526,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fvulnerabilities\u002Fremediation\u002Fvulnerability\u002Freferences\u002Fworkflows.md",{"path":95,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":98,"sourceHtmlUrl":99},"scripts\u002Fagent.py","SCRIPT","脚本",8796,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fvulnerabilities\u002Fremediation\u002Fvulnerability\u002Fscripts\u002Fagent.py",{"path":101,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":67,"sourceHtmlUrl":102},"scripts\u002Findex.json","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fvulnerabilities\u002Fremediation\u002Fvulnerability\u002Fscripts\u002Findex.json",{"path":104,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":105,"sourceHtmlUrl":106},"scripts\u002Fprocess.py",11013,"https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fvulnerabilities\u002Fremediation\u002Fvulnerability\u002Fscripts\u002Fprocess.py",[108,134,156,178,200,216],{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":37},"01M71HAPZ01KQ30RKTB0FFSQ05","services-wmi-persistence-detect","Detect WMI event subscription persistence by enumerating ActiveScriptEventConsumer, CommandLineEventConsumer, and permanent subscriptions in the WMI repository.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fservices\u002Fwmi\u002Fpersistence\u002Fdetect\u002FSKILL.md",[],[115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133],"services","detect","services wmi persistence detect","wmi","persistence","de","cm","process","activescript","event","subscriptions","commandline-consumer","repository","subscription","event-subscription","t1546.003","forensics","cybersecurity","process-forensics",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":37},"01M71HAK6JTTTS229T17WJMMCG","services-wmi-exec-exploit","Perform lateral movement across Windows networks using WMI-based remote execution techniques including Impacket wmiexec.py, CrackMapExec, and native WMI commands for stealthy post-exploitation during red team engagements.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fservices\u002Fwmi\u002Fexec\u002Fexploit\u002FSKILL.md",[],[33,115,141,118,142,143,144,132,145,146,147,148,149,150,120,151,152,153,154,155],"services wmi exec exploit","exec","remote","traffic","Bash","analysis","team","across","crackmapexec","native","command","lateral movement","read","lateral-movement","Impacket",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":162,"publishedAt":37},"01M71HAG6MHKNQV8KDZKMT4886","registry-artifact-extract","Extract and analyze Windows Registry hives to uncover user activity, installed software, autostart entries, and evidence of system compromise.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fregistry\u002Fartifact\u002Fextract\u002FSKILL.md",[],[163,164,165,166,167,168,132,145,169,146,170,171,120,153,172,173,174,175,176,177],"artifact","registry","registry artifact extract","extract","evidence-collection","artifact-analysis","collection","analyze","uncover","software","activity","digital-forensics","windows-registry","regripper","sonnet",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":184,"publishedAt":37},"01M71HACR4A8XTWTTSXK4124AA","processes-token-impersonate-detect","Detect Windows token impersonation and privilege abuse including SeImpersonatePrivilege exploitation via Potato attacks and token stealing techniques.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fprocesses\u002Ftoken\u002Fimpersonate\u002Fdetect\u002FSKILL.md",[],[116,185,186,187,188,189,190,121,191,132,133,192,193,194,195,196,197,198,199,120],"processes token impersonate detect","token","processes","attacks","windows","escalation","techniques","privilege-escalation","seimpersonate","token-impersonation","printspoofer","exploitation","potato","impersonation","via",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":206,"publishedAt":37},"01M71HAABSB4Z6QFSXEG00R4RK","processes-thread-injection-detect","Detect Windows thread injection techniques including CreateRemoteThread, QueueUserAPC, NtCreateThreadEx, and thread hijacking via process memory analysis.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fprocesses\u002Fthread\u002Finjection\u002Fdetect\u002FSKILL.md",[],[207,208,116,209,187,189,210,121,211,191,132,133,146,212,213,214,215,199,120,122],"thread","processes thread injection detect","injection","memory","process-injection","api","apc-injection","thread-injection","nt-api",{"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":222,"publishedAt":37},"01M71HA7H311V5G14WMX58HQSS","processes-hollow-technique-detect","Detect process hollowing (RunPE) by identifying processes with mismatched image paths between PEB and VAD tree, or unmapped PE headers in memory.","https:\u002F\u002Fgithub.com\u002FDCx7C5\u002Fai-marketplace\u002Fblob\u002Fmain\u002Fskills\u002Fwindows\u002Fprocesses\u002Fhollow\u002Ftechnique\u002Fdetect\u002FSKILL.md",[],[223,116,187,224,210,121,225,226,132,133,227,228,229,230,231,232,120,122,233,234],"processes hollow technique detect","tree","memory-forensics","process-hollow","peb","runpe","image","pe-header","in memory","with","mismatched","headers"]