30 de abril de 2010

Funcionalidades pouco conhecidas ou usadas do Netcat

Introdução

Ainda que haja muitos artigos sobre esse tema, talvez muitas pessoas utilizam o Netcat apenas para conseguir um shell reverso ou descobrir o sistema operacional de um alvo e varrer suas portas.

Além das operações citadas, há muitas outras funcionalidades que esse canivete suíço nos oferece, e que em algum dado momento possa nos servir de ajuda.

Esse artigo não pretende ser um guia completo, mas simplesmente um ponto de partida para atiçar a curiosidade em explorar um pouco mais os possíveis usos do Netcat.

Transferência de arquivos

Há momento em que precisamos transferir arquivos de um host à outro e não sabemos como, e o Netcat nos oferece um caminho fácil de conseguí-lo, sem necessidade de montar um servidor FTP ou qualquer outra coisa do tipo.

É tão fácil como o que está a seguir.

No servidor:

# netcat -l -p 5050 > pass.txt

No cliente:

# cat pass.txt | netcat ip_server 5050

Com isso conseguimos enviar sem problemas um simples arquivo de texto, mas... O que acontece se quisermos ir mais além e enviar um binário (um executável, um arquivo do OpenOffice.org ,...)?

Vamos tentar o seguinte.

No servidor:

# netcat -l -p 5050 > exemplo.odt

No cliente:

# cat saida.odt | netcat ip_server 5050

E agora vamos comprovar (supondo que o exemplo tenha sido realizado na mesma máquina):

# diff exemplo.odt saida.odt

Como vemos, não há NENHUMA diferença, assim podemos transferir binários sem problemas...


Relays utilizando Netcat

Para esse exercício precisamos de 3 máquinas diferentes. Criaremos um relay na máquina Linux utilizando o Netcat executando-o no modo de escuta e como cliente. Esse encaminhamento dirigirá os dados de uma primeira máquina (A) para outra (B).

Esta máquina de encaminhamento conectará a primeira máquina, executando o Netcat em modo cliente, com uma terceira máquina (C) executando o Netcat em modo servidor, ou de escuta.

Uma vez estabelecida a conexão, o encaminhamento permitirá o acesso a esta última máquina a partir da máquina original.

O host intermediário serve de proxy, de forma que nos conectamos à ele e ele nos conecta ao servidor final, deste modo conseguindo que seja mais difícil nos rastrear, já que nos logs do servidor aparecerá o IP do host relay. Obviamente que quanto mais hosts intermediários utilizarmos, mais difícil será a tarefa de nos rastrear.

Uma maneira de criarmos relays, é unir a entrada e a saída de um cliente e servidor Netcat utilizando um arquivo especial denominado FIFO (Firts In, First Out). Podemos criar um arquivo FIFO e utilizá-lo para unir um Netcat em modo servidor com um cliente através dos seguintes comandos:

# mknod backpipe p
# nc -l -p [portaA] 0backpipe


Onde a portaA é a porta onde o relay está escutando e Porta_Destino a porta da máquina destino (IP_Destino) onde configuramos um backdoor com o shell. É importante não colocar espaços nos direcionamentos (>,<). Estes redirecionamentos permitem dirigir a entrada e saída padrão para um backpipe e não podem ter espaços neles.

Para que isso funcione, é necessário que caso tenhamos um filtro de pacotes rodando, permitamos o envio de pacotes à máquina C. É possível que se estivermos com o iptables ativo (funcionando como firewall), isso não será permitido. Podemos desativar o iptables do seguinte modo:

# /etc/init.d/iptables stop

Bem, mãos à obra, como escrevi antes, vamos precisar de três máquina (no meu caso, o próprio host onde trabalho, e 2 máquinas virtuais), os IPs são os seguintes:
  • Servidor: 192.168.1.129
  • Relay: 172.16.72.135
  • Cliente: 172.16.72.136

Vamos em frente.

No servidor, deixamos o Netcat escutando uma porta com um shell de presente:

# nc -l -p 5555

No relay, criamos o FIFO, e através dos direcionamentos fazemos as conexões:

# mknod buffer p
# netcat -l -p 1111 0buffer


Como podemos observar, primeiro criamos o buffer com ajuda do mknod, e depois usamos o mesmo para unir a entrada padrão (que nesse caso será aquilo que o cliente nos enviará através do Netcat) com a conexão no servidor e armazenar de novo a saída dessa última conexão no buffer, que será encaminhado para o cliente.

