O que você recebe quando contrata a TreeSec.
Um pentest só vale pelo que fica depois: os relatórios. Aqui mostramos a anatomia do que entregamos — dois relatórios e reteste incluído — para você saber exatamente o padrão antes de fechar.
Técnico + Executivo
em todo projeto
OWASP · PTES · NIST · OSSTMM · ATT&CK
Não entregamos um dump de scanner. Entregamos uma decisão.
Todo relatório da TreeSec responde três perguntas do seu ponto de vista: o que está em risco, por que isso importa para o negócio, e em que ordem corrigir. Estes são os princípios que guiam cada entrega.
Dois relatórios, dois públicos
O Relatório Técnico fala com quem corrige. O Executivo fala com a diretoria, em linguagem de risco de negócio. O mesmo achado, traduzido para cada leitor.
Prioridade pela cadeia, não pelo CVSS isolado
Um achado "Médio" que abre a porta para um "Crítico" é tratado como o que ele realmente é: a chave da invasão. Priorizamos pelo papel na cadeia de ataque, não só pela nota.
"Achar a falha não é o fim. Provar o impacto de negócio é."
Reteste sempre incluído
Um achado só é marcado como "Corrigido" depois que a TreeSec reexplora o vetor e confirma. Não basta declarar a correção, a gente prova que fechou.
Correção de código, não de borda
Dizemos com todas as letras o que um WAF não resolve. Um IDOR ou uma falha de lógica se corrige no código, o resto é ganhar tempo. Sem ilusão de "subiu o WAF, está resolvido".
"WAF não corrige IDOR."
Mapa de superfície navegável
Você recebe a superfície explorada como um mapa visual e navegável, não uma lista: endpoints, serviços e pontos de entrada identificados, com nós que se expandem e filtram por severidade. A sua aplicação do jeito que um invasor a enxerga.
Prova acima de hype
Cada afirmação vem com evidência e critério objetivo (CVSS 4.0, mapeamento OWASP/CWE). Sem alarmismo e sem inflar severidade para vender medo.
O relatório que a sua equipe usa para corrigir.
O documento principal. Cada achado com contexto, evidência e a correção-raiz, no nível de detalhe que um desenvolvedor precisa para resolver sem adivinhação.
Para quem corrige: dev, DevSecOps, time de infraestrutura.
- Resumo quantitativo — contagem por severidade e nível de risco geral do ambiente.
- Superfície de ataque mapeada — o que está exposto: serviços, portas, endpoints e como se conectam.
- Achados em detalhe — cada falha com severidade CVSS 4.0, evidência, impacto e correção-raiz.
- Reteste — status de reexploração de cada vetor após a correção.
- Implementar validação de tipo de arquivo no servidor (whitelist de extensões permitidas); não confiar apenas no header
Content-Type, que pode ser facilmente alterado pelo cliente. - Remover o parâmetro
pathcontrolado pelo usuário; definir o diretório de upload exclusivamente no backend da aplicação. - Executar a aplicação com um usuário de sistema dedicado e de baixo privilégio — nunca como
root. - Atualizar o JBoss (v4.0.x, EOL 2013) e o Apache Tomcat (v7.x, EOL 2021) para versões com suporte ativo.
Durante a análise da aplicação web, foi identificado um endpoint de upload de arquivos sem autenticação e sem validação de tipo ou extensão. Ao interceptar a requisição, verificou-se que o path de destino era controlável pelo atacante. A enumeração da aplicação revelou um relatório interno com caminhos físicos do servidor — incluindo o diretório de templates do Tomcat (/app/tomcat7/webapps/dash/template/dash_html/), acessível publicamente via HTTP. Alterando o path para esse diretório e enviando uma JSP webshell como payload, obteve-se acesso à shell diretamente pelo browser com privilégios de root no sistema operacional.
path visível e controlávelpath alterado para diretório web-acessível — webshell JSP enviada como payloadrootO relatório que a diretoria usa para decidir.
A mesma verdade técnica, traduzida para risco de negócio: o que priorizar, quanto tempo leva e qual o risco enquanto não se corrige. Sem jargão.
Para quem decide: C-level, gestão, área de risco e conformidade.
- Dashboard de risco — a foto imediata: quantos achados por severidade e o nível de risco geral.
- Impacto no negócio — cada risco traduzido em operação, receita, reputação e conformidade.
- Distribuição OWASP Top 10 — onde estão concentradas as fragilidades.
- Cronograma de remediação — correção em fases, com o risco residual de cada etapa.
- Recomendações estratégicas — os próximos passos de segurança, priorizados.
Números ilustrativos. Cada projeto recebe o seu próprio panorama.
| Indicador | Valor |
|---|---|
| Total de vulnerabilidades identificadas | 10 |
| Vulnerabilidades Críticas | 1 |
| Vulnerabilidades Altas | 3 |
| Vulnerabilidades Médias | 4 |
| Vulnerabilidades Baixas | 2 |
| Contas de usuário expostas | ~ 3.100 |
| Registros de dados pessoais acessíveis | ~ 42.000 |
| Credenciais em texto claro | 24 |
| Nível de risco geral | Alto |
Metodologia "war-game" em 5 fases.
Não rodamos um scanner e mandamos o PDF. Agimos como um adversário real agiria, entendendo o terreno e provando o impacto ponta a ponta.
Reconhecimento
Mapeamos a superfície de ataque: o que está exposto, quais serviços e por onde se entra.
Risco estratégico
Identificamos o "Santo Graal": os ativos e dados cuja perda prejudicaria mais o negócio.
Definição de missões
Traçamos os objetivos de ataque concretos que testam esses pontos críticos.
Exploração
Executamos e encadeamos as falhas até provar o impacto real, não só a existência do bug.
Relatório estratégico
Consolidamos tudo nos dois relatórios: técnico para corrigir, executivo para decidir.
Solicite o material gratuito
Preencha seus dados abaixo. Analisaremos sua solicitação e enviaremos o material por e-mail.