> ## Documentation Index
> Fetch the complete documentation index at: https://docs.decodalabs.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Triage Pipeline
> What happens automatically when you upload a sample to DECODA.
Every file uploaded to DECODA goes through an automated triage pipeline before you ask a single question. This gives you an immediate baseline of intelligence to work from.
## Pipeline Stages
The triage runs asynchronously and you'll see real-time progress updates in the chat as each stage completes.
If the upload is an archive (ZIP, RAR, or 7z), DECODA extracts the contents inside the isolated sandbox. Zip bomb detection is built in to prevent decompression attacks.
Password-protected archives are handled automatically. DECODA tries the passwords most commonly used to distribute malware samples, in order: `infected`, `malware`, `virus`, `password`, and `123456`. If none of these unlock the archive, it falls back to extracting without a password for unprotected files.
Once extracted, DECODA selects the primary sample to analyse (preferring executables, then scripts, then documents, and falling back to the largest file). It is this extracted file - not the archive wrapper - that flows through the rest of the pipeline. The original archive name is preserved in context so you always know where the sample came from.
The file is hashed using three algorithms:
* **MD5** - Legacy identifier, still widely used in threat intel feeds
* **SHA1** - Common in older detection systems
* **SHA256** - Primary identifier for lookup and threat-intel searches
For PE files, an **imphash** (import hash) is also computed during PE metadata extraction and is useful for clustering malware families.
The sample is scanned against DECODA's built-in YARA rulesets covering:
* Known malware families
* Packer and protector signatures
* Ransomware indicators
* Suspicious API patterns
DECODA identifies the file type and classifies it into one of 28 categories:
| Type | Description |
| -------------- | --------------------------------------------------------- |
| `native-pe` | Native Windows PE (C/C++, Delphi, Rust, etc.) |
| `dotnet` | .NET assembly (IL bytecode) |
| `elf` | Linux ELF binary |
| `macho` | macOS Mach-O binary |
| `go` | Go-compiled binary |
| `uefi` | UEFI firmware binary (EFI application/driver) |
| `shellcode` | Raw shellcode blob |
| `java-jar` | Java JAR archive |
| `apk` | Android APK/DEX file |
| `office-ole` | Legacy Office format with OLE streams |
| `office-ooxml` | Modern Office format (docx, xlsx, pptx) |
| `pdf` | PDF document |
| `onenote` | OneNote file with embedded attachments |
| `script` | Scripts (PowerShell, VBScript, JavaScript, batch, Python) |
| `lnk` | Windows shortcut file |
| `hta` | HTML Application file |
| `chm` | Compiled HTML Help file |
| `email` | Email file (.eml/.msg) |
| `iso` | ISO/IMG disk image |
| `vhd` | VHD/VHDX virtual disk image |
| `msi` | Windows Installer package |
| `firmware` | Embedded firmware (router, IoT) |
| `pcap` | PCAP/PCAPNG network capture |
| `evtx` | Windows Event Log file |
| `registry` | Windows Registry hive file |
| `prefetch` | Windows Prefetch file |
| `packed` | Packed/protected binary (UPX, Themida, etc.) |
| `unknown` | Unrecognised format |
For PE files (both native and .NET), additional metadata is extracted:
* **Compilation timestamp** - When the binary was compiled (can be faked but often useful)
* **Entry point address** - Where execution begins
* **Section table** - Names, sizes, and entropy of each section
* **Security flags** - ASLR, DEP, SEH, CFG, and other protection mechanisms
## Reading the Triage Card
Once triage completes, a summary card appears in your chat. Here's what each section means:
### Detection Assessment & Verdict
At the top of the card, DECODA shows a provisional verdict that summarises everything triage observed. The verdict is one of four values:
| Verdict | Meaning |
| -------------- | -------------------------------------------------------------------- |
| `Malicious` | Strong or compounding evidence of malicious behaviour. |
| `Suspicious` | Concerning indicators that fall short of a confident malicious call. |
| `Insufficient` | Not enough was observable to make a call - never assume benign here. |
| `Benign` | Affirmative clean evidence on a well-observed sample. |
Beneath the verdict, an **Evidence** list shows the signals that drove it, strongest first. Each row is tagged with a category (such as `family`, `injection`, `anti-analysis`, or `packing`), and lower-signal heuristic indicators collapse into a single expandable group to keep the lead findings prominent.
The verdict is backed by two underlying measures:
* **Confidence** - how strongly the evidence supports the verdict (high, medium, or low). A single strong indicator (for example an extracted C2 address) can yield high confidence; weaker indicators only reach high confidence when they compound.
* **Observability** - how much of the sample DECODA could actually see, expressed as a percentage. A heavily packed or encrypted sample has low observability, which caps confidence and steers an evidence-free result toward `Insufficient` rather than `Benign`.
Confidence and observability are different questions. Confidence asks "how sure are we about what we found?"; observability asks "how much could we see in the first place?" A sample can be highly observable yet still inconclusive, and an opaque sample with one decisive signal can still be called with confidence.
The score and verdict combine positively-weighted malicious signals with clean signals that subtract credit, so the assessment reflects evidence on both sides rather than a single red flag.
This verdict is a **pre-analysis baseline**, not a final answer. When you run Agent analysis, new findings are reconciled with the triage baseline: the verdict can be **escalated** freely as the Agent uncovers more, but it is only **de-escalated** toward `Benign` when positive clean evidence is found. The triage result acts as a floor you can build on.
### Hashes
The MD5, SHA-1, and SHA-256 hash values for the sample. Use the SHA256 to search other threat intel platforms.
### YARA Matches
Each match shows the rule name and the ruleset it came from. Multiple matches from different rulesets increase confidence in a classification.
### File Classification
The detected type determines which Agent mode tools are most relevant. For example, .NET samples unlock the .NET decompiler tools, while Office documents enable OLE analysis.