Skip to main content
Malicious code detection identifies malware, implants, and supply-chain compromises embedded in a scanned image, distinct from vulnerability detection. Where vulnerability detection looks for security issues that could be exploited, malicious code detection looks for evidence that a component has already been tampered with or replaced.

​
What’s detected

Malicious code detection produces the malware/* and suspicious/* finding classes documented in Finding Classes Reference, covering known malware threats, confirmed malicious or suspicious behavior, and UEFI bootkit-style hook installations, alongside signals like executable data segments or missing standard library usage that can indicate tampering. The same engines also produce the supply-chain/* finding class: confirmed supply chain compromises such as a backdoored dependency, a tampered upstream release, or a leaked signing key, matched by signature the same way a malware family is.

​
Rule-based detection

Detection is signature and pattern-based rather than version-based: rules match code and data byte sequences, strings, or firmware-specific characteristics directly against the binary.

​
YaraHunt

YaraHunt is Binarly’s engine based on modern YARA-X, a pattern-matching language for hunting known malware families, implants, and supply-chain compromises by signature. YARA-X rules can target any binary: executables, firmware images, libraries, or raw file blobs. A default set of YaraHunt rules ships with the Binarly Transparency Platform. It covers known malware, including backdoors, implants, UEFI bootkits, kernel and userland rootkits, and ransomware, as well as malicious artifacts used by Advanced Persistent Threat (APT) actors and supply-chain compromises. The rules come from Binarly’s internal research and from curated third-party sources, which are validated, benchmarked, and improved where needed to meet Binarly’s quality standards. A small number of shipped rules also match vulnerabilities rather than malicious code, and those produce vulnerability findings.

​
FwHunt

FwHunt is Binarly’s YAML-based rule format for UEFI firmware threat hunting. Because it understands UEFI module structure natively, a FwHunt rule can scope to a specific module by GUID and match known-bad implant patterns within it. Most of the shipped FwHunt rules target vulnerabilities rather than malicious code, covered in Vulnerability Detection; implant detection is the smaller share of the set.

​
Custom Rules

In addition to the default set of rules, customers can also write, test, and deploy their own rules of either type through the Custom Rule Manager.

​
Semantic and behavioral detection

Beyond signature matching, malicious code detection also uses semantic and behavioral analysis that doesn’t depend on a predefined rule:
  • UEFI firmware modules are analyzed semantically to identify bootkit and implant behavior directly in the code, independent of a specific YARA or FwHunt signature. See malware and suspicious UEFI findings.
  • ELF binaries are checked for anomalies, such as packing or code injected during or after the build. See suspicious POSIX findings.
This analysis runs on Binarly’s built-in engines and, unlike YARA and FwHunt rules, isn’t configurable through the Custom Rule Manager.

​
Capability analysis of embedded executables

A malicious UEFI module may contain a Windows executable payload. The platform searches every UEFI module for embedded Portable Executable (PE) files, extracts them and lists them as embedded executable. Each extracted executable is evaluated against a set of capability rules. These rules detect potentially malicious behavior, such as communicating with a command-and-control server, injecting code into other processes, encrypting files, evading analysis tools, and establishing persistence across system reboots. The rule set is based on the open-source capa rules and is applied with Binarly’s capability detection engine. The findings list each matched capability and map it to MITRE ATT&CK techniques.