Google Dorking para Investigação: o Guia Honesto de 2026

Google dorking para investigação é o uso de operadores de busca avançada para forçar o Google a devolver só o que interessa: um domínio, um tipo de arquivo, um trecho de URL ou uma faixa de datas. Ele transforma o buscador em recuperação dirigida, mas o resultado não é confiável sozinho: cada item precisa ser verificado na fonte.

O Que É Google Dorking para Investigação?

Google dorking, ou Google hacking, é a prática de escrever consultas com operadores de busca avançada para localizar conteúdo que já está indexado, mas que uma busca comum não faria emergir. Em investigação, o objetivo raramente é "achar qualquer coisa sobre o alvo". É achar o documento certo, na fonte certa, com formato previsível: um PDF de diário oficial, uma ata, um edital, uma página institucional que cita um nome.

O nome "hacking" confunde. Não há invasão: o dork só filtra o que o rastreador do Google já coletou de páginas públicas, e muita coisa foi publicada por engano e nunca removida. Se você está começando, vale ler antes o que é OSINT e o roteiro de como começar em OSINT.

A comunidade mantém coleções públicas dessas consultas. A mais conhecida é a Google Hacking Database, hospedada no Exploit-DB, que cataloga dorks por categoria, de arquivos sensíveis a páginas de login expostas. Ótimo repertório de padrões, péssimo roteiro para copiar e colar sem entender cada query.

Quais Operadores o Google Realmente Documenta?

Esta é a primeira correção importante. A ajuda oficial do Google descreve ao usuário final um conjunto pequeno de operadores: aspas para frase exata, site: para restringir a um domínio, o hífen para excluir termo, before: e after: para janela de data e filetype: para tipo de arquivo. A documentação de refinar pesquisas do Google também avisa de uma armadilha banal: não pode haver espaço entre o operador e o termo. site:exemplo.com funciona; site: exemplo.com não.

Todo o resto que aparece nas listas gigantes de dorks (inurl:, intitle:, intext:, allintitle:) é comportamento observado, não contrato. Funciona na maior parte do tempo e pode mudar amanhã sem aviso. Tratar operador não documentado como garantia é a raiz da maioria dos erros que vejo em relatório.

Sobre filetype:, existe um detalhe que evita meia hora de frustração: o universo real do operador é a lista de tipos que o Google indexa. A documentação de tipos de arquivo indexáveis nomeia, entre outros, .pdf, .doc, .docx, .xls, .xlsx, .ppt, .pptx, .odt, .ods, .odp, .rtf, .csv, .txt, .xml, .kml, .kmz, .gpx, .epub e .ps. Formato binário fora dessa lista, como filetype:zip, não rende nada. Já texto plano com extensão incomum, caso de .sql e .log, costuma cair no guarda-chuva de texto da própria documentação, porque o operador também casa a extensão da URL. Ou seja: vazio em filetype:zip significa uma coisa, vazio em filetype:sql não significa quase nada.

Quais Operadores Deixaram de Funcionar?

Aqui mora a parte desatualizada de praticamente todo guia em português. O operador cache:, que abria a cópia armazenada de uma página, foi descontinuado pelo Google em 2024, em anúncio do perfil oficial Google Search Liaison, junto com o link de cache que aparecia nos resultados. O related:, que listava sites parecidos, deixou de entregar algo útil. Continuar ensinando os dois é o sinal mais rápido de que o material é reciclado.

Como Combinar Operadores sem Quebrar a Query?

Dork bom é curto. A tentação de empilhar cinco operadores numa linha só produz consultas que retornam zero ou, pior, que o Google reinterpreta silenciosamente. A regra que uso é começar amplo e apertar um filtro por vez, observando o que cada aperto tira.

1. Comece pela âncora forte: a frase exata entre aspas, normalmente o nome completo, a razão social ou o CNPJ formatado.
2. Adicione a fonte: site: no domínio ou sufixo onde o documento deveria estar.
3. Adicione o formato só se você espera um arquivo: filetype:pdf.
4. Recorte o período com after: quando o caso tem data conhecida.
5. Só então exclua ruído com o hífen, um termo por vez, checando o que sumiu.

Duas armadilhas de sintaxe merecem atenção. A primeira é o espaço depois do operador, que o Google avisa não funcionar. A segunda é o OR: precisa estar em maiúsculas e, misturado a muitos filtros, torna a query imprevisível. Para alternativas de grafia (com e sem acento, com e sem "LTDA"), rodar duas consultas separadas sai mais barato do que montar uma monstruosidade lógica.