Finalmente, nos conectamos a partir do nosso cliente e observamos que temos o shell com o servidor:

# netcat 172.16.72.135
# pwd

/home/XXXX

Para nos asseguramos que a conexão a partir de nosso cliente até o servidor, tenha sido "mascarada" pelo relay, verificamos no servidor as conexões ativas, filtrando, por exemplo, a porta 5555 que é onde estamos "escutando", e obtemos o seguinte:

# netstat -aveptn | grep 5555
tcp 0 0 192.168.1.129:5555 172.16.72.135:51220 ESTABELECIDO 1000 44068 9038/bash

Vemos que, efetivamente, alguém se conectou em nossa porta 5555, que possui um shell (bash) e que a conexão vem do relay (172.16.72.135:51220).


Uso como scanner

Podemos encontrar alguma situação em que não temos o NMap ou algum outro programa à mão, no entanto, sempre poderemos lançar mão do Netcat e usá-lo como um scanner de portas (um pouco barulhento e tosco... rs).

Por exemplo:

# nc -vv 127.0.0.1 22-25
localhost [127.0.0.1] 25 (smtp) : Connection refused
localhost [127.0.0.1] 24 (?) : Connection refused
localhost [127.0.0.1] 23 (telnet) : Connection refused
localhost [127.0.0.1] 22 (ssh) open
SSH-2.0-OpenSSH_4.7p1 Debian

Enviar e-mail

É sempre divertido interagir com protocolos de rede baseados em texto com nada mais do que o Netcat e um teclado. Segue um pequeno exemplo mostrando como enviar e-mails comunicando-se com um servidor SMTP. O SMTP está descrito na RFC 5321, mas não é necessário muito sobre o protocolo para enviar uma simples mensagem. O serviço está vinculado à porta 25, e utilizaremos o parâmetro -C porque o mesmo é requerido para finalizações de linha (CRLF). O exemplo abaixo possui a transcrição de uma sessão:

$ ncat -C mail.exemplo.com 25
220 mail.exemplo.com ESMTP
HELO cliente.exemplo.com
250 mail.exemplo.com Olá cliente.exemplo.com
MAIL FROM:a@exemplo.com
250 OK
RCPT TO:b@exemplo.com
250 Accepted
DATA
354 Enter message, ending with "." on a line by itself
From: a@exemplo.com
To: b@exemplo.com
Subject: Saudações!

Olá. Esta é uma pequena mensagem enviado pelo netcat.
.

250 OK
QUIT
221 mail.exemplo.com closing connection

Para fazer esse exemplo funcionar, altere o mail.exemplo.com para o seu servidor SMTP e o cliente.exemplo.com para o seu domínio. Naturalmente mudará o endereço de e-mail e a mensagem também. Isso funcionará utilizando seu servidor de e-mail válido, com seu endereço real, ou quando utilizar o servidor de e-mail do remetente (procure pelo registro MX para o domínio em seu endereço de e-mail).

Obviamente que esta técnica pode ser utilizada para mais do que apenas enviar emails. Netcat é uma grande ferramenta de debug para qualquer protocolo baseado em texto. O debug é feito algumas vezes com o comando telnet, pois ele provê algo como uma resposta em texto bruto. Porém, o Netcat possui algumas vantagens sobre o telnet. O Netcat não exibe nada além do que é enviado pelo host remoto. O telnet não é tão bom para dados binários arbitrários, pois reserva alguns bytes como caracteres de controle. Além do mais, telnet não funciona com o protocolo UDP.


Encadeando netcats

Netcat foi desenvolvido para trabalhar com um pipeline, então naturalmente a saída de uma instância do Netcat pode alimentar a entrada de outro. Abaixo segue uma maneira de enviar um arquivo de log de um host para outro através de um intermediário:

host3# ncat -l > log.txt
host2# ncat -l | ncat host3
host1# ncat --send-only host2 <>

Um possível problema com esta técnica é que funciona em "mão única": host1 pode enviar, mas não é possível para o host3 enviar qualquer coisa para o host1. Nesse caso não importa, mas isso pode ser feito com algumas pequenas mudanças. Vejamos:

host3# ncat -l > log.txt
host2# ncat -l --sh-exec "ncat host3"
host1# ncat --send-only host2 <>

