Here’s how a proactive approach to targeted threat hunting can better prepare hospitals against cyberattacksCategory:Leadership InsightsIncident Response and ManagementRead how a proactive approach to targeted threat hunting can better prepare hospital…
FIN7 is a financially-motivated threat group that has been associated
with malicious operations dating back to late 2015. FIN7 is referred
to by many vendors as “Carbanak Group”, although we do not equate all
usage of the CARBANAK backdoor with FIN7. FireEye recently observed a
spear phishing campaign targeting personnel involved with United
States Securities and Exchange Commission (SEC) filings at various organizations.
In a newly-identified campaign, FIN7 modified their phishing
techniques to implement unique infection and persistence mechanisms.
FIN7 has moved away from weaponized Microsoft Office macros in order
to evade detection. This round of FIN7 phishing lures implements
hidden shortcut files (LNK files) to initiate the infection and
VBScript functionality launched by mshta.exe to infect the victim.
In this ongoing campaign, FIN7 is targeting organizations with spear
phishing emails containing either a malicious DOCX or RTF file – two
versions of the same LNK file and VBScript technique. These lures
originate from external email addresses that the attacker rarely
re-used, and they were sent to various locations of large restaurant
chains, hospitality, and financial service organizations. The subjects
and attachments were themed as complaints, catering orders, or
resumes. As with previous campaigns, and as highlighted in our annual
M-Trends 2017 report, FIN7 is calling stores at targeted
organizations to ensure they received the email and attempting to walk
them through the infection process.
While FIN7 has embedded VBE as OLE objects for over a year, they
continue to update their script launching mechanisms. In the current
lures, both the malicious DOCX and RTF attempt to convince the user to
double-click on the image in the document, as seen in Figure 1. This
spawns the hidden embedded malicious LNK file in the document.
Overall, this is a more effective phishing tactic since the malicious
content is embedded in the document content rather than packaged in
the OLE object.
By requiring this unique interaction – double-clicking on the image
and clicking the “Open” button in the security warning popup – the
phishing lure attempts to evade dynamic detection as many sandboxes
are not configured to simulate that specific user action.
Figure 1: Malicious FIN7 lure asking victim to
double click to unlock contents
The malicious LNK launches “mshta.exe” with the following arguments
passed to it:
vbscript:Execute(“On Error Resume Next:set
The script in the argument combines all the textbox contents in the
document and executes them, as seen in Figure 2.
Figure 2: Textbox inside DOC
The combined script from Word textbox drops the following components:
Also, the script creates a named schedule task for persistence to
launch “58d2a83f7778d5.36783181.vbs” every 25 minutes.
The dropped script “58d2a83f7778d5.36783181.vbs” acts as a launcher.
This VBScript checks if the “58d2a83f777942.26535794.ps1” PowerShell
script is running using WMI queries and, if not, launches it.
“58d2a83f777942.26535794.ps1” is a multilayer obfuscated PowerShell
script, which launches shellcode for a Cobalt Strike stager.
The shellcode retrieves an additional payload by connecting to the
following C2 server using DNS:
Once a successful reply is received from the command and control
(C2) server, the PowerShell script executes the embedded Cobalt Strike
shellcode. If unable to contact the C2 server initially, the shellcode
is configured to reattempt communication with the C2 server address in
the following pattern:
“mshta.exe” further executes the second VBScript
“58d2a83f777908.23270411.vbs”, which creates a folder by GUID name
inside “Intel” and drops the VBScript payloads and configuration files:
This script then executes “58d2a83f777716.48248237.vbs”, which is a
variant of FIN7’s HALFBAKED backdoor.
HALFBAKED Backdoor Variant
The HALFBAKED malware family consists of multiple components
designed to establish and maintain a foothold in victim networks, with
the ultimate goal of gaining access to sensitive financial
information. This version of HALFBAKED connects to the following C2 server:
This version of HALFBAKED listens for the following commands from
the C2 server:
info: Sends victim machine information (OS, Processor, BIOS
and running processes) using WMI queries
- processList: Send list of process running
screenshot: Takes screen shot of victim machine (using
- runvbs: Executes a VB script
- runexe: Executes EXE file
- runps1: Executes PowerShell script
- delete: Delete the specified file
- update: Update the specified file
All communication between the backdoor and attacker C2 are encoded
using the following technique, represented in pseudo code:
encoded_data = URLEncode(SimpleEncrypt(data))
post_data(“POST”, random_string &
“=” & encoded_data, Hard_coded_c2_url,
The FireEye iSIGHT Intelligence MySIGHT Portal contains additional
information based on our investigations of a variety of topics
discussed in this post, including FIN7 and the HALFBAKED backdoor.
Click here for
Figure 3 shows that for persistence, the document creates two
scheduled tasks and creates one auto-start registry entry pointing to
the LNK file.
Figure 3: FIN7 phishing lure persistence mechanisms
Examining Attacker Shortcut Files
In many cases, attacker-created LNK files can reveal valuable
information about the attacker’s development environment. These files
can be parsed with lnk-parser to
extract all contents. LNK files have been valuable during Mandiant
incident response investigations as they include volume serial number,
NetBIOS name, and MAC address.
For example, one of these FIN7 LNK files contained the following properties:
- Version: 0
- NetBIOS name: andy-pc
volume identifier: e2c10c40-6f7d-4442-bcec-470c96730bca
- Droid file identifier: a6eea972-0e2f-11e7-8b2d-0800273d5268
- Birth droid volume identifier:
- Birth droid file
- UUID timestamp: 03/21/2017
- UUID sequence number: 2861
From this LNK file, we can see not only what the shortcut launched
within the string data, but that the attacker likely generated this
file on a VirtualBox system with hostname “andy-pc” on March 21, 2017.
Example Phishing Lures
- Filename: Doc33.docx
- MD5: 6a5a42ed234910121dbb7d1994ab5a5e
- Filename: Mail.rtf
- MD5: 1a9e113b2f3caa7a141a94c8bc187ea7
FIN7 April 2017 Community Protection Event
On April 12, in response to FIN7 actively targeting multiple
clients, FireEye kicked off a Community Protection Event (CPE) – a
coordinated effort by FireEye as a Service (FaaS), Mandiant, FireEye
iSight Intelligence, and our product team – to secure all clients
affected by this campaign.
In this post we are going to take a quick look at what it takes to
write a libemu compatibility layer for the Unicorn engine. In the
course of this work, we will also import the libemu Win32 environment
to run under Unicorn.
For a bit of background, libemu is a lightweight x86 emulator
written in C by Paul Baecher and Markus Koetter. It was released in
2007 and includes a built-in Win32 environment that allows shellcodes
to resolve API at runtime. The library also provides end users with a
convenient way to receive callbacks when API functions are hit. The
original project supported 5 Windows dlls, 51 hooks and 234 opcodes
all wrapped in a tight 1mb package. Unfortunately it is no longer
In late 2015, we saw the Unicorn engine project released by Nguyen
Anh Quynh and Dang Hoang Vu. This project takes the processor
emulators from QEMU and wraps them into an easy to use library.
Unicorn, however, does not provide a Win32 layer.
As an experiment, we were curious to see what it would take to bring
the libemu Win32 environment into Unicorn. This task actually turned
out to be quite simple since it was nicely self contained. In the
process of exploring this it also made sense to write a basic shim
layer to support the libemu API and translate its inner workings over
Lets start with the common libemu API:
The API is actually very similar to Unicorn:
The major differences are that Unicorn does everything through an
opaque uc_engine* handle, while libemu uses a series of structs such
as emu, emu_cpu, and emu_memory:
In general, the emu and emu_memory structures are passed directly as
arguments to API wrappers such as emu_cpu_get, emu_memory_get and the
emu_memory_read/write functions. There is one common case of direct
member access to the emu_cpu structure that requires some special
attention. This structure gives the user direct read/write access to
the emulator’s virtual processor and is commonly utilized by user
code. Examples to support include:
The next task was to see if we could mimic the direct access to the
emu_cpu elements as if they were static struct fields. Here we enter
the world of C++ operator overloading.
With these tasks complete, porting existing code from libemu over to
Unicorn should be a pretty straightforward task.
In Figure 1 we see an initial test, we put together that includes
the Win32 environment, shim layer, several API hooks and a hard coded payload.
Figure 1: Initial test of the libemu Win32
environment and hooks running under Unicorn
With this working, the next stage was to try it out against a larger
code base. Here we imported the userhooks.cpp from scdbg, an extension
of the libemu sctest that includes some 250 API hooks. As it turns
out, very few changes were required to get it working.
In Figure 2, we can see the results of testing it against a fairly
complex shellcode that:
- allocates virtual memory
- copies code to the new
- creates a new thread
- downloads an
- checks the registry for the presence of Antivirus
Note that while this shellcode would normally do process injection,
scdbg handles it all inline for simplified analysis.
Figure 2: Complex shellcode running with
hooks imported from scdbg
Another large feature to test was the scdbg debug shell. When
testing software in an emulated environment, having interactive debug
tools available is extremely handy.
Figure 3 shows an example of setting a breakpoint, single stepping,
and examining memory of code running in the emulator.
Figure 3: Imported scdbg debug shell
running with Unicorn Engine and libemu shim layer
In this article we took a quick look at the differences between the
libemu and Unicorn emulators API. This allowed us to create a shim
layer to import legacy libemu code and use it with Unicorn largely unchanged.
Once the shim layer was in place, we next imported the libemu Win32
Environment so we could run it under Unicorn.
As a final test we ported several large portions of the scdbg
project, which was originally written to run under libemu. Here our
previous work allowed for the importation of scdbg’s 250+ API hooks
and debug shell to run under Unicorn with only minimal changes.
Overall the entire process went quite smoothly and should provide
benefits for developers of libemu and/or Unicorn. If you would like to
experiment for yourself you can download a copy of our test project here.
CVE-2017-0199 Used as Zero Day to Distribute FINSPY Espionage Malware and LATENTBOT Cyber Crime Malware
FireEye recently identified a vulnerability – CVE-2017-0199 – that
allows a malicious actor to download and execute a Visual Basic script
containing PowerShell commands when a user opens a Microsoft Office
RTF document containing an embedded exploit. We worked with Microsoft
the technical details of this vulnerability as soon as a patch
was made available.
In this follow-up post, we discuss some of the campaigns we observed
leveraging the CVE-2017-0199 zero-day in the days, weeks and months
leading up to the patch being released.
CVE-2017-0199 Used by Multiple Actors
FireEye assesses with moderate confidence that CVE-2017-0199 was
leveraged by financially motivated and nation-state actors prior to
its disclosure. Actors leveraging FINSPY and LATENTBOT used the
zero-day as early as January and March, and similarities between their
implementations suggest they obtained exploit code from a shared
source. Recent DRIDEX activity began following a disclosure on April
FINSPY Malware Used to Target Russian-Speaking Victims
As early as Jan. 25,2017, lure documents referencing a
Russian Ministry of Defense decree and a manual allegedly published in
the “Donetsk People’s Republic” exploited CVE-2017-0199 to
deliver FINSPY payloads. Though we have not identified the targets,
FINSPY is sold by Gamma Group to multiple nation-state clients, and we
assess with moderate confidence that it was being used along with the
zero-day to carry out cyber espionage.
The malicious document, СПУТНИК РАЗВЕДЧИКА.doc (MD5:
c10dabb05a38edd8a9a0ddda1c9af10e), is a weaponized version of a widely
available military training manual (Figure 1). Notably, this version
purports to have been published in the “Donetsk People’s Republic,”
the name given to territory controlled by anti-Kyiv rebels in Eastern Ukraine.
The initial malicious document downloaded further payloads,
including malware and a decoy document from 18.104.22.168. This site
was open indexed to allow recovery of additional lure content,
including prikaz.doc (MD5: 0F2B7068ABFF00D01CA7E64589E5AFD9), which
claims to be a Russian Ministry of Defense decree approving a forest
Per a 2015 report
from CitizenLab, Gamma Group licenses their software to clients and
each client uses unique infrastructure, making it likely that the two
documents are being used by a single client.
FINSPY malware is sold by Gamma Group, an Anglo-German “lawful
intercept” company. Gamma Group works on behalf of numerous
nation-state clients, limiting insight into the ultimate sponsor of
the activity. The FINSPY malware was heavily obfuscated, preventing
the extraction of command and control (C2) information.
Figure 1: FINSPY Lure Purporting to be Russian
CVE-2017-0199 Used to Distribute LATENTBOT
As early as March 4, 2017, malicious documents exploiting
CVE-2017-0199 were used to deliver the LATENTBOT
malware. The malware, which includes credential theft capability,
has thus far only been observed by FireEye iSIGHT Intelligence in
financially motivated threat activity. Additionally, generic lures
used in this most recent campaign are consistent with methods employed
by financially motivated actors.
LATENTBOT is a modular and highly obfuscated type of malware first
discovered by FireEye iSIGHT intelligence in December 2015. It is
capable of a variety of functions, including credential theft, hard
drive and data wiping, disabling security software, and remote desktop
functionality. Recently, we observed LATENTBOT campaigns using
Microsoft Word Intruder (MWI).
The lure documents distributing LATENTBOT malware used generic
social engineering. The documents that were used are shown in Table 1,
and all used 22.214.171.124 as a C2 domain.
Table 1: LATENTBOT Documents
On April 10, the actors altered their infrastructure to deliver
TERDOT payloads instead of LATENTBOT. This TERDOT payload (MD5:
e3b600a59eea9b2ea7a0d4e3c45074da) beacons to
http://126.96.36.199/SBz1efFx/gt45gh.php, then downloads a Tor client
and beacons to sudoofk3wgl2gmxm.onion.
FINSPY and LATENTBOT Samples Share Origin
Shared artifacts in the FINSPY and LATENTBOT samples suggest the
same builder was used to create both, indicating the zero-day exploit
was supplied to both criminal and cyber espionage operations from the
Malicious documents used in both campaigns share a last revision
time of: 2016-11-27 22:42:00 (Figure 2).
Figure 2: Revision Time Artifact Shared Between
FINSPY and LATENTBOT Samples
DRIDEX Spam Follows Recent Disclosure
Following a disclosure of specifics related to the zero-day on April
7, 2017, the vulnerability was used in DRIDEX spam campaigns, which
continue as of the publication of this blog. We cannot confirm the
mechanism through which the actors obtained the exploit. These actors
may have leveraged knowledge of the vulnerability gained through the
disclosure, or been given access to it when it became clear that
patching was imminent.
A spam wave was sent out on April 10, 2017, leveraging a “Scan Data”
lure. The attached document leveraged CVE-2017-0199 to install DRIDEX
on the victim’s computer.
Outlook and Implications
Though only one FINSPY user has been observed leveraging this
zero-day exploit, the historic scope of FINSPY, a capability used by
several nation states, suggests other customers had access to it.
Additionally, this incident exposes the global nature of cyber threats
and the value of worldwide perspective – a cyber espionage incident
targeting Russians can provide an opportunity to learn about and
interdict crime against English speakers elsewhere.
Industrial enterprises such as electric utilities, petroleum
companies, and manufacturing organizations invest heavily in industrial
control systems (ICS) to efficiently, reliably, and safely
operate industrial processes. Without this technology operating the
plant floor, these businesses cannot exist.
Board members, executives, and security officers are often unaware
that the technology operating the economic engine of their enterprise
invites undetected subversion.
In this paper, FireEye iSIGHT Intelligence prepares risk executives
and security practitioners to knowledgeably discuss six core
weaknesses an adversary can use to undermine a plant’s operation:
- Unauthenticated protocols
- Outdated hardware
- Weak user authentication
- Weak file integrity
- Vulnerable Windows operating systems
- Undocumented third-party relationships
report to learn more. To discuss these six subversive
vulnerabilities threatening today’s industrial environments, register
for our live webinar scheduled for Tuesday, April 25 at 11:00am
ET/8:00am PT. Explore the implications and how to address them
firsthand with our ICS intelligence experts.
FireEye recently detected malicious Microsoft Office RTF documents
that leverage CVE-2017-0199, a previously undisclosed vulnerability.
This vulnerability allows a malicious actor to download and execute a
Visual Basic script containing PowerShell commands when a user opens a
document containing an embedded exploit. FireEye has observed Office
documents exploiting CVE-2017-0199 that download and execute malware
payloads from different well-known malware families.
FireEye shared the details of the vulnerability with Microsoft and
has been coordinating public disclosure timed with the release of a
patch by Microsoft to address the vulnerability, which can be found here.
The vulnerability bypassed most mitigations prior to patch
availability; however, FireEye email and network products detected the
malicious documents. FireEye recommends that Microsoft Office users
apply the patch
The attack occurs in the following manner:
- A threat actor emails a Microsoft Word document to a targeted
user with an embedded OLE2 embedded link object
- When the
user opens the document, winword.exe issues a HTTP request to a
remote server to retrieve a malicious HTA file
- The file
returned by the server is a fake RTF file with an embedded malicious
- Winword.exe looks up the file handler for
application/hta through a COM object, which causes the Microsoft HTA
application (mshta.exe) to load and execute the malicious
In the two documents that FireEye observed prior to the initial
blog acknowledging these attacks, malicious scripts terminated the
winword.exe processes, downloaded additional payloads, and loaded
decoy documents. The original winword.exe process was terminated to
conceal a user prompt generated by the OLE2link. Figure 1 shows this prompt.
Figure 1: User prompt hidden by the Visual Basic script
Document 1 – (MD5: 5ebfd13250dd0408e3de594e419f9e01)
The first malicious document identified by FireEye had three stages.
An embedded OLE2 link object causes winword.exe to reach out to the
following URL to download the stage one malicious HTA file:
Once downloaded, the malicious HTA file is processed by the
“application/hta” handler. The highlighted line in Figure 2 shows the
first download occurring, followed by the additional malicious payloads.
Figure 2: Live attack scenario
Once downloaded, the template file was stored in the user’s
temporary internet files with the name template[?].hta, where [?] is
determined at run time.
The Logic Bug
Mshta.exe is responsible for handling the Content-Type
“application/hta,” parsing the content, and executing the script.
Figure 3 shows winword.exe querying registry value of CLSID for the
Figure 3: Winword query registry value
Winword.exe makes a request to the DCOMLaunch service, which in turn
causes the svchost.exe process hosting DCOMLaunch to execute
mshta.exe. Mshta.exe then executes the script embedded in the
malicious HTA document. Figure 4 shows the deobfuscated VBScript from
the first stage download.
Figure 4: First document, stage one VBScript
The script shown in Figure 4 performs the following malicious actions:
- Terminates the winword.exe process with taskkill.exe to hide
the prompt shown in Figure 1.
- Downloads a VBScript file
from http[:]//www.modani[.]com/media/wysiwyg/ww.vbs and saving it to
- Downloads a decoy
document from http[:]//www.modani[.]com/media/wysiwyg/questions.doc
and saving it to %temp%\document.doc
- Cleans up the Word
Resiliency keys for Word versions 15.0 and 16.0 so that Microsoft
Word will restart normally
- Executes the malicious stage two
the decoy document, %temp%\document.doc, to hide the malicious
activity from the user
Once executed, the downloaded stage two VBScript
(ww.vbs/maintenance.vbs) performs the following actions:
- Writes an embedded obfuscated script to
- Executes the script
The obfuscated eoobvfwiglhiliqougukgm.js script performs the
following actions when executed:
- Attempts to delete itself from the system
- Attempts to
download http[:]//www.modani[.]com/media/wysiwyg/wood.exe (at most
44 times), and save the file to
Figure 5 shows the process execution chain of events.
Figure 5: Process creation events
The final payload utilized in this malware is a newer variant of the
LATENTBOT malware family. Additional details of the updates to this
malware follow the Document 2 walkthrough.
Malicious HTA file
Stage two VBScript
Updated final payload
Table 1: First document file metadata
The LATENTBOT Payload
The payload associated with the first document is an updated version
of the LATENTBOT
malware family. LATENTBOT is a highly-obfuscated BOT that has
been in the wild since 2013.
The newer version of the LATENTBOT has different injection
mechanisms for Windows XP (x86) and Windows 7 operating systems:
Attrib.exe patching – The bot calls Attrib.exe, patches the
entry in memory, and inserts a JMP instruction to transfer control
to the mapped section. To map the section in the address space of
atrrib.exe it uses ZwMapViewOfSection().
Svchost code Injection – Attrib.exe starts the svchost.exe
process in suspended mode, creates space, and allocates code by
Control transfer – It then uses SetThreadContext() to modify
the OEP of the primary thread, which will be executed in the remote
process to trigger code execution.
Browser injection – A similar process is used to inject the
final payload into the default web browser with the help of
In Windows 7 or later operating systems, the bot does not use
attrib.exe. Rather, it injects code into svchost.exe followed by
launching the default browser with malicious payload by leveraging NtMapViewOfSection().
This variant then connects to the following command and control (C2) server:
Upon successful communication with the C2 server, LATENTBOT
generates a beacon. One of the decrypted beacons are as follows with
an updated version number of 5015:
At the time of analysis, the C2 server was offline. The bot comes
with a highly modular plugin architecture and has been associated with
the “Pony” campaigns as an infostealer.
As of April 10, 2017, the malware hosted at
www.modani[.]com/media/wysiwyg/wood.exe has been updated and the C2
server has been moved to: 217.12.203[.]100.
Document 2 – (MD5: C10DABB05A38EDD8A9A0DDDA1C9AF10E)
The second malicious document identified by FireEye consisted of two
malicious stages. The initial stage reached out to the following URL
to download the stage one malicious HTA file:
This file is downloaded into the user’s temporary internet files
directory with the name template[?].hta, where [?] is determined at
runtime. Once downloaded, winword.exe utilizes mshta.exe to parse the
file. mshta.exe parses through file finding <script>
</script> tags and executes the contained script. Figure 6 shows
the deobfuscated script.
Figure 6: Second document, first stage VBScript
Figure 6 shows the following malicious actions:
- Terminate the winword.exe process with taskkill.exe to hide
the prompt shown in Figure 1
- Download an executable from
http[:]//95.141.38[.]110/mo/dnr/copy.jpg, saving it to
- Download a document from
http[:]//95.141.38[.]110/mo/dnr/docu.doc, saving it to
- Clean up the Word Resiliency keys for
Word versions 15.0 and 16.0, so that Microsoft Word will restart
- Execute the malicious payload at
- Open the decoy document,
%temp%\document.doc, to hide the malicious activity from the
Examination of the malicious payload revealed that it is a variant
of the dropper for what Microsoft calls WingBird,
which has similar characteristics as FinFisher. The malware is heavily
obfuscated with several anti-analysis measures, including a custom VM
to slow analysis. A blog
post by “Artem” covers a payload driver of WingBird.
The blog author briefly mentions the protection techniques of the
dropper, which match this sample.
Malicious HTA file
Table 2: Second document metadata
FireEye observed CVE-2017-0199, a vulnerability in Microsoft Word
that allows an attacker to execute a malicious Visual Basic script.
The CVE-2017-0199 vulnerability is a logic bug and bypasses most
mitigations. Upon execution of the malicious script, it downloads and
executes malicious payloads, as well as displays decoy documents to
the user. The two documents achieve execution of their malicious
payloads, with one containing LATENTBOT and the other containing
WingBird/FinFisher. The malicious document contained only a link to
the attacker controlled server, showing the advantage of FireEye’s MVX
engine to detect multi-stage attacks. Further campaigns leveraging
this attack have been observed prior to patch availability, but are
not covered in this blog.
We recommend that Microsoft Office users apply the patch
as soon as possible.
Thank you to Michael Matonis, Dhanesh Kizhakkinan, Yogesh Londhe,
Swapnil Patil, Joshua Triplett, and Tyler Dean from FLARE Team,
FireEye Labs Team, and FireEye iSIGHT Intelligence for their
contributions to this blog. Thank you as well to everyone who worked
with us at the Microsoft Security Response Center (MSRC).
FireEye recently detected malicious Microsoft Office RTF documents
that leverage a previously undisclosed vulnerability. This
vulnerability allows a malicious actor to execute a Visual Basic
script when the user opens a document containing an embedded exploit.
FireEye has observed several Office documents exploiting the
vulnerability that download and execute malware payloads from
different well-known malware families.
FireEye shared the details of the vulnerability with Microsoft and
has been coordinating for several weeks public disclosure timed with
the release of a patch by Microsoft to address the vulnerability.
After recent public disclosure by another company, this blog serves to
acknowledge FireEye’s awareness and coverage of these attacks.
FireEye email and network products detect the malicious documents
The attack involves a threat actor emailing a Microsoft Word
document to a targeted user with an embedded OLE2link object. When the
user opens the document, winword.exe issues a HTTP request to a remote
server to retrieve a malicious .hta file, which appears as a fake RTF
file. The Microsoft HTA application loads and executes the malicious
script. In both observed documents the malicious script terminated the
winword.exe process, downloaded additional payload(s), and loaded a
decoy document for the user to see. The original winword.exe process
is terminated in order to hide a user prompt generated by the OLE2link.
The vulnerability is bypassing most mitigations; however, as noted
above, FireEye email and network products detect the malicious
documents. Microsoft Office users are recommended to apply the patch
as soon as it is available.
FLARE Team, FireEye Labs Team, FireEye iSIGHT Intelligence, and
Microsoft Security Response Center (MSRC).
Sony Playstation 4 (PS4) 3.50