If you deal with the same threats that Mandiant does, you may have
noticed a lot of malware lately named " style="color: rgb(128,0,0);">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 target="_blank"> style="color: rgb(128,0,0);">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 style="color: rgb(128,0,0);">System32 folder, and a search
for the DLL on a live system with Process Explorer shows that it is
loaded inside the style="color: rgb(128,0,0);">Explorer.exe process. At this
point it sounds very similar to the style="color: rgb(128,0,0);">ntshrui.dll problem, but we'll
keep digging.
I found that my malware analysis VM did not
contain fxsst.dll so I
placed a malware DLL of this name in the style="color: rgb(128,0,0);">System32 folder and rebooted.
The malware was loaded by style="color: rgb(128,0,0);">Explorer.exe upon reboot. Unlike
ntshrui.dll though,
there is no mention of style="color: rgb(128,0,0);">fxsst.dll anywhere in the
Registry. A string search through style="color: rgb(128,0,0);">Explorer.exe reveals that it is
also not loaded directly by the program through its import table or
dynamically with style="color: rgb(0,0,255);">LoadLibrary(). A complete search
for fxsst.dll through all
files revealed it to be referenced by the file style="color: rgb(128,0,0);">stobject.dll in the style="color: rgb(128,0,0);">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 style="color: rgb(128,0,0);">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.
href="https://www.fireeye.com/content/dam/legacy/ammo/fxsst-12.png"> class="alignnone size-full wp-image-1791"
src="https://www.fireeye.com/content/dam/legacy/ammo/fxsst-12.png"
alt="" width="743" height="155" />
With the mystery
of stobject.dll solved, we
can focus on how it loads style="color: rgb(128,0,0);">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 style="color: rgb(128,0,0);">stobject.dll which shows the
loading of fxsst.dll.
href="https://www.fireeye.com/content/dam/legacy/ammo/fxsst-21.png"> class="alignnone size-full wp-image-1792"
src="https://www.fireeye.com/content/dam/legacy/ammo/fxsst-21.png"
alt="" width="535" height="147" />
According to this
fragment of code if the
fxsst.dll file is found it will be loaded and the two
functions, IsFaxMessage()
and FaxMonitorShutdown()
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.
href="https://www.fireeye.com/content/dam/legacy/ammo/fxsst-31.png"> class="alignnone size-full wp-image-1793"
src="https://www.fireeye.com/content/dam/legacy/ammo/fxsst-31.png"
alt="" width="366" height="159" />
The style="color: rgb(0,0,255);">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 style="color: rgb(0,0,255);">FaxMonitorShutdown(). Why does
this matter? If a malware replaces style="color: rgb(128,0,0);">fxsst.dll and is loaded by
Explorer through style="color: rgb(128,0,0);">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 style="color: rgb(128,0,0);">Explorer.exe process, it is
vulnerable to the same DLL load order hijack as style="color: rgb(128,0,0);">ntshrui.dll. By that I mean you
can place a malicious DLL in the style="color: rgb(128,0,0);">C:WINDOWS folder and it will
load instead of the legitimate copy in style="color: rgb(128,0,0);">System32. You can also just
overwrite the copy in style="color: rgb(128,0,0);">System32 and the user of the
system will not notice. Unlike with style="color: rgb(128,0,0);"> ntshrui.dll, the malware
replacing fxsst.dll
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 style="color: rgb(128,0,0);">fxsst.dll and drop it in style="color: rgb(128,0,0);">C:WINDOWS or the style="color: rgb(128,0,0);">System32 folder and style="color: rgb(128,0,0);">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.
