Original Post from FireEye
Author: Nick Harbour
If you deal with the same threats that Mandiant does, you may have
noticed a lot of malware lately named “fxsst.dll“. If you’re
wondering why this is happening, this article is for you.
When I spend time working solely on reverse engineering malware,
I don’t often get the whole story with a malware sample. I wasn’t
curious about the name
fxsst.dll until we had a plump stack of malware samples in
our library that all had this name and were completely unrelated to
each other. A quick check with our incident responders confirmed
that in my latest specimen the malware was operational and the
persistence mechanism was not immediately apparent. It gave me a
flashback of ntshrui.dll from last year
and I decided to investigate the issue.
If you try a quick
Google search, you will find that
fxsst.dll is a legitimate system DLL, specifically the fax
server. The DLL is found on most systems that were installed with
default settings, though it is an optional feature during the
operating system installation process. It resides in the System32 folder, and a search
for the DLL on a live system with Process Explorer shows that it is
loaded inside the Explorer.exe process. At this
point it sounds very similar to the ntshrui.dll problem, but we’ll
I found that my malware analysis VM did not
contain fxsst.dll so I
placed a malware DLL of this name in the System32 folder and rebooted.
The malware was loaded by Explorer.exe upon reboot. Unlike
there is no mention of fxsst.dll anywhere in the
Registry. A string search through Explorer.exe reveals that it is
also not loaded directly by the program through its import table or
dynamically with LoadLibrary(). A complete search
for fxsst.dll through all
files revealed it to be referenced by the file stobject.dll in the System32 folder.
Stobject.dll is the System
Tray component of the Windows Shell (the tray at the bottom right of
your screen). It is loaded by Explorer.exe as an In-Process
Server (InprocServer in Windows lingo) and utilized through a COM
interface. It is referenced in the Registry as shown below.
With the mystery
of stobject.dll solved, we
can focus on how it loads fxsst.dll. We also need to
figure out what a piece of malware must do to successfully replace
the legitimate DLL and still ensure a stable system. The following
is the decompiled fragment of stobject.dll which shows the
loading of fxsst.dll.
According to this
fragment of code if the
fxsst.dll file is found it will be loaded and the two
will be resolved and stored in a pair of global function pointers.
If the DLL is not found, or if the functions were not found within
the DLL, then the global function pointers will be NULL. Let us now
examine how these function pointers are used to see if a NULL
pointer will adversely affect the program.
The IsFaxMessage() function is used
only once, and in the fragment above you can see that the program
checks to see if it is NULL before calling the function. If the
pointer is NULL, then the program just skips this piece of
functionality. The same is the case for FaxMonitorShutdown(). Why does
this matter? If a malware replaces fxsst.dll and is loaded by
Explorer through stobject.dll, then it doesn’t
need to implement the fax server function calls. The only
repercussion is that the system can no longer act as a fax server,
but that is a feature I don’t think anyone would notice was missing.
The malware authors obviously arrived at the same conclusion.
Since fxsst.dll resides
in the System32 folder, is
not protected by KnownDlls and is loaded by the Explorer.exe process, it is
vulnerable to the same DLL load order hijack as ntshrui.dll. By that I mean you
can place a malicious DLL in the C:WINDOWS folder and it will
load instead of the legitimate copy in System32. You can also just
overwrite the copy in System32 and the user of the
system will not notice. Unlike with ntshrui.dll, the malware
doesn’t really need to take the extra step of loading the legitimate
copy to restore its important functionality. In this case, the
original functionality is useless to all but the last few people in
the world who still use their Windows computer to receive faxes.
Conclusion (and TL;DR version):
You can take
pretty much any malware DLL, name it fxsst.dll and drop it in C:WINDOWS or the System32 folder and Explorer.exe will load it at
boot time. No hassle, no fuss. There are bound to be more
problematic DLL locations like this, but I’ll keep spreading the
word as we find them.
Go to Source
Author: Nick Harbour