One Article Review
| Source |  FireEye |
|---|---|
| Identifiant | 4593806 |
| Date de publication | 2021-09-14 22:44:26 (vue: 2022-05-13 21:47:31) |
| Titre | ELFant in the Room – capa v3 |
| Texte | Since our initial public
release of capa, incident responders and reverse engineers have
used the tool to automatically identify capabilities in Windows
executables. With our newest code and ruleset updates, capa v3 also
identifies capabilities in Executable and Linkable Format (ELF) files,
such as those used on Linux and other Unix-like operating systems.
This blog post describes the extended analysis and other improvements.
You can download capa v3 standalone binaries from the project's release page and
checkout the source code on GitHub.
ELF File Format Support
capa finds capabilities in programs by parsing executable file
formats, disassembling code, and then recognizing features in
functions. In versions v1 and v2, capa only understood the PE file
format, so its analysis was restricted to Windows programs. Thanks to
our colleagues at Intezer, capa
now recognizes ELF files! This means you can use the tool to identify
behaviors in malware that targets Linux computers. Figure 1 shows a
rule that describes techniques to fetch the current user on Linux.
Figure 1: capa rule identifying
capabilities on Linux
We're excited Intezer leverages capa and thrilled they are sharing
their improvements with the community. In addition to the code
updates, Intezer proposed 36 capa rules to identify various
capabilities in ELF files, such as reconnaissance, persistence, and
host interaction techniques. Please read Intezer's
blog post for more details.
New Features capa Can Recognize
As we taught capa to recognize ELF files, we also wanted rule
authors to tune their rules to find behaviors specific to different
operating systems (OS), CPU architectures, and file formats. For
example, the APIs exposed by Windows are very different from those
found on Linux systems; therefore, rules should clearly designate
which pattern to use on Windows versus Linux.
Based on discussions and feedback collected from users and
contributors, we've extended capa's rule format to describe OSes, CPU
architectures, and file formats. The rule shown in Figure 2 uses os features to distinguish techniques used to get
networking interface information on Windows and Linux. Note that the
rule is explicit about which APIs are found on each OS, making it easy
for both humans and machines to interpret the matching logic.
Figure 2: capa rule using the os feature
to distinguish OS specific features
We've also added arch (such as arch: i386 for 32-bit Intel code) and format (such as format:
elf for ELF files) features to distinguish between CPU
architectures and file formats. To learn more about these and capa's
rule syntax see the rule
format documentation on GitHub.
Unfortunately, rules with these new features are not backwards
compatible with older versions of capa. Therefore, you should prefer
to upgrade your capa installation to take advantage of our enhanced rules.
Substring Features
To make many rules easier to read, we've added a convenience feature
named substring that acts |
| Envoyé | Oui |
| Condensat | about acts add added addition advantage all also analysis any apis arch arch: architectures are authors automatically available backslashes backwards based behaviors between binaries bit blog both bug can capa capabilities changelog character characters checkout clearly code collaboration colleagues collected community compatible components computers conclusion continued contributors convenience cpu current describe describes describing designate details different disassembling discussion discussions distinguish documentation download each easier easy elf elfant engineers enhanced escape even example excited executable executables explicit explorer exposed expressive extended feature features feedback fetch figure file files find finds fixes format format: formats forward found from functions future get github had have host how humans i386 idapython identifies identify identifying implied improvements incident includes incomprehensible information initial public installation intel interaction interface interpret intezer issue its leading learn leverages like linkable linux literal location logic longer love machines make makes making malware many match matching means more much named nearly networking new newest not notably note now old older only open operating opportunities oses other page parsing part path pattern persistence please plugin post prefer previously programs project proposed pypi questions read recognize recognizes recognizing reconnaissance release repository respective responders restricted reverse room rsa rule rules ruleset see sequences sharing should shown shows since slashes source special specific ssh/id standalone string style substring such support syntax systems systems; take targets taught techniques than thank thanks then therefore these those thrilled tool trailing tune understood unfortunately unix update updates upgrade use used user users uses using various versions versus very wanted ways which wildcards windows wrap your |
| Tags | Malware Tool Guideline |
| Stories | |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.