This YARA rule targets specific tooling artifacts associated with the Armadillo v410 variant, potentially indicating the presence of custom or obfuscated malware components within memory or on disk. Proactively hunting for these signatures allows the SOC team to identify low-severity, stealthy implantations that may serve as initial footholds or lateral movement tools before they escalate to higher-impact activities.
rule Armadillov410SiliconRealmsToolworks
{
meta:
author="malware-lu"
strings:
$a0 = { 55 8B EC 6A FF 68 F8 8E 4C 00 68 D0 EA 49 00 64 A1 00 00 00 00 50 64 89 25 00 00 00 00 83 EC 58 53 56 57 89 65 E8 FF 15 88 31 4C 00 33 D2 8A D4 89 15 7C A5 4C 00 8B C8 81 E1 FF 00 00 00 89 0D 78 A5 4C 00 C1 E1 08 03 CA 89 0D 74 A5 4C 00 C1 E8 10 A3 70 A5 }
condition:
$a0 at pe.entry_point
}
This YARA rule can be deployed in the following contexts:
This rule contains 1 string patterns in its detection logic.
armadillo CLI tool (a hypothetical or internal wrapper for ARM-based silicon profiling) on a Linux build agent to generate performance metrics for new silicon realms. The tool writes temporary binary artifacts to /tmp or the user’s home directory, which match the byte patterns defined in the YARA rule.
/tmp/, /var/tmp/, or /home/<user>/.cache/armadillo/ if the parent process is armadillo-cli or python3 executing armadillo.py.toolworks (an internal build orchestration tool) to compile firmware for ARM64 targets. The resulting .elf or .bin output file is scanned by the EDR agent before being moved to the artifact repository, triggering the detection due to specific header signatures or embedded strings.
.bin, .elf, or .fw if the creating process is toolworks-agent or make and the file path contains /builds/ or /artifacts/./opt/yara-tests/) where they are scanned, causing the rule to match its own test fixtures.
/opt/yara-tests/ or /var/lib/edr-test-samples/ regardless of the parent process.dd or cp to copy a pre-compiled ARM64 library (libsilicon.so)