Por qué usar NotHoly para análisis de malware

El triaje de una muestra sospechosa tiene dos necesidades que tiran en sentidos opuestos: una lectura rápida de qué es, y un modelo que de verdad la discuta. Un asistente genérico rechaza la segunda en cuanto aparece la palabra malware. Una plataforma compartida no da la primera con seguridad, porque correr la muestra es lo único que no quieres que haga. NotHoly se encarga del lado estático y de la explicación, y nunca corre la muestra. La detonación queda en tu laboratorio aislado. El caso de uso de detection engineering cubre las reglas que construyes a partir de ella.

#Triaje estático sin correr la muestra

Adjunta una muestra en el chat o corre notholy analyze, y el parser extrae un primer retrato sin ejecutar nada. Para un PE o ELF recibes el SHA-256, el tamaño, la entropía, el formato, el entry point, las secciones y los imports. Recibes las strings y una vista previa de disassembly del inicio del archivo. Un archivo comprimido da su árbol, un documento da su texto sin correr una macro ni un script, y un pickle de Python se desensambla, nunca se carga. Un patrón de clave o token levanta un aviso credentials_detected, y un zip bomb para pronto con un mensaje. Cada archivo se parsea en un sandbox desechable sin red y con raíz de solo lectura, porque un archivo subido se trata como hostil. La referencia de archivos tiene los tipos y límites.

notholy analyze ./sample.exe

#El modelo lo explica y nombra la técnica

Con los hechos estáticos en mano, el modelo los lee sin trabarse en si el análisis está permitido, porque el análisis es el trabajo. Explica lo que una sección o un import sugiere, agrupa strings en lo que parece C2, persistencia o anti-análisis, y mapea el comportamiento a MITRE ATT&CK, que está en la base de conocimiento con la atribución que MITRE exige. Pide una regla YARA o Sigma y bosqueja una a partir de los indicadores que confirmaste. Una string de versión o producto puede ir a un lookup de CVE, que informa si el CVE está en CISA KEV y si tiene uso conocido en ransomware. Tanto la base de conocimiento como los datos de CVE se leen por la CLI y por la API, así que un lote de muestras se tría desde un script. Cuando el documento es la muestra, el parser saca su texto sin correr una macro, así que un archivo de office o PDF malicioso entrega su script embebido y sus URLs para que el modelo lea, no ejecute. El resultado es una lectura que pones frente a un colega, con la técnica nombrada y una fuente en cada afirmación.

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

#Tu muestra queda contenida

Nada de lo que subes se ejecuta, y no hay análisis dinámico, así que la muestra nunca corre de nuestro lado ni llega a un objetivo. Un archivo que mandas a análisis se guarda cifrado, con una expiración de una hora registrada. El borrado automático aún no está activo, así que escribe a [email protected] para quitar uno. La inferencia de la API no guarda prompt ni respuesta, solo metadatos, así que un análisis que corres por la API no se conserva. La base de conocimiento y el modelo llevan técnica y documentación, no malware que funciona, así que esto es un lugar para entender una muestra, no un lugar para conseguir una.

#Dónde no encaja

Esto es triaje estático, no una cámara de detonación. No hay análisis dinámico, ni captura de red ni unpacking en tiempo de ejecución, así que una muestra empaquetada o consciente del sandbox solo entrega su comportamiento real en tu laboratorio. No hay decompilador ni grafo de flujo de control, y la vista previa de disassembly es solo el inicio del archivo. El modelo puede nombrar la familia equivocada, perder un indicador o inventar uno, así que confirma cada IOC antes de que entre en un informe o una lista de bloqueo. Las imágenes dan solo dimensiones, sin OCR aún.

Mantén la detonación en tu laboratorio, y deja que NotHoly tríe y explique. Pon un saldo pequeño en precios y manda la primera muestra.