Noriben: manual malware analysis that produces a text report instead of a VM image

The sandbox is the analyst, not the software

Noriben is a Python-based script that works in conjunction with Sysinternals Procmon to automatically collect, analyse, and report on runtime indicators of malware. The summary compresses the workflow into one line: it allows you to run an application, hit a keypress, and get a simple text report of the sample's activities.

That is the whole design idea, and it is the opposite of what an automated sandbox does. A conventional sandbox detonates the sample in an emulated or heavily instrumented environment with no human involved, and returns you a report. Noriben does not emulate anything. It runs the sample on your machine, with Procmon recording the system activity, and it is you who decides what to click.

The reason that matters is stated with examples. Noriben allows you to not only run malware similar to a sandbox, but to also log system-wide events while you manually run malware in ways particular to making it run. It can listen as you run an application that requires varying command line options, or user interaction, or you can watch the system as you step through the application in a debugger.

There is a video in the project summary about debugging a VM-checking malware in a way that still gets sandbox results, and the parenthetical is the interesting part, mis-clicks due to a mouse pointer that was 5 pixels off. That is a real and specific failure mode of automated detonation, a sample that detects the virtual machine and behaves differently, or a human interaction that the harness gets wrong. A human running the sample with the recording on sidesteps the whole class of problem.

The tool also has a second life that is worth knowing about. While Noriben was designed for analysis of malware, it has also been widely used to audit normal software applications. In 2013 it was used by the Tor Project to provide a public audit of the Tor Browser Bundle, linked as a technical report. That is a good sanity check on the design, because auditing a legitimate application is the same shape of task with none of the risk, and the tool behaved correctly in both cases.

The dependency is one binary, and the noise comes from whitelists

Noriben only requires Sysinternals procmon.exe, or procmon64.exe, to operate. That is the entire external dependency, and it is the key to understanding the design.

Procmon is a system-wide activity recorder. It watches the registry, the file system, processes, threads, network activity, and more, and it can save its capture as a PML file. What it cannot do is tell you which of those events matter. A raw Procmon capture of a few seconds of normal activity is thousands of lines, most of them the operating system doing what it always does.

Noriben takes that capture and turns it into something you can read, and the mechanism is filtering. The summary says it requires no pre-filtering, though it would greatly help, as it contains numerous white list items to reduce unwanted noise from system activity.

The phrase no pre-filtering matters, because Procmon itself supports filters, and Noriben lets you supply your own with the `-f FILTER` option to specify an alternate Procmon Filter PMC. The repository ships `ProcmonConfiguration.pmc` at the root, which is the capture configuration Noriben uses, and `Noriben.config` beside it, which is Noriben's own configuration file. So the layering is: the PMC file controls what Procmon captures, and the white lists inside Noriben control what survives analysis.

That two-layer design is also the tool's main weakness, and it is worth being honest about. A white list is a judgement about what is normal, encoded as a list of paths, registry keys, and hashes. It will suppress real activity if the sample happens to touch something on the list, and it will leave noise in if the sample does something unusual. The tool makes the output readable, and readable output is a filtered view of what happened.

The last push to the repository was on 2026-09-18, and the only release tag is 2.0 from 2023-08-09, so the code is being maintained while the published version is three years old.

The command line, and the flags that matter

The usage block in the project summary is the full option set, and a few of them are worth pulling out.

usage: Noriben.py [-h] [-c CSV] [-p PML] [-f FILTER] [--hash HASH]
                  [--hashtype {MD5,SHA1,SHA256}] [--headless] [-t TIMEOUT]
                  [--output OUTPUT] [--yara YARA] [--generalize] [--cmd CMD]
                  [-d]

The `-t TIMEOUT` option is the number of seconds to collect activity, and `--cmd CMD` is the command line to execute in quotes. Together they are what turns Noriben into an automated sandbox run: the script launches the sample, records for the given time, and stops.

The `-c CSV` and `-p PML` options are the ones that make it a tool rather than a script. They re-analyse an existing Noriben CSV file or an existing PML file. So you can capture once with Procmon and then re-run the analysis with different filters, different whitelists, or with YARA rules added, without re-running the sample. For an analyst this is the feature that turns a one-off script into a workflow, because the sample may be destructive or time-limited and you only get one chance to run it.

`--hash HASH` specifies a hash whitelist file, with `--hashtype` choosing between MD5, SHA1, and SHA256. `--headless` means do not open the results on the VM after processing, which matters when the script is running unattended on a machine with no interactive session, and `--process_tree` adds an ASCII process tree after created processes, which is one of the most useful views for spotting a process that drops a child.

`--output OUTPUT` is the folder to store output files, `--yara YARA` is a folder containing YARA rules, `--generalize` generalizes file paths to their environment variables and defaults to True, and `-d` enables debugging.

The version banner in the usage block says Noriben v1.7.2 while the release tag is 2.0, which tells you the banner string was not updated along with the release numbering.

The features that turn raw events into indicators

Three features do the work of converting a capture into something actionable.

The first is YARA scanning. If you have a folder of YARA signature files, you can specify it with the `--yara` option, and every new file created will be scanned against these signatures with the results displayed in the output results. This is the highest-value integration in the tool, because a YARA rule encodes a family or a technique and the scan turns an analyst's prior knowledge into an automatic check on every artefact the sample drops.

The second is VirusTotal submission. If you have a VirusTotal API key, you place it into a file named `virustotal.api`, or embed it directly in the script, to auto-submit MD5 file hashes to VirusTotal to get the number of viral results. So every file the sample writes is looked up, and the report tells you how many engines have seen it.

The third is the hash ignore list. You can add lists of MD5s to auto-ignore, such as all of your system files, using md5deep and throwing them into a text file, and you read it with `--hash <file>`. The summary is careful that this will ultimately go under changes, though, which is a slightly confusing phrasing, and what it means is that these hashes are not simply dropped from the report but classified differently, which is how you tell a known-good artefact apart from something the sample just wrote.

The fourth is `--generalize`, which automatically substitutes absolute paths with Windows environment paths for better IOC development. The example is that `C:\Users\malware_user\AppData\Roaming\malware.exe` will be automatically resolved to `%AppData%\malware.exe`. That is a small feature with a large effect on the usefulness of the output, because an indicator with a hardcoded user path is an indicator that only matches one machine. The option is on by default, and the help text confirms it, with the default True.

The automation script and the integration test harness

There are two auxiliary tools in the repository, and they solve different problems.

The first is the operator frontend, NoribenSandbox.py. The project summary describes it as a much desired frontend operator, and it automates the execution of Noriben within a guest VM and retrieves the reports. It currently runs on OSX but will be ported, and it is responsible for spinning up a predefined VM and snapshot, copying the malware to the VM, starting Noriben and the malware, waiting a predetermined period of time, copying the results to the host as a ZIP, and taking a screen capture of the VM.

The `--update` option is the detail worth noting. You can use it to automatically copy the newest Noriben from your host, so that you do not have to continually make new snapshots when you make a change to the script. That is the difference between a workflow you can iterate on and one that requires a snapshot rebuild per change, and it is the kind of small convenience that tells you someone actually uses this.

The repository also ships a Windows batch version, `NoribenSandbox.bat` alongside the Python one, and a `postexec.txt` file that is presumably read after the run.

The second tool is the integration test, unit_tester.ps1, and the way it is documented is a good indicator of how the project expects to be used. It is run from the Noriben directory in a Windows VM with Procmon module loads enabled, with a PowerShell command that bypasses the execution policy and runs non-interactively with no profile.

Running the test suite requires a full Procmon capture of a live Windows VM. That tells you something about the nature of the project. There is no unit test suite in the usual sense, because the thing being tested is a script's interaction with a real system recorder, and the only faithful test is to record a real capture and check the output. The trade-off is that the project has a test at all, which many comparable scripts do not.

The `Sample/` directory at the root contains a set of example outputs, a CSV, a PML, and a text report from a run in April 2013, which is both a fixture and a piece of history about the tool's age.

Where Noriben is the wrong tool

The limits are real, and most of them follow from the choice to observe rather than emulate.

First, Noriben does not sandbox anything. It runs the sample on your machine, with Procmon recording, and the recording stops when the timeout expires or you stop it. There is no rollback, no snapshot restoration, and no isolation. The automation script exists precisely because you should be doing this inside a disposable guest VM, and if you run Noriben directly on a machine with anything you care about, you are running unknown code with your privileges. The tool assumes the surrounding discipline and does not enforce it.

Second, it is a script and not a pipeline. There is one sample at a time, the reports are text files in an output folder, and the automation script is a single VM and a single snapshot. If you need a queue of samples, a database of results, deduplication across campaigns, or dashboards, that is a full sandbox product and Noriben is not it. The one-at-a-time design is also what makes the sample preservation problem real, since a run may be the only chance you get with a destructive sample.

Third, the output is filtered, and filtering is where a false negative lives. The white lists exist to reduce noise from system activity, and they are a list of assumptions about what normal looks like on the analyst's machine. A sample that writes to a path on the white list, or that renames a known system binary rather than creating a new file, can slip past. The `--hash` ignore list has the same property. A report that reads clean is evidence of what was not suppressed, and the white lists are maintained by the project rather than by you, unless you go and edit them.

Fourth, the dependency is Windows and Procmon. The automation script currently runs on OSX and the summary says it will be ported, which is an unusual arrangement since a host script that drives a Windows guest needs some way to reach it. Procmon itself is a Windows tool, so the analysis side is firmly Windows-only.

Fifth, the licence situation needs reading. The repository listing records the licence as a custom one that GitHub cannot classify, with the terms in a LICENSE file, while the project summary states Apache License, Version 2.0 and prints the Apache 2.0 text. The two are probably the same thing, and the LICENSE file is the authoritative version, but a discrepancy in a file listing is worth a glance before you redistribute the script.

Sixth, and this is the maintenance one, the release numbering has drifted. The only release tag is 2.0 from 2023, the usage banner still says v1.7.2, and the last push was in September 2026. The code is being worked on, but there is no tagged version to pin and no changelog to read, which for a security tool is worth knowing before you build it into a process.

Editorial conclusion

Noriben fits a malware analyst who wants the system-wide view that Procmon gives but the readable output that a sandbox dashboard does not, and who wants to drive the sample by hand instead of handing it to an emulator. It is the wrong tool for a team that needs automated submission and multi-sample queues, since that is a full sandbox product rather than a script. Check three things before you use it: that the licence recorded in the repository listing matches the Apache 2.0 text in the project summary, since the two disagree, that you are on a machine where running the sample is safe, since the tool runs it in the foreground on your own desktop, and that you read the whitelist behaviour, because the filtering that makes the output readable is also what determines what you do not see.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. Rurik/Noriben on GitHub