Metamorfo Campaigns Targeting Brazilian Users

FireEye Labs recently identified several widespread malspam (malware
spam) campaigns targeting Brazilian companies with the goal of
delivering banking Trojans. We are referring to these campaigns as
Metamorfo. Across the stages of these campaigns, we have observed the
use of several tactics and techniques to evade detection and deliver
the malicious payload. In this blog post we dissect two of the main
campaigns and explain how they work.

Campaign #1

The kill chain starts with an email containing an HTML attachment
with a refresh tag that uses a Google URL shortener as the
target. Figure 1 shows a sample email, and Figure 2 show the contents
of the HTML file.

Figure 1: Malicious Email with HTML Attachment

Figure 2: Contents of HTML File

When the URL is loaded, it redirects the victim to a cloud storage
site such as GitHub, Dropbox, or Google Drive to download a ZIP
file. An example is shown in Figure 3.

Figure 3: URL Shortener Redirects to
Github Link

The ZIP archive contains a malicious portable executable (PE) file
with embedded HTML application (HTA). The user has to unzip the
archive and double-click the executable for the infection chain to
continue. The PE file is a simple HTA script compiled into an
executable. When the user double-clicks the executable, the malicious
HTA file is extracted to %temp% and executed by mshta.exe.

The HTA script (Figure 4) contains VBS code that fetches a second
blob of VBS code encoded in base64 form from hxxp:///ilha/pz/logs.php.

Figure 4: Contents of HTA File

After the second stage of VBS is decoded (Figure 5 and Figure 6),
the script downloads the final stage from hxxp:///28022018/

Figure 5: Contents of Decoded VBS

Figure 6: More Contents of Decoded VBS

The downloaded ZIP file contains four files. Two are PE files. One
is a legitimate Windows tool, pvk2pfx.exe, that is abused
for DLL side-loading. One is the malicious banking Trojan as the DLL.

The VBS code unzips the archive, changes the extension of the
legitimate Windows tool from .png to .exe, and renames the malicious
DLL as cryptui.dll. The VBS code also creates a file in
C:UsersPublicAdministradorcar.dat with random strings. These
random strings are used to name the Windows tool, which is then
executed. Since this tool depends on a legitimate DLL named
cryptui.dll, the search order path will find the malicious Trojan with
the same name in the same directory and load it into its process space.

In Q4 of 2017, a similar malspam campaign delivered the same banking
Trojan by using an embedded JAR file attached in the email instead of
an HTML attachment. On execution, the Java code downloaded a ZIP
archive from a cloud file hosting site such as Google Drive, Dropbox,
or Github. The ZIP archive contained a legitimate Microsoft tool and
the malicious Trojan.

Banking Trojan Analysis

The Trojan expects to be located in the hardcoded directory
C:\Users\PublicAdministrador\ along with three other files to
start execution. As seen in Figure 7, these files are:

  • car.dat (randomly
    generated name given to Windows tool)
  • i4.dt (VBS script
    that downloads the same zip file)
  • id (ID given to
  • cryptui.dll (malicious Trojan)

Figure 7: Contents of ZIP Archive


The string found in the file
C:\Users\Public\Administrador\car.dat is extracted and used to add
the registry key
SoftwareMicrosoftWindowsCurrentVersionRun for persistence, as shown in Figure 8.

Figure 8: Reading from car.dat File

The sample also looks for a file named i4.dt in the same directory
and extracts the contents of it, renames the file to icone.vbs, and
creates a new persistent key (Figure 9) in
SoftwareMicrosoftWindowsCurrentVersionRun to open this file.

Figure 9: Persistence Keys

The VBS code in this file (Figure 10) has the ability to recreate
the whole chain and download the same ZIP archive.

Figure 10: Contents of VBS Script

Next, the Trojan searches for several folders in the Program Files
directories, including:

  • C:\Program
  • C:\Program Files\AVAST Software
  • C:\Program Files\Diebold\Warsaw
  • C:\Program
  • C:\Program Files\Java
  • C:\Program Files (x86)\scpbrad

If any of the folders are found, this information, along with the
hostname and Operating System version, is sent to a hardcoded domain
with the hardcoded User-Agent value “Mozilla/5.0 (Windows NT 6.1;
WOW64; rv:12.0) Gecko/20100101 Firefox/12.0” in the format shown in
Figure 11. The value of AT is “<host_name+OS&MD>=”.

Figure 11: Network Traffic for Host Enumeration

The sample iterates through the running processes, kills the
following, and prevents them from launching:

  • msconfig.exe
  • TASKMGR.exe
  • regedit.exe
  • ccleaner64.exe
  • taskmgr.exe
  • itauaplicativo.exe

Next, it uses GetForegroundWindow to get a handle to the window the
user is viewing and GetWindowText to extract the title of the window.
The title is compared against a hardcoded list of Brazilian banking
and digital coin sites. The list is extensive and includes major
organizations and smaller entities alike.

If any of those names are found and the browser is one of the
following, the Trojan will terminate that browser.

  • firefox.exe
  • chrome.exe
  • opera.exe
  • safari.exe

The folder C:UsersPublicAdministradorlogs is created to store
screenshots, as well as the number of mouse clicks the user has
triggered while browsing the banking sites (Figure 12). The
screenshots are continuously saved as .jpg images.

Figure 12: Malware Capturing Mouse Clicks

Command and Control

The command and control (C2) server is selected based on the string
in the file “id”:

  • al ->
  • gr -> ‘212.237.46[.]6’
  • pz
    -> ‘87.98.146[.]34’
  • mn -> ’80.211.140[.]235′

The connection to one of the hosts is then started over raw TCP on
port 9999. The command and control communication generally follows the
pattern <|Command |>, for example:

  • ‘<|dispida|>logs>SAVE<‘ sends the screenshots
    collected in gh.txt.
  • ” is sent from C2 to
    host, and ” is sent from host to C2, to keep the
    connection alive.
  • ‘<|INFO|>’ retrieves when the
    infection first started based on the file timestamp from car.dat
    along with ‘<|>’ and the host information.

There were only four possible IP addresses that the sample analyzed
could connect to based on the strings found in the file “id”. After
further researching the associated infrastructure of the C2 (Figure
13), we were able to find potential number of victims for this
particular campaign.

Figure 13: Command and Control Server Open Directories

Inside the open directories, we were able to get the following
directories corresponding to the different active campaigns. Inside
each directory we could find statistics with the number of victims
reporting to the C2. As of 3/27/2018, the numbers were:

  • al – 843
  • ap –
  • gr – 397
  • kk – 2,153
  • mn – 296
  • pz – 536
  • tm – 187

A diagram summarizing Campaign #1 is shown in Figure 14.

Figure 14: Infection Chain of Campaign #1

Campaign #2

In the second campaign, FireEye Labs observed emails with links to
legitimate domains (such as
or compromised domains (such
as hxxps://curetusu.-industria[.]site/) that use a
refresh tag with a URL shortener as the target.
The URL shortener redirects the user to an online storage site, such
as Google Drive, Github, or Dropbox, that hosts a malicious ZIP
file. A sample phishing email is shown in Figure 15.

Figure 15: Example Phishing Email

The ZIP file contains a malicious executable written in AutoIt
(contents of this executable are shown in Figur 16). When executed by
the user, it drops a VBS file to a randomly created and named
directory (such as C:mYPdrTkCJLQPXHwoCmYPdr.vbs) and fetches
contents from the C2 server.

Figure 16: Contents of Malicious AutoIt Executable

Two files are downloaded from the C2 server. One is a legitimate
Microsoft tool and the other is a malicious DLL:

  • https[:]//panel-dark[.]com/w3af/img2.jpg
  • https[:]//panel-dark[.]com/w3af/img1.jpg

Those files are downloaded and saved into random directories named
with the following patterns:

  • <5 random chars><8 random chars><4 random chars><5 random chars>.exe
  • <5 random chars><8 random chars><4 random chars>CRYPTUI.dll

The execution chain ensures that persistence is set on the affected
system using a .lnk file in the Startup directory. The .lnk file shown
in Figure 17 opens the malicious VBS dropped on the system.

Figure 17: Persistence Key

The VBS file (Figure 18) will launch and execute the downloaded
legitimate Windows tool, which in this case is Certmgr.exe. This tool
will be abused using the DLL side loading technique. The malicious
Cryptui.dll is loaded into the program instead of the legitimate one
and executed.

Figure 18: Contents of Dropped VBS File

Banking Trojan Analysis

Like the Trojan from the first campaign, this sample is executed
through search-order hijacking. In this case, the binary abused is a
legitimate Windows tool, Certmgr.exe, that loads Cryptui.dll. Since
this tool depends on a legitimate DLL named cryptui.dll, the search
order path will find the malicious Trojan with the same name in the
same directory and load it into its process space.

The malicious DLL exports 21 functions. Only DllEntryPoint contains
real code that is necessary to start the execution of the malicious
code. The other functions return hardcoded values that serve no real purpose.

On execution, the Trojan creates a mutex called
“correria24” to allow only one instance of it to run at a time.

The malware attempts to resolve “www.goole[.]com” (most likely a
misspelling). If successful, it sends a request to
hxxp://api-api[.]com/json in order to detect the external IP of the
victim. The result is parsed and execution continues only if the
country code matches “BR”, as shown in Figure 19.

Figure 19: Country Code Check

The malware creates an empty file in %appdata%Mariapeirura on first
execution, which serves as a mutex lock, before attempting to send any
collected information to the C2 server. This is done in order to get
only one report per infected host.

The malware collects host information, base64 encodes it, and sends
it to two C2 servers. The following items are gathered from the
infected system:

  • OS name
  • OS
  • OS architecture
  • AV installed
  • List
    of banking software installed
  • IP address
  • Directory
    where malware is being executed from

The information is sent to hxxp:// (Figure 20).

Figure 20: Host Recon Data Sent to First
C2 Server

The same information is sent to panel-dark[.]com/Contador/put.php
(Figure 21).

Figure 21: Host Recon Data Sent to Second
C2 Server

The malware alters the value of registry key
to 2710 in order to change the number of milliseconds a thumbnail is
showed while hovering on the taskbar, as seen in Figure 22.

Figure 22: ExtendedUIHoverTime Registry
Key Change

Like the Trojan from the first campaign, this sample checks if the
foreground window’s title contains names of Brazilian banks and
digital coins by looking for hardcoded strings.

The malware displays fake forms on top of the banking sites and
intercepts credentials from the victims. It can also display a fake
Windows Update whenever there is nefarious activity in the background,
as seen in Figure 23.

Figure 23: Fake Form Displaying Windows Update

The sample also contains a keylogger functionality, as shown in
Figure 24.

Figure 24: Keylogger Function

Command and Control

The Trojan’s command and control command structure is identical to
the first sample. The commands are denoted by the <|Command|> syntax.

  • <|OK|> gets a list
    of banking software installed on the host.

  • is sent from C2 to host, and ” is sent from host to C2,
    to keep connection alive.
  • <|dellLemb|> deletes the
    registry key SoftwareMicrosoftInternet Explorernotes.
  • EXECPROGAM calls ShellExecute to run the application given in
    the command.
  • EXITEWINDOWS calls ExitWindowsEx.
  • NOVOLEMBRETE creates and stores data sent with the command in
    the registry key SoftwareMicrosoftInternet Explorernotes.

Figure 25: Partial List of Victims

This sample contains most of the important strings encrypted. We
provide the following script (Figure 26) in order to decrypt them.

Figure 26: String Decryption Script


The use of multi-stage infection chains makes it challenging to
research these types of campaigns all the way through.

As demonstrated by our research, the attackers are using various
techniques to evade detection and infect unsuspecting
Portuguese-speaking users with banking Trojans. The use of public
cloud infrastructure to help deliver the different stages plays a
particularly big role in delivering the malicious payload. The use of
different infection methods combined with the abuse of legitimate
signed binaries to load malicious code makes these campaigns worth highlighting.

Indicators of Compromise

Campaign #1
MD5 860fa744d8c82859b41e00761c6e25f3 PE with Embedded HTA
MD5 3e9622d1a6d7b924cefe7d3458070d98 PE with Embedded HTA
MD5 f402a482fd96b0a583be2a265acd5e74 PE with Embedded HTA
MD5 f329107f795654bfc62374f8930d1e12 PE with Embedded HTA
MD5 789a021c051651dbc9e01c5d8c0ce129 PE with Embedded HTA
MD5 68f818fa156d45889f36aeca5dc75a81 PE with Embedded HTA
MD5 c2cc04be25f227b13bcb0b1d9811e2fe cryptui.dll
MD5 6d2cb9e726c9fac0fb36afc377be3aec id
MD5 dd73f749d40146b6c0d2759ba78b1764 i4.dt
MD5 d9d1e72165601012b9d959bd250997b3 VBS file with commands to create staging directories for
MD5 03e4f8327fbb6844e78fda7cdae2e8ad pvk2pfx.exe [Legit Windows Tool]
URL hxxp://
URL hxxp:// 
C2 ibamanetibamagovbr[.]org/virada/pz/logs.php
URL sistemasagriculturagov[.]org
URL hxxp://
Campaign #2
MD5 2999724b1aa19b8238d4217565e31c8e AutoIT Dropper
MD5 181c8f19f974ad8a84b8673d487bbf0d img1.jpg [lLegit Windows Tool]
MD5 d3f845c84a2bd8e3589a6fbf395fea06 img2.jpg [Banking Trojan]
MD5 2365fb50eeb6c4476218507008d9a00b Variants of Banking Trojan
MD5 d726b53461a4ec858925ed31cef15f1e Variants of Banking Trojan
MD5 a8b2b6e63daf4ca3e065d1751cac723b Variants of Banking Trojan
MD5 d9682356e78c3ebca4d001de760848b0 Variants of Banking Trojan
MD5 330721de2a76eed2b461f24bab7b7160 Variants of Banking Trojan
MD5 6734245beda04dcf5af3793c5d547923 Variants of Banking Trojan
MD5 a920b668079b2c1b502fdaee2dd2358f Variants of Banking Trojan
MD5 fe09217cc4119dedbe85d22ad23955a1 Variants of Banking Trojan
MD5 82e2c6b0b116855816497667553bdf11 Variants of Banking Trojan
MD5 4610cdd9d737ecfa1067ac30022d793b Variants of Banking Trojan
MD5 34a8dda75aea25d92cd66da53a718589 Variants of Banking Trojan
MD5 88b808d8164e709df2ca99f73ead2e16 Variants of Banking Trojan
MD5 d3f845c84a2bd8e3589a6fbf395fea06 Variants of Banking Trojan
MD5 28a0968163b6e6857471305aee5c17e9 Variants of Banking Trojan
MD5 1285205ae5dd5fa5544b3855b11b989d Variants of Banking Trojan
MD5 613563d7863b4f9f66590064b88164c8 Variants of Banking Trojan
MD5 3dd43e69f8d71fcc2704eb73c1ea7daf Variants of Banking Trojan
C2 https[:]//panel-dark[.]com/w3af/img2.jpg
C2 https[:]//panel-dark[.]com/w3af/img1.jpg

Go to Source
Author: Edson Sierra

SANNY Malware Delivery Method Updated in Recently Observed Attacks


In the third week of March 2018, through FireEye’s Dynamic Threat
Intelligence, FireEye discovered malicious macro-based Microsoft Word
documents distributing SANNY malware to multiple governments
worldwide. Each malicious document lure was crafted in regard to
relevant regional geopolitical issues. FireEye has tracked the SANNY
malware family since 2012 and believes that it is unique to a group
focused on Korean Peninsula issues. This group has consistently
targeted diplomatic entities worldwide, primarily using lure documents
written in English and Russian.

As part of these recently observed attacks, the threat actor has
made significant changes to their usual malware delivery method. The
attack is now carried out in multiple stages, with each stage being
downloaded from the attacker’s server. Command line evasion
techniques, the capability to infect systems running Windows 10, and
use of recent User Account Control (UAC) bypass techniques have also
been added.

Document Details

The following two documents, detailed below, have been observed in
the latest round of attacks:

MD5 hash: c538b2b2628bba25d68ad601e00ad150

Original Filename: РГНФ 2018-2019.doc

The document shown in Figure 1 discusses Eurasian geopolitics as
they relate to China, as well as Russia’s security.

Figure 1: Sample document written in Russian

MD5 hash: 7b0f14d8cd370625aeb8a6af66af28ac

Original Filename: Copy of communication from Security
Council Committee (1718).doc

The document shown in Figure 2 discusses sanctions on humanitarian
operations in the Democratic People’s Republic of Korea (DPRK).

Figure 2: Sample document written in English

Macro Analysis

In both documents, an embedded macro stores the malicious command
line to be executed in the TextBox property (TextBox1.Text) of the
document. This TextBox property is first accessed by the macro to
execute the command on the system and is then overwritten to delete
evidence of the command line.

Stage 1: BAT File Download

In Stage 1, the macro leverages the legitimate Microsoft Windows
certutil.exe utility to download an encoded Windows Batch (BAT) file
from the following URL: http://more.1apps[.]com/1.txt. The macro then
decodes the encoded file and drops it in the %temp% directory with the
name: 1.bat.

There were a few interesting observations in the command line:

  1. The macro copies the
    Microsoft Windows certutil.exe utility to the %temp% directory with
    the name: ct.exe. One of the reasons for this is to evade detection
    by security products. Recently, FireEye has observed other threat
    actors using certutil.exe for malicious purposes. By renaming
    “certutil.exe” before execution, the malware authors are attempting
    to evade simple file-name based heuristic detections.
  2. The
    malicious BAT file is stored as the contents of a fake PEM encoded
    SSL certificate (with the BEGIN and END markers) on the Stage 1 URL,
    as shown in Figure 3.  The “certutil.exe” utility is then leveraged
    to both strip the BEGIN/END markers and decode the Base64 contents
    of the file. FireEye has not previously observed the malware authors
    use this technique in past campaigns.

Figure 3: Malicious BAT file stored as an
encoded file to appear as an SSL certificate

BAT File Analysis

Once decoded and executed, the BAT file from Stage 1 will download
an encoded CAB file from the base URL: hxxp://more.1apps[.]com/. The
exact file name downloaded is based on the architecture of the
operating system.

  • For a 32-bit operating
    system: hxxp://more.1apps[.]com/2.txt
  • For a 64-bit
    operating system: hxxp://more.1apps[.]com/3.txt

Similarly, based on Windows operating system version and
architecture, the CAB file is installed using different techniques.
For Windows 10, the BAT file uses rundll32 to invoke the appropriate
function from update.dll (component inside

  • For a 32-bit operating
    system: rundll32 update.dll _EntryPoint@16
  • For a 64-bit
    operating system: rundll32 update.dll EntryPoint

For other versions of Windows, the CAB file is extracted using the
legitimate Windows Update Standalone Installer (wusa.exe) directly
into the system directory:

The BAT file also checks for the presence of Kaspersky Lab Antivirus
software on the machine. If found, CAB installation is changed
accordingly in an attempt to bypass detection:

Stage 2: CAB File Analysis

As described in the previous section, the BAT file will download the
CAB file based on the architecture of the underlying operating system.
The rest of the malicious activities are performed by the downloaded
CAB file.

The CAB file contains the following components:

  • install.bat – BAT file
    used to deploy and execute the components.
  • ipnet.dll – Main
    component that we refer to as SANNY malware.
  • ipnet.ini –
    Config file used by SANNY malware.
  • NTWDBLIB.dll – Performs
    UAC bypass on Windows 7 (32-bit and 64-bit).
  • update.dll –
    Performs UAC bypass on Windows 10.

install.bat will perform the following essential activities:

  1. Checks the current
    execution directory of the BAT file. If it is not the Windows system
    directory, then it will first copy the necessary components
    (ipnet.dll and ipnet.ini) to the Windows system directory before
    continuing execution:

  2. Hijacks a legitimate Windows system service,
    COMSysApp (COM+ System Application) by first stopping this service,
    and then modifying the appropriate Windows service registry keys to
    ensure that the malicious ipnet.dll will be loaded when the
    COMSysApp service is started:

  3. After the hijacked COMSysApp service is
    started, it will delete all remaining components of the CAB

ipnet.dll is the main component inside the CAB file that is used for
performing malicious activities. This DLL exports the following two functions:

  1. ServiceMain – Invoked
    when the hijacked system service, COMSysApp, is started.
  2. Post – Used to perform data exfiltration to the command and
    control (C2) server using FTP protocol.

The ServiceMain function first performs a check to see if it is
being run in the context of svchost.exe or rundll32.exe. If it is
being run in the context of svchost.exe, then it will first start the
system service before proceeding with the malicious activities. If it
is being run in the context of rundll32.exe, then it performs the
following activities:

  1. Deletes the module
    NTWDBLIB.DLL from the disk using the following command:

    cmd /c taskkill /im cliconfg.exe /f /t && del /f /q

  2. Sets the code page on the system
    to 65001, which corresponds to UTF-8:

    cmd /c REG ADD
    HKCUConsole /v CodePage /t REG_DWORD /d 65001 /f

Command and Control (C2) Communication

SANNY malware uses the FTP protocol as the C2 communication channel.

FTP Config File

The FTP configuration information used by SANNY malware is encoded
and stored inside ipnet.ini.

This file is Base64 encoded using the following custom character
set: SbVIn=BU/dqNP2kWw0oCrm9xaJ3tZX6OpFc7Asi4lvuhf-TjMLRQ5GKeEHYgD1yz8

Upon decoding the file, the following credentials can be recovered:

  • FTP Server:
  • Username: cnix_21072852
  • Password:

It then continues to perform the connection to the FTP server
decoded from the aforementioned config file, and sets the current
directory on the FTP server as “htdocs” using the
FtpSetCurrentDirectoryW function.

System Information Collection

For reconnaissance purposes, SANNY malware executes commands on the
system to collect information, which is sent to the C2 server.

System information is gathered from the machine using the following command:

The list of running tasks on the system is gathered by executing the
following command:

C2 Commands

After successful connection to the FTP server decoded from the
configuration file, the malware searches for a file containing the
substring “to everyone” in the “htdocs” directory. This file will
contain C2 commands to be executed by the malware.

Upon discovery of the file with the “to everyone” substring, the
malware will download the file and then performs actions based on the
following command names:

  • chip command: This
    command deletes the existing ipnet.ini configuration file from the
    file system and creates a new ipnet.ini file with a specified
    configuration string. The chip commands allows the attacker to
    migrate malware to a new FTP C2 server. The command has the
    following syntax:

  • pull command: This command is used for the
    purpose of data exfiltration. It has the ability to upload an
    arbitrary file from the local filesystem to the attacker’s FTP
    server. The command has the following syntax:

The uploaded file is compressed and
encrypted using the routine described later in the Compression and
Encoding Data section.

  • put command: This command
    is used to copy an existing file on the system to a new location and
    delete the file from the original location. The command has the
    following syntax:

  • default command: If the
    command begins with the substring “cmd /c”, but it is not followed
    by either of the previous commands (chip, pull, and put), then it
    directly executes the command on the machine using WinExec.
  • /user command: This
    command will execute a command on the system as the logged in user.
    The command duplicates the access token of “explorer.exe” and spawns
    a process using the following steps:

    1. Enumerates the running processes on the system to search for
      the explorer.exe process and obtain the process ID of
    2. Obtains the access token for the
      explorer.exe process with the access flags set to
    3. Starts the application (defined in the C2
      command) on the system by calling the CreateProcessAsUser
      function and using the access token obtained in Step 2.
C2 Command Purpose
chip Update the FTP server config file
pull Upload a file from the machine
put Copy an existing file to a new destination
/user Create a new process with explorer.exe access
default command Execute a program on the machine
using WinExec()

Compression and Encoding Data

SANNY malware uses an interesting mechanism for compressing the
contents of data collected from the system and encoding it before
exfiltration. Instead of using an archiving utility, the malware
leverages Shell.Application COM object and calls the CopyHere method
of the IShellDispatch interface to perform compression as follows:

  1. Creates an empty ZIP file
    with the name: in the %temp% directory.
  2. Writes the
    first 16 bytes of the PK header to the ZIP file.
  3. Calls the
    CopyHere method of IShellDispatch interface to compress the
    collected data and write to
  4. Reads the contents of to memory.
  5. Deletes from the disk.
  6. Creates an empty file, post.txt, in the %temp% directory.
  7. The file contents are Base64 encoded (using the same
    custom character set mentioned in the previous FTP Config File
    section) and written to the file: %temp%post.txt.
  8. Calls
    the FtpPutFileW function to write the contents of post.txt to the
    remote file with the format: “from

Execution on Windows 7 and User Account Control (UAC) Bypass

NTWDBLIB.dll – This component from the CAB file will be extracted to
the %windir%system32 directory. After this, the cliconfg command is
executed by the BAT file.

The purpose of this DLL module is to launch the install.bat file.
The file cliconfg.exe is a legitimate Windows binary (SQL Client
Configuration Utility), loads the library NTWDBLIB.dll upon execution.
Placing a malicious copy of NTWDBLIB.dll in the same directory as
cliconfg.exe is a technique known as DLL side-loading, and results in
a UAC bypass.

Execution on Windows 10 and UAC Bypass

Update.dll – This component from the CAB file is used to perform UAC
bypass on Windows 10. As described in the BAT File Analysis section,
if the underlying operating system is Windows 10, then it uses
update.dll to begin the execution of code instead of invoking the
install.bat file directly.

The main actions performed by update.dll are as follows:

  1. Executes the following
    commands to setup the Windows registry for UAC bypass:

  2. Leverages a UAC
    bypass technique
    that uses the legitimate Windows binary,
    fodhelper.exe, to perform the UAC bypass on Windows 10 so that the
    install.bat file is executed with elevated privileges:

  3. Creates an additional BAT file, kill.bat, in
    the current directory to delete evidence of the UAC bypass. The BAT
    file kills the current process and deletes the components update.dll
    and kill.bat from the file system:


This activity shows us that the threat actors using SANNY malware
are evolving their malware delivery methods, notably by incorporating
UAC bypasses and endpoint evasion techniques. By using a multi-stage
attack with a modular architecture, the malware authors increase the
difficulty of reverse engineering and potentially evade security solutions.

Users can protect themselves from such attacks by disabling Office
macros in their settings and practicing vigilance when enabling macros
(especially when prompted) in documents, even if such documents are
from seemingly trusted sources.

Indicators of Compromise

SHA256 Hash Original Filename
b0f30741a2449f4d8d5ffe4b029a6d3959775818bf2e85bab7fea29bd5acafa4 РГНФ 2018-2019.doc
e29fad201feba8bd9385893d3c3db42bba094483a51d17e0217ceb7d3a7c08f1 Copy of
communication from Security Council Committee (1718).doc
eb394523df31fc83aefa402f8015c4a46f534c0a1f224151c47e80513ceea46f 1.bat
a2e897c03f313a097dc0f3c5245071fbaeee316cfb3f07785932605046697170 (64-bit)
a3b2c4746f471b4eabc3d91e2d0547c6f3e7a10a92ce119d92fa70a6d7d3a113 (32-bit)

Go to Source
Author: Sudeep Singh

Fake Software Update Abuses NetSupport Remote Access Tool

Over the last few months, FireEye has tracked an in-the-wild campaign
that leverages compromised sites to spread fake updates. In some
cases, the payload was the NetSupport Manager remote access tool
(RAT). NetSupport Manager is a commercially available RAT that can be
used legitimately by system administrators for remotely accessing
client computers. However, malicious actors are abusing this
application by installing it to the victims’ systems without their
knowledge to gain unauthorized access to their machines. This blog
details our analysis of the JavaScript and components used in
instances where the identified payload was NetSupport RAT.

Infection Vector

The operator behind these campaigns uses compromised sites to spread
fake updates masquerading as Adobe Flash, Chrome, and FireFox updates.
When users navigate to the compromised website, the malicious
JavaScript file is downloaded, mostly from a DropBox link. Before
delivering the payload, the JavaScript sends basic system information
to the server. After receiving further commands from the server, it
then executes the final JavaScript to deliver the final payload. In
our case, the JavaScript that delivers the payload is named Update.js,
and it is executed from %AppData% with the help of wscript.exe. Figure
1 shows the infection flow.

Figure 1: Infection Flow

In-Depth Analysis of JavaScript

The initial JavaScript file contains multiple layers of obfuscation.
Like other malicious scripts, the first layer has obfuscation that
builds and executes the second layer as a new function. The second
layer of the JavaScript contains the dec function, which is
used to decrypt and execute more JavaScript code. Figure 2 shows a
snapshot of the second layer.

Figure 2: Second Layer of Initial
JavaScript File

In the second JavaScript file, the malware author uses a tricky
method to make the analysis harder for reverse engineers. The author
uses the caller and callee function code to get the key
for decryption. During normal JavaScript analysis, if an analyst finds
any obfuscated script, the analyst tries to de-obfuscate or beautify
the script for analysis. JavaScript beautification tools generally add
line breaks and tabs to make the script code look better and easier to
analyze. The tools also try to rename the local variables and remove
unreferenced variables and code from the script, which helps to
analyze core code only.

But in this case, since the malware uses the caller and
callee function code to derive the key, if the analyst adds or
removes anything from the first or second layer script, the script
will not be able to retrieve the key and will terminate with an
exception. The code snippet in Figure 3 shows this trick.

Figure 3: Anti-Analysis Trick Implemented
in JavaScript (Beautified Code)

The code decrypts and executes the JavaScript code as a function.
This decrypted function contains code that initiates the network
connection. In the decoded function, the command and control (C2) URL
and a value named tid are hard-coded in the script and
protected with some encoded function.

During its first communication to the server, the malware sends the
tid value and the current date of the system in encoded format,
and waits for the response from the server. It decodes the server
response and executes the response as a function, as shown in Figure 4.

Figure 4: Initial Server Communication
and Response

The response from the server is JavaScript code that the malware
executes as a function named step2.

The step2 function uses WScript.Network and Windows Management
Instrumentation(WMI) to collect the following system information,
which it then encodes and sends to the server:

Architecture, ComputerName, UserName, Processors, OS, Domain,
Manufacturer, Model, BIOS_Version, AntiSpywareProduct,
AntiVirusProduct, MACAddress, Keyboard, PointingDevice,
DisplayControllerConfiguration, ProcessList;

After sending the system information to the server, the response
from the server contains two parts: content2 and content3.

The script (step2 function) decodes both parts. The
decoded content3 part contains the function named as
step3, as shown in Figure 5.

Figure 5: Decrypting and Executing
Response step3

The step3 function contains code that writes decoded
content2 into a %temp% directory as Update.js. Update.js
contains code to download and execute the final payload. The
step3 function also sends the resulting data, such as
runFileResult and _tempFilePath, to the server, as shown
in Figure 6.

Figure 6: Script to Drop and Execute Update.js

The Update.js file also contains multi-layer obfuscation. After
decoding, the JavaScript contains code to drop multiple files in
%AppData%, including a 7zip standalone executable (7za.exe),
password-protected archive (Loglist.rtf), and batch script (Upd.cmd).
We will talk more about these components later.

JavaScript uses PowerShell commands to download the files from the
server. It sets the attribute’s execution policy to bypass and
window-style to hidden to hide itself from the end user.

Components of the Attack

Figure 7 shows the index of the malicious server where we have
observed the malware author updating the script content.

Figure 7: Index of Malicious Server

  • 7za.exe: 7zip standalone
  • LogList.rtf: Password-protected archive file
  • Upd.cmd: Batch script to install the NetSupport Client
  • Downloads.txt: List of IPs (possibly the infected systems)
  • Get.php: Downloads LogList.rtf

This file is a batch script that extracts the archive file and
installs the remote control tool on the system. The script is
obfuscated with the variable substitution method. This file was
regularly updated by the malware during our analysis.

After de-obfuscating the script, we can see the batch commands in
the script (Figure 8).

Figure 8: De-Obfuscated Upd.cmd Script

The script performs the following tasks:

  1. Extract the archive using
    the 7zip executable with the password mentioned in the script.
  2. After extraction, delete the downloaded archive file
  3. Disable Windows Error Reporting and App
  4. Add the remote control client executable to
    the firewall’s allowed program list.
  5. Run remote control
    tool (client32.exe).
  6. Add Run registry entry with the name
    “ManifestStore” or downloads shortcut file to Startup folder.
  7. Hide the files using attributes.
  8. Delete all the
    artifacts (7zip executable, script, archive file).

Note: While analyzing the script, we found some typos in the
script (Figure 9). Yes, malware authors make mistakes too. This script
might be in beta phase. In the later version of script, the author has
removed these typos.

Figure 9: Registry Entry Bloopers

Artifact Cleaning

As mentioned, the script contains code to remove the artifacts used
in the attack from the victim’s system. While monitoring the server,
we also observed some change in the script related to this code, as
shown in Figure 10.

Figure 10: Artifact Cleaning Commands

The highlighted command in one of the variants indicates that it
might drop or use this file in the attack. The file could be a decoy document.

Persistence Mechanism

During our analysis, we observed two variants of this attack with
different persistence mechanisms.

In the first variant, the malware author uses a RUN registry entry
to remain persistent in the system.

In the second variant, the malware author uses the shortcut file
(named desktop.ini.lnk), which is hosted on the server. It
downloads the shortcut file and places it into the Startup folder, as
shown in Figure 11.

Figure 11: Downloading Shortcut File

The target command for the shortcut file points to the remote
application “client32.exe,” which was dropped in %AppData%, to start
the application on startup.


Although the file extension is .rtf, the file is actually a 7zipped
archive. This archive file is password-protected and contains the
NetSupport Manager RAT. The script upd.cmd contains the password to
extract the archive.

The major features provided by the NetSupport tool include:

  • Remote desktop
  • File transfer
  • Remote inventory and system
  • Launching applications in client’s
  • Geolocation

This file contains a list of IP addresses, which could be
compromised systems. It has IPs along with User-agent. The IP
addresses in the file belong to various regions, mostly the U.S.,
Germany, and the Netherlands.


RATs are widely used for legitimate purposes, often by system
administrators. However, since they are legitimate applications and
readily available, malware authors can easily abuse them and sometimes
can avoid user suspicion as well.

The FireEye HX Endpoint platform successfully detects this attack at
the initial phase of the attack cycle.


Thanks to my colleagues Dileep Kumar Jallepalli, Rakesh Sharma and
Kimberly Goody for their help in the analysis.

Indicators of Compromise

Registry entries

:  ManifestStore

















Shortcut file

%AppData%RoamingMicrosoftWindowsStart MenuProgramsStartupdesktop.ini.lnk

Firewall program entry allowing the following application


Running process named “client32.exe” from the path “%AppData%ManifestStoreclient32.exe”


The following hashes are JavaScript files that use the same
obfuscation techniques described in the blog:























Go to Source
Author: Sudhanshu Dubey

Suspected Chinese Cyber Espionage Group (TEMP.Periscope) Targeting U.S.Engineering and Maritime Industries

Intrusions Focus on the Engineering and Maritime Sector

Since early 2018, FireEye (including our FireEye as a Service
(FaaS), Mandiant Consulting, and iSIGHT Intelligence teams) has been
tracking an ongoing wave of intrusions targeting engineering and
maritime entities, especially those connected to South China Sea
issues. The campaign is linked to a group of suspected Chinese cyber
espionage actors we have tracked since 2013, dubbed TEMP.Periscope.
The group has also been reported as “Leviathan
by other security firms.

The current campaign is a sharp escalation of detected activity
since summer 2017. Like multiple other Chinese cyber espionage actors,
TEMP.Periscope has recently re-emerged and has been observed
conducting operations with a revised toolkit. Known targets of this
group have been involved in the maritime industry, as well as
engineering-focused entities, and include research institutes,
academic organizations, and private firms in the United States.
FireEye products have robust detection for the malware used in this campaign.

TEMP.Periscope Background

Active since at least 2013, TEMP.Periscope has primarily focused on
maritime-related targets across multiple verticals, including
engineering firms, shipping and transportation, manufacturing,
defense, government offices, and research universities. However, the
group has also targeted professional/consulting services, high-tech
industry, healthcare, and media/publishing. Identified victims were
mostly found in the United States, although organizations in Europe
and at least one in Hong Kong have also been affected. TEMP.Periscope
overlaps in targeting, as well as tactics, techniques, and procedures
(TTPs), with TEMP.Jumper, a group that also overlaps significantly
with public reporting on “NanHaiShu.”

TTPs and Malware Used

In their recent spike in activity, TEMP.Periscope has leveraged a
relatively large library of malware shared with multiple other
suspected Chinese groups. These tools include:

    JavaScript-based backdoor also reported as “Orz” that retrieves
    commands from hidden strings in compromised webpages and actor
    controlled profiles on legitimate services.
    backdoor that is capable of modifying the file system, generating a
    reverse shell, and modifying its command and control (C2)
  • PHOTO: a DLL backdoor also reported publicly
    as “Derusbi”, capable of obtaining directory, file, and drive
    listing; creating a reverse shell; performing screen captures;
    recording video and audio; listing, terminating, and creating
    processes; enumerating, starting, and deleting registry keys and
    values; logging keystrokes, returning usernames and passwords from
    protected storage; and renaming, deleting, copying, moving, reading,
    and writing to files.
  • HOMEFRY: a 64-bit Windows password
    dumper/cracker that has previously been used in conjunction with
    AIRBREAK and BADFLICK backdoors. Some strings are obfuscated with
    XOR x56. The malware accepts up to two arguments at the command
    line: one to display cleartext credentials for each login session,
    and a second to display cleartext credentials, NTLM hashes, and
    malware version for each login session.
    uploader that can exfiltrate files to Dropbox.
    command-line reconnaissance tool. It can be used to execute files as
    a different user, move, and delete files locally, schedule remote AT
    jobs, perform host discovery on connected networks, scan for open
    ports on hosts in a connected network, and retrieve information
    about the OS, users, groups, and shares on remote hosts.
  • China Chopper: a simple code injection webshell that executes
    Microsoft .NET code within HTTP POST commands. This allows the shell
    to upload and download files, execute applications with web server
    account permissions, list directory contents, access Active
    Directory, access databases, and any other action allowed by the
    .NET runtime.

The following are tools that TEMP.Periscope has leveraged in past
operations and could use again, though these have not been seen in the
current wave of activity:

  • Beacon: a backdoor that
    is commercially available as part of the Cobalt Strike software
    platform, commonly used for pen-testing network environments. The
    malware supports several capabilities, such as injecting and
    executing arbitrary code, uploading and downloading files, and
    executing shell commands.
    a backdoor that obfuscates its communications as normal traffic to
    legitimate websites such as Github and Microsoft’s Technet portal.
    Used by APT17 and
    other Chinese cyber espionage operators.

Additional identifying TTPs include:

  • Spear phishing, including
    the use of probably compromised email accounts.
  • Lure
    documents using CVE-2017-11882 to drop malware.
  • Stolen code
    signing certificates used to sign malware.
  • Use of
    bitsadmin.exe to download additional tools.
  • Use of
    PowerShell to download additional tools.
  • Using
    C:WindowsDebug and C:Perflogs as staging directories.
  • Leveraging Hyperhost VPS and Proton VPN exit nodes to access
    webshells on internet-facing systems.
  • Using Windows
    Management Instrumentation (WMI)
    for persistence
  • Using Windows Shortcut files (.lnk)
    in the Startup folder that invoke the Windows Scripting Host
    (wscript.exe) to execute a Jscript backdoor for persistence.
  • Receiving C2 instructions from user profiles created by the
    adversary on legitimate websites/forums such as Github and
    Microsoft’s TechNet portal.


The current wave of identified intrusions is consistent with
TEMP.Periscope and likely reflects a concerted effort to target
sectors that may yield information that could provide an economic
advantage, research and development data, intellectual property, or an
edge in commercial negotiations.

As we continue to investigate this activity, we may identify
additional data leading to greater analytical confidence linking the
operation to TEMP.Periscope or other known threat actors, as well as
previously unknown campaigns.


x.js 3fefa55daeb167931975c22df3eca20a HOMEFRY, a 64-bit Windows password
mt.exe 40528e368d323db0ac5c3f5e1efe4889 MURKYTOP, a command-line
reconnaissance tool
com4.js a68bf5fce22e7f1d6f999b7a580ae477 AIRBREAK, a JavaScript-based
backdoor which retrieves commands from hidden strings in
compromised webpages

Historical Indicators

green.ddd 3eb6f85ac046a96204096ab65bbd3e7e AIRBREAK, a JavaScript-based
backdoor which retrieves commands from hidden strings in
compromised webpages
BGij 6e843ef4856336fe3ef4ed27a4c792b1 Beacon, a commercially available
msresamn.ttf a9e7539c1ebe857bae6efceefaa9dd16 PHOTO, also reported as
1024-aa6a121f98330df2edee6c4391df21ff43a33604 bd9e4c82bf12c4e7a58221fc52fed705 BADFLICK, backdoor that is capable
of modifying the file system, generating a reverse shell, and
modifying its command-and-control configuration

Go to Source
Author: FireEye

Iranian Threat Group Updates Tactics, Techniques and Procedures in SpearPhishing Campaign


From January 2018 to March 2018, through FireEye’s Dynamic Threat
Intelligence, we observed attackers leveraging the latest code
execution and persistence techniques to distribute malicious
macro-based documents to individuals in Asia and the Middle East.

We attribute this activity to TEMP.Zagros, an Iran-nexus actor that
has been active since at least May 2017. This actor has engaged in
prolific spear phishing of government and defense entities in Central
and Southwest Asia. The spear phishing emails and attached malicious
macro documents typically have geopolitical themes. When successfully
executed, the malicious documents install a backdoor we track as POWERSTATS.

One of the more interesting observations during the analysis of
these files was the re-use of the latest AppLocker bypass, and lateral
movement techniques for the purpose of indirect code execution. The IP
address in the lateral movement techniques was substituted with the
local machine IP address to achieve code execution on the system.

Campaign Timeline

In this campaign, the threat actor’s tactics, techniques and
procedures (TTPs) shifted after about a month, as did their targets. A
brief timeline of this activity is shown in Figure 1.

Figure 1: Timeline of this recently
observed spear phishing campaign

The first part of the campaign (From Jan. 23, 2018, to Feb. 26,
2018) used a macro-based document that dropped a VBS file and an INI
file. The INI file contains the Base64 encoded PowerShell command,
which will be decoded and executed by PowerShell using the command
line generated by the VBS file on execution using WScript.exe. The
process chain is shown in Figure 2.

Figure 2: Process chain for the first
part of the campaign

Although the actual VBS script changed from sample to sample, with
different levels of obfuscation and different ways of invoking the
next stage of process tree, its final purpose remained same: invoking
PowerShell to decode the Base64 encoded PowerShell command in the INI
file that was dropped earlier by the macro, and executing it. One such
example of the VBS invoking PowerShell via MSHTA is shown in Figure 3.

Figure 3: VBS invoking PowerShell via MSHTA

The second part of the campaign (from Feb. 27, 2018, to March 5,
2018) used a new variant of the macro that does not use VBS for
PowerShell code execution. Instead, it uses one of the recently
disclosed code execution techniques leveraging INF and SCT files,
which we will go on to explain later in the blog.

Infection Vector

We believe the infection vector for all of the attacks involved in
this campaign are macro-based documents sent as an email attachment.
One such email that we were able to obtain was targeting users in
Turkey, as shown in Figure 4:

Figure 4: Sample spear phishing email
containing macro-based document attachment

The malicious Microsoft Office attachments that we observed appear
to have been specially crafted for individuals in four countries:
Turkey, Pakistan, Tajikistan and India. What follows is four examples,
and a complete list is available in the Indicators of Compromise
section at the end of the blog.

Figure 5 shows a document purporting to be from the National
Assembly of Pakistan.

Figure 5: Document purporting to be from
the National Assembly of Pakistan

A document purporting to be from the Turkish Armed Forces, with
content written in the Turkish language, is shown in Figure 6.

Figure 6: Document purporting to be from
the Turkish Armed Forces

A document purporting to be from the Institute for Development and
Research in Banking Technology (established by the Reserve Bank of
India) is shown in Figure 7.

Figure 7: Document purporting to be from
the Institute for Development and Research in Banking Technology

Figure 8 shows a document written in Tajik that purports to be from
the Ministry of Internal Affairs of the Republic of Tajikistan.

Figure 8: Document written in Tajik that
purports to be from the Ministry of Internal Affairs of the Republic
of Tajikistan

Each of these macro-based documents used similar techniques for code
execution, persistence and communication with the command and control
(C2) server.

Indirect Code Execution Through INF and SCT

This scriptlet
code execution technique
leveraging INF and SCT files was
recently discovered and documented in February 2018. The threat group
in this recently observed campaign – TEMP.Zagros – weaponized their
malware using the following techniques.

The macro in the Word document drops three files in a hard coded
path: C:programdata. Since the path is hard coded, the execution will
only be observed in operating systems, Windows 7 and above. The
following are the three files:

  • Defender.sct – The malicious JavaScript based scriptlet
  • DefenderService.inf – The INF file that is used to
    invoke the above scriptlet file.
  • WindowsDefender.ini – The Base64 encoded and obfuscated
    PowerShell script.

After dropping the three files, the macro will set the following
registry key to achieve persistence:

= cmstp.exe /s c:programdataDefenderService.inf

Upon system restart, cmstp.exe will be used to execute the SCT file
indirectly through the INF file. This is possible because inside the
INF file we have the following section:


That section gets indirectly invoked through the
DefaultInstall_SingleUser section of INF, as shown in Figure 9.

Figure 9: Indirectly invoking SCT through
the DefaultInstall_SingleUser section of INF

This method of code execution is performed in an attempt to evade
security products. FireEye MVX and HX Endpoint Security technology
successfully detect this code execution technique.

SCT File Analysis

The code of the Defender.sct file is an obfuscated JavaScript. The
main function performed by the SCT file is to Base64 decode the
contents of WindowsDefender.ini file and execute the decoded
PowerShell Script using the following command line:

powershell.exe -exec Bypass -c
iex([System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String((get-content C:\ProgramData\WindowsDefender.ini)

The rest of the malicious activities are performed by the PowerShell Script.

PowerShell File Analysis

The PowerShell script employs several layers of obfuscation to hide
its actual functionality. In addition to obfuscation techniques, it
also has the ability to detect security tools on the analysis machine,
and can also shut down the system if it detects the presence of such tools.

Some of the key obfuscation techniques used are:

  • Character Replacement: Several instances of character
    replacement and string reversing techniques (Figure 10) make
    analysis difficult.

Figure 10: Character replacement and
string reversing techniques

  • PowerShell Environment Variables: Nowadays, malware authors
    commonly mask critical strings such as “IEX” using environment
    variables. Some of the instances used in this script are:

    • $eNv:puBLic[13]+$ENv:pUBLIc[5]+’x’
    • ($ENV:cOMsPEC[4,26,25]-jOin”)
  • XOR encoding: The biggest section of the PowerShell script is
    XOR encoded using a single byte key, as shown in Figure 11.

Figure 11: PowerShell script is XOR
encoded using a single byte key

After deobfuscating the contents of the PowerShell Script, we can
divide it into three sections.

Section 1

The first section of the PowerShell script is responsible for
setting different key variables that are used by the remaining
sections of the PowerShell script, especially the following variables:

  • TEMpPAtH =
    “C:ProgramData” (the path used for storing the temp
  • Get_vAlIdIP = (used to
    get the public IP address of the machine)
    WindowsDefender.ini (file used to store Powershell code)
  • PRIVAtE = Private Key exponents
  • PUbLIc = Public Key
  • Hklm = “HKLM:Software”
  • Hkcu =
  • ValuE =
  • DrAGon_MidDLe = [array
    of proxy URLs]

Among those variables, there is one variable of particular interest,
DrAGon_MidDLe, which stores the list of proxy URLs (detailed at
the end of the blog in the Network Indicators portion of the
Indicators of Compromise section) that will be used to interact with
the C2 server, as shown in Figure 12.

Figure 12: DrAGon_MidDLe stores the list
of proxy URLs used to interact with C2 server

Section 2

The second section of the PowerShell script has the ability to
perform encryption and decryption of messages that are exchanged
between the system and the C2 server. The algorithm used for
encryption and decryption is RSA, which leverages the public and
private key exponents included in Section 1 of the PowerShell script.

Section 3

The third section of the PowerShell script is the biggest section
and has a wide variety of functionalities.

During analysis, we observed a code section where a message written
in Chinese and hard coded in the script will be printed in the case of
an error while connecting to the C2 server:

The English translation for this message is: “Cannot connect to
website, please wait for dragon”.

Other functionalities provided by this section of the PowerShell
Script are as follows:

  • Retrieves the following
    data from the system by leveraging Windows Management
    Instrumentation (WMI) queries and environment variables:

    • IP
      Address from Network Adapter Configuration
    • OS Name
    • OS Architecture
    • Computer Name
    • Computer
      Domain Name
    • Username

All of this data is concatenated and
formatted as shown in Figure 13:

Figure 13: Concatenated and formatted
data retrieved by PowerShell script

  • Register the victim’s
    machine to the C2 server by sending the REGISTER command to the
    server. In response, if the status is OK, then a TOKEN is received
    from the C2 server that is used to synchronize the activities
    between the victim’s machine and the C2 server.

While sending to the C2 server, the
data is formatted as follows:

@{SYSINFO  = $get.ToString(); ACTION = “REGISTER”;}

  • Ability to take
  • Checks for the presence
    of security tools (detailed in the Appendix) and if any of these
    security tools are discovered, then the system will be shut down, as
    shown in Figure 14.

Figure 14: System shut down upon
discovery of security tools

  • Ability to receive
    PowerShell script from the C2 server and execute on the machine.
    Several techniques are employed for executing the PowerShell

    • If command starts with “excel”, then it leverages
      DDEInitiate Method of Excel.Appilcation to execute the
    • If the command starts with “outlook”, then it leverages
      Outlook.Application and MSHTA to execute the code: 
    • If the command starts with “risk”, then execution is
      performed through DCOM object: 
  • File upload
  • Ability to disable
    Microsoft Office Protected View (as shown in Figure 15) by setting
    the following keys in the Windows Registry:

    • DisableAttachmentsInPV
    • DisableInternetFilesInPV
    • DisableUnsafeLocationsInPV

Figure 15: Disabling Microsoft Office
Protected View

  • Ability to remotely
    reboot or shut down or clean the system based on the command
    received from the C2 server, as shown in Figure 16.

Figure 16: Reboot, shut down and clean commands

  • Ability to sleep for a
    given number of seconds.

The following table summarizes the main C2 commands supported by
this PowerShell Script.

C2 Command Purpose
reboot Reboot the system using shutdown command
shutdown Shut down the system using shutdown
clean Wipe the Drives, C:, D:, E:, F:
screenshot Take a screenshot of the System
upload Encrypt and upload the information from the
excel Leverage Excel.Application COM object for code
outlook Leverage Outlook.Application COM object for
code execution
risk Leverage DCOM object for code execution


This activity shows us that TEMP.Zagros stays up-to-date with the
latest code execution and persistence mechanism techniques, and that
they can quickly leverage these techniques to update their malware. By
combining multiple layers of obfuscation, they deter the process of
reverse engineering and also attempt to evade security products.

Users can protect themselves from such attacks by disabling Office
macros in their settings and also by being more vigilant when enabling
macros (especially when prompted) in documents, even if such documents
are from seemingly trusted sources.

Indicators of Compromise

Macro based Documents and Hashes
SHA256 Hash Filename Targeted Region
eff78c23790ee834f773569b52cddb01dc3c4dd9660f5a476af044ef6fe73894 na.doc


76e9988dad0278998861717c774227bf94112db548946ef617bfaa262cb5e338 Invest in Turkey.doc Turkey
6edc067fc2301d7a972a654b3a07398d9c8cbe7bb38d1165b80ba4a13805e5ac güvenlik yönergesi. .doc Turkey
009cc0f34f60467552ef79c3892c501043c972be55fe936efb30584975d45ec0 idrbt.doc


18479a93fc2d5acd7d71d596f27a5834b2b236b44219bb08f6ca06cf760b74f6 Türkiye Cumhuriyeti Kimlik
3da24cd3af9a383b731ce178b03c68a813ab30f4c7c8dfbc823a32816b9406fb Turkish Armed Forces.doc




3b1d8dcbc8072b1ec10f5300c3ea9bb20db71bd8fa443d97332790b74584a115 MVD-FORM-1800.doc Tajikistan
cee801b7a901eb69cd166325ed3770daffcd9edd8113a961a94c8b9ddf318c88 KEGM-CyberAttack.doc Turkey
1ee9649a2f9b2c8e0df318519e2f8b4641fd790a118445d7a0c0b3c02b1ba942 IL-1801.doc Turkey
aa60c1fae6a0ef3b9863f710e46f0a7407cf0feffa240b9a4661a4e8884ac627 kiyiemniyeti.doc Turkey
93745a6605a77f149471b41bd9027390c91373558f62058a7333eb72a26faf84 TCELL-S1-M.doc Tajikistan
c87799cce6d65158da97aa31a5160a0a6b6dd5a89dea312604cc66ed5e976cc9 egm-1.doc Turkey
2cea0b740f338c513a6390e7951ff3371f44c7c928abf14675b49358a03a5d13 Connectel .pk.doc Pakistan
18cf5795c2208d330bd297c18445a9e25238dd7f28a1a6ef55e2a9239f5748cd gßvenlik_yÜnergesi_.doc Turkey
153117aa54492ca955b540ac0a8c21c1be98e9f7dd8636a36d73581ec1ddcf58 MIT.doc Turkey
d07d4e71927cab4f251bcc216f560674c5fb783add9c9f956d3fc457153be025 Gvenlik Ynergesi.doc Turkey
af5f102f0597db9f5e98068724e31d68b8f7c23baeea536790c50db587421102 Gvenlik Ynergesi.doc Turkey
5550615affe077ddf66954edf132824e4f1fe16b3228e087942b0cad0721a6af NA Turkey
3d96811de7419a8c090a671d001a85f2b1875243e5b38e6f927d9877d0ff9b0c Anadolu Güneydoğu
Projesinde .doc

Network Indicators

List of Proxy URLs








































































































































































































































































































































































































































































Security Tools Checked on the Machine





























Go to Source
Author: Sudeep Singh

CVE-2017-10271 Used to Deliver CryptoMiners: An Overview of TechniquesUsed Post-Exploitation and Pre-Mining


FireEye researchers recently observed threat actors abusing
CVE-2017-10271 to deliver various cryptocurrency miners.

CVE-2017-10271 is a known input validation vulnerability that exists
in the WebLogic Server Security Service (WLS Security) in Oracle
WebLogic Server versions and prior, and attackers can
exploit it to remotely execute arbitrary code. Oracle released a Critical
Patch Update
that reportedly fixes this vulnerability. Users who
failed to patch their systems may find themselves mining
cryptocurrency for threat actors.

FireEye observed a high volume of activity associated with the
exploitation of CVE-2017-10271 following the public posting of proof
of concept code in December 2017. Attackers leveraged this
vulnerability to subsequently download cryptocurrency miners in victim
environments. The recent cryptocurrency boom has resulted in a growing
number of operations – employing diverse tactics – aimed at stealing
cryptocurrencies. The idea that these cryptocurrency mining operations
are less risky, along with the potentially nice profits, could lead
cyber criminals to begin shifting away from ransomware campaigns.

Tactic #1: Delivering the miner directly to a vulnerable server

Some tactics we’ve observed involve exploiting CVE-2017-10271,
leveraging PowerShell to download the miner directly onto the victim’s
system (Figure 1), and executing it using ShellExecute().

Figure 1: Downloading the payload directly

Tactic #2: Utilizing PowerShell scripts to deliver the miner

Other tactics involve the exploit delivering a PowerShell script,
instead of downloading the executable directly (Figure 2).

Figure 2: Exploit delivering PowerShell script

This script has the following functionalities:

  • Downloading miners from remote servers

Figure 3: Downloading cryptominers

As shown in Figure 3, the .ps1 script
tries to download the payload from the remote server to a vulnerable server.

  • Creating scheduled tasks for persistence

Figure 4: Creation of scheduled task

  • Deleting scheduled tasks of other known cryptominers

Figure 5: Deletion of scheduled tasks
related to other miners

In Figure 4, the cryptominer creates a
scheduled task with name “Update service for Oracle
”.  In Figure 5, a different variant deletes this task
and other similar tasks after creating its own, “Update service for
Oracle productsa

From this, it’s quite clear that
different attackers are fighting over the resources available in the system.

  • Killing processes matching certain strings associated with other

Figure 6: Terminating processes directly

Figure 7: Terminating processes matching
certain strings

Similar to scheduled tasks deletion,
certain known mining processes are also terminated (Figure 6 and
Figure 7).

  • Connects to mining pools with wallet key

Figure 8: Connection to mining pools

The miner is then executed with
different flags to connect to mining pools (Figure 8). Some of the
other observed flags are: -a for algorithm, -k for keepalive to
prevent timeout, -o for URL of mining server, -u for wallet key, -p
for password of mining server, and -t for limiting the number of miner threads.

  • Limiting CPU usage to avoid suspicion

Figure 9: Limiting CPU Usage

To avoid suspicion, some attackers are
limiting the CPU usage of the miner (Figure 9).

Tactic #3: Lateral movement across Windows environments using
Mimikatz and EternalBlue

Some tactics involve spreading laterally across a victim’s
environment using dumped Windows credentials and the EternalBlue vulnerability

The malware checks whether its running on a 32-bit or 64-bit system
to determine which PowerShell script to grab from the command and
control (C2) server. It looks at every network adapter, aggregating
all destination IPs of established non-loopback network connections.
Every IP address is then tested with extracted credentials and a
credential-based execution of PowerShell is attempted that downloads
and executes the malware from the C2 server on the target machine.
This variant maintains persistence via WMI (Windows Management Instrumentation).

The malware also has the capability to perform a Pass-the-Hash
attack with the NTLM information derived from Mimikatz in order to
download and execute the malware in remote systems.

Additionally, the malware exfiltrates stolen credentials to the
attacker via an HTTP GET request to:

If the lateral movement with credentials fails, then the malware
uses PingCastle MS17-010 scanner (PingCastle is a French Active
Directory security tool) to scan that particular host to determine if
its vulnerable to EternalBlue, and uses it to spread to that host.

After all network derived IPs have been processed, the malware
generates random IPs and uses the same combination of PingCastle and
EternalBlue to spread to that host.

Tactic #4: Scenarios observed in Linux OS

We’ve also observed this vulnerability being exploited to deliver
shell scripts (Figure 10) that have functionality similar to the
PowerShell scripts.

Figure 10: Delivery of shell scripts

The shell script performs the following activities:

  • Attempts to kill already running cryptominers

Figure 11: Terminating processes matching
certain strings

  • Downloads and executes cryptominer malware

Figure 12: Downloading CryptoMiner

  • Creates a cron job to maintain persistence

Figure 13: Cron job for persistence

  • Tries to kill other potential miners to hog the CPU

Figure 14: Terminating other potential miners

The function shown in Figure 14 is used
to find processes that have high CPU usage and terminate them. This
terminates other potential miners and maximizes the utilization of resources.


Use of cryptocurrency mining malware is a popular tactic leveraged
by financially-motivated cyber criminals to make money from victims.
We’ve observed one threat actor mining around 1 XMR/day, demonstrating
the potential profitability and reason behind the recent rise in such
attacks. Additionally, these operations may be perceived as less risky
when compared to ransomware operations, since victims may not even
know the activity is occurring beyond the slowdown in system performance.

Notably, cryptocurrency mining malware is being distributed using
various tactics, typically in an opportunistic and indiscriminate
manner so cyber criminals will maximize their outreach and profits.

FireEye HX, being a behavior-based solution, is not affected by
cryptominer tricks. FireEye HX detects these threats at the initial
level of the attack cycle, when the attackers attempt to deliver the
first stage payload or when the miner tries to connect to mining pools.

At the time of writing, FireEye HX detects this activity with the
following indicators:

Detection Name

Indicators of Compromise

MD5 Name
3421A769308D39D4E9C7E8CAECAF7FC4 cranberry.exe/logic.exe
B3A831BFA590274902C77B6C7D4C31AE xmrig.exe/yam.exe
26404FEDE71F3F713175A3A3CEBC619B 1.ps1
D3D10FAA69A10AC754E3B7DDE9178C22 2.ps1
9C91B5CF6ECED54ABB82D1050C5893F2 info3.ps1
3AAD3FABF29F9DF65DCBD0F308FF0FA8 info6.ps1
933633F2ACFC5909C83F5C73B6FC97CC lower.css
B47DAF937897043745DF81F32B9D7565 lib.css
3542AC729035C0F3DB186DDF2178B6A0 bootstrap.css

Thanks to Dileep Kumar Jallepalli and Charles Carmakal for their
help in the analysis.

Go to Source
Author: Rakesh Sharma

ReelPhish: A Real-Time Two-Factor Phishing Tool

Social Engineering and Two-Factor Authentication

Social engineering campaigns are a constant threat to businesses
because they target the weakest chain in security: people. A typical
attack would capture a victim’s username and password and store it for
an attacker to reuse later. Two-Factor Authentication (2FA) or
Multi-Factor Authentication (MFA) is commonly seen as a solution to
these threats.

2FA adds an extra layer of authentication on top of the typical
username and password. Two common 2FA implementations are one-time
passwords and push notifications. One-time passwords are generated by
a secondary device, such as a hard token, and tied to a specific user.
These passwords typically expire within 30 to 60 seconds and cannot be
reused. Push notifications involve sending a prompt to a user’s mobile
device and requiring the user to confirm their login attempt. Both of
these implementations protect users from traditional phishing
campaigns that only capture username and password combinations.

Real-Time Phishing

While 2FA has been strongly recommended by security professionals
for both personal and commercial applications, it is not an infallible
solution. 2FA implementations have been successfully defeated using real-time
phishing techniques
. These phishing attacks involve interaction
between the attacker and victims in real time.

A simple example would be a phishing website that prompts a user for
their one-time password in addition to their username and password.
Once a user completes authentication on the phishing website, they are
presented with a generic “Login Successful” page and the one-time
password remains unused but captured. At this point, the attacker has
a brief window of time to reuse the victim’s credentials before expiration.

Social engineering campaigns utilizing these techniques are not new.
There have been reports of real-time
phishing in the wild
as early as 2010. However, these types of
attacks have been largely ignored due to the perceived difficulty of
launching such attacks. This article aims to change that perception,
bring awareness to the problem, and incite new solutions.

Explanation of Tool

To improve social engineering assessments, we developed a tool –
named ReelPhish – that simplifies the real-time phishing technique.
The primary component of the phishing tool is designed to be run on
the attacker’s system. It consists of a Python script that listens for
data from the attacker’s phishing site and drives a locally installed
web browser using the Selenium
. The tool is able to control the attacker’s web browser
by navigating to specified web pages, interacting with HTML objects,
and scraping content.

The secondary component of ReelPhish resides on the phishing site
itself. Code embedded in the phishing site sends data, such as the
captured username and password, to the phishing tool running on the
attacker’s machine. Once the phishing tool receives information, it
uses Selenium to launch a browser and authenticate to the legitimate
website. All communication between the phishing web server and the
attacker’s system is performed over an encrypted SSH tunnel.

Victims are tracked via session tokens, which are included in all
communications between the phishing site and ReelPhish. This token
allows the phishing tool to maintain states for authentication
workflows that involve multiple pages with unique challenges. Because
the phishing tool is state-aware, it is able to send information from
the victim to the legitimate web authentication portal and vice versa.


We have successfully used ReelPhish and this methodology on numerous
Red Team
engagements. The most common scenario we have come
across is an externally facing VPN portal with two-factor
authentication. To perform the social engineering attack, we make a
copy of the real VPN portal’s HTML, JavaScript, and CSS. We use this
code to create a phishing site that appears to function like the original.

To facilitate our real-time phishing tool, we embed server-side code
on the phishing site that communicates with the tool running on the
attacker machine. We also set up a SSH tunnel to the phishing server.
When the authentication form on the phishing site is submitted, all
submitted credentials are sent over the tunnel to the tool on the
attacker’s system. The tool then starts a new web browser instance on
the attacker’s system and submits credentials on the real VPN portal.
Figure 1 shows this process in action.

Figure 1: ReelPhish Flow Diagram

We have seen numerous variations of two-factor authentication on VPN
portals. In some instances, a token is passed in a “secondary
password” field of the authentication form itself. In other cases, the
user must respond to a push request on a mobile phone. A user is
likely to accept an incoming push request after submitting credentials
if the phishing site behaved identically to the real site.

In some situations, we have had to develop more advanced phishing
sites that can handle multiple authentication pages and also pass
information back and forth between the phishing web server and the
tool running on the attacking machine. Our script is capable of
handling these scenarios by tracking a victim’s session on the
phishing site and associating it with a particular web browser
instance running on the attacker’s system. Figure 1 shows a general
overview of how our tool would function within an attack scenario.

We are publicly releasing the tool on the FireEye GitHub
. Feedback, pull requests, and issues can also be
submitted to the Git repository.


Do not abandon 2FA; it is not a perfect solution, but it does add a
layer of security. 2FA is a security mechanism that may fail like any
other, and organizations must be prepared to mitigate the impact of
such a failure.

Configure all services protected by 2FA to minimize attacker impact
if the attacker successfully bypasses the 2FA protections. Lowering
maximum session duration will limit how much time an attacker has to
compromise assets. Enforcing a maximum of one concurrent session per
user account will prevent attackers from being active at the same time
as the victim. If the service in question is a VPN, implement strict
network segmentation. VPN users should only be able to access the
resources necessary for their respective roles and responsibilities.
Lastly, educate users to recognize, avoid, and report social
engineering attempts.

By releasing ReelPhish, we at Mandiant hope to highlight the need
for multiple layers of security and discourage the reliance on any
single security mechanism. This tool is meant to aid security
professionals in performing a thorough penetration test from beginning
to end.

During our Red Team engagements at Mandiant, getting into an
organization’s internal network is only the first step. The tool
introduced here aids in the success of this first step. However, the
overall success of the engagement varies widely based on the target’s
internal security measures. Always work to assess and improve your
security posture as a whole. Mandiant provides a variety of services
that can assist all types of organizations in both of these activities.

Go to Source
Author: Pan Chan

Microsoft Office Vulnerabilities Used to Distribute Zyklon Malware inRecent Campaign


FireEye researchers recently observed threat actors leveraging
relatively new vulnerabilities in Microsoft Office to spread Zyklon
HTTP malware. Zyklon has been observed in the wild since early 2016
and provides myriad sophisticated capabilities.

Zyklon is a publicly available, full-featured backdoor capable of
keylogging, password harvesting, downloading and executing additional
plugins, conducting distributed denial-of-service (DDoS) attacks, and
self-updating and self-removal. The malware may communicate with its
command and control (C2) server over The Onion Router (Tor) network if
configured to do so. The malware can download several plugins, some of
which include features such as cryptocurrency mining and password
recovery, from browsers and email software. Zyklon also provides a
very efficient mechanism to monitor the spread and impact.

Infection Vector

We have observed this recent wave of Zyklon malware being delivered
primarily through spam emails. The email typically arrives with an
attached ZIP file containing a malicious DOC file (Figure 1 shows a
sample lure).

The following industries have been the primary targets in this campaign:

  • Telecommunications
  • Insurance
  • Financial Services

Figure 1: Sample lure documents

Attack Flow

  1. Spam email arrives in the
    victim’s mailbox as a ZIP attachment, which contains a malicious DOC
  2. The document files exploit at least three known
    vulnerabilities in Microsoft Office, which we discuss in the
    Infection Techniques section. Upon execution in a vulnerable
    environment, the PowerShell based payload takes over.
  3. The
    PowerShell script is responsible for downloading the final payload
    from C2 server to execute it.

A visual representation of the attack flow and execution chain can
be seen in Figure 2.

Figure 2: Zyklon attack flow

Infection Techniques


This vulnerability was discovered
by FireEye
in September 2017, and it is a vulnerability we have
observed being exploited in the wild.

The DOC file contains an embedded OLE Object that, upon execution,
triggers the download of an additional DOC file from the stored URL
(seen in Figure 3).

Figure 3: Embedded URL in OLE object


Similarly, we have also observed actors leveraging another newly discovered
vulnerability (CVE-2017-11882) in Microsoft Office. Upon opening the
malicious DOC attachment, an additional download is triggered from a
stored URL within an embedded OLE Object (seen in Figure 4).

Figure 4: Embedded URL in OLE object

Figure 5: HTTP GET request to download
the next level payload

The downloaded file, doc.doc, is XML-based and contains a
PowerShell command (shown in Figure 6) that subsequently
downloads the binary Pause.ps1.

Figure 6: PowerShell command to download
the Pause.ps1 payload

Dynamic Data Exchange (DDE)

Dynamic Data Exchange (DDE) is the interprocess communication
mechanism that is exploited to perform remote code execution. With the
help of a PowerShell script (shown in Figure 7), the next payload
(Pause.ps1) is downloaded.

Figure 7: DDE technique used to download
the Pause.ps1 payload

One of the unique approaches we have observed is the use of dot-less
IP addresses (example: hxxp://258476380).

Figure 8 shows the network communication of the Pause.ps1 download.

Figure 8: Network communication to
download the Pause.ps1 payload

Zyklon Delivery

In all these techniques, the same domain is used to download the
next level payload (Pause.ps1), which is another PowerShell
script that is Base64 encoded (as seen in Figure 8).

The Pause.ps1 script is responsible for resolving the APIs
required for code injection. It also contains the injectable
shellcode. The APIs contain VirtualAlloc(), memset(), and
CreateThread(). Figure 9 shows the decoded Base64 code.

Figure 9: Base64 decoded Pause.ps1

The injected code is responsible for downloading the final payload
from the server (see Figure 10). The final stage payload is a PE
executable compiled with .Net framework.

Figure 10: Network traffic to download
final payload (words.exe)

Once executed, the file performs the following activities:

  1. Drops a copy of itself in
    %AppData%svchost.exesvchost.exe and drops an XML file, which
    contains configuration information for Task Scheduler (as shown in
    Figure 11).
  2. Unpacks the code in memory via process
    hollowing. The MSIL file contains the packed core payload in its
    .Net resource section.
  3. The unpacked code is Zyklon.

Figure 11: XML configuration file to
schedule the task

The Zyklon malware first retrieves the external IP address of the
infected machine using the following:

  • api.ipify[.]org
  • ip.anysrc[.]net
  • myexternalip[.]com
  • whatsmyip[.]com

The Zyklon executable contains another encrypted file in its .Net
resource section named tor. This file is decrypted and injected
into an instance of InstallUtiil.exe, and functions as a Tor anonymizer.

Command & Control Communication

The C2 communication of Zyklon is proxied through the Tor network.
The malware sends a POST request to the C2 server. The C2 server is
appended by the gate.php, which is stored in file memory. The
parameter passed to this request is getkey=y. In response to this
request, the C2 server responds with a Base64-encoded RSA public key
(seen in Figure 12).

Figure 12: Zyklon public RSA key

After the connection is established with the C2 server, the malware
can communicate with its control server using the commands shown in
Table 1.

Command Action
sign Requests system information
settings Requests settings from C2 server
logs Uploads harvested passwords
wallet Uploads harvested cryptocurrency wallet
proxy Indicates SOCKS proxy port opened
miner Cryptocurrency miner commands
error Reports errors to C2 server
ddos DDoS attack commands

Table 1: Zyklon accepted commands

The following figures show the initial request and subsequent server
response for the “settings” (Figure 13), “sign” (Figure 14), and
“ddos” (Figure 15) commands.

Figure 13: Zyklon issuing “settings”
command and subsequent server response

Figure 14: Zyklon issuing “sign” command
and subsequent server response

Figure 15: Zyklon issuing “ddos” command
and subsequent server response

Plugin Manager

Zyklon downloads number of plugins from its C2 server. The plugin
URL is stored in file in following format:

  • /plugin/index.php?plugin=<Plugin_Name>

The following plugins are found in the memory of the Zyklon malware:

  • /plugin/index.php?plugin=cuda
  • /plugin/index.php?plugin=minerd
  • /plugin/index.php?plugin=sgminer
  • /plugin/index.php?plugin=socks
  • /plugin/index.php?plugin=tor
  • /plugin/index.php?plugin=games
  • /plugin/index.php?plugin=software
  • /plugin/index.php?plugin=ftp
  • /plugin/index.php?plugin=email
  • /plugin/index.php?plugin=browser

The downloaded plugins are injected into WindowsMicrosoft.NETFrameworkv4.0.30319RegAsm.exe.

Additional Features

The Zyklon malware offers the following additional capabilities (via plugins):

Browser Password Recovery

Zyklon HTTP can recover passwords from popular web browsers, including:

  • Google Chrome
  • Mozilla Firefox
  • Internet Explorer
  • Opera
  • Chrome Canary/SXS
  • CoolNovo Browser
  • Apple Safari
  • Flock Browser
  • SeaMonkey
  • SRWare Iron Browser
  • Comodo Dragon
FTP Password Recovery

Zyklon currently supports FTP password recovery from the following
FTP applications:

  • FileZilla
  • SmartFTP
  • FlashFXP
  • FTPCommander
  • Dreamweaver
  • WS_FTP
Gaming Software Key Recovery

Zyklon can recover PC Gaming software keys from the following games:

  • Battlefield
  • Call
    of Duty
  • FIFA
  • NFS
  • Age of Empires
  • Quake
  • The Sims
  • Half-Life
  • IGI
  • Star Wars
Email Password Recovery

Zyklon may also collect email passwords from following applications:

  • Microsoft Outlook
  • Microsoft Outlook 2002/XP/2003/2007/2010/2013
  • Mozilla Thunderbird
  • Windows Live Mail 2012
  • IncrediMail, Foxmail v6.x – v7.x
  • Windows Live
  • MSN Messenger
  • Google Talk
  • GMail
  • PaltalkScene IM
  • Pidgin (Formerly Gaim)
  • Miranda Messenger
  • Windows Credential
License Key Recovery

The malware automatically detects and decrypts the license/serial
keys of more than 200 popular pieces of software, including Office,
SQL Server, Adobe, and Nero.

Socks5 Proxy

Zyklon features the ability to establish a reverse Socks5 proxy
server on infected host machines.

Hijack Clipboard Bitcoin Address

Zyklon has the ability to hijack the clipboard, and replaces the
user’s copied bitcoin address with an address served up by the actor’s
control server.

Zyklon Pricing

Researchers identified different versions of Zyklon HTTP being
advertised in a popular underground marketplace for the following prices:

  • Normal build: $75
  • Tor-enabled build: $125 (USD)
  • Rebuild/Updates:
    $15 (USD)
  • Payment Method: Bitcoin (BTC)


Threat actors incorporating recently discovered vulnerabilities in
popular software – Microsoft Office, in this case – only increases the
potential for successful infections. These types of threats show why
it is very important to ensure that all software is fully updated.
Additionally, all industries should be on alert, as it is highly
likely that the threat actors will eventually move outside the scope
of their current targeting.

At this time of writing, FireEye Multi Vector Execution (MVX)
 is able to recognize and block this threat. Table 2 lists
the current detection and blocking capabilities by product.

Detection Name Product Action
Malware.Binary.rtf EX/ETP/NX Block
Malware.Binary EX/ETP/NX Block
FE_Exploit_RTF_CVE_2017_8759 EX/ETP/NX Block
FE_Exploit_RTF_CVE201711882_1 EX/ETP/NX Block

Table 2: Current detection capabilities by
FireEye products

Indicators of Compromise

The contained analysis is based on the representative sample lures
shown in Table 3.

MD5 Name
d91bed734a8e98b52b8ab0c7fafc6573 accounts.doc
4bae7fb819761a7ac8326baf8d8eb6ab Courier.doc
eb5fa454ab42c8aec443ba8b8c97339b doc.doc
886a4da306e019aa0ad3a03524b02a1c Pause.ps1
04077ecbdc412d6d87fc21e4b3a4d088 words.exe

Table 3: Sample Zyklon lures

Network Indicators

Go to Source
Author: Swapnil Patil

Debugging Complex Malware that Executes Code on the Heap


In this blog, I will share a simple debugging tactic for creating
“save points” during iterative remote debugging of complex multi-stage
samples that execute code in heap memory at non-deterministic
addresses. I’ll share two examples: one contrived, and the other a
complex, modular malware sample (MD5 hash:
830a09ff05eac9a5f42897ba5176a36a) from a family that we call
POISONPLUG. I will focus on IDA Pro and WinDbg, but I’ll explain how
to achieve the same effect with other tools as well. With this tactic,
you can also hand off program execution between multiple debuggers
using the strengths of different tools (e.g. unpacking a binary,
dumping memory maps, combatting anti-RE, or normal debugging).

The essence is merely suspending the malware. To set the stage, I
must first explain how malware influences our debugging tactics to
necessitate this. This explanation will serve as a review of common
techniques that make malware debugging easier and culminate in the
case study of POISONPLUG. If you’re already a seasoned analyst using
IDA Pro to remotely debug malware, and you’re only interested in the
bottom line of how to suspend and snapshot live malware, then skip to
the Summary section at the end.

VMs and Snapshots as Save Points

To prevent malware from doing damage, most malware reverse engineers
debug in an isolated VM. This gives rise to the powerful tactic of
capturing VM snapshots throughout the debugging process to be able to
return to a “save point” after making a mistake. The analyst is then
free to be aggressively experimental about exploring malware behavior.
The only consequence of an error is that the analyst must revert the
VM and avoid making the same mistake again.

Remote Debugging

Debugging malware on the same system where static analysis artifacts
are stored is dangerous; malware (e.g. ransomware) can destroy notes
and disassembly databases, or malware anti-RE measures can inflict
data loss (e.g. by rebooting). Consequently, it makes sense to use
separate systems for debugging versus disassembly and note-taking.
Depending on the tools used, this can force the analyst to flip back
and forth between viewing disassembler output and the debugger, like a
spectator at a tennis match. These transitions are distracting.

Unifying Static and Dynamic Analysis with IDA Pro as a Front-End

Fortunately, IDA Pro (and probably most modern disassemblers) can
act as a debugging front-end, superimposing disassembly annotations
over live memory and register state in a running program. This lets
the analyst see and directly alter disassembly annotations in response
to their observations, without switching back and forth.

Malware that Modifies its Memory Map at Runtime

There is one frequent scenario that further shapes the requirements
for a dynamic analysis methodology: malware that allocates heap
memory, writes code to that memory, and executes that code. Consider
Figure 1, which shows a simple program written in C.

Figure 1: Simple shellcode example program

The program allocates memory using malloc, copies six bytes to that
location using memcpy, logically inverts each byte, calls the buffer
as a function, and finally returns the shellcode’s return value (error
checking omitted both for brevity and realism). Figure 2 shows the
decoded shellcode in memory.

Figure 2: Simple shellcode function
returns 42

Without this code, the disassembly database is missing useful
information about the malware’s code, leaving its behavior as a bit of
a black box. This simple example demonstrates a common pattern, but
its trivial nature isn’t compelling enough to consider this a serious
problem. A more realistic example will provide more substantial
motivation for the debugging tactic at hand.


For a realistic example, consider the sample with MD5 hash
830a09ff05eac9a5f42897ba5176a36a (which is available from VirusTotal).
This malware creates a thread that decodes and calls shellcode, which
unpacks and calls into the entry point of a modified DLL module. The
module in turn unpacks six additional modules before finally calling a
function within one of those modules. The DllEntryPoint functions of
several modules each create several anti-RE threads that attempt to
detect common analyst tools and terminate the malware in response.
After completely unpacking the malware, tools such as Tyler Dean’s injectfind
for flare-dbg
or my own flare-qdb
(Query-Oriented Debugger)
can expose all the read/write/execute
(R/W/X) mappings in memory that, in this case, point directly to the
malware modules. Figure 3 shows the output from flare-qdb debugging a
subset of the malware to this point and dumping its R/W/X allocations.

Figure 3: POISONPLUG R/W/X memory
locations after unpacking

Figure 4 shows the unpacked shellcode-based loader from this sample,
which is intricate, obfuscated, and time-consuming to annotate.

Figure 4: POISONPLUG’s shellcode-based loader

This shellcode implements several anti-RE features specific to this
malware family, and a copy of this is used to unpack seven modules
altogether with modified/custom PE-COFF headers. A common response to
finding an entire executable file in memory is to dump the file and
create its own disassembly database. However, the modules use a list
of function pointers stashed in a mapping of the paging file to locate
and call into one-another’s function “exports” in spaghetti code
fashion to deliberately obfuscate control flow and functional
semantics. Figure 5 shows an example, where each lane represents one
executable code module, and the boxes inside each lane represent
distinct function entry point RVAs within that module.

Figure 5: Partial interaction diagram for
retrieving and decoding configuration

The code at offset 0x11f2 in module 0 is simply calling into other
modules to eventually arrive at code within its own module (at offset
0x1d42). Dumping to separate disassembly databases creates
distractions for the analyst as they must Alt+Tab between entirely
different disassembly databases to follow the path of execution.

These types of complex samples create a dual problem for the
debugging tactics described so far…

Challenge 1: Syncing Code from the Heap

The first problem is that the code written to memory is generally
not readily available in the original disassembly output, and dumping
to separate disassembly databases is not always appropriate. It can
also be a lot of work to neutralize anti-reversing measures and
shepherd a sample to the point where it has unpacked all its encoded
modules into heap memory. A debugging mistake can entail a lot of
additional work to fix and resume analysis. Live memory is a resource
that could hasten reverse engineering if it can be preserved beyond
the life of the debug session. Luckily, this first problem of making
unpacked modules conveniently available in a single disassembly
database can be solved trivially, at least in IDA Pro:

  1. Visit each dynamically
    allocated code region to change its segment attributes (Alt+S) and
    mark each as a Loader segment
  2. Pull the dynamically
    allocated memory into the disassembly database (Debugger >
    Take memory snapshot > Loader Segments)

If you are following along without having started a debugging
session, IDA’s Change segment attributes dialog will omit the
Loader segment checkbox. Figure 6 shows this dialog during a
debugging session, with the Loader segment checkbox highlighted.

Figure 6: Change segment attributes
dialog during debugging session

After pulling in live memory, it is possible to read and annotate
unpacked modules and code in heap allocations even after terminating
the debugging session, as shown in Figure 7.

Figure 7: Function code from heap saved
from a debug memory snapshot

Challenge 2: Non-Deterministic Memory Maps

A second problem arises from samples that execute code in
dynamically allocated memory. Recovering from a debugging mistake
still requires debugging the program again, but modules frequently
occupy varying addresses across different executions. Consequently,
the helpful annotations created in IDA Pro at the original addresses
are absent from the new code locations. Figure 8 shows an example
containing the same code as in Figure 7, but loaded at a different
address during a subsequent execution of the program. The analyst must
then recognize and/or relabel everything to continue the analysis.
This can be scripted, but it is a time-consuming distraction.

Figure 8: Same code at a different
address lacks annotations

The reason the code appears at varying addresses across debugging
sessions is that Windows’ memory allocation functions such as
VirtualAlloc do not always return consistent addresses from one
execution of a program to the next. For example, the first time a
program runs, it may obtain memory at address 0xe000, the second time
at 0x11a000, et cetera. For complex malware with several modules, this
presents a problem.

We’d like the memory map to be uniform from one debug session to
another so we can continue to build on our existing static analysis
annotations, each of which IDA Pro has associated with a single
virtual address. Alas, even though VirtualAlloc accepts an optional
lpAddress parameter to indicate the starting address of the region to
allocate, this is merely a suggestion unless memory was already
reserved and uncommitted at that address. Forcing the lpAddress
parameter to a desired value rarely (in my experience, never) yields success.

Alternately, it would be nice to go back to using virtual machine
snapshots to create “save points” like before. Unfortunately, when
debugging remotely over a network, the process of reverting a virtual
machine snapshot breaks the TCP connection between the debug server
and IDA Pro and prevents the malware from continuing under the control
of the debugger.

…Where we Lay our Scene

The stage is now set to introduce the new technique. First, a short
recap of how we got here:

  • Need to debug in a VM to
    avoid damage to the host system
  • Prefer to use IDA Pro as
    the debugging front-end to unify static and dynamic analysis
  • Need to use remote debugging to avoid damage to static analysis
    artifacts and documentation
  • Need to debug iteratively
    across multiple debug sessions
  • Disassembly annotations must
    align with the memory map in the debug session to be useful

Malware behavior and analyst preferences seem to have painted us
into a corner. Running the malware repeatedly results in a
non-deterministic memory map that does not align with the annotations
in the disassembly database, and using IDA Pro to unify the static
view with live remote debugging appears impede the use of VM snapshots
to act as save points. What should an analyst do?

Park Your Malware

To capture a VM snapshot that allows us to repeatedly reattach to
and resume debugging, we’ll increase the suspend count of all the
threads in the program and detach the debugger. The debug server will
gracefully close its TCP connection, and the program will stay
suspended until we reattach. We then capture a VM snapshot. Finally,
we can repeatedly revert the VM, reattach, and resume execution to
continue our analysis. This way, you can park your malware once, and
then crash it over and over again until you understand its behavior.

As it turns out, IDA Pro’s facility for suspending threads
(right-click -> Suspend) doesn’t maintain its effect after
detaching the debugger. Instead, we’ll specifically use WinDbg as
IDA’s debugger back-end (see the directions
at Hex-Rays’ site

The WinDbg command for viewing thread status is ~ (tilde). The ~
command accepts an optional numeric argument to specify which thread
to display (e.g. ~3), or you can specify ~* to display full status for
all threads. WinDbg also supports commands ~n and ~m for
suspending and resuming threads. These also permit
numeric or asterisk arguments, so we can use ~*n to suspend all
threads before detaching, and ~*m to resume them upon
reattaching. Figure 9 shows IDA/WinDbg output after viewing thread
status, suspending all threads, and finally viewing their status once more.

Figure 9: Viewing thread status,
suspending, and viewing again

The suspend count increases from 1 to 2 after issuing the ~*n
command. Now, when the debugger detaches from the process and
decrements the suspend count of all threads (as usual), the
artificially elevated suspend count of each thread will remain greater
than zero. Consequently, the NT dispatcher will not schedule any
threads in the process to run, and the process will continue to exist
in a suspended state.

Now, we can capture a VM snapshot that can be repeatedly reverted to
resume debugging from where we left off. Figure 10 shows the process
attachment dialog in IDA Pro after reverting the VM snapshot and
clicking Debugger -> Attach to process…

Figure 10: Attaching to the suspended process

You can create these “save points” at various junctures – as many as
you have disk space to store.

The one caveat to this procedure is that it is easy to forget to
resume threads between reattaching and attempting to continue
debugging. If you forget this step, then the “Please wait…” modal
dialog in Figure 11 will appear.

Figure 11: Debugging a suspended process

A reverse engineer might be accustomed to seeing this dialog only
after making a mistake and allowing malware to run free, but in this
case, the program is not actually executing any instructions. To fix
it, simply click the Suspend button in IDA Pro’s “Please wait…” dialog
and then resume all threads (WinDbg: ~*m) to decrease their suspend
count. Then, execution can continue as normal.


To suspend a program that you are running within an IDA Pro + WinDbg
remote debug session to capture a reusable VM snapshot:

  1. Suspend all threads
    (WinDbg: ~*n)
  2. Detach from the process (IDA Pro:
    Debugger -> Detach from process)
  3. Capture
    your VM snapshot

To resume the suspended program:

  1. Attach to the remote
    process (IDA Pro: Debugger -> Attach to
  2. Resume all threads (WinDbg: ~*m)
  3. Resume
    debugging as normal

If you aren’t interested in using WinDbg commands, you can instead
use SysInternals’ Process Explorer to suspend the process in your
debugging VM and simply detach using IDA Pro. You could also write a
Python ctypes script or native program to directly use the relevant
Windows APIs if you prefer (specifically via CreateToolhelp32Snapshot
with the TH32_SNAPTHREAD flag, OpenThread, SuspendThread, and ResumeThread).

This tactic allows us to cope with complex multi-stage shellcode or
modular malware that has several (sometimes cascading) unpacked code
regions. It lets us create save points in our debug session while
maintaining the same memory map so our disassembly annotations always
remain aligned with the memory map in the debug session. It also
allows us to suspend malware execution in one debugger and pick it up
in another, provided each debugger allows thread suspend count to
remain at a non-zero value before detaching.

Before closing, I’d like to give credit to Tarik Soulami for his
explanation of WinDbg thread management in his book, “Inside Windows
Debugging” (Microsoft Press, 2012). If you’re starting to confront
more difficult debugging scenarios in your journey as a reverse
engineer, I strongly encourage you to pick up “Inside Windows
Debugging” to augment your repertoire and further understand the
powerful debugging capabilities of WinDbg and Windows itself.

Go to Source
Author: Michael Bailey

Attackers Deploy New ICS Attack Framework “TRITON” and Cause OperationalDisruption to Critical Infrastructure


Mandiant recently responded to an incident at a critical
infrastructure organization where an attacker deployed malware
designed to manipulate industrial safety systems. The targeted systems
provided emergency shutdown capability for industrial processes. We
assess with moderate confidence that the attacker was developing the
capability to cause physical damage and inadvertently shutdown
operations. This malware, which we call TRITON, is an attack framework
built to interact with Triconex Safety Instrumented System (SIS)
controllers. We have not attributed the incident to a threat actor,
though we believe the activity is consistent with a nation state
preparing for an attack.

TRITON is one of a limited number of publicly identified malicious
software families targeted at industrial control systems (ICS). It
follows Stuxnet which was used against Iran in 2010 and Industroyer
which we believe was deployed by Sandworm Team against Ukraine in
2016. TRITON is consistent with these attacks, in that it could
prevent safety mechanisms from executing their intended function,
resulting in a physical consequence.

Malware Family Main Modules Description
TRITON trilog.exe Main
executable leveraging Custom
communication library for interaction with Triconex

Table 1: Description of TRITON Malware

Incident Summary

The attacker gained remote access to an SIS engineering workstation
and deployed the TRITON attack framework to reprogram the SIS
controllers. During the incident, some SIS controllers entered a
failed safe state, which automatically shutdown the industrial process
and prompted the asset owner to initiate an investigation. The
investigation found that the SIS controllers initiated a safe shutdown
when application code between redundant processing units failed a
validation check — resulting in an MP diagnostic failure message.

We assess with moderate confidence that the attacker inadvertently
shutdown operations while developing the ability to cause physical
damage for the following reasons:

  • Modifying the SIS could
    prevent it from functioning correctly, increasing the likelihood of
    a failure that would result in physical consequences.
  • TRITON was used to modify application memory on SIS controllers
    in the environment, which could have led to a failed validation
  • The failure occurred during the time period when
    TRITON was used.
  • It is not likely that existing or external
    conditions, in isolation, caused a fault during the time of the


FireEye has not connected this activity to any actor we currently
track; however, we assess with moderate confidence that the actor is
sponsored by a nation state. The targeting of critical infrastructure
as well as the attacker’s persistence, lack of any clear monetary goal
and the technical resources necessary to create the attack framework
suggest a well-resourced nation state actor.  Specifically, the
following facts support this assessment:

The attacker targeted the SIS suggesting an interest in causing a
high-impact attack with physical consequences. This is an attack
objective not typically seen from cyber-crime groups.

The attacker deployed TRITON shortly after gaining access to the SIS
system, indicating that they had pre-built and tested the tool which
would require access to hardware and software that is not widely
available. TRITON is also designed to communicate using the
proprietary TriStation protocol which is not publicly documented
suggesting the adversary independently reverse engineered this protocol.

The targeting of critical infrastructure to disrupt, degrade, or
destroy systems is consistent with numerous attack and reconnaissance
activities carried out globally by Russian, Iranian, North Korean,
U.S., and Israeli nation state actors. Intrusions of this nature do
not necessarily indicate an immediate intent to disrupt targeted
systems, and may be preparation for a contingency.

Background on Process Control and Safety Instrumented Systems

Figure 1: ICS Reference Architecture

Modern industrial process control and automation systems rely on a
variety of sophisticated control systems and safety functions. These
systems and functions are often referred to as Industrial Control
Systems (ICS) or Operational Technology (OT).

A Distributed Control System (DCS) provides human operators with the
ability to remotely monitor and control an industrial process. It is a
computerized control system consisting of computers, software
applications and controllers. An Engineering Workstation is a computer
used for configuration, maintenance and diagnostics of the control
system applications and other control system equipment.

A SIS is an autonomous control system that independently monitors
the status of the process under control. If the process exceeds the
parameters that define a hazardous state, the SIS attempts to bring
the process back into a safe state or automatically performs a safe
shutdown of the process. If the SIS and DCS controls fail, the final
line of defense is the design of the industrial facility, which
includes mechanical protections on equipment (e.g. rapture discs),
physical alarms, emergency response procedures and other mechanisms to
mitigate dangerous situations.

Asset owners employ varied approaches to interface their plant’s DCS
with the SIS. The traditional approach relies on the principles of
segregation for both communication infrastructures and control
strategies. For at least the past decade, there has been a trend
towards integrating DCS and SIS designs for various reasons including
lower cost, ease of use, and benefits achieved from exchanging
information between the DCS and SIS. We believe TRITON acutely
demonstrates the risk associated with integrated designs that allow
bi-directional communication between DCS and SIS network hosts.

Safety Instrumented Systems Threat Model and Attack Scenarios

Figure 2: Temporal Relationship Between
Cyber Security and Safety

The attack lifecycle for disruptive attacks against ICS is similar
to other types of cyber attacks, with a few key distinctions. First,
the attacker’s mission is to disrupt an operational process rather
than steal data. Second, the attacker must have performed OT
reconnaissance and have sufficient specialized engineering knowledge
to understand the industrial process being controlled and successfully
manipulate it.

Figure 2 represents the relationship between cyber security and
safety controls in a process control environment. Even if cyber
security measures fail, safety controls are designed to prevent
physical damage. To maximize physical impact, a cyber attacker would
also need to bypass safety controls.

The SIS threat model below highlights some of the options available
to an attacker who has successfully compromised an SIS.

Attack Option 1: Use the SIS to shutdown the process

  • The attacker can
    reprogram the SIS logic to cause it to trip and shutdown a process
    that is, in actuality, in a safe state. In other words, trigger a
    false positive.
  • Implication: Financial losses due to
    process downtime and complex plant start up procedure after the

Attack Option 2: Reprogram the SIS to allow an unsafe state

  • The attacker can
    reprogram the SIS logic to allow unsafe conditions to persist.
  • Implication: Increased risk that a hazardous situation will
    cause physical consequences (e.g. impact to equipment, product,
    environment and human safety) due to a loss of SIS

Attack Option 3: Reprogram the SIS to allow an unsafe state – while
using the DCS to create an unsafe state or hazard

  • The attacker can
    manipulate the process into an unsafe state from the DCS while
    preventing the SIS from functioning appropriately.
  • Implication: Impact to human safety, the environment, or damage
    to equipment, the extent of which depends on the physical
    constraints of the process and the plant design.

Analysis of Attacker Intent

We assess with moderate confidence that the attacker’s long-term
objective was to develop the capability to cause a physical
consequence. We base this on the fact that the attacker initially
obtained a reliable foothold on the DCS and could have developed the
capability to manipulate the process or shutdown the plant, but
instead proceeded to compromise the SIS system. Compromising both the
DCS and SIS system would enable the attacker to develop and carry out
an attack that causes the maximum amount of damage allowed by the
physical and mechanical safeguards in place.

Once on the SIS network, the attacker used their pre-built TRITON
attack framework to interact with the SIS controllers using the
TriStation protocol. The attacker could have caused a process shutdown
by issuing a halt command or intentionally uploading flawed code to
the SIS controller to cause it to fail. Instead, the attacker made
several attempts over a period of time to develop and deliver
functioning control logic for the SIS controllers in this target
environment. While these attempts appear to have failed due one of the
attack scripts’ conditional checks, the attacker persisted with their
efforts. This suggests the attacker was intent on causing a specific
outcome beyond a process shutdown.

Of note, on several occasions, we have observed evidence of long
term intrusions into ICS which were not ultimately used to disrupt or
disable operations. For instance, Russian operators, such as Sandworm
Team, have compromised Western ICS over a multi-year period without
causing a disruption.

Summary of Malware Capabilities

The TRITON attack tool was built with a number of features,
including the ability to read and write programs, read and write
individual functions and query the state of the SIS controller.
However, only some of these capabilities were leveraged in the
trilog.exe sample (e.g. the attacker did not leverage all of TRITON’s
extensive reconnaissance capabilities).

The TRITON malware contained the capability to communicate with
Triconex SIS controllers (e.g. send specific commands such as halt
or read its memory content) and remotely reprogram them with an
attacker-defined payload. The TRITON sample Mandiant analyzed added an
attacker-provided program to the execution table of the Triconex
controller. This sample left legitimate programs in place, expecting
the controller to continue operating without a fault or exception. If
the controller failed, TRITON would attempt to return it to a running
state. If the controller did not recover within a defined time window,
this sample would overwrite the malicious program with invalid data to
cover its tracks.


Asset owners who wish to defend against the capabilities
demonstrated in the incident, should consider the following controls:

  • Where technically feasible, segregate safety system networks
    from process control and information system networks. Engineering
    workstations capable of programming SIS controllers should not be
    dual-homed to any other DCS process control or information system
  • Leverage hardware features that provide for physical
    control of the ability to program safety controllers. These usually
    take the form of switches controlled by a physical key. On Triconex
    controllers, keys should not be left in the PROGRAM mode other than
    during scheduled programming events.
  • Implement change
    management procedures for changes to key position. Audit current key
    state regularly.
  • Use a unidirectional gateway rather than
    bidirectional network connections for any applications that depend
    on the data provided by the SIS.
  • Implement strict access
    control and application whitelisting on any server or workstation
    endpoints that can reach the SIS system over TCP/IP.
  • Monitor ICS network traffic for unexpected communication flows
    and other anomalous activity.

Figure 3: Triconex Key Switch (source)

Appendix: Technical Analysis

Figure 4: TRITON Architecture and Attack Scenario

TRITON was deployed on an SIS engineering workstation running the
Microsoft Windows operating system. The malware was named to
masquerade as the legitimate Triconex Trilog application. This
application is used for reviewing logs and is a part of the TriStation
application suite. The malware was delivered as a Py2EXE compiled
python script dependent on a zip file containing standard Python
libraries, open source libraries, as well as the attacker-developed
Triconex attack framework for interacting with the Triconex
controllers. Along with the executable, two binary files,
inject.bin (malicious function code) and imain.bin
(malicious control logic)
, were deployed as the controller’s
payload. These file names were hard coded in the Py2EXE compiled
python script.

Trilog.exe took one option from the command line, which was a single
IP address of the target Triconex device. It did not leverage the
underlying TRITON library’s capability for Triconex device discovery,
instead an instance of trilog.exe had to be invoked separately for
each target controller in the environment. Once invoked, trilog.exe
checked the status of the controller, then read the configuration
information exposed by the TriStation protocol. If the controller was
in a running state, trilog.exe encoded the two payload files
inject.bin and imain.bin and passed them to the
communication libraries to be appended to the controller’s program
memory and execution table.

After payload files were inserted into memory on the Triconex
controller, the script initiated a countdown, periodically checking
the status of the controller. If an error was detected, the
communication library’s method SafeAppendProgramMod attempted
to reset the controller to the previous state using a TriStation
protocol command. If this failed, trilog.exe attempted to write a
small ‘dummy’ program to memory. We assess that this was an
anti-forensics technique to hide the presence of the attacker code on
the Triconex controller.

Working with the asset owner, Mandiant ran trilog.exe in a lab
environment with a valid Triconex controller and discovered a
conditional check in the malware that prevented the payload binary
from persisting in the environment. Mandiant confirmed that, after
correcting patching the attack script to remove this check, the
payload binary would persist in controller memory, and the controller
would continue to run.

TRITON implements the TriStation protocol, which is the protocol
used by the legitimate TriStation application, to configure controllers.

TsHi is the high-level interface created by the
malware’s authors that allows the threat actor’s operators to
implement attack scripts using the TRITON framework. It exposes
functions for both reconnaissance and attack. The functions generally
accept binary data from the user, and handle the code ‘signing’ and
check sums prior to passing the data to lower level libraries for
serialization on to the network.

TsBase, another attacker-written module, contains the
functions called by TsHi, which translate the attacker’s
intended action to the appropriate TriStation protocol function code.
For certain functions, it also packs and pads the data in to the
appropriate format.

TsLow is an additional attacker module that implements the
TriStation UDP wire protocol. The TsBase library primarily
depends on the ts_exec method. This method takes the function
code and expected response code, and serializes the commands payload
over UDP. It checks the response from the controller against the
expected value and returns a result data structure indicating success
or a False object representing failure.

TsLow also exposes the connect method used to check
connectivity to the target controller. If invoked with no targets, it
runs the device discovery function detect_ip. This leverages a
“ping” message over the TriStation protocol using IP
broadcast to find controllers that are reachable via a router from
where the script is invoked.


Filename / Domain / IP Address MD5 Hash or Description
trilog.exe 6c39c3f4a08d3d78f2eb973a94bd7718
imain.bin 437f135ba179959a580412e564d3107f
inject.bin 0544d425c7555dc4e9d76b571f31f500 0face841f7b2953e7c29c064d6886523
TS_cnames.pyc e98f4f3505f05bf90e17554fbc97bba9
TsBase.pyc 288166952f934146be172f6353e9a1f5
TsHi.pyc 27c69aa39024d21ea109cc9c9d944a04
TsLow.pyc f6b3a73c8c87506acda430671360ce15
sh.pyc 8b675db417cc8b23f4c43f3de5c83438


author =
“nicholas.carr @itsreallynick”
md5 =
description = “TRITON framework recovered during Mandiant
ICS incident response”
$python_compiled = “.pyc” nocase ascii wide
$python_module_01 = “__module__” nocase
ascii wide
$python_module_02 =
“” nocase ascii wide
$python_script_01 = “import Ts” nocase ascii
$python_script_02 = “def ts_”
nocase ascii wide

$py_cnames_01 =
“” nocase ascii wide
$py_cnames_02 = “TRICON” nocase ascii wide
$py_cnames_03 = “TriStation ” nocase ascii
$py_cnames_04 = ” chassis ”
nocase ascii wide

$py_tslibs_01 =
“GetCpStatus” nocase ascii wide
$py_tslibs_02 = “ts_” ascii wide
$py_tslibs_03 = ” sequence” nocase ascii wide
$py_tslibs_04 = /import Ts(Hi|Low|Base)[^:alpha:]/
nocase ascii wide
$py_tslibs_05 =
/modules?version/ nocase ascii wide
$py_tslibs_06 = “bad ” nocase ascii wide
$py_tslibs_07 = “prog_cnt” nocase ascii

$py_tsbase_01 = “”
nocase ascii wide
$py_tsbase_02 =
“.TsBase(” nocase ascii wide

$py_tshi_01 = “” nocase ascii
$py_tshi_02 = “keystate” nocase
ascii wide
$py_tshi_03 =
“GetProjectInfo” nocase ascii wide
$py_tshi_04 = “GetProgramTable” nocase ascii
$py_tshi_05 =
“SafeAppendProgramMod” nocase ascii wide
$py_tshi_06 = “.TsHi(” ascii nocase wide

$py_tslow_01 = “” nocase ascii
$py_tslow_02 =
“print_last_error” ascii nocase wide
$py_tslow_03 = “.TsLow(” ascii nocase wide
$py_tslow_04 = “tcm_” ascii wide
$py_tslow_05 = ” TCM found” nocase ascii

$py_crc_01 = “crc.pyc” nocase
ascii wide
$py_crc_02 =
“CRC16_MODBUS” ascii wide
= “Kotov Alaxander” nocase ascii wide
$py_crc_04 = “CRC_CCITT_XMODEM” ascii wide
$py_crc_05 = “crc16ret” ascii wide
$py_crc_06 = “CRC16_CCITT_x1D0F” ascii
$py_crc_07 = /CRC16_CCITT[^_]/ ascii

$py_sh_01 = “sh.pyc” nocase
ascii wide

$py_keyword_01 = ”
FAILURE” ascii wide
$py_keyword_02 =
“symbol table” nocase ascii wide

$py_TRIDENT_01 = “inject.bin” ascii nocase
$py_TRIDENT_02 = “imain.bin”
ascii nocase wide

of ($python_*) and 7 of ($py_*) and filesize < 3MB

Go to Source
Author: Blake Johnson