Juiz, Júri e Executável

Uma Ferramenta Forense de Caça a Ameaças

Funcionalidades:

• Analise um sistema de ficheiros montado à procura de ameaças imediatamente
• Ou recolha uma linha de base do sistema antes de um incidente, para capacidade extra de caça a ameaças
• Pode ser usado antes, durante ou após um incidente
• Para uma ou muitas estações de trabalho
• Analisa a MFT, ignorando permissões de ficheiros, bloqueios de ficheiros ou proteções/ocultações/sombreamentos do SO
• Até 51 propriedades diferentes recolhidas para cada ficheiro
• Os resultados da análise vão para uma tabela SQL para pesquisa posterior, agregação de resultados ao longo de várias análises e/ou várias máquinas, e análise histórica ou retrospetiva
• Aproveite o poder do SQL para pesquisar sistemas de ficheiros, consultar propriedades de ficheiros, responder a perguntas complexas ou de alto nível, e caçar ameaças ou indicadores de compromisso

Requisitos:

• .NET Framework v4.8
• Microsoft Visual C++ 2015 Redistributable
• Base de dados SQL local ou remota com acesso de leitura/escrita/criação.
• Visual Studio (se desejar compilar o código C#)
• Acesso à internet (ou então como obteve este código??? Também para pacotes nuget...)
• Conhecimento básico de SQL

Caça a vírus, malware e APTs em (vários) sistemas de ficheiros escrevendo consultas em SQL.

Deixe-me elaborar...

Começa com um disco ou imagens de disco que estão potencialmente sujos com malware, vírus, APTs (ameaças persistentes avançadas) ou similares, e depois analisa-os com esta ferramenta. (Opcionalmente, e assumindo que tem a sabedoria e previsão para o fazer, pode desejar analisar primeiro uma imagem de disco de base conhecida como boa com esta ferramenta (ou depois — não importa). Isto certamente não é necessário, mas só pode ajudar.) A parte de análise forense desta ferramenta recolhe um monte de propriedades sobre cada ficheiro num sistema de ficheiros (ou numa(s) imagem(ns) dele), e coloca essas propriedades numa tabela de base de dados relacional SQL. O segredo está em poder caçar ameaças, investigar ou fazer perguntas sobre os dados através do uso de consultas, na linguagem SQL, contra a base de dados criada. Uma caraterística chave aqui foi NÃO inventar uma linguagem de consulta proprietária. Se sabe SQL e como clicar num botão, então já sabe usar esta ferramenta como um profissional. Mesmo que não saiba, este conceito é suficientemente poderoso para que consultas pré-definidas (veja abaixo) lhe dêem muito rendimento.

Análise a nível forense.

Primeiro, a ferramenta cria uma entrada na base de dados para cada registo encontrado na MFT (tabela de ficheiros mestre — é como o NTFS faz o seu registo). Isto ignora permissões de segurança de ficheiros, ocultação de ficheiros, técnicas de ocultação ou ofuscação, eliminação de ficheiros ou adulteração de carimbos de data/hora. Estas técnicas não impedirão que o ficheiro seja analisado e catalogado. Os bytes do ficheiro são lidos da MFT e o máximo de pontos de dados possível são recolhidos dos bytes do ficheiro lidos da MFT antes de tentar aceder a qualquer ponto de dados usando as chamadas de API do SO de nível superior.

Análise de dados rica e de alto nível.

Após os dados forenses e da MFT estarem seguros, as propriedades a nível do sistema operativo, dados e metadados disponíveis sobre cada ficheiro são recolhidos e aumentam cada entrada criada a partir da entrada da MFT. Como resultado disto, mesmo que o ficheiro ou as suas propriedades da API do Sistema Operativo ou do framework dotnet não possam ser acedidas devido a permissões de ficheiros (ACL), bloqueios de ficheiros (está em uso), corrupção do disco, um ficheiro de comprimento zero, ou qualquer uma das várias outras razões, a existência do ficheiro será ainda assim registada, logada e rastreada. A entrada, no entanto, simplesmente não conterá a informação sobre ele que não estava acessível ao sistema operativo. Até 51 pontos de dados diferentes podem ser recolhidos para cada ficheiro.

Para cada ficheiro, a informação recolhida inclui:

• Hash SHA256
• Hash MD5
• Hash da tabela de importação (se existir)
• Número MFT e Número de Sequência
• Datas de Criação/Modificação/Acesso da MFT
• Datas de Criação/Modificação/Acesso Reportadas pelo SO
• Todas as propriedades de ficheiro 'padrão' do SO: localização, tamanho, carimbos de data/hora, atributos, metadados
• É um PE ou DLL ou Driver?
• É assinado com Authenticode?
• A cadeia de certificados X.509 verifica?
• Regras YARA personalizadas (Lista os nomes das regras que correspondem)
• Entropia do ficheiro
• Até 51 pontos de dados diferentes no total

Exemplo de linha de dados:

Consultas Predefinidas:

/*
IDEA: All files in the directory C:\Windows\System32\ should be 'owned' by TrustedInstaller.
If a file in the System32 directory is owned by a different user, this indicates an anomaly, 
and that user is likely the user that created that file.
Malware likes to masquerade around as valid Windows system files.
Executables that are placed in the System32 directory not only look more official, as it is a common path for
system files, but an explicit path to that executable does not need to be supplied to execute it from the
command line, windows 'Run' dialog box of the start menu, or the win32 API call ShellExecute.
*/

SELECT 
TOP 1000 * 
FROM  [FileProperties]
WHERE
        [FileOwner] <> 'TrustedInstaller'
    AND [DirectoryLocation] = ':\Windows\System32'
    AND IsSigned = 0
ORDER BY [PrevalenceCount] DESC


/*
IDEA: The MFT creation timestamp and the OS creation timestamp should match.
If the MFT creation timestamp occurs after the creation time reported by the OS meta-data,
this indicates an anomaly.
Timestomp is a tool that is part of the Metasploit Framework that allows a user to backdate a file
to an arbitrary time of their choosing. There really isn't a good legitimate reason for doing this
(let me know if you can think of one), and is considered an anti-forensics technique.
*/

SELECT 
TOP 1000 * 
FROM  [FileProperties]
WHERE
	([MftTimeAccessed] <> [LastAccessTime]) OR
	([MftTimeCreation] <> [CreationTime]) OR
	([MftTimeMftModified] <> [LastWriteTime])
ORDER BY [DateSeen] DESC

/*
IDEA: The 'CompileDate' property of any executable or dll should always come before the creation timestamp for that file.
Similar logic applies as for the MFT creation timestamp occuring after the creation timestamp. How could a program have been
compiled AFTER the file that holds it was created? This anomaly indicates backdating or timestomping has occurred.
*/


SELECT 
TOP 1000 *
FROM  [FileProperties]
WHERE
	([MftTimeCreation] < [CompileDate]) OR
	([CreationTime] < [CompileDate])
ORDER BY [DateSeen] DESC