Mahalo FIN7: Responding to the Criminal Operators’ New Tools and TechniquesDuring several recent incident response engagements, FireEye Mandiant
investigators uncovered new tools in FIN7’s malware arsenal and kept
pace as href="/content/fireeye-www/en_US/blog/threat-research/2018/08/fin7-pursuing-an-enigmatic-and-evasive-global-criminal-operation.html">the
global criminal operators attempted new evasion techniques. In
this blog, we reveal two of FIN7’s new tools that we have called
BOOSTWRITE and RDFSNIFFER.
The first of FIN7's new tools is BOOSTWRITE – an in-memory-only
dropper that decrypts embedded payloads using an encryption key
retrieved from a remote server at runtime. FIN7 has been observed
making small changes to this malware family using multiple methods to
avoid traditional antivirus detection, including a BOOSTWRITE sample
where the dropper was signed by a valid Certificate Authority. One of
the analyzed BOOSTWRITE variants contained two payloads: CARBANAK and
RDFSNIFFER. While href="/content/fireeye-www/en_US/blog/threat-research/2019/04/carbanak-week-part-one-a-rare-occurrence.html">CARBANAK
has been thoroughly analyzed and has been used maliciously by
several financial attackers including FIN7, RDFSNIFFER is a
newly-identified tool recovered by Mandiant investigators.
RDFSNIFFER, a payload of BOOSTWRITE, appears to have been developed
to tamper with NCR Corporation's “Aloha Command Center” client. NCR
Aloha Command Center is a remote administration toolset designed to
manage and troubleshoot systems within payment card processing sectors
running the Command Center Agent. The malware loads into the same
process as the Command Center process by abusing the DLL load order of
the legitimate Aloha utility. Mandiant provided this information to NCR.
BOOSTWRITE Loader: Where You At?
BOOSTWRITE is a loader crafted to be launched via abuse of the DLL
search order of applications which load the legitimate ‘Dwrite.dll’
provided by the Microsoft DirectX Typography Services. The application
loads the ‘gdi’ library, which loads the ‘gdiplus’ library, which
ultimately loads ‘Dwrite’. Mandiant identified instances where
BOOSTWRITE was placed on the file system alongside the RDFClient
binary to force the application to import DWriteCreateFactory from it
rather than the legitimate DWrite.dll.
Once loaded, `DWrite.dll` connects to a hard-coded IP and port from
which it retrieves a decryption key and initialization vector (IV) to
decrypt two embedded payload DLLs. To accomplish this task, the
malware first generates a random file name to be used as a text log
under the current user's %TEMP% directory; this filename starts with
~rdf and is followed by a set of random numbers. Next, the malware
scans its own image to find the location of a 32-byte long multi-XOR
key which is used to decode data inside its body. Part of the decoded
data is an IP address and port which are used to retrieve the key and
the IV for the decryption of the embedded payloads. The encryption
algorithm uses the ChaCha stream cipher with a 256-bit key and 64-bit IV.
Once the key and the IV are downloaded the malware decrypts the
embedded payloads and performs sanity checks on the results. The
payloads are expected to be PE32.DLLs which, if the tests pass, are
loaded into memory without touching the filesystem.
The malware logs various plaintext messages to the previously
created logfile %TEMP%\~rds<rnd_numbers> which are indicative of
the loader’s execution progress. An example of the file content is
shown in Figure 1:
Loading... Starting...
Init OK Key OK Data: 4606941 HS: 20
K:[32] V:[8] DCnt: 732642317(ERR) |
Figure 1: BOOSTWRITE log file
Before exiting, the malware resolves the location of the benign
DWrite.dll library and passes the execution control to its
DWriteCreateFactory method.
The malware decrypts and loads two payload DLLs. One of the DLLs is
an instance of the CARBANAK backdoor; the other DLL is a tool tracked
by FireEye as RDFSNIFFER which allows an attacker to hijack instances
of the NCR Aloha Command Center Client application and interact with
victim systems via existing legitimate 2FA sessions.
RDFSNIFFER Module: We Smell a RAT
RDFSNIFFER is a module loaded by BOOSTWRITE which allows an attacker
to monitor and tamper with legitimate connections made via NCR
Corporation’s ‘Aloha Command Center Client’ (RDFClient), an
application designed to provide visibility and system management
capabilities to remote IT techs. RDFSNIFFER loads into the same
process as the legitimate RDFClient by abusing the utility’s DLL load
order, launching each time the ‘Aloha Command Center Client’ is
executed on an impacted system.
When the RDFSNIFFER module is loaded by BOOSTWRITE it hooks several
Win32 API functions intended to enable it to tamper with NCR Aloha
Command Center Client sessions or hijack elements of its
user-interface (Table 1). Furthermore, this enables the malware to
alter the user’s last input time to ensure application sessions do not
time out.
Win32 API Function | Hook Description |
CertVerifyCertificateChainPolicy | | width="312">Used to man-in-the-middle SSL sessions
CertGetCertificateChain | | width="312">Used to man-in-the-middle SSL sessions
WSAConnect | Used to man-in-the-middle socket connections |
connect | Used to man-in-the-middle socket connections |
ConnectEx | Used to man-in-the-middle socket connections |
DispatchMessageW | | width="312">Used to hijack the utility's UI
DispatchMessageA | | width="312">Used to hijack the utility's UI
DefWindowProcW | | width="312">Used to hijack the utility's UI
DefWindowProcA | | width="312">Used to hijack the utility's UI
GetLastInputInfo | | width="312">Used to change the user's last input time (to
avoid timed lock outs)
Table 1: RDFSNIFFER’s Hooked Win32 API Functions
This module also contains a backdoor component that enables it to
inject commands into an active RDFClient session. This backdoor allows
an attacker to upload, download, execute and/or delete arbitrary files
(Table 2).
Command Name | Legit Function in RDFClient | RDFClient Command ID | Description |
Upload | | width="163">FileMgrSendFile
| width="89">107
Uploads a file to the remote system |
Download | | width="163">FileMgrGetFile
| width="89">108
Retrieves a file from the remote system |
Execute | | width="163">RunCommand
3001 | Executes a command on the remote system |
DeleteRemote | | width="163">FileMgrDeleteFile
| width="89">3019
Deletes file on remote system |
DeleteLocal | - | - | Deletes a local file |
Table 2: RDFSNIFFER’s Backdoor Functions
Signed: Yours Truly, FIN7
While the majority of BOOSTWRITE variants recovered from
investigations have been unsigned, Mandiant identified a signed
BOOSTWRITE sample used by FIN7 during a recent investigation.
Following that discovery, a signed BOOSTWRITE sample href="https://www.virustotal.com/gui/file/18cc54e2fbdad5a317b6aeb2e7db3973cc5ffb01bbf810869d79e9cb3bf02bd5/detection">was
uploaded to VirusTotal on October 3. This executable uses a code
signing certificate issued by MANGO ENTERPRISE LIMITED (Table 3).
MD5 | Organization | Country | Serial |
| valign="top">a67d6e87283c34459b4660f19747a306
| width="156" valign="top">mango ENTERPRISE LIMITED
GB | | valign="top">32 7F 8F 10 74 78 42 4A BE B8 2A 85 DC 36 57
03 CC 82 70 5B
Table 3: Code signing certificate used for BOOSTWRITE
This indicates the operators may be actively altering this malware
to avoid traditional detection mechanisms. Notably, the signed
BOOSTWRITE sample had a 0/68 detection ratio when it was uploaded to
VirusTotal, demonstrating the effectiveness of this tactic (Figure 2).
src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/mahalofin7/fin7a.png" alt="" />
Figure 2: Current VirusTotal detection
ratio for signed BOOSTWRITE
Use of a code signing certificate for BOOSTWRITE is not a completely
new technique for FIN7 as the group has used digital certificates in
the past to sign their phishing documents, backdoors, and later stage
tools. By exploiting the trust inherently provided by code
certificates, FIN7 increases their chances of bypassing various
security controls and successfully compromising victims. The full
evasion achieved against the detection engines deployed to VirusTotal
– href="https://www.virustotal.com/gui/file/8773aeb53d9034dc8de339651e61d8d6ae0a895c4c89b670d501db8dc60cd2d0/detection"
title="https://www.virustotal.com/gui/file/8773aeb53d9034dc8de339651e61d8d6ae0a895c4c89b670d501db8dc60cd2d0/detection">as
compared to an unsigned BOOSTWRITE sample with an invalid
checksum– illustrates that FIN7’s methods were effective in
subverting both traditional detection and ML binary classification
engines. This is a known issue and has been deeply studied since at
least href="https://dl.acm.org/citation.cfm?doid=2872518.2888610">2016’s
“Chains of Distrust” research and href="http://users.umiacs.umd.edu/~tdumitra/papers/CCS-2017.pdf">2017’s
“Certified Malware” paper. Since there are plenty of goodware
samples with bad or no signatures – and a growing number of malware
samples with good signatures – there is no easy solution here. The
upside is that vendors selectively deploy engines to VirusTotal
(including FireEye) and VT detection performance often isn’t a
comprehensive representation of encountering full security technology
stacks that implement detection-in-depth. Later in this blog we
further explore BOOSTWRITE’s PE Authenticode signature, its anomalies,
and how code signing can be turned from a detection challenge into
detection opportunities.
Outlook and Implications
While these incidents have also included FIN7’s typical and
long-used toolsets, such as CARBANAK and BABYMETAL, the introduction
of new tools and techniques provides further evidence FIN7 is
continuing to evolve in response to security enhancements. Further,
the use of code signing in at least one case highlights the group's
judicious use of resources, potentially limiting their use of these
certificates to cases where they have been attempting to bypass
particular security controls. Barring any further law enforcement
actions, we expect at least a portion of the actors who comprise the
FIN7 criminal organization to continue conducting campaigns. As a
result, organizations need to remain vigilant and continue to monitor
for changes in methods employed by the FIN7 actors.
Sigs Up Dudes! Indicators, Toolmarks, and Detection Opportunities
While FireEye does not release our production detection logic for
the code families, this section does contain some identification and
hunting concepts that we adopt in our layered detection strategy.
Table 4 contains malware samples referenced in this blog that FireEye
is able to share from the larger set recovered during active investigations.
Type | Indicator(s) |
BOOSTWRITE (signed) | | width="84%">MD5: a67d6e87283c34459b4660f19747a306
SHA-1: a873f3417d54220e978d0ca9ceb63cf13ec71f84
SHA-256:
18cc54e2fbdad5a317b6aeb2e7db3973cc5ffb01bbf810869d79e9cb3bf02bd5
C2: 109.230.199[.]227
BOOSTWRITE (unsigned) | | width="84%">MD5: af2f4142463f42548b8650a3adf5ceb2
SHA1: 09f3c9ae382fbd29fb47ecdfeb3bb149d7e961a1
SHA256:
8773aeb53d9034dc8de339651e61d8d6ae0a895c4c89b670d501db8dc60cd2d0
C2: 109.230.199[.]227
Table 4: Publicly-shareable BOOSTWRITE samples
The signed BOOSTWRITE sample has a PE Authenticode anomaly that can
be detected using href="https://yara.readthedocs.io/en/stable/modules/pe.html#c.signatures">yara’s
PE signature module. Specifically, the PE linker timestamp is
prior to the Authenticode validity period, as seen in Table 5.
Timestamp | Description |
2019-05-20 09:50:55 UTC | | width="82%">Signed BOOSTWRITE’s PE compilation time
2019-05-22 00:00 UTC through
2020-05-21 23:59 UTC | Signed BOOSTWRITE’s “mango ENTERPRISE LIMITED” certificate validity window |
Table 5: Relevant executabe timestamps
A public example of href="https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2017/september/signaturing-an-authenticode-anomaly-with-yara">a
Yara rule covering this particular PE Authenticode timestamp anomaly
is available in a blog post from David Cannings, with the key
logic shown in Figure 3.
pe.number_of_signatures > 0 and not for all i in (0..pe.number_of_signatures - 1): pe.signatures[i].valid_on(pe.timestamp) |
Figure 3: Excerpt of NCC Group’s research Yara rule
There are other PE Authenticode anomalies that can also be
represented as Yara rules to surface similarly suspicious files. Of
note, this signed BOOSTWRITE sample has no counter signature and,
while the unauthenticated attributes timestamp structure is present,
it is empty. In preparing this blog, FireEye’s Advanced Practices team
identified a possible issue with VirusTotal’s parsing of signed
executable timestamps as seen in Figure 4.
src="https://www.fireeye.com/content/dam/fireeye-www/blog/images/mahalofin7/fin7b.png" alt="" />
Figure 4: Inconsistency in VirusTotal
file signature timestamps for the signed BOOSTWRITE sample
FireEye filed a bug report with Google to address the discrepancy in
VirusTotal in order to remove confusion for other users.
To account for the detection weaknesses introduced by techniques
like code signing, our Advanced Practices team combines the malicious
confidence spectrum that comes from ML detection systems with file
oddities and anomalies (weak signals) to surface highly interesting
and evasive malware. This technique was recently described in our own
href="/content/fireeye-www/en_US/blog/threat-research/2019/08/definitive-dossier-of-devilish-debug-details-part-one-pdb-paths-malware.html">Dr.
Steven Miller’s Definitive Dossier of Devilish Debug Details. In
fact, the exact same program database (PDB) path-based approach from
his blog can be applied to the toolmarks seen in this sample for a
quick hunting rule. Figure 5 provides the PDB path of the BOOSTWRITE
samples from this blog.
| valign="top">F:\projects\DWriteImpl\Release\DWriteImpl.pdb
Figure 5: BOOSTWRITE PDB path
The Yara rule template can be applied to result in the quick rule in
Figure 6.
rule ConventionEngine_BOOSTWRITE { meta: author = "Nick Carr (@itsreallynick)" reference = "https://www.fireeye.com/blog/threat-research/2019/08/definitive-dossier-of-devilish-debug-details-part-one-pdb-paths-malware.html"
strings: $weetPDB = /RSDS[\x00-\xFF]{20}[a-zA-Z]?:?\\[\\\s|*\s]?.{0,250}\\DWriteImpl[\\\s|*\s]?.{0,250}\.pdb\x00/ nocase condition: (uint16(0) == 0x5A4D) and uint32(uint32(0x3C)) == 0x00004550 and $weetPDB and filesize < 6MB } |
Figure 6: Applying BOOSTWRITE’s PDB path to a
Yara rule
We can apply this same concept across other executable traits, such
as BOOSTWRITE’s export DLL name (DWriteImpl.dll), to create quick and
easy rules that can aid in quick discovery as seen in Figure 7.
rule Exports_BOOSTWRITE
{ meta: author = "Steve Miller (@stvemillertime) & Nick Carr (@itsreallynick)"
strings: $exyPants = "module_ls.dll" nocase condition: uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and $exyPants at pe.rva_to_offset(uint32(pe.rva_to_offset(pe.data_directories[pe.IMAGE_DIRECTORY_ENTRY_EXPORT].virtual_address) + 12)) and filesize < 6MB } |
Figure 7: Applying BOOSTWRITE’s export DLL names
to a Yara rule
Of course, resilient prevention capabilities are needed and to that
end, FireEye detects this activity across our platforms. Table 6
contains several specific detection names from a larger list of
detection capabilities that captured this activity natively.
Platform | Signature Name |
Endpoint Security | | width="433">MalwareGuard ML detection (unsigned
variants)
Network Security and Email Security |
Malware.binary.dll (dynamic detection)
MalwareGuard ML detection (unsigned variants)
APTFIN.Dropper.Win.BOOSTWRITE (network traffic)
APTFIN.Backdoor.Win.RDFSNIFFER (network traffic)
FE_APTFIN_Dropper_Win_BOOSTWRITE (static code family detection) FE_APTFIN_Backdoor_Win_RDFSNIFFER (static code family detection) |
Table 6: FireEye detection matrix
Don’t Sweat the Techniques – MITRE ATT&CK Mappings
BOOSTWRITE
ID | Tactic | BOOSTWRITE Context |
href="https://attack.mitre.org/techniques/T1022/">T1022
| Data Encrypted | | width="365">BOOSTWRITE encodes its payloads using a ChaCha
stream cipher with a 256-bit key and 64-bit IV to evade
detection
href="https://attack.mitre.org/techniques/T1027/">T1027
| Obfuscated Files or Information |
BOOSTWRITE encodes its payloads using a ChaCha stream cipher with a 256-bit key and 64-bit IV to evade detection |
href="https://attack.mitre.org/techniques/T1038/">T1038
| DLL Search Order Hijacking | | width="365">BOOSTWRITE exploits the applications’ loading
of the ‘gdi’ library, which loads the ‘gdiplus’ library, which
ultimately loads the local ‘Dwrite’ dll
href="https://attack.mitre.org/techniques/T1116">T1116
| Code Signing | | width="365">BOOSTWRITE variants were observed signed by a
valid CA
href="https://attack.mitre.org/techniques/T1129/">T1129
| Execution through Module Load |
BOOSTWRITE exploits the applications’ loading of the ‘gdi’ library, which loads the ‘gdiplus’ library, which ultimately loads the local ‘Dwrite’ dll |
href="https://attack.mitre.org/techniques/T1140/">T1140
| Deobfuscate/Decode Files or Information | BOOSTWRITE decodes its payloads at runtime using using a ChaCha stream cipher with a 256-bit key and 64-bit IV |
RDFSNIFFER
ID | Tactic | RDFSNIFFER Context |
href="https://attack.mitre.org/techniques/T1106/">T1106
| Execution through API | | width="365">RDFSNIFFER hooks several Win32 API functions
intended to enable it to tamper with NCR Aloha Command Center
Client sessions or hijack elements of its user-interface
href="https://attack.mitre.org/techniques/T1107/">T1107
| File Deletion | | width="365">RDFSNIFFER has the capability of deleting local
files
href="https://attack.mitre.org/techniques/T1179/">T1179
| Hooking | | width="365">RDFSNIFFER hooks several Win32 API functions
intended to enable it to tamper with NCR Aloha Command Center
Client sessions or hijack elements of its user-interface
Acknowledgements
The authors want to thank href="https://twitter.com/SElovitz">Steve Elovitz, Jeremy
Koppen, and the many Mandiant incident responders that go toe-to-toe
with FIN7 regularly, quietly evicting them from victim environments.
We appreciate the thorough detection engineering from Ayako Matsuda
and the reverse engineering from FLARE’s href="https://twitter.com/dandonov">Dimiter Andonov, href="https://twitter.com/t00manybananas">Christopher
Gardner and Tyler Dean.
A special thanks to FLARE’s Troy Ross for the development of his PE
Signature analysis service and for answering our follow-up questions.
Shout out to Steve
Miller for his hot fire research and Yara anomaly work. And
lastly, the rest of the Advanced Practices team for both the
unparalleled front-line FIN7 technical intelligence expertise and
MITRE ATT&CK automated mapping project – with a particular thanks
to Regina Elwell and href="https://twitter.com/BarryV">Barry Vengerik.
Source:
Mahalo FIN7: Responding to the Criminal Operators’ New Tools and Techniques