{"id":9314,"date":"2024-08-01T22:29:34","date_gmt":"2024-08-01T22:29:34","guid":{"rendered":"https:\/\/www.hexacorn.com\/blog\/?p=9314"},"modified":"2024-08-01T22:29:34","modified_gmt":"2024-08-01T22:29:34","slug":"high-fidelity-detections-are-low-fidelity-detections-until-proven-otherwise-part-2","status":"publish","type":"post","link":"https:\/\/www.hexacorn.com\/blog\/2024\/08\/01\/high-fidelity-detections-are-low-fidelity-detections-until-proven-otherwise-part-2\/","title":{"rendered":"High Fidelity detections are Low Fidelity detections, until proven otherwise, Part 2"},"content":{"rendered":"\n

In my last post<\/a> I looked at ‘good’ file names. Today I will look at them again. <\/p>\n\n\n\n

Sort of…<\/p>\n\n\n\n

Over the years I have written a number of yara rules that use a peculiar condition that hits on an internal PE file name sometimes being preserved inside some of the PE files, both DLL and EXE… If you ever looked at an internal structure of a PE file you know that its export directory has a capability to preserve a programmer-chosen, internal file name that is compiled into the final binary file, and that internal file name often differs from the file name being used on a file system level… <\/p>\n\n\n\n

Some Threat actors know about it and abuse it, but many don’t – in some cases allowing us to write very precise detection rules… That internal file name is a great forensic and telemetry artifact and it would be a crime not to use it, where applicable…<\/p>\n\n\n\n

In my old Yara rules I would usually rely on this (somehow) esoteric syntax that I copied and pasted from someone else (sorry, don’t remember who that person was):<\/p>\n\n\n\n

strings:\n   $dllname = \"<filename>\"\ncondition:\n   ($dllname at pe.rva_to_offset(uint32(pe.rva_to_offset(pe.data_directories [pe.IMAGE_DIRECTORY_ENTRY_EXPORT].virtual_address)+12)))<\/pre>\n\n\n\n
which is basically a rudimentary PE file format parsing condition checking if the specific ANSI string is present at a given place inside the file’s export directory (where that internal PE file name resides) and if it matches the string I defined…<\/p>\n\n\n\n
After the release of yara 4.0.0 we can use a far more simpler construct to define the very same condition – one that leverages the PE module:<\/p>\n\n\n\n
pe.dll_name==\"<filename>\"<\/pre>\n\n\n\n
Now… <\/p>\n\n\n\n
This internal file name preserved in the export directory of many PE files is a bit of a phenomenon because if we just focus on native Windows OS binaries we will discover a lot of interesting bits. Say, we look at the native PE files taken from the Windows 11 system32 directory — we can easily discover a number of PE files where the ‘external’ (file system-based) and ‘internal’ (PE export directory-based\/pe.dll_name) file names do not match…<\/p>\n\n\n\n
Here’s a quick & dirty list<\/a> of such files that I’ve extracted…<\/p>\n\n\n\n
And just for a second, let me digress here – I must mention that I generated this quick&dirty file for the purpose of writing this post but then… just eyeballing its content… my attention was immediately drawn to this interesting finding…:<\/p>\n\n\n\n