File analysis & content inspection
Static, format-aware file analysis: a verdict with its reasons, malware family and configuration, ATT&CK matrix, indicators to block and related samples.
The mlab File Scan analyzes a file statically and opens on its conclusion: a verdict, the malware family when one is known, the findings that led to it and the indicators to block. Below the conclusion sit the evidence (findings, ATT&CK matrix, indicators, related samples) and the raw output of every tool, so each statement can be checked against its source.
How a file scan works
Upload: choose a public or private report, then follow the upload as it happens.
Fingerprinting: hashes identify the file. A file mlab has already analyzed is not scanned again: you get its existing report, and no scan is counted.
Type detection: the type is read from the file's content, not trusted from its name. A type that contradicts the extension is itself a finding.
Routed scanners: executables, Office files, PDFs, shortcuts, scripts, archives, web pages and images each go to the scanners built for them.
Findings: what the tools found, worst first, folded into a verdict.
Results: the report, with the raw output of each tool.
File identity
- SHA256 & MD5: cryptographic hashes for unique identification and correlation across sources.
- SSDEEP and TLSH: fuzzy hashes for finding similar or modified variants of the same file.
- Size & MIME: file size and the type detected from the content.
- First seen: when mlab first analyzed the file, whatever its name or origin.
The waiting page
While a file is being analyzed, the waiting page follows each tool live and estimates the time left. Windows executables run through the most tools and get more processing capacity, so their reports finish sooner.
1. Verdict
Every report starts with one of four verdicts:
| Verdict | Meaning |
|---|---|
| Malicious | At least one finding is a behaviour legitimate files do not have: an extracted malware configuration, a malware family rule, a reputation feed listing the exact file as malicious, DDE, a remote template, a macro or shortcut that runs a command, a credential form posting to another host. One is enough. |
| Suspicious | Traits worth a look, none conclusive on its own. |
| Known good | A reference set of legitimate software lists this exact file, and nothing malicious was found. |
| No detection | Nothing fired. |
Under the verdict, the summary shows:
- Family: the malware family, from an extracted configuration, a reputation feed or a YARA rule, most specific first.
- Why: the main findings that decided the verdict.
- Block: the key indicators to block first (command-and-control addresses from a configuration, then URLs, domains and IPs).
No detection is not clean
There is no score. Static analysis can show that a file is malicious or suspicious, never that it is safe. "No detection" means an absence of signal, which is why it is never shown in green.
2. Findings
Findings are listed worst first. Each one says what it means and lists the values behind it (rule names, macro keywords, decoded commands, configuration fields).
Reputation
When a reputation feed knows the exact file, it says so at the top:
- Known malicious sample: a feed carries this file as malicious.
- Listed as known-good: a reference set of legitimate software carries this file.
What is flagged
| Severity | Findings |
|---|---|
| High | Extracted malware configurations, YARA rules for known malware or attacker tooling, remote templates (ATT&CK T1221), DDE command execution, Excel 4 (XLM) macros that run on open, credential forms posting to another host, phishing kit exfiltration channels (Telegram bots, mailto:) |
| High or medium | VBA macros (high when a macro both starts itself and reaches out), PDFs that act on their own (high for JavaScript or a program launch), encoded commands decoded from scripts, shortcut (LNK) command lines (high when they download, hide a window or run encoded code) |
| Medium | YARA hunting rules, obfuscated JavaScript, QR codes in images, embedded OLE objects, structural anomalies (polyglots, trailing data, a type that contradicts the extension), packers and protectors, encrypted content, CVE identifiers in tool output, Authenticode signatures that do not verify |
| Medium or low | What an executable can do, from capa, with its ATT&CK technique: injection, privilege changes, anti-analysis, persistence, C2. A verified signature lowers it, since signed tools trip some of these too. |
| Low | High entropy in executables, missing code signature, TLS callbacks, other capabilities, noteworthy entries inside archives |
Files are checked against a large, curated set of YARA rules, plus mlab's own rules for exploit documents. Entropy is only flagged on executables: documents, archives and images are compressed by design.
Malware family and configuration
For known families, the configuration embedded in the sample is decoded: its command-and-control addresses, keys and identifiers. The family it names leads the summary, and its C2 addresses lead the indicators to block.
Windows executables also go through packer and protector identification, and obfuscated strings are recovered with FLOSS, so strings hidden at build time still reach the findings and indicators.
Identifiers to pivot on
Values that say nothing about intent but link a sample to its siblings are grouped apart from the findings: imphash, Rich header hash, telfhash, TLSH, PDB path, compile time, overlay SHA-256, and the MAC address recorded in a shortcut.
3. ATT&CK matrix
The capabilities found in the code are laid out as a MITRE ATT&CK matrix: one column per tactic seen, in the matrix's order, with the techniques under it (linked to MITRE) and the capabilities that showed each one.
4. Indicators
Every network indicator found in the file (command-and-control addresses, URLs, domains, IPs, e-mail addresses) is listed with:
- the tool that found it and its context;
- a Pivot button that opens mlab's own lookup for that indicator;
- an Add to case button.
Indicators are shown as text, never as links: they may be live malicious URLs.
5. Related samples
Other files analyzed by mlab that are linked to this one, each with the reason:
| Link | Reason shown |
|---|---|
| Same build fingerprint | same imphash, same authentihash (same code), same Rich header, same telfhash, same PDB path |
| Same infrastructure | a command-and-control address shared through an extracted configuration |
| Same family | the same family configuration |
| Close bytes | a small TLSH distance: most of the bytes match, which survives the edits that change every exact hash |
A value shared by a very large number of samples (a toolchain default, like the imphash many .NET binaries share) is not treated as a link. Private samples you cannot open are never listed, so this view never reveals what another organization uploaded.
6. Tool results
Each compatible tool runs independently and its raw output is preserved, one section per tool, so you can see how every finding was derived. Findings link back to what the tools produced: there is no hidden scoring layer. A tool that fails does not affect the others.
Why some tools may not appear
Tools are selected by file type, size and content. Some files are not compatible with some analyses, and more tools are added as support expands.
7. Export and AI explanation
From the top of the report:
- PDF: download the report as a PDF.
- JSON: download the results as JSON.
- AI explanation: a language model reads the report's evidence and explains what the file does. Nothing is generated until you click. It needs an account (visitors are asked to sign in), counts against your AI quota, and never changes the verdict.
Supported formats
The type is detected from the file's content. At upload, these extensions are accepted:
| Category | Extensions |
|---|---|
| Executables and installers | .exe, .dll, .sys, .scr, .cpl, .ocx, .msi, .elf, .so, .bin |
| Shortcuts | .lnk |
| Office documents and mail | .doc, .dot, .docx, .docm, .dotm, .xls, .xlt, .xlsx, .xlsm, .xltm, .ppt, .pps, .pptx, .pptm, .ppsm, .potm, .rtf, .one, .msg |
.pdf | |
| Web pages and HTML applications | .html, .htm, .xhtml, .shtml, .mht, .hta, .svg |
| Scripts | .js, .jse, .vbs, .vbe, .wsf, .wsh, .ps1, .psm1, .psd1, .bat, .cmd, .py, .pl, .php, .au3, .ahk |
| Archives and disk images | .zip, .jar, .7z, .rar, .gz, .tgz, .bz2, .xz, .tar, .cab, .iso, .img |
| Images | .png, .jpg, .jpeg |
Size limits and quotas
| Plan | Largest file | File scans per day |
|---|---|---|
| Without an account | 10 MB | 2 |
| Free | 10 MB | 10 |
| Pro | 100 MB | 50 |
| Team | 100 MB | 250 |
| Enterprise | 100 MB | Fair use |
Uploading a file mlab has already analyzed opens its existing report and does not count against your quota. Without an account, you accept the terms of service and the privacy policy before uploading, and the report is public.
Private reports
On Pro, Team and Enterprise, a file can be scanned privately: the report is visible to your organization only, and anyone else sees no trace of it, including in other files' related samples. On Free and without an account, reports are public.
Privacy follows the file
If someone else later submits the same file as a public scan, its report becomes public.
Responsible usage & limitations
File analysis is performed in a controlled and defensive context. mlab does not execute files, does not attempt exploitation, and does not modify uploaded content.
- No execution: uploaded files are never executed. Analysis is strictly static and read-only.
- Isolated analysis: each analysis runs in an isolated sandbox that holds no credentials, with single-use access valid for that file only. Scanners are rebuilt from pinned versions, and each build publishes its software bill of materials.
- Retention: uploaded files are stored privately in the EU and deleted within 48 hours, on every plan. We keep technical indicators derived from the analysis (hashes, verdicts, detection results, malicious IOCs) for up to 3 years, detached from your account and with no personal data. See the privacy policy.
- Defensive use: designed for defensive security use cases and legitimate analysis.
- User responsibility: users are responsible for the content they upload and how they interpret results.
Microsoft 365 tenant scans
Scan a connected Microsoft 365 / Entra ID tenant from RedKit and get a report against the CIS Microsoft 365 Foundations Benchmark v7.0. Beta.
Email (EML) Analysis
Transparent, analyst-oriented inspection of raw email (.eml) files to understand phishing, spoofing, and mail delivery behavior.