pentest-pre-engagement

name	pentest-pre-engagement
description	PTES Phase 1 - Pre-Engagement Interactions for AWS security assessments
type	skill

PTES Phase 1: Pre-Engagement Interactions

🎯 pfSense Detection & Routing

IMPORTANTE: Se durante a definição de escopo você identificar que o alvo inclui pfSense, ATIVE A SKILL pentest-pfsense imediatamente.

Questões de Escopo para pfSense

INCLUIR NO ESCopo:
[ ] pfSense firewall identificado
    - Versão: _____________________ (CE ou Plus?)
    - Interfaces: [ ] WAN  [ ] LAN  [ ] OPT___
    - Serviços: [ ] OpenVPN  [ ] IPsec  [ ] WireGuard
    - Pacotes: [ ] pfBlockerNG  [ ] Suricata  [ ] Snort

[ ] HA/CARP configuration
    - Primary: _____________________
    - Secondary: _____________________

[ ] Gestão de pacotes instalados
    - Lista: _____________________

EXCLUIR DO ESCOPO (se aplicável):
[ ] Produção durante horário comercial
[ ] Alterações de configuração permanentes
[ ] Testes de DoS/DDoS
[ ] Exploração de vulnerabilidades sem patch prévio

Ação Imediata

# Se pfSense identificado no escopo → ATIVAR pentest-pfsense skill
# Esta skill continua para pre-engagement geral
# Use pentest-pfsense para:
# - Version-specific testing (2.7.0+)
# - Stealth reconnaissance (Shodan/Censys first)
# - Feature-based testing checklist
# - CVE verification (27+ CVEs mapeadas)

---

Objetivo

Estabelecer os termos, escopo, regras de engajamento e requisitos legais/contratuais antes de iniciar o penetration test, conforme diretrizes PTES.

Checklist de Pre-Engagement (PTES-Aligned)

1. Definição de Escopo

Informações da Organização

NOME DA ORGANIZAÇÃO: _________________________________
INDÚSTRIA/SETOR: _____________________________________
CONTATO PRINCIPAL: ___________________________________
EMAIL: ______________________________________________
TELEFONE: ____________________________________________

Escopo Técnico AWS

CONTAS AWS INCLUÍDAS:
- Account ID: _____________________ (Account Alias: _________)
- Account ID: _____________________ (Account Alias: _________)
- Account ID: _____________________ (Account Alias: _________)

REGIÕES AWS INCLUÍDAS:
[ ] us-east-1      [ ] us-west-1     [ ] us-west-2
[ ] eu-west-1      [ ] eu-west-2     [ ] eu-central-1
[ ] ap-southeast-1 [ ] ap-southeast-2 [ ] ap-northeast-1
[ ] sa-east-1      [ ] ca-central-1  [ ] Todas as regiões

SERVIÇOS AWS INCLUÍDOS (PTES Technical Guidelines):
[ ] IAM (Identity and Access Management)
[ ] EC2 (Elastic Compute Cloud)
[ ] S3 (Simple Storage Service)
[ ] Lambda (Serverless Computing)
[ ] ECS/EKS (Container Services)
[ ] RDS (Relational Database Service)
[ ] Secrets Manager / Parameter Store
[ ] CloudTrail / CloudWatch
[ ] VPC / Networking
[ ] Outros: _________________________

SERVIÇOS EXCLUÍDAS (NÃO TESTAR):
_______________________________________________________
_______________________________________________________

2. Tipo de Engajamento (PTES Classification)

Nível de Conhecimento

TIPO DE TESTE:
[ ] Black Box (Sem conhecimento prévio - simular atacante externo)
[ ] Grey Box (Conhecimento parcial - credenciais limitadas)
[ ] White Box (Conhecimento total - documentação e credenciais completas)

PARA GREY/WHITE BOX:
- Credenciais fornecidas: _____________________________
- Documentação fornecida: _____________________________
- Endpoints conhecidos: _______________________________
- Arquitetura conhecida: _____________________________

