Por que usar a NotHoly para análise de malware

A triagem de uma amostra suspeita tem duas necessidades que puxam em direções opostas: uma leitura rápida do que ela é, e um modelo que de fato discuta a amostra. Um assistente genérico recusa a segunda no instante em que a palavra malware aparece. Uma plataforma compartilhada não dá a primeira com segurança, porque rodar a amostra é a única coisa que você não quer que ela faça. A NotHoly cuida do lado estático e da explicação, e nunca roda a amostra. A detonação fica no seu laboratório isolado. O caso de uso de detection engineering cobre as regras que você constrói a partir dela.

#Triagem estática sem rodar a amostra

Anexe uma amostra no chat ou rode notholy analyze, e o parser extrai um primeiro retrato sem executar nada. Para um PE ou ELF você recebe o SHA-256, o tamanho, a entropia, o formato, o entry point, as seções e os imports. Você recebe as strings e uma prévia de disassembly do começo do arquivo. Um arquivo compactado dá a sua árvore, um documento dá o seu texto sem rodar uma macro ou um script, e um pickle de Python é desmontado, nunca carregado. Um padrão de chave ou token levanta um aviso credentials_detected, e um zip bomb para cedo com uma mensagem. Todo arquivo é parseado num sandbox descartável sem rede e com raiz só de leitura, porque um arquivo enviado é tratado como hostil. A referência de arquivos tem os tipos e limites.

notholy analyze ./sample.exe

#O modelo explica e nomeia a técnica

Com os fatos estáticos em mãos, o modelo os lê sem travar sobre se a análise é permitida, porque a análise é o trabalho. Ele explica o que uma seção ou um import sugere, agrupa strings no que parece C2, persistência ou anti-análise, e mapeia o comportamento para o MITRE ATT&CK, que está na base de conhecimento com a atribuição que a MITRE exige. Peça uma regra YARA ou Sigma e ele rascunha uma a partir dos indicadores que você confirmou. Uma string de versão ou produto pode ir para um lookup de CVE, que informa se o CVE está no CISA KEV e se tem uso conhecido em ransomware. Tanto a base de conhecimento quanto os dados de CVE leem pela CLI e pela API, então um lote de amostras é triado de um script. Quando o documento é a amostra, o parser puxa o texto sem rodar uma macro, então um arquivo de office ou PDF malicioso entrega o script embutido e as URLs para o modelo ler, não executar. O resultado é uma leitura que você põe na frente de um colega, com a técnica nomeada e uma fonte em cada afirmação.

strings -n 8 ./sample.exe | notholy "group these by C2, persistence and anti-analysis, then draft a YARA rule"

#A sua amostra fica contida

Nada que você envia é executado, e não há análise dinâmica, então a amostra nunca roda do nosso lado nem chega a um alvo. Um arquivo que você manda para análise é guardado criptografado, com uma expiração de uma hora registrada. A deleção automática ainda não está ativa, então escreva para [email protected] para remover um. A inferência da API não guarda prompt nem resposta, só metadados, então uma análise que você roda pela API não é mantida. A base de conhecimento e o modelo carregam técnica e documentação, não malware que funciona, então aqui é um lugar para entender uma amostra, não um lugar para conseguir uma.

#Onde não encaixa

Isto é triagem estática, não uma câmara de detonação. Não há análise dinâmica, nem captura de rede nem unpacking em tempo de execução, então uma amostra empacotada ou ciente de sandbox só entrega o seu comportamento real no seu laboratório. Não há decompilador nem grafo de fluxo de controle, e a prévia de disassembly é só o começo do arquivo. O modelo pode nomear a família errada, perder um indicador ou inventar um, então confirme cada IOC antes de ir para um relatório ou uma lista de bloqueio. Imagens dão só dimensões, sem OCR ainda.

Mantenha a detonação no seu laboratório, e deixe a NotHoly triar e explicar. Ponha um saldo pequeno em preços e mande a primeira amostra.