PE (Portable Executable) information gives more insight about the files themselves, such as who the file is signed by, the associated DLLs (Dynamically Linked Libraries) that get downloaded, etc. These details all help to develop better context around the file.
A few weeks back, we released more metadata in our scan results, starting with portable executable information. Moreover, we empowered our developers to gain access to this new data through our hash lookup API.
Now that this additional information is available on Metascan® Online, I wanted to go over and describe the meaning of the information at a high-level. I will be using two examples, both mentioned in our release: a legitimate clean file created by Microsoft, and an infected file that is detected by over 15 anti-malware engines.
Clean File:7F7BC59F453539194C2D38FD68FB2B4BEB3C1B5B5273CEC1B7DD1150B0EA929D (aka 7F7BC)
Infected File:FD5A450092F9310EF0F8CCB2EB5F2CAE5BCE7ABBC0018C2BA998F9C2F7027C6D (aka FD5A4)
Now let's take a look at each group in more detail.
AUTHENTICODE SIGNATURE BLOCK
AUTHENTICODE SIGNATURE BLOCK contains digital signature information for a file. Signature information is similar to the way we sign things in real-life: a way to validate who we are. This is especially important when it comes to identifying forgery and tampering. In our examples, Microsoft was the signee for the clean file, 7F7BC. By using this information, anyone who wants to run this file will know that Microsoft, a reputable software company, were the ones to originally create the file. To no surprise, the infected file FD5A4 has no signature available for validation, as an anonymous malware writer would most likely prefer not to share signature information. Unfortunately, just as there are ways to counterfeit a signature in real-life, there is also a way to fake digital signatures. I will be expanding on this topic in a future blog post that will talk about counterfeiting digital signatures.
AUTHENTICODE SIGNATURE BLOCK info for clean file results
PE HEADER BASIC INFORMATION
PE HEADER BASIC INFORMATION contains metadata specific to the portable executable. Think of this metadata as metadata of the PE. This shows the number of sections in the file, the operating system the file is intended for and when the file was compiled. In our examples, both files were intended to run on the x86 architecture. By looking at the compile time for each file, you will notice something that seems a little suspicious. The file created by Microsoft, 7F7BC, was compiled in 1997, which makes sense given how long Microsoft has been around [1]. Conversely, the file that contained malware, FD5A4, was compiled just a few months ago. This particular file contains the Bladabindi malware, with detection records dating back to 2012. One could speculate that this is a variant from the original one, was included in this exe, and is currently in circulation around the web.
PE HEADER BASIC INFO for clean file (left) and infected file (right)
PE SECTIONS
PE SECTIONS describe what sections exist within the file and where they are located. Any important code or data used by the PE is kept within a designated section. Between files 7F7BC and FD5A4, there is nothing in particular that stands out. Here are some common sections [1].
- .text — code where the loader begins. Think of this as the starting point for execution.
- .data — where initialized data goes (e.g. global and static variables)
- .bss — for uninitialized data
- .rdata — holds debug related information
- .idata — hash information about functions (and data) that module imports from other DLLs. Another name for this section is import table.
- .rsrc — contains resources for the PE
- .reloc — a limited use section. This stands for base relocation, which is an adjustment to an instruction or uninitialized variable. Otherwise, the information isn't needed and is ignored.
PE SECTIONS information for clean file
PE SECTIONS information for infected file
PE IMPORTS
This is split into two parts
- Imphash
- Import information
When a PE is run, there are often DLLs loaded into the system. DLLs are shared libraries, which when executed carry out further instructions. Since DLLs can potentially contain malware, PE IMPORTS looks at which DLLs are loaded and what function calls are run by the DLL. The order in which the DLLs are loaded and run make up an import address table, which is uniquely identified by the imphash [1].
PE IMPORTS information for clean file
PE IMPORTS information for infected file
NUMBER OF PE RESOURCES BY TYPE
Every PE can contain resources, and those details are displayed in the NUMBER OF PE RESOURCES BY TYPE. These are elements that are typically familiar in the user interface [2][3].
- RT_BITMAP — bitmap resource
- RT_ICON — icon resource
- RT_DIALOG — dialog box
- RT_GROUP_ICON — icon resource
- RT_VERSION — version information
- RT_MANIFEST — side-by-side assembly manifest
- RT_RCDATA — raw data
- RT_STRING — string details
- AVI — avi video
NUMBER OF PE RESOURCES BY TYPE for clean file
NUMBER OF RESOURCES BY TYPE for infected file
NUMBER OF PE RESOURCES BY LANGUAGE
Based on the resources above, this metric contains the languages supplied for each resource. Multi-language PEs will contain more language support. Otherwise, there will be a single language listed.
NUMBER OF PE RESOURCES BY LANGUAGE for clean file
NUMBER OF PE RESOURCES BY LANGUAGE for infected file
EXIFTOOL FILE METADATA
Exchangeable image file format (or Exif) is a standard for formats for certain files such as images, sounds, etc. However, this standard can also be applied to executables and DLLs. This is just another approach to obtaining metadata about the executable. For example, checksums are often used to verify data integrity. Between the two example files, the clean file has a checksum of 1088635 and the dirty file has a checksum of 0. A file with a checksum of 0 would be considered suspicious [4].
EXIFTOOL FILE METADATA for clean file (left) and infected file (right)
That's about it for now. As we roll out more metadata for scan results, we'll have more "in-depth" articles on them.
Happy multi-scanning!
References:
1. https://msdn.microsoft.com/en-us/library/ms809762.aspx
2. https://msdn.microsoft.com/en-us/library/ms648009(v=vs.85).aspx
3. https://msdn.microsoft.com/en-us/library/windows/desktop/ms648007%28v=vs.85%29.aspx
4. http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/EXE.html