Janela de Teste

DATA DE INÍCIO: _______________________________________
DATA DE TÉRMINO: ______________________________________
HORÁRIOS PERMITIDOS: __________________________________
FUSO HORÁRIO: _________________________________________

3. Regras de Engajamento (ROE)

Técnicas Permitidas (WorstAssume Capabilities)

TÉCNICAS AUTORIZADAS (WorstAssume - Read-Only):
[ ] Enumeração adaptiva de IAM (GetAccountAuthorizationDetails ou slow-path)
[ ] Análise de políticas e trust policies (parsing de JSON policies)
[ ] Mapeamento de attack paths (BFS traversal, 37 edge families)
[ ] Detecção de attack chains (7 famílias: I-VII)
[ ] Security assessment (5 categorias de findings)
[ ] Cross-account trust analysis (inferência automática)
[ ] Capability probing (detecta permissões antes de enumerar)

TÉCNICAS REQUEREM APROVAÇÃO EXPLÍCITA:
[ ] PassRole attacks (simulação via attack graph)
[ ] Lateral movement cross-account (via trust relationships)
[ ] Criação de recursos para persistência (não executado - apenas detection)
[ ] Exfiltração de dados (apenas identificação de vetores)

TÉCNICAS PROIBIDAS (WorstAssume não executa):
[ ] DoS / DDoS (fora do escopo da ferramenta)
[ ] Destruição de dados (ferramenta é read-only)
[ ] Modificação de produção (nenhuma write API é chamada)
[ ] Engenharia social (fora do escopo técnico)
[ ] Ataques físicos (fora do escopo)

NOTA: WorstAssume é uma ferramenta de enumeração e análise - todas as
operações são READ-ONLY. A exploração ativa requer ferramentas adicionais.

Requisitos de Stealth e Rate Limiting (WorstAssume --stealth)

REQUISITOS DE STEALTH:
[ ] Nenhum requisito especial (default - sem delay)
[ ] Moderado (usar --stealth: 0.3-1.2s jitter entre calls)
[ ] Alto stealth (customizar jitter no código: random.uniform(X, Y))

WORSTASSUME STEALTH MODE:
# Com stealth mode (serializado + jitter)
worst enumerate --profile my-profile --stealth

# Implementação do jitter (worstassume/cli.py):
def jitter():
    if stealth:
        time.sleep(random.uniform(0.3, 1.2))

# Módulos executam em sequência com jitter:
run_module("IAM", iam.enumerate, ...)  # ~2-5s entre módulos
run_module("EC2", ec2.enumerate, ...)  # com stealth: +1-3s
run_module("S3", s3.enumerate, ...)    # por módulo

RATE LIMITING NATIVO:
- Stealth mode: ~10-15 requests/minute (com jitter)
- Normal mode: ~50-100 requests/minute (limitado por AWS SDK)
- Fast path (GetAccountAuthorizationDetails): 1 chamada = tudo

CLOUDTRAIL IMPACTO:
- Fast path: 1-2 eventos CloudTrail (iam:GetAccountAuthorizationDetails)
- Slow path: 50-200+ eventos (list/get calls individuais)
- Stealth mode: Eventos distribuídos no tempo (padrão menos detectável)

4. Considerações Legais e Contratuais

Autorizações

CARTA DE AUTORIZAÇÃO ASSINADA: [ ] Sim  [ ] Não
DATA DA ASSINATURA: ___________________________________
SIGNATÁRIO AUTORIZADO: ________________________________
CARGO: ________________________________________________

ACORDO DE CONFIDENCIALIDADE (NDA): [ ] Sim  [ ] Não
SEGURO DE RESPONSABILIDADE: [ ] Sim  [ ] Não

Conformidade e Regulamentação

REQUISITOS DE CONFORMIDADE:
[ ] SOC 2
[ ] PCI DSS
[ ] HIPAA
[ ] GDPR
[ ] LGPD
[ ] ISO 27001
[ ] Outros: _________________________