O Netcat em modo de escuta no host2, ao receber uma conexão cria um "novo netcat" para falar com o host3 e conecta a entrada e saída do programa em execução no host1 e host3 encadeando-os. Esse mesmo "macete" pode ser utilizado em um host local também. O exemplo a seguir direciona a porta 8080 para o servidor web exemplo.org.br:

# ncat -l localhost 8080 --sh-exec "ncat exemplo.org.br 80"

Simulando SSL

Suponhamos que precise conectar em um servidor IMAP que requeira SSL, mas seu leitor de e-mails mão suporta SSL. O Netcat pode agir como uma ponta criptografada para conectar o cliente e o servidor. Conectaremos o cliente de e-mail à uma porta local e o Netcat encaminhará o tráfego, encriptado, para o servidor. Abaixo está como conectar o IMAP (porta 143) no host local ao IMAP com SSL (porta 993) no imap.exemplo.com.

# ncat -l localhost 143 --sh-exec "ncat --ssl imap.exemplo.com 993"

Uma vez que isso tenha sido executado, instrua o cliente de e-mail a conectar ao servidor IMAP no host local (localhost).

Esse "macete" funciona com protocolos que enviem o tráfego estritamente entre dois hosts. Não funciona muito bem para HTTP porque envolve hostnames e frequentemente envolve múltiplos hosts.

SSH através de um túnel Netcat

Com o Netcat e OpenSSH, é possível executar o SSH para um host atrás de um roteador com NAT sem precisar direcionar as portas no roteador. O roteador precisa ter o Netcat instalado. Abaixo segue como conectar via SSH à um host através de um roteador:

# ssh -o ProxyCommand="ssh -q ncat %h %p"

A opção ProxyCommand do ssh diz como abrir a conexão SSH para o host. Isso é feito abrindo outra sessão SSH para o roteador e conectando-o ao host com o Netcat.

E mais...

Há muitas coisas mais que podemos fazer com essa fantástica ferramenta, como por exemplo:
  • um programa de força bruta (bruteforce): poderíamos criar um dicionário e mandar palavra por palavra à uma porta, de forma que quando encontre a senha correta, faça o registro.
  • enumeração de serviços: basta conectar-se com a porta que queremos extrair a informação do serviço e guardar sua resposta para analisá-la posteriormente.
  • mini-chat: ainda que não acredite, isso pode ser feito :-)

E isso é apenas a ponta do iceberg...

24 de abril de 2010

Teste de invasão (parte 1) - Identificação de banner

Introdução

Um teste de invasão é um método de avaliação de segurança de um sistema ou rede computacional mediante a simulação de um ataque malicioso, por parte de um cracker. O processo implica em uma análise ativa das vulnerabilidades em potencial que possam resultar de uma má ou inadequada configuração do sistema. Essa análise se realiza a partir da posição de um atacante em potencial, e pode implicar na exploração ativa de vulnerabilidades de segurança.

Qualquer problema de segurança que se encontre será apresentado ao proprietário da rede, juntamente com uma avaliação de seu impacto e uma proposta de mitigação ou solução técnica.

Fonte: http://en.wikipedia.org/wiki/Penetration_test

Esse artigo será o primeiro de uma série, onde explicarei de forma básica as ferramentas e métodos utilizados em cada uma das seguintes fases de um teste de invasão:
  • Identificação de banner
  • Enumeração do alvo
  • Varredura
  • Sniffing e Spoofing
  • Ataques de força bruta
  • Varredura de vulnerabilidades
  • Negação de serviço

Cada fase terá sua análise sobre os seguintes aspectos:
  • Descrição (da técnica/fase)
  • Ferramentas (utilizadas para a execução da técnica)
  • Método de Uso (forma de utilizar a ferramenta)
  • PoC (a famosa prova de conceito - Proof of Concept -, onde será dado um exemplo real com o resultado da utilização da ferramenta).


Identificação de banner

Um banner é definido como a obtenção do estado ou informação por meio de solicitações a determinadas portas do sistema.

Ferramentas:

Telnet

Telnet usa a porta 23 para realizar a conexão. Agora, se tentarmos conectar a uma determinada porta, ele nos devolve um banner da porta que tentamos conectar.

Método de uso: telnet [host-name [port]]

PoC:

# telnet 192.168.0.4 25
Trying 192.168.0.4...
Connected to 192.168.0.4.
Escape character is '^]'.
220 hacklabxp Microsoft ESMTP MAIL Service, Version: 6.0.2600.2180 ready at
Fri, 2 Apr 2010 19:45:41 -0500