Vale lembrar do óbvio operacional: rodar dork em volume, do mesmo IP, dispara verificação de robô. Se você investiga com frequência, leia o guia irmão de OPSEC para investigador OSINT antes de automatizar qualquer coisa.

Dorks para Fontes Brasileiras: Objetivo, Query e o Que Esperar

A maioria das listas de dorks foi escrita para o ecossistema americano e não conversa com as fontes que importam aqui. Diários oficiais, portais de transparência, tribunais, juntas comerciais e editais formam a espinha do OSINT brasileiro, e quase tudo isso está em PDF indexado. A tabela abaixo é o núcleo prático deste guia.

Duas ressalvas honestas. Não use curinga em site:: a documentação do Google mostra que site:exemplo.com já alcança os subdomínios, então o *. é sintaxe não documentada que ora funciona, ora atrapalha. Quando o sufixo largo render ruído demais, troque pelo domínio do tribunal ou do órgão. E esses dorks encontram menção, não identidade: fechar quem é a pessoa exige o cruzamento descrito em encontrar pessoa pelo nome e, no lado corporativo, em consulta de CPF e CNPJ em OSINT.

Por Que Seu Dork "Funcionou" e Trouxe Lixo?

Porque buscador não é banco de dados e a sua query não é SQL. O sistema é otimizado para responder pessoa, não para cumprir sintaxe ao pé da letra: quando a leitura estrita renderia pouco, a tendência é afrouxar e devolver o que parece próximo o suficiente. Na prática, um item pode aparecer na lista sem trazer o termo do intext: no corpo da página ou sem o padrão do inurl: na URL.

Somem-se a isso a personalização por sessão, idioma, país e histórico, além da variação entre data centers. O mesmo dork, na mesma hora, em duas máquinas diferentes, devolve conjuntos diferentes. Isso não é bug: é como a busca web foi projetada, para responder pessoas, não auditores.

Batemos nisso na nossa própria operação. A busca por nome da espectrosint roda dorks através de uma SERP API, e em julho de 2026 instrumentamos uma query para entender por que o usuário via achados que sumiam ao clicar em "ver no Google". O mesmo dork, inurl:"akageluv", repetido oito vezes, devolveu zero resultados orgânicos em algumas chamadas e seis em outras. Das seis, só um item realmente tinha o termo na URL. O provedor havia relaxado o operador e respondido com busca de texto livre.

Aquilo era a camada de API, e o Google no navegador honrou o operador na mesma query. A lição vale igual, porque da cadeira do analista o sintoma é idêntico: lista cheia, operador não aplicado, nenhuma mensagem de erro. Desde então, descartamos qualquer item que não seja demonstravelmente compatível com os operadores da dork que o produziu.

Protocolo de Verificação: Como Transformar Dork em Achado

Um dork produz candidatos. Achado é o que sobra depois da verificação. O protocolo abaixo leva poucos minutos por consulta e é o que separa relatório defensável de print de SERP colado no documento.

1. Abra a URL de verdade. Nunca use só o snippet: ele é gerado pelo Google e pode conter o termo que a página não contém.
2. Confirme o termo na fonte. Busque o nome, o CNPJ ou a frase dentro da página ou do PDF. Em PDF escaneado sem camada de texto, o Ctrl+F falha; confira com o olho.
3. Confirme o operador. O domínio bate com o site:? O caminho tem o padrão do inurl:? A extensão é a do filetype:? Um "não" derruba o item.
4. Confirme a pessoa, não o nome. Homônimo é a maior fonte de erro aqui. Exija um segundo elemento coincidente: cidade, cargo, CPF parcial, data.
5. Registre query, data e URL final. Sem isso, o achado não é reconstituível por terceiro.
6. Classifique: confirmado, plausível ou descartado. Só o primeiro grupo entra no corpo do relatório.

Quando o Resultado Vazio Não Significa Nada?

Quase sempre. "Não achei nada no Google" é uma das conclusões mais perigosas de um relatório, porque parece uma constatação e é apenas uma ausência de evidência produzida por uma ferramenta limitada. O próprio Google diz isso na documentação técnica: a página do Search Central sobre o operador site: afirma que ele não retorna necessariamente todas as URLs indexadas sob aquele prefixo, que os resultados nem sempre são exaustivos e que, sem termos adicionais, a ordenação é relativamente aleatória.

Some a isso três camadas de perda. O conteúdo pode existir e não estar indexado, por bloqueio no robots.txt, por login ou por ser gerado dinamicamente. Pode estar indexado e não emergir para a sua query. E pode estar num PDF escaneado sem OCR, invisível para busca textual mesmo publicado.

A formulação correta no relatório é operacional: "a consulta X, em DD/MM/AAAA, não retornou resultados no Google". Isso é verificável. Já "não existe registro público" você não tem como sustentar. Quando a ausência importa, repita o dork em outro buscador, em outra data e na fonte primária antes de concluir.

Google Dorking É Ilegal no Brasil?

Consultar o índice público de um buscador é lícito. Não há acesso indevido em pedir ao Google uma lista de páginas que ele já rastreou de sites abertos. A ilegalidade aparece no passo seguinte, quando o achado deixa de ser uma página pública e vira acesso a sistema.

O marco é o art. 154-A do Código Penal, incluído pela Lei 12.737/2012, que tipifica a invasão de dispositivo informático. Um dork que expõe um painel administrativo, um diretório aberto ou um arquivo claramente restrito não autoriza você a entrar, testar credencial ou baixar o conteúdo. O correto é interromper, registrar a URL e a data e reportar ao responsável ou à autoridade.

Há ainda a camada de proteção de dados. A LGPD (Lei 13.709/2018) dispensa consentimento, no art. 7º, parágrafo 4º, para dado pessoal tornado manifestamente público pelo próprio titular. Isso não é passe livre: finalidade legítima, necessidade e prazo de retenção continuam valendo, e agregar dados públicos dispersos num dossiê produz um risco que as fontes isoladas não tinham. O recorte prático dessa fronteira está em OSINT é legal no Brasil.

Dork Não É Reprodutível: Como Registrar a Prova

Como a busca varia por sessão, data e geografia, um dork não é experimento reprodutível no sentido estrito. Quem rodar a mesma query amanhã pode ver outro conjunto. Isso não invalida o achado, mas muda o que você precisa guardar: a prova é a página capturada, não a lista de resultados. O mínimo que registro para cada item que entra em relatório:

• A query literal, copiada exatamente como foi rodada, sem reescrever depois.
• Data e hora da execução, com fuso.
• Buscador e contexto: Google, idioma, país da sessão, se havia login ativo.
• A URL final do item, não a URL de redirecionamento do buscador.
• A captura da página aberta, de preferência com o conteúdo relevante visível, mais o hash do arquivo baixado quando for PDF.
• O motivo da inclusão: qual elemento confirma que é o alvo.

Esse cuidado é o que permite que o material sobreviva a contestação. O procedimento completo de preservação, incluindo hash e continuidade, está no guia irmão de prova digital e cadeia de custódia. Para a montagem do documento final, o modelo que usamos está em dossiê de investigação OSINT.

Passo a Passo na espectrosint

Dorking resolve a fonte específica, não o cruzamento de identificadores, que é onde a investigação costuma travar. O fluxo que funciona é usar a plataforma para o cruzamento amplo e o dork para as lacunas que nenhuma ferramenta cobre bem, como diário oficial municipal e portal de transparência de prefeitura.

1. Rode a busca por nome, CPF ou CNPJ para levantar identificadores associados: e-mails, telefones, usernames e perfis.
2. Pegue cada identificador novo e volte ao dork com ele: "email@dominio.com" entre aspas costuma render páginas que a busca por nome não alcança.
3. Se o alvo é empresa, use a análise de domínio e depois dorke o domínio com site: e filetype: para achar documentos publicados sem revisão. O passo a passo está em análise de domínio em OSINT.
4. Cheque exposição em vazamentos para os e-mails e telefones confirmados, o que dá contexto de risco ao caso.
5. Exporte o resultado em PDF, CSV ou JSON e anexe, ao lado, o registro dos dorks rodados com data e URL.

Sendo honesta sobre a divisão de trabalho: a plataforma correlaciona identificadores, checa exposição em vazamentos e entrega dossiê, grafo e timeline. Ela não escolhe por você qual fonte brasileira consultar num caso específico, e não transforma dork em prova. A verificação item a item continua sendo trabalho de analista.

Conclusão

Google dorking continua sendo uma das técnicas de melhor custo-benefício em OSINT, e continua mal ensinada. O repertório de operadores é menor do que as listas sugerem, parte dele morreu, e o buscador entrega resultado aproximado por design. Quem trata a SERP como resposta final produz relatório frágil; quem trata como lista de candidatos e verifica item a item produz achado que se sustenta.

Fique com três hábitos: escreva dorks curtos e aperte um filtro por vez, verifique cada item na fonte antes de citar, e registre query, data e URL de tudo que entrar no documento. Para o próximo passo, o cruzamento de identificadores está em encontrar pessoa pelo nome e a proteção da sua própria operação está em OPSEC para investigador OSINT.