Pretty much all of the phantom DLL scenarios that I have been describing over the years are linked to specific use cases, where the code referencing these non-existing DLLs is most of the time immediately accessible from a native OS program. And as such, the technique can be leveraged immediately. In other words, anyone with some basic know-how about phantom DLLs can control the process of loading payloads leveraging this trick at any time.
The complexity of Windows OS cannot be understated.
Despite many efforts, hours spent reversing, I often come across situations where I simply don’t understand the code, the logic, or the conditions to load certain phantom DLLs are so convoluted, that it is simply not worth inspecting any further….
This is where this post begins.
There are still many phantom DLLs that I have not described yet, but the chances that I ever will are not very high. This is because most of the ‘obvious’ phantom DLLs are already pretty well-described, and the effort that one has to make to describe the ones that are left is ‘uuuuge. But… there is an easier way.
Instead of chasing unicorns, we can just list the possible scenarios w/o going into details on how they are invoked. From a defender’s perspective it is still a win, because we can simply focus on detection of phantom DLL files being created, without a need to understand how they will be loaded by threat actors.
Okay…
That’s a lot of words to describe never-seen-before IOCs.
So, here they are.
When the files are created that match the file names in the column 2, it is worth investigating further…