RESTRIÇÕES DE DATA RESIDENCE: _________________________

5. Comunicação e Escalation

Matriz de Comunicação

CONTATOS DE EMERGÊNCIA:
Nome: _________________________ Tel: __________________
Email: _________________________ Cargo: ________________

Nome: _________________________ Tel: __________________
Email: _________________________ Cargo: ________________

CADÊNCIA DE REPORT:
[ ] Diário
[ ] Semanal
[ ] Ao final do engajamento
[ ] Quando findings críticos forem descobertos

CANAL DE COMUNICAÇÃO:
[ ] Email
[ ] Slack/Teams
[ ] Telefone
[ ] Portal seguro

Critérios de Escalation

ESCALAR IMEDIATAMENTE PARA:
- Vulnerabilidades CRITICAL exploradas com sucesso
- Acesso não autorizado a dados sensíveis
- Impacto em ambiente de produção
- Incidentes de segurança descobertos durante o teste

CONTATO DE ESCALATION:
Nome: _________________________ Tel: __________________
Email: _________________________ Cargo: ________________

6. Critérios de Sucesso e Deliverables

Objetivos do Teste (PTES Goals)

OBJETIVOS PRIMÁRIOS:
[ ] Identificar vulnerabilidades de IAM
[ ] Mapear attack paths para privilégio elevado
[ ] Validar controles de detecção
[ ] Testar resposta a incidentes
[ ] Cumprir requisitos de conformidade

OBJETIVOS SECUNDÁRIOS:
_______________________________________________________
_______________________________________________________

Deliverables Esperados (PTES Reporting)

RELATÓRIOS:
[ ] Relatório Executivo (PDF)
[ ] Relatório Técnico (PDF)
[ ] Dados estruturados (JSON/CSV)
[ ] Apresentação para stakeholders
[ ] Session de knowledge transfer

PRAZO DE ENTREGA: _____________________________________

7. Setup de Credenciais e Acesso

Credenciais AWS (WorstAssume Session Manager)

MÉTODO DE AUTENTICAÇÃO:
[ ] Access Keys (AKIA*) - worst enumerate --access-key AKIA... --secret-key ...
[ ] IAM Role (assumed via SSO) - worst enumerate --profile my-profile
[ ] Temporary Credentials (STS) - worst enumerate --session-token ...
[ ] SAML Federation - worst enumerate --profile sso-profile

PERMISSÕES MÍNIMAS REQUERIDAS (WorstAssume Capability Probing):
Fast Path (ótimo):
- iam:GetAccountAuthorizationDetails (enumeração completa em 1 chamada)

Slow Path (fallback):
- iam:ListUsers, iam:ListRoles, iam:ListGroups
- iam:ListUserPolicies, iam:ListRolePolicies, iam:ListGroupPolicies
- iam:GetUserPolicy, iam:GetRolePolicy, iam:GetGroupPolicy
- iam:GetPolicy, iam:GetPolicyVersion
- iam:ListAttachedUserPolicies, iam:ListAttachedRolePolicies
- iam:ListGroupsForUser

Resource Enumeration (opcional):
- ec2:DescribeInstances, lambda:ListFunctions
- s3:ListAllMyBuckets, s3:GetBucketPolicy
- ecs:ListClusters, ecs:ListTaskDefinitions

AMBIENTE DE TESTE:
[ ] Produção (com --stealth para rate limiting)
[ ] Staging/UAT
[ ] Dedicated test account
[ ] LocalStack/ambiente isolado

Ferramentas e Infraestrutura (WorstAssume-Native)

FERRAMENTAS PRIMÁRIAS:
- WorstAssume CLI (worst enumerate, worst assess, worst viz)
- WorstAssume Web Dashboard (Cytoscape.js graph visualization)
- AWS CLI v2 (fallback/validação)
- Python 3.x + boto3 (runtime do WorstAssume)
- SQLite (armazenamento local: ~/.worstassume/db.sqlite)

INFRAESTRUTURA DO TESTER:
[ ] Docker Compose (recomendado) - docker compose up --build
[ ] Python venv local - pip install -e .
[ ] Instância EC2 dedicada (para testes de dentro da VPC)
[ ] Máquina local com acesso VPN

WORSTASSUME SETUP:
# Docker (recomendado)
git clone https://github.com/BrunoSBecke/WorstAssume.git
cd WorstAssume
docker compose up --build

# Local
python -m venv venv
source venv/bin/activate
pip install -e .
cd worstassume/viz/frontend && npm install && npm run build

ENDPOINTS/PROXIES:
- Dashboard Web: http://localhost:3000
- Database: ~/.worstassume/db.sqlite

8. Plano de Remediação de Emergência

Procedimentos de Rollback

SE IMPACTO NÃO INTENCIONAL OCORRER:
1. Parar imediatamente todas as atividades
2. Documentar o estado atual
3. Contatar o ponto de contato de emergência
4. Executar procedimentos de rollback
5. Documentar lições aprendidas

BACKUP/RESTORE:
- Responsável pelo backup: ____________________________
- Procedimento de restore: ___________________________
- Tempo estimado de recuperação: _____________________

Template de Documento de Escopo (PTES Format)

ENGAGEMENT: [Nome do Projeto]
CLIENT: [Nome do Cliente]
DATE: [Data]
CLASSIFICATION: [Confidential]

SCOPE:
- Account IDs: [Lista de contas]
- Regions: [us-east-1, eu-west-1, ...]
- Services: [IAM, EC2, S3, Lambda, ...]
- Exclusions: [Serviços/regiões fora do escopo]

CREDENTIALS:
- Type: [Grey Box - IAM User provided]
- Initial Access: [arn:aws:iam::ACCOUNT:user/auditor]
- MFA Required: [Yes/No]

RULES OF ENGAGEMENT:
- Testing Window: [YYYY-MM-DD to YYYY-MM-DD]
- Rate Limit: [10 requests/second]
- Stealth Required: [Yes/No]
- Destructive Actions: [Prohibited/Allowed with approval]

GOALS:
1. [Primary goal]
2. [Secondary goal]
3. [Tertiary goal]

DELIVERABLES:
1. [Deliverable 1]
2. [Deliverable 2]

COMMUNICATION:
- Primary Contact: [Name, Email, Phone]
- Escalation Contact: [Name, Email, Phone]
- Reporting Cadence: [Daily/Weekly/Final]

Output Esperado desta Fase

1. SOW (Statement of Work) assinado
2. ROE (Rules of Engagement) documentado
3. Credenciais de acesso provisionadas
4. Canais de comunicação estabelecidos
5. Critérios de sucesso alinhados

Transição para Próxima Fase

Após completar esta fase, iniciar a fase de Intelligence Gathering com o escopo definido.

Próximos Passos

Prossiga para pentest_intelligence-gathering

---

🔥 pfSense Detection & Routing

IMPORTANTE: Se durante o pre-engagement você identificar que o alvo utiliza pfSense, DOCUMENTE E CONSULTE A SKILL pentest-pfsense durante o planejamento.

O que verificar no Pre-Engagement para pfSense

ESCOPO TÉCNICO - ADICIONAR:
[ ] pfSense firewall identificado
[ ] Versão conhecida: _________________
[ ] Modo de acesso: [ ] WAN  [ ] LAN  [ ] Ambos
[ ] HA/Cluster: [ ] Sim  [ ] Não
[ ] Pacotes instalados conhecidos: ___________________

Informações a Coletar Antes do Teste

• Versão exata do pfSense (CE ou Plus)
• Pacotes instalados (pfBlockerNG, Suricata, Snort, etc.)
• Método de autenticação (local, LDAP, RADIUS)
• MFA habilitado?
• HA/Cluster configuration
• Janela de manutenção para testes mais invasivos
• Backup disponível antes dos testes

Ação Imediata

# Se pfSense identificado no escopo → ATIVAR pentest-pfsense skill
# Use pentest-pfsense para:
# - Pre-engagement específico (documentação de features)
# - CVE mapping baseado na versão
# - Stealth recommendations (firewall = maior chance de detecção)
# - Feature-based testing checklist

---

🤖 AIRecon Integration for Pre-Engagement

AIRecon é um agente autônomo de penetration testing (v0.1.7-beta) que pode ser invocado como ferramenta incremental durante o pre-engagement para automatizar escopo, detecção de tecnologias e planejamento de ataques.

Invocando AIRecon para Pre-Engagement

# AIRecon com keywords do PTES para auto-carregar skills apropriadas
airecon "pentest pre-engagement aws iam assessment"

# AIRecon detectará keywords e carregará:
# - pentest-pre-engagement.md (skill primária)
# - pentest-threat-modeling.md (para AWS IAM)
# - MCP tools: cve-mcp, hexstrike, pentestswarm-remote

# Para pfSense-specific pre-engagement:
airecon "pfsense pre-engagement scope definition 2.7.0"

AIRecon Slash Commands Úteis para Pre-Engagement

# Network discovery inicial para definição de escopo
/naabu-scan --target <scope> -p 443,8443,22

# API key discovery em dados de recon
/api-keys --target <recon-data> --recursive

# Detecção de webshells (útil para escopo de pós-exploração)
/webshell-detect --target <web-root>

# Wordlist generation para escopo de brute-force
/wordlist --type passwords --length 8

MCP Tool Integration via AIRecon

Durante o pre-engagement, AIRecon pode invocar MCP tools automaticamente:

# cve-mcp: CVE lookup e EPSS scores para tecnologias no escopo
# Exemplo: Se pfSense 2.7.0 identificado no escopo
airecon "check CVEs for pfSense 2.7.0"
# → Usará mcp__cve-mcp__search_cves para listar vulnerabilidades

# hexstrike-local: nmap, nuclei scans para validação de escopo
airecon "scan target.com with nmap version detection"
# → Usará mcp__hexstrike-local__nmap_scan

# pentestswarm-remote: Automated reconnaissance campaigns
airecon "start reconnaissance campaign for example.com"
# → Usará mcp__pentestswarm-remote__start_campaign

Workflow Example: Pre-Engagement com AIRecon + WorstAssume

# 1. Usar AIRecon para escopo inicial e detecção de tecnologias
airecon "aws iam reconnaissance scope definition"

# 2. AIRecon auto-carrega pentest-pre-engagement.md + pentest-threat-modeling.md

# 3. Invocar WorstAssume via AIRecon para enumeração inicial
airecon "run worstassume enumerate --profile my-profile --stealth"

# 4. AIRecon processa output e gera attack tree visual
# 5. Exportar findings para relatório de pre-engagement
airecon "export findings to JSON for stakeholder review"

AIRecon Auto-Skill Loading

AIRecon detecta keywords e carrega skills automaticamente:

Keywords Detectadas	Skills Carregadas	MCP Tools Ativados
aws iam	pentest-pre-engagement, pentest-threat-modeling	cve-mcp, hexstrike
pfsense	pentest-pfsense, pentest-pre-engagement	shodan, cve-mcp
network scan	pentest-intelligence-gathering, pentest-network-scanning	hexstrike (nmap, naabu)
vulnerability	pentest-vulnerability-analysis	cve-mcp, pentestswarm
exploit	pentest-exploitation	boaz, hexstrike (metasploit)

Considerações Especiais para pfSense

• Stealth é crítico: pfSense é um firewall — testes agressivos serão detectados
• Janela de manutenção: Recomendar para testes de DoS/failover
• Backup obrigatório: Config backup antes de qualquer teste
• HA testing: Requer aprovação explícita (pode causar failover)