Why use NotHoly for malware analysis

Triage of a suspicious sample has two needs that pull against each other: a fast read of what it is, and a model that will actually discuss it. A general assistant refuses the second the moment the word malware appears. A shared platform cannot give you the first safely, because running the sample is the one thing you do not want it to do. NotHoly handles the static side and the explanation, and it never runs the sample. Detonation stays in your own isolated lab. The detection engineering use case covers the rules you build from it.

#Static triage without running the sample

Attach a sample in the chat or run notholy analyze, and the parser extracts a first picture without executing anything. For a PE or ELF you get the SHA-256, the size, the entropy, the format, the entry point, the sections and the imports. You get the strings and a disassembly preview of the start of the file. An archive gives its tree, a document gives its text without running a macro or a script, and a Python pickle is disassembled, never loaded. A key or token pattern raises a credentials_detected warning, and a zip bomb stops early with a message. Every file is parsed in a disposable sandbox with no network and a read-only root, because an uploaded file is treated as hostile. The files reference has the types and limits.

notholy analyze ./sample.exe

#The model explains it and names the technique

With the static facts in hand, the model reads them without stalling on whether analysis is allowed, because analysis is the work. It explains what a section or an import suggests, groups strings into what looks like C2, persistence or anti-analysis, and maps behavior to MITRE ATT&CK, which is in the knowledge base with the attribution MITRE requires. Ask for a YARA or Sigma rule and it drafts one from the indicators you confirmed. A version or product string can go to a CVE lookup, which reports whether the CVE is in CISA KEV and whether it has known ransomware use. Both the knowledge base and the CVE data read through the CLI and the API, so a batch of samples is triaged from a script. When a document is the sample, the parser pulls its text without running a macro, so a malicious office file or PDF gives up its embedded script and URLs for the model to read, not to execute. The result is a read you can put in front of a teammate, with the technique named and a source on each claim.

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

#Your sample stays contained

Nothing you upload is executed, and there is no dynamic analysis, so the sample never runs on our side or reaches a target. A file you send for analysis is stored encrypted, with a one-hour expiry recorded. Automatic deletion is not active yet, so write to [email protected] to have one removed. API inference stores no prompt or response, only metadata, so an analysis you run through the API is not kept. The knowledge base and the model carry technique and documentation, not working malware, so this is a place to understand a sample, not a place to source one.

#Where it does not fit

This is static triage, not a detonation chamber. There is no dynamic analysis, no network capture and no unpacking at run time, so a packed or sandbox-aware sample only gives up its real behavior in your own lab. There is no decompiler and no control-flow graph, and the disassembly preview is only the first part of the file. The model can name the wrong family, miss an indicator or invent one, so confirm every IOC before it goes in a report or a block list. Images give dimensions only, with no OCR yet.

Keep detonation in your lab, and let NotHoly triage and explain. Put a small balance on pricing and send the first sample.