In May and June 2017, FireEye observed a phishing campaign targeting
at least seven global law and investment firms. We have associated
this campaign with APT19, a group that we assess is composed of
freelancers, with some degree of sponsorship by the Chinese government.
APT19 used three different techniques to attempt to compromise
targets. In early May, the phishing lures leveraged RTF attachments
that exploited the Microsoft Windows vulnerability described in href="https://www.fireeye.com/blog/threat-research/2017/04/cve-2017-0199-hta-handler.html">CVE
2017-0199. Toward the end of May, APT19 switched to using
macro-enabled Microsoft Excel (XLSM) documents. In the most recent
versions, APT19 added an application whitelisting bypass to the XLSM
documents. At least one observed phishing lure delivered a Cobalt
Strike payload.
As of the writing of this blog post, FireEye had not observed
post-exploitation activity by the threat actors, so we cannot assess
the goal of the campaign. We have previously observed APT19 steal data
from law and investment firms for competitive economic purposes.
This purpose of this blog post is to inform law firms and investment
firms of this phishing campaign and provide technical indicators that
their IT personnel can use for proactive hunting and detection.
APT19 phishing emails from this campaign originated from sender
email accounts from the "@cloudsend[.]net" domain and used a
variety of subjects and attachment names. Refer to the Indicators of
Compromise section for more details.
APT19 leveraged Rich Text Format (RTF) and macro-enabled Microsoft
Excel (XLSM) files to deliver their initial exploits. The following
sections describe the two methods in further detail.
Through the exploitation of the HTA handler vulnerability described
in href="https://www.fireeye.com/blog/threat-research/2017/04/cve-2017-0199-hta-handler.html">CVE-2017-1099,
the observed RTF attachments download
hxxp://tk-in-f156.2bunny[.]com/Agreement.doc. Unfortunately, this file
was no longer hosted at tk-in-f156.2bunny[.]com for further analysis.
Figure 1 is a screenshot of a packet capture showing one of the RTF
files reaching out to hxxp://tk-in-f156.2bunny[.]com/Agreement.doc.

Figure 1: RTF PCAP
The XLSM attachments contained multiple worksheets with content that
reflected the attachment name. The attachments also contained an image
that requested the user to “Enable Content”, which would enable macro
support if it was disabled. Figure 2 provides a screenshot of one of
the XLSM files (MD5:30f149479c02b741e897cdb9ecd22da7).

Figure 2: Enable macros
One of the malicious XLSM attachments that we observed contained a
macro that:
Figure 3 depicts the macro embedded within the XLSM file (MD5: 38125a991efc6ab02f7134db0ebe21b6).

Figure 3: XLSX Macro
Figure 4 contains the decoded output of the encoded text.

Figure 4: Decoded ZLIB + Base64 payload
The shellcode invokes PowerShell to issue a HTTP GET request for a
random four (4) character URI on the root of
autodiscovery[.]2bunny[.]com. The requests contain minimal HTTP
headers since the PowerShell command is executed with mostly default
parameters. Figure 5 depicts an HTTP GET request generated by the
payload, with minimal HTTP headers.

Figure 5: GET Request with minimal HTTP headers
Converting the shellcode to ASCII and removing the non-printable
characters provides a quick way to pull out network-based indicators
(NBI) from the shellcode. Figure 6 shows the extracted NBIs.

Figure 6: Decoded shellcode
FireEye also identified an alternate macro in some of the XLSM
documents, displayed in Figure 7.

Figure 7: Alternate macro
This macro uses href="http://subt0x10.blogspot.com/2017/04/bypass-application-whitelisting-script.html">Casey
Smith’s “Squiblydoo” Application Whitelisting bypass technique
to run the command in Figure 8.

Figure 8: Application Whitelisting Bypass
The command in Figure 8 downloads and launches code within an SCT
file. The SCT file in the payload (MD5:
1554d6fe12830ae57284b389a1132d65) contained the code shown in Figure 9.

Figure 9: SCT contents
Figure 10 provides the decoded script. Notice the “$DoIt” string,
which is usually indicative of a Cobalt Strike payload.

Figure 10: Decoded SCT contents
A quick conversion of the contents of the variable “$var_code” from
Base64 to ASCII shows some familiar network indicators, shown in
Figure 11.

Figure 11: $var_code to ASCII
Once the XLSM launches its PowerShell command, it downloads a
typical Cobalt Strike BEACON payload, configured with the following parameters:
Figure 12 depicts an example of a BEACON C2 attempt from this payload.

Figure 12: Cobalt Strike BEACON C2
The following FireEye products currently detect and block the
methods described above. Table 1 lists the current detection and
blocking capabilities by product.
|
|
|
|
SUSPICIOUS POWERSHELL USAGE | HX | Detect | width="161" valign="bottom"> |
| valign="bottom"> | HX | width="41" valign="top"> | valign="bottom"> |
Malware Object | width="46" valign="bottom"> | valign="top"> | valign="bottom"> |
Backdoor.BEACON | width="46" valign="bottom"> | valign="top"> | valign="bottom"> |
FE_Malformed_RTF | width="46" valign="bottom"> | valign="top"> | valign="bottom"> |
Malware.Binary.rtf | EX/ETP/NX | width="41" valign="top"> | valign="bottom"> |
Malware.Binary | width="46" valign="bottom"> | valign="top"> | valign="bottom"> |
Malware.Binary.xlsx | EX/ETP/NX | width="41" valign="top"> | valign="bottom"> |
Table 1: Detection review
*Appliances must be configured for block mode.
FireEye recommends organizations perform the following steps to
mitigate the risk of this campaign:
The following section provides the IOCs for the variants of the
phishing emails and malicious payloads that FireEye has observed
during this campaign.
RTF MD5 hash values
XLSX MD5 hash values
BEACON and Meterpreter payload MD5 hash values
Process arguments, named pipes, and file paths
rule FE_LEGALSTRIKE_MACRO { condition: |
| rule FE_LEGALSTRIKE_MACRO_2 { meta:version=".1" filetype="MACRO" author="Ian.Ahl@fireeye.com @TekDefense" date="2017-06-02" description="This rule was written to hit on specific variables and powershell command fragments as seen in the macro found in the XLSX file3a1dca21bfe72368f2dd46eb4d9b48c4." strings: // Setting the environment $env1 = "Arch = Environ(\"PROCESSOR_ARCHITECTURE\")" ascii wide $env2 = "windir = Environ(\"windir\")" ascii wide $env3 = "windir + \"\\syswow64\\windowspowershell\\v1.0\\powershell.exe\"" ascii wide // powershell command fragments $ps1 = "-NoP" ascii wide $ps2 = "-NonI" ascii wide $ps3 = "-W Hidden" ascii wide $ps4 = "-Command" ascii wide $ps5 = "New-Object IO.StreamReader" ascii wide $ps6 = "IO.Compression.DeflateStream" ascii wide $ps7 = "IO.MemoryStream" ascii wide $ps8 = ",$([Convert]::FromBase64String" ascii wide $ps9 = "ReadToEnd();" ascii wide $psregex1 = /\W\w+\s+\s\".+\"/ condition: ( ( (uint16(0) != 0x5A4D) ) and ( all of ($env*) and 6 of ($ps*) or all of ($env*) and 4 of ($ps*) and all of ($psregex*) ) ) } |
rule FE_LEGALSTRIKE_RTF { strings: $lnkinfo = $http1 = // $datastore = condition: |
Joshua Kim, Nick Carr, Gerry Stellatos, Charles Carmakal, TJ Dahms,
Nick Richard, Barry Vengerik, Justin Prosco, Christopher Glyer