Read the original article: Analyzing Dark Crystal RAT, a C# backdoor
The FireEye
Mandiant Threat Intelligence Team helps protect our customers by
tracking cyber attackers and the malware they use. The FLARE Team
helps augment our threat intelligence by reverse engineering malware
samples. Recently, FLARE worked on a new C# variant of Dark Crystal
RAT (DCRat) that the threat intel team passed to us. We reviewed open
source intelligence and prior work, performed sandbox testing, and
reverse engineered the Dark Crystal RAT to review its capabilities and
communication protocol. Through publishing this blog post we aim to
help defenders look for indicators of compromise and other telltale
signs of Dark Crystal RAT, and to assist fellow malware researchers
new to .NET malware, or who encounter future variants of this sample.
Discovering Dark Crystal RAT
The threat intel team provided FLARE with an EXE sample, believed to
contain Dark Crystal RAT, and having the MD5 hash
b478d340a787b85e086cc951d0696cb1. Using sandbox testing, we found that
this sample produced two executables, and in turn, one of those two
executables produced three more. Figure 1 shows the relationships
between the malicious executables discovered via sandbox testing.
Figure 1: The first sample we began analyzing ultimately
produced five executables.
Armed with the sandbox results, our next step was to perform a
triage analysis on each executable. We found that the original sample
and mnb.exe were droppers, that dal.exe was a clean-up utility to
delete the dropped files, and that daaca.exe and fsdffc.exe were
variants of Plurox, a family with existing reporting. Then we moved to
analyzing the final dropped sample, which was dfsds.exe. We found
brief public reporting by @James_inthe_box on the same sample,
identifying
it as DCRat and as a RAT and credential stealer. We also found a
public
sandbox run that included the same sample. Other public
reporting described
DCRat, but actually analyzed the daaca.exe Plurox component
bundled along with DCRat in the initial sample.
Satisfied that dfsds.exe was a RAT lacking detailed public
reporting, we decided to perform a deeper analysis.
Analyzing Dark Crystal RAT
Initial Analysis
Shifting aside from our sandbox for a moment, we performed static
analysis on dfsds.exe. We chose to begin static analysis using CFF
Explorer, a good tool for opening a PE file and breaking down its
sections into a form that is easy to view. Having viewed dfsds.exe in
CFF Explorer, as shown in Figure 2, the utility showed us that it is a
.NET executable. This meant we could take a much different path to
analyzing it than we would on a native C or C++ sample. Techniques we
might have otherwise used to start narrowing down a native sample’s
functionality, such as looking at what DLLs it imports and what
functions from those DLLs that it uses, yielded no useful results for
this .NET sample. As shown in Figure 3, dfsds.exe imports only the
function _CorExeMain from mscoree.dll. We
could have opened dfsds.exe in IDA Pro, but IDA Pro is usually not the
most effective way of analyzing .NET samples; in fact, the free
version of IDA Pro cannot handle .NET Common Language Infrastructure
(CLI) intermediate code.
Figure 2: CFF Explorer shows that dfsds.exe is a .NET executable.
Figure 3: The import table for dfsds.exe is not useful as it
contains only one function.
Instead of using a disassembler like IDA Pro on dfsds.exe, we used a
.NET decompiler. Luckily for the reverse engineer, decompilers operate
at a higher level and often produce a close approximation of the
original C# code. dnSpy is a great .NET decompiler. dnSpy’s interface
displays a hierarchy of the sample’s namespaces and classes in the
Assembly Explorer and shows code for the selected class on the right.
Upon opening dfsds.exe, dnSpy told us that the sample’s original name
at link time was DCRatBuild.exe, and that its entry point is at <PrivateImplementationDetails>{63E52738-38EE-4EC2-999E-1DC99F74E08C}.Main,
shown in Figure 4. When we browsed to the Main method using the
Assembly Explorer, we found C#-like code representing that method in
Figure 5. Wherever dnSpy displays a call to another method in the
code, it is possible to click on the target method name to go to it
and view its code. By right-clicking on an identifier in the code, and
clicking Analyze in the context menu, we caused dnSpy to look for all
occurrences where the identifier is used, similar to using
cross-references in IDA Pro.
Figure 4: dnSpy can help us locate the
sample’s entry point
Figure 5: dnSpy decompiles the Main
method into C#-like code
We went to the SchemaServerManager.Main
method that is called from the entry point method, and observed that
it makes many calls to ExporterServerManager.InstantiateIndexer with
different integer arguments, as shown in Figure 6. We browsed to the
ExporterServerManager.InstantiateIndexer
method, and found that it is structured as a giant switch statement
with many goto statements and labels; Figure 7 shows an excerpt. This
does not look like typical dnSpy output, as dnSpy often reconstructs a
close approximation of the original C# code, albeit with the loss of
comments and local variable names. This code structure, combined with
the fact that the code refers to the CipherMode.CBC constant, led us to believe that
ExporterServerManager.InstantiateIndexer
may be a decryption or deobfuscation routine. Therefore, dfsds.exe is
likely obfuscated. Luckily, .NET developers often use obfuscation
tools that are somewhat reversible through automated means.
Figure 6: SchemaServerManager.Main makes
many calls to ExporterServerManager.InstantiateIndexer
Figure 7:
ExporterServerManager.InstantiateIndexer looks like it may be a
deobfuscation routine
Deobfuscation
De4dot is a .NET deobfuscator that knows how to undo many types of
obfuscations. Running de4dot -d (for detect) on dfsds.exe (Figure 8)
informed us that .NET Reactor was used to obfuscate it.
|
> de4dot -d dfsds.exe
de4dot v3.1.41592.3405 Copyright (C)
Detected .NET Reactor |
Figure 8: dfsds.exe is obfuscated with .NET Reactor
After confirming that de4dot can deobfuscate dfsds.exe, we ran it
again to deobfuscate the sample into the file dfsds_deob.exe (Figure 9).
|
> de4dot -f dfsds.exe -o
de4dot v3.1.41592.3405 Copyright (C)
Detected .NET Reactor |
Figure 9: de4dot successfully deobfuscates dfsds.exe
After deobfuscating dfsds.exe, we ran dnSpy again on the resulting
dfsds_deob.exe. When we decompiled SchemaServerManager.Main again, the results were
much different, as shown in Figure 10. Contrasting the new output with
the obfuscated version shown previously in Figure 6, we found the
deobfuscated code much more readable. In the deobfuscated version, all
the calls to ExporterServerManager.InstantiateIndexer were
removed; as suspected, it was apparently a string decoding routine. In
contrast, the class names shown in the Assembly Explorer did not
change; the obfuscator must have irrecoverably replaced the original
class names with meaningless ones obtained from a standard list. Next,
we noted that ten lines in Figure 10 hold base64-encoded data. Once
the sample was successfully deobfuscated, it was time to move on to
extracting its configuration and to follow the sample’s code path to
its persistence capabilities and initial beacon.
Figure 10: Deobfuscating dfsds.exe shows
that the method begins with some path manipulation and then accesses
Base64-encoded data
Configuration, Persistence and Initial Beacon
Recall that in Figure 10 we found that the method SchemaServerManager.Main has a local variable
containing Base64-encoded data; decoding that data revealed what it
contains. Figure 11 shows the decoded configuration (with C2 endpoint
URLs de-fanged):
|
> echo
MHost:hxxp://domalo[.]online/ksezblxlvou3kcmbq8l7hf3f4cy5xgeo4udla91dueu3qa54/ |
Figure 11: Decoding the base64 data in
SchemaServerManager.Main reveals a configuration string
Figure 11 shows that the data decoded to a configuration string
containing four values: MHost, BHost, MX, and TAG. We analyzed the
code that parses this string and found that MHost and BHost were used
as its main and backup command and control (C2) endpoints. Observe
that the MHost and BHost values in Figure 11 are identical, so this
sample did not have a backup C2 endpoint.
In dnSpy it is possible to give classes and methods meaningful names
just as it is possible to name identifiers in IDA Pro. For example,
the method SchemaServerManager.StopCustomer
picks the name of a random running process. By right-clicking the
StopCustomer identifier and choosing Edit
Method, it is possible to change the method name to PickRandomProcessName, as shown in Figure 12.
Figure 12: Assigning meaningful names to
methods makes it easier to keep analyzing the program
Continuing to analyze the SchemaServerManager.Main method revealed that the
sample persists across reboots. The persistence algorithm can be
summarized as follows:
- The malware picks the name of a random running process, and
then copies itself to %APPDATA% and C:\. For example, if svchost.exe is selected,
then the malware copies itself to %APPDATA%\svchost.exe and C:\svchost.exe. - The malware creates a
shortcut %APPDATA%\dotNET.lnk pointing to
the copy of the malware under %APPDATA%. - The malware creates a shortcut
named dotNET.lnk in the logged-on user’s Startup folder pointing to
%APPDATA%\dotNET.lnk. - The
malware creates a shortcut C:\Sysdll32.lnk
pointing to the copy of the malware under C:\. - The malware creates a shortcut named
Sysdll32.lnk in the logged-on user’s Startup folder pointing to
C:\Sysdll32.lnk. - The malware
creates the registry value HKCU\Software\Microsoft\Windows\CurrentVersion\Run\scrss
pointing to %APPDATA%\dotNET.lnk. - The malware creates the registry value HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Wininit
pointing to C:\Sysdll32.lnk.
After its persistence steps, the malware checks for multiple
instances of the malware:
- The malware sleeps for a random interval between 5 and 7
seconds. - The malware takes the MD5 hash of the
still-base64-encoded configuration string, and creates the mutex
whose name is the hexadecimal representation of that hash. For this
sample, the malware creates the mutex bc2dc004028c4f0303f5e49984983352. If this fails
because another instance is running, the malware exits.
The malware then beacons, which also allows it to determine whether
to use the main host (MHost) or backup host (BHost). To do so, the
malware constructs a beacon URL based on the MHost URL, makes a
request to the beacon URL, and then checks to see if the server
responds with the HTTP response body “ok.” If the server does not send
this response,
[…]
Read the original article: Analyzing Dark Crystal RAT, a C# backdoor