Netcat

Netcat é uma ferramenta para protocolo TCP/IP, mas quando usamo-lo para reconhecimento de banners, retorna as informações da porta na qual tentamos conectar.

Método de uso: nc [host-name [port]]

PoC:

# nc 192.168.0.4 25
220 hacklabxp Microsoft ESMTP MAIL Service, Version: 6.0.2600.2180 ready at
Fri, 2 Apr 2010 19:58:41 -0500

FTP

FTP é uma ferramenta para transferência de arquivos, mas quando usamos para reconhecimento de banners, retorna as informações da porta na qual tentamos conectar.

Método de uso: ftp [host-name [port]]

PoC:

# ftp 192.168.0.4 25
Connected to 192.168.0.4.
220 hacklabxp Microsoft ESMTP MAIL Service, Version: 6.0.2600.2180 ready at
Fri, 2 Apr 2010 20:07:32 -0500

AMAP

AMAP é uma ferramenta para identificar os protocolos de aplicação nas portas do alvo.

Método de uso: amap [Options] [host-name [port]]

PoC:

# amap -b 192.168.0.4 25
amap v5.2 (www.thc.org/thc-amap) started at 2010-04-02 20:40:15 - MAPPING mode
[..cortado..]
Protocol on 192.168.0.4:25/tcp matches smtp - banner: 220 hacklabxp Microsoft
ESMTP MAIL Service, Version 6.0.2600.2180 ready at Fri, 2 Apr 2010 204015
-0500 \r\n500 5.3.3 Unrecognized command\r\n
[..cortado..]


Complemento

Depois de obter a informação das portas nas quais realizamos as conexões, o mais importante é saber a qual sistema operacional pertence esses dados.

Nmap

Um parâmetro do Nmap, nos permite identificar e/ou estabelecer o sistema operacional residente na máquina alvo.

Método de uso: nmap -O [host-name]

PoC:

# nmap -O 192.168.0.4
[..cortado..]
OS details: Microsoft Windows XP SP2 or SP3, or Windows Server 2003
[..cortado..]

Xprobe2

Xprobe2 permite determinar qual sistema operacional está sendo executado em um servidor remoto. Envia vários pacotes de dados ao servidor e analisa as respostas.

Método de uso: xprobe2 [host-name]

PoC:

# xprobe2 192.168.0.4
[..cortado..]
[+] Primary guess:
[+] Host 192.168.0.4 Running OS: "Microsoft Windows XP SP2" (Guess probability: 100%)
[..cortado..]

Auxiliary Metasploit

NetBIOS Information Discovery.

Método de uso:

msf> use scanner/netbios/nbname
msf auxiliary(nbname)> set rhosts [host-name]


PoC:

msf> use scanner/netbios/nbname
msf auxiliary(nbname)> set rhosts 192.168.0.4
rhosts => 192.168.0.4
msf auxiliary(nbname)> exploit
[..cortado..]
[*] 192.168.0.4 [HACKLABXP] OS:Windows Names:(HACKLABXP, GRUPO_TRABAJO,
__MSBROWSE__) Addresses:(192.168.0.4) Mac:00:0c:29:33:dd:72
[..cortado..]

Conclusão

A partir disso, com as informações que coletamos, podemos imaginar quais os possíveis serviços ou sistema operacional que podem ser usados num ataque.

6 de abril de 2010

O Brasil, Inteligência, e o Custo do Vazamento das Informações Governamentais

Por José Antonio Milagre

Fonte: http://www.dicas-l.com.br/legaltech/legaltech_20100225.php

Não é de hoje que sabemos sobre certos episódios envolvendo espionagem, vazamento de informações e crime organizado dentro do setor público brasileiro. Com a tecnologia da informação, as formas de coleta indevida e difusão das informações facilitaram os crimes digitais, associado ao fato da ignorância de muitos servidores públicos na proteção das informações.

Longe dos pomposos e não tão eficientes órgãos de segurança e inteligência do Governo Federal e dos Estados ricos da Federação, encontramos Estados, Prefeituras e orgãos manipulando informações sensíveis, diga-se, matéria prima para fraudes e golpes, sem qualquer proteção. São dados de concursos, de segurança, arrecadação, licitações, contratos, convênios, imóveis a serem leiloados e outras informações aptas a serem exploradas para a fraude ou exploração ilícita. O resultado é previsível.

