freki is a free, self-hosted malware analysis platform exposing static PE triage, YARA matching, and VirusTotal enrichment through a web UI and REST API for authorized researchers.
| Tool | cristianzsh/freki — open-source malware analysis platform with web UI and REST API |
| Category | Malware analysis / static triage platform |
| Primary Use | Automated static analysis of PE samples: hashes, headers, sections, imports, capabilities, strings, and YARA pattern matching, with VirusTotal lookups |
| Safe Use | Intended for malware researchers, SOC analysts, and defenders analyzing samples in isolated lab environments during authorized security work |
| Telemetry Note | As a defensive analysis tool, freki itself generates outbound VirusTotal API queries; defenders should note sample-submission telemetry and ensure the platform runs only on isolated analysis networks |
freki positions itself as a free and open-source malware analysis platform, and the project's stated goals are refreshingly concrete: facilitate malware analysis and reverse engineering, provide an easy-to-use REST API that other projects can build on, keep deployment simple through Docker, and leave the door open for community-driven feature additions. That framing matters, because it tells you the author — Cristian Souza, with co-author Felipe Silva — designed this as infrastructure rather than a one-shot script. The repository carries roughly 446 stars, is tagged AGPL-3.0, and lists YARA as its primary language, which is a strong signal about where the technical heart of the platform lives.
The feature set, as documented in the README, clusters around static triage. freki performs hash extraction on submitted samples, queries the VirusTotal API for third-party verdicts, and runs static analysis of PE files covering headers, sections, imports, capabilities, and strings. On top of that, it applies pattern matching with YARA, which is where the YARA primary-language classification becomes tangible: rules authored or imported into the platform are matched against samples to flag known families or behaviors. It is not a dynamic sandbox — there is no detonation or behavioral tracing in the documented feature list — so think of it as the front half of an analysis pipeline.
Architecturally, the topics and README point to a classic three-tier design. The web tier is built on Flask (the flask topic and the python3 badge make this explicit), the whole stack ships as Docker images orchestrated with docker-compose, and an nginx configuration file at nginx/freki.conf fronts the deployment. The README's run instructions are telling: edit the .env file for configuration, and if you are going to use freki in production, edit freki.conf to enable HTTPS. That parenthetical about TLS at the reverse proxy is a small but meaningful operational detail — the authors clearly expect internet-reachable deployments, likely because the platform supports multiple users.
Two features elevate freki beyond a bare analysis script: user management and community comments. User management implies authentication and per-user sample visibility, which is what you want before exposing an analysis platform to a team. Community comments let analysts annotate samples collaboratively, effectively building an institutional knowledge base around previously triaged binaries. Combined with the REST API, this suggests the intended workflow is a shared analyst workbench: submit a suspicious binary, get hashes and PE statics back, see YARA hits, check VirusTotal, and read what colleagues have already concluded about the file.
The download-samples capability deserves a note from a handling perspective. A platform that both analyzes and serves stored samples is, functionally, a malware repository — extremely useful for research and retrospective investigation, but it means access control on the deployment is not optional. In an authorized lab context you would run freki on an isolated network segment, keep the nginx TLS configuration enabled as the README advises, and restrict who can authenticate. The AGPL license also means that if you expose a modified instance as a network service, you are obligated to make source available — a consideration for commercial deployments.
The academic pedigree is unusually solid for a tool of this size. freki was presented at the XXI Brazilian Symposium on Information and Computational Systems Security (SBSeg 2021), with a published paper titled 'Freki: Uma Ferramenta para Análise Automatizada de Malware' and a DOI (10.5753/sbseg_estendido.2021.17340). Peer-reviewed provenance does not guarantee code quality, but it does mean the design rationale was written down and reviewed, which is more documentation than most GitHub analysis tools can claim. The README also links hosted documentation at cristianzsh.github.io/freki and a video demo for those who want to see the interface before deploying.
Deployment is deliberately boring, in the best way. You install Docker and Docker Compose, adjust .env, and run docker-compose up or simply make. The presence of a Makefile wrapper indicates some developer convenience tooling beyond the container stack. For local development without containers, the README defers to the online documentation rather than inline instructions — a reasonable choice that keeps the README focused on the recommended path.
The topic tags sketch the intended audience and ecosystem precisely: malware-analysis, malware-research, reverse-engineering, static-analysis, threat-intelligence, binary-analysis, and a cluster of self-hosted / self-hosted-api / self-hosting tags. That self-hosting emphasis is the differentiator versus commercial services — you keep samples and verdict metadata inside your own infrastructure instead of shipping binaries to a third party, beyond the optional VirusTotal lookups, which themselves leak hashes (and depending on configuration, samples) to an external service. Analysts working sensitive incidents should factor that into their configuration choices.
The hacktoberfest topic signals an openness to outside contributions, reinforced by the README's explicit invitation to open issues for feature suggestions. For a platform whose goal list ends with 'allow the addition of new features by the community,' that is consistent branding, and the AGPL license aligns with it. Anyone extending freki — say, adding ELF static analysis or additional intelligence feeds — inherits a clean extension point in the REST API design.
For defenders and authorized security teams, where freki fits is the triage stage of malware handling: fast, repeatable static assessment of a suspicious PE before anything gets near a detonation environment. The combination of YARA rule matching with structured PE parsing (headers, sections, imports, capabilities, strings) mirrors what a junior analyst would otherwise do manually in a disassembler or with standalone utilities, but automated, recorded, and shareable via the web UI and API. From a blue-team telemetry perspective, the tool is entirely benign — the observable footprint is outbound VirusTotal API traffic and storage growth on the host — but the samples it manages are not, so isolation and access control remain the operator's responsibility.
In sum, freki is a credible, documented, academically grounded option for teams that want a self-hosted static analysis workbench without shipping samples to a SaaS provider. Its limits are equally clear: it is PE-focused and static-only in its documented feature set, so dynamic behavior, non-Windows formats, and detonation belong to other tools in the pipeline. As a Docker-deployable, Flask-backed, YARA-powered front end for collaborative malware triage, it earns its place on a shortlist for lab infrastructure.
cristianzsh/freki.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.