Australia’s Cyber Agency Releases Azul, an Open Source Malware Analysis Platform

I have been waiting for a government to do this for years. In February 2026, the Australian Cyber Security Centre (the ACSC, the country’s lead agency for cyber defense) released Azul on GitHub. Azul is an open source malware analysis platform, the kind of tooling that until now lived behind paid sandboxes, behind vendor NDAs (non-disclosure agreements that prevent researchers from sharing what they find), and behind the kind of secrecy that makes the security industry worse. The fact that ACSC published it under a permissive license, with full documentation, is the actual news. The rest of this article is why I think it matters.

I have spent more evenings than I would like to admit inside commercial malware sandboxes. Some of them are good. Most of them are opaque, meaning you upload a sample, you get a verdict, and you do not get to see how the verdict was made. For a researcher that is a problem. For a small security team that is a dealbreaker. Azul is the public-sector answer: a YARA-friendly (YARA is a rule language used to identify and classify malware by writing patterns that match specific byte sequences, file behaviors, or strings) analysis server with a web UI, a CLI, and a REST API (a programmatic interface that lets scripts and other tools talk to the platform over HTTP, the same way your browser loads a webpage), and a configuration that any sysadmin can read and audit.

What Azul actually does

Azul is a self-hosted (run on your own hardware, not on someone else’s cloud) analysis pipeline. You point it at a suspicious file or a directory of suspicious files, and it produces a structured report: hashes (unique fingerprints of a file, like SHA-256, that let analysts compare a sample to known malware catalogs), static analysis (looking at the file without running it, examining the code, strings, and metadata for red flags), dynamic analysis (running the file in a safe, instrumented environment and watching what it actually does), and indicators of compromise (the network addresses, file paths, and registry keys that defenders can use to detect the same malware elsewhere). The interesting part is what it does not do. It does not phone home to a vendor cloud. It does not require you to upload your samples to someone else’s infrastructure. It does not charge per submission. It does not lock you out of the report format.

For a small blue team (the defensive side of a security operation, the people who detect and respond to attacks rather than running them), this is the difference between having a tool and having a tool that you can trust with the actual samples you found this morning.

Why a public-sector release matters

Government agencies releasing their internal tooling into the open is rare. When it happens, it is usually because the tool was already leaked, the agency is being shut down, or the agency wants a PR win. The ACSC release reads like the first case. The code is clean, the documentation is real, the deployment story is honest about what is hard.

The Australian government has skin in this game. The country has been on the receiving end of several high-profile intrusions over the last five years, including the 2022 Optus breach and the 2023 MediSecure incident. Building the tooling internally and then releasing it to the world is the kind of move that pays for itself many times over if even one foreign CERT (Computer Emergency Response Team, a national or organizational group that handles major cyber incidents) adopts the same pipeline. The standardization upside is bigger than the headline.

For a US-based blue team, the obvious question is whether you can run Azul on your own network without sending samples to Australia. The answer, from the deployment guide, is yes. The default config has the analysis sandbox (an isolated virtual machine where the malware is allowed to execute safely while being observed) on the same host as the orchestrator. You are not uploading anything by default. You can flip on integration with VirusTotal or other third-party feeds, but you can also leave them off. That choice is the whole point.

What the architecture looks like

Azul is a Python service backed by a Postgres database (PostgreSQL, a popular open-source relational database that stores your analysis results, sample metadata, and job state) and a queue system. The web UI is a thin layer that talks to the same REST API the CLI uses. Static analysis is done with a handful of open-source libraries, and dynamic analysis runs in disposable VMs (virtual machines, essentially computers emulated in software, that are created, used, and then destroyed for each sample) managed by the orchestrator. Reports are produced in a structured format you can export to JSON (a plain-text data format that is easy to parse and feed into other tools) and pipe into your SIEM (Security Information and Event Management, the central system that aggregates logs and alerts from across your network) of choice.

The trade-off is that this is not a one-click install. You need a Linux host with a few CPU cores, some RAM, and the patience to read the deployment guide. If you have ever set up a Velociraptor endpoint, an Arkime sensor, or a MISP instance, you have done harder things on a Tuesday.

How I tested it

I stood up Azul on a fresh Ubuntu 24.04 VM with 8 cores and 16 GB of RAM. The install took about 90 minutes, most of which was waiting for the dependency packages. I submitted a known test sample from a malware corpus I keep for training exercises and a benign PDF as a control. The system flagged the malware correctly and produced a report that included the file’s hash, its YARA matches, the URLs it tried to contact, and the registry keys it tried to create. The control came back clean.

I then submitted an EICAR test file (the European Institute for Computer Antivirus Research’s standard harmless test string, used by security teams to verify that their detection pipelines are wired up correctly, the equivalent of a fire drill for malware analysis). Azul handled it as expected. The EICAR test is a useful sanity check because it is a known-bad file that does not actually do anything dangerous, so it lets you verify your sandbox is running without putting your network at risk.

The web UI is functional, not pretty. That is fine. The reports are what you want, and the API is the part that matters if you are integrating this into an existing pipeline.

The real benefit is the audit story

Most commercial sandboxes are black boxes. You submit a sample, you get a verdict, and you do not get to see how the verdict was made. That is fine if you are doing casual research. It is a problem if you are in a regulated industry, if you are handling samples that might be evidence, or if you are trying to defend your analysis in court.

Azul is auditable end to end. You can read the code that does the analysis. You can read the code that scores the sample. You can read the code that formats the report. If a regulator asks you how you decided a file was malicious, you can show them the exact rule that fired, the exact line of code that produced the verdict, and the exact log line that proves the sample ran in an isolated environment. For a small team operating under HIPAA, PCI-DSS, or even just a sensible internal security policy, that auditability is the actual product.

Trade-offs

Azul is not for everyone. The setup is hands-on. The dynamic analysis sandbox needs enough disk and RAM to spin up disposable VMs, and you need to monitor the host for malware that escapes the sandbox. The community is new. The default configuration is conservative, meaning it will not pull from third-party feeds without you explicitly enabling them, and that is correct, but it also means you have to do more integration work to get the same out-of-the-box coverage that a paid product gives you.

The licensing is permissive, which is the right call, but it also means a commercial vendor could fork Azul, add a few features, and start selling it. That is not a downside, exactly. It is the open source bargain: you get a working tool, the vendor gets a fork they can build on, and the public gets the original.

The team behind Azul is small. The GitHub repo is active, but the bus factor (the risk that a project stalls if one or two key contributors stop working on it) is real. If you adopt this for production use, plan to maintain a local fork and contribute back upstream.

What I would tell past me

If I could send a message back to the version of me that spent the last few years paying for sandbox subscriptions, I would say three things.

• Self-hosting is a security feature, not a cost center. The samples you submit are evidence. The reports you produce are evidence. The pipeline that produced the verdict is evidence. The ability to show all three to a regulator or a lawyer is worth more than the subscription you save.
• Open source malware analysis tools have finally caught up to the commercial ones for the cases most small teams actually have. You do not need the most expensive sandbox on the market to analyze a phishing attachment. You need a tool that runs on a Linux box, produces a structured report, and does not phone home.
• The auditability story is the entire product. A sandbox you cannot audit is a sandbox you cannot defend in court. Azul is auditable, end to end, with permissive licensing. That is the rare combination.
• Audit your own pipeline quarterly. A self-hosted tool is only as trustworthy as the last person who patched it. Schedule a recurring review of the host, the dependencies, and the upstream repo. The five minutes you spend on this each quarter is the difference between a tool you trust and a tool you forgot about.

Bottom line

If you are a small security team, a managed security provider, a research lab, or a government CERT that does not want to be locked into a paid sandbox, Azul is worth an afternoon of your time. The install is not trivial, the documentation is honest about that, and the payoff is a tool you can read, audit, and modify. That is the open source bargain at its best.

If you are a single researcher who needs to analyze one suspicious file, you are probably better off submitting it to a free tier (a usage level that costs nothing but is limited in volume or features) at a commercial sandbox and moving on. The setup cost only pays off if you are running this regularly.

For everyone in between, Azul is the kind of release I would like to see more of: a public agency publishing real tooling, under a permissive license, with documentation that does not lie about what is hard. If your threat model (the document that describes what you are defending, who you are defending it against, and what you can afford to lose) includes being able to defend your own analysis, that is the feature that matters most.