No Brasil, o gabinete de segurança institucional apresenta relatos de falhas, como no caso das câmeras do Palácio do Planalto, que não registraram as placas dos veículos que estiveram por lá no início de 2009[1]. Na previdência, a fraude chega a 1,6 bilhões de reais[2], e conta com uso indevido de informações do sistema de óbito de segurados, o SISOB, bem como outras técnicas de uso indevido de dados, o que faz do país um dos que mais possuem "mortos-vivos" do mundo em termos previdenciários. Estamos também entre os campeões de "empresas-fantasma", aptas a abocanhar licitações do norte a sul do país.

A prórpia Polícia Federal tem sua conduta questionada, no que cerne ao vazamento de informações de inquéritos e outros procedimentos, para a imprensa, televisões e outros privilegiados, o que gerou a indignação do ministro do Supremo Tribunal Federal, Gilmar Mendes, também em 2009 [2], e que também motivou o pacotão da segurança pública que pretende suspender e até demitir o agente que se manifestar sobre investigação que participe ou tenha conhecimento[3]

No centro de São Paulo, é possível comprar senhas para o maior banco de dados da segurança pública do Brasil, o InfoSeg [4], a custo irrisório de 2 mil reais, como já noticiado na mídia brasileira.

Outros entes públicos de nível federal, estadual e municipal já experimentaram a fraude resultado da associação entre maus servidores e particulares bandidos. A epidemia não é só pública, já que estima-se que no Brasil boa parte dos negócios fechados no mercado financeiro tenham como suporte o vazamento de informações[5].

O que o vazamento de informações causa" Dano e desfalque ao erário. Tomemos o exemplo do vazamento de informações que prejudicou uma operação policial no Rio de Janeiro, em 2007, nas favelas do Complexo São Carlos, no Estácio, onde a Polícia pretendia prender 100 pessoas. Um homem foi preso.

Outro exemplo, o vazamento das provas do ENEM em 2009[7]. 500 mil reais era o que o funcionário da gráfica contratada pelo Ministério da Educação queria para fornecer as informações ao Jornal "O Estado de São Paulo". Resultado? O sabido cancelamento da prova, ato que custou nada menos que 30 milhões ao Governo.

Mais um exemplo, a venda dos caças ao Governo Brasileiro, fato amplamente noticiado em 2009, onde a despeito do termo de confidencialidade estabelecido pela Força Aérea Brasileira (FAB), ficou claro o vazamento de informações sobre o preço ofertado pela francesa Dassault[8]. No Brasil, a Lei 9883/99 institui o Sistema Brasileiro de Inteligência, no âmbito federal, e cria a ABIN. Este sistema é responsável pela coleta e custódia de informações para servir ao Presidente da República em suas decisões. Todos os entes públicos que manipulam informações de interesse nacional compõem o SBI e estão sujeitos ao controle da ABIN. Ora, se existe permissivo legal para o monitoramento e auditoria, porque tantos escândalos?

Não bastasse, sabemos que fora do executivo federal, órgãos públicos municipais e estaduais ainda não atentaram para o risco da negligencia, imprudência ou imperícia na manipulação de informações confidenciais. O Código Penal brasileiro prevê em seu artigo 325 o crime de violação de sigilo funcional também para quem permite ou facilita o acesso de terceiros a sistemas de informações da administração pública, estabelecendo ainda uma pena de reclusão que pode chegar de 2 a 6 anos e multa. Ou seja, ser negligente com sistemas informáticos, na administração pública, é crime!

Já se o funcionário público é quem insere ou altera os dados nos sistemas da administração, pode responder pelo peculato informático, dependendo das circustâncias, será enquadrado nos arts. 313-A e 313-B do Código Penal, com pena que pode chegar a 12 anos de reclusão. Mas só punição adianta? Efetivamente que não, eis que como verificamos, o peculato informático foi criado em 2000 e nem por isto desestimulou o vazamento de informações públicas e pelo contrário, hoje são os particulares que praticam o crime de exploração de prestígio, ao se valerem das relações com funcionários públicos maléficos, na obtenção de vantagens.

A resposta é a efetiva gestão de segurança da informação, com a implementação de um sistema eficaz e que considere pessoas acima de ferramentas e softwares e leve em consideração que influências internas são as principais responsáveis pelo vazamento de dados na área pública e também privada. Uma pesquisa mais refinada no Google e descobrimos quantos servidores utilizam e-mails do governo para usos privados. Mais, sabemos de casos em que o servidor foi desligado e anos depois ainda detinha privilégios de acesso à rede VPN governamental, agenciando tais informações à seu critério. Documentos privados circulam na internet com timbres oficiais, e que podem ser utilizados por estelionatários para confecção de falsos documentos e aplicação de golpes.

Dados não são validados quanto ingressam nas bases da adminsitração, acordos de confidencialidade não são cumpridos, funcionários não são conscientizados dos riscos, não existem perímetros físicos de proteção de ativos, funções não são segregadas e o pior, em alguns órgãos os gestores públicos sequer sabem quais os ativos informacionais são importantes para a empresa pública, e o quanto devem se esforçar para protegê-los.

Estas, são apenas algumas posturas inerentes à ausência de um sistema de gestão que preze pelos fundamentos da segurança: integridade, disponibilidade e confidencialidade de dados, e principalmente, que seja testado e avaliado periodicamente, por meio de testes de intrusão, engenharia social e outras técnicas homologadas e válidas em segurança da informação.

Se você questionar a um gestor de segurança de um órgão público se ele tem uma ferramenta firewall licitada funcionando em sua área o mesmo afirmará que sim. Agora experimente questionar se ele tem uma política de gestão de continuidade do negócio, ou se adota gestão da segurança no desenvolvimento e suporte de seus sistemas, ou ainda se desenvolveu uma célula de forense digital vinculada a seu time de resposta a incidentes...

As proteções contra vazamentos devem ser objeto de avaliação periódica e a inteligência é fundamental neste ponto. Não acabaremos com o vazamento de informações públicas licitando firewalls, software de segurança e detectores de intrusão, mas aliando a rigorosa legislação brasileira já existente, com técnicas de monitoramento e screening dos funcionários públicos que lidam com informações críticas. A inteligência não deve estar só no âmbito federal, e principalmente, deve sair do papel e ser aplicada. Aquele que manipula informações públicas sensíveis deve estar ciente de que dada a responsabilidade que detém, pode ser auditado, sem que possa evocar a proteção conferida a um cidadão comum, no que tange à privacidade.

Tomemos o exemplo de Portugal onde o Serviço de Informações da República (SIS) e o Serviço de Informações Estratégias, em 2009, assinaram protocolos para a inserção de espiões nos serviços públicos. Mas qual a finalidade desta medida" Simples, combater a criminalidade organizada dentro do Governo, esta, que se vale de informações confidenciais e privilegiadas para movimentar um mercado negro de milhões de euros. Aqui não é diferente.

No Brasil, algumas iniciativas ainda engatinham, mas servem de exemplo para todos os órgãos públicos da Federação, como o projeto de Lei que dispõe sobre o regime disciplinar do Departamento da Polícia Federal e da Polícia Civil do Distrito Federal, que institui a chamada "sindicância patrimonial", destinada a averiguar e identificar servidores que ostentam patrimônio imensamente maior do que o compatível com a função. São medidas que podem auxiliar a redução dos crimes envolvendo vazamento de informações eis que quem tem acesso a informações sigilosas governamentais, com certeza não as cede gratuitamente.

Enfim, demonstramos que o vazamento de informações na administração pública em todas as suas esferas é realidade, motivada e impulsionada pelo vantajoso e lucrativo tráfico de informações e principalmente pela ausência de monitoramento dos ativos de tecnologia da informação e seus respectivos suportes. Igualmente, concluímos que não existe uma solução pacífica e incontroversa para amenização desta patologia, porém sabemos que esta solução passa longe da compra e mais compra de softwares e dispositivos de segurança, e que um caminho pode ser a aplicação da lei, em cotejo com a fiscalização e testes de intrusão para avaliar condutas dolosas e culposas, perícia digital para identificar a autoria de incidentes, além do monitoramento de ex-agentes e a chamada sindicância patrimonial.

Resta pacífico que serviços de inteligência em sua gênese são concebidos no escopo de apoiar a tomada de decisões governamentais, e mais que isso, de proteger ativos das ameaças, sobretudo digitais, antecipando problemas e identificando causadores. Porém, mais claro ainda, fica demonstrado que sem governança, análise de risco, conformidade e monitoramento constante, tais serviços podem se voltar contra o Estado e seus cidadãos, servindo, por ação ou omissão, interesses escusos e criminosos, de sabida alta lucratividade.