TreasureHunter Point-of-Sale Malware and Builder Source Code Leaked

The source code for a longstanding point-of-sale (PoS) malware family called TreasureHunter has been leaked on a top-tier Russian-speaking forum. Compounding the issue is the coinciding leak by the same actor of the source code for the malware’s graphical user interface builder and administrator panel.

The availability of both code bases lowers the barrier for entry for cybercriminals wishing to capitalize on the leaks to build their own variants of the PoS malware.

Point-of-sale malware has been at the root of many breaches, including massive thefts at retailers Target in 2013 and Home Depot in 2014; in each case attackers were able to extract more than 100 million payment card and customer records from point-of-sale terminals by scraping card data before it was encrypted and sent to the payment processor. Both retail giants paid tens of millions of dollars in settlements, and in Target’s case, its chief executive officer resigned his position.

Industry Collaboration on Detection and Prevention

TreasureHunter has been known and investigated since 2014, but until now investigators have had to reverse-engineer its code in order to analyze it. Now with the full code available, analysts have previously unseen insight into the malware’s operation. Flashpoint analysts, who discovered the source code leak in March, proactively collaborated with researchers at Cisco Talos, who reviewed and improved protections, and advanced-detection mechanisms, in an effort to disrupt potential copycats who may have their hands on the source code.

In the meantime, Russian-speaking cybercriminals have been observed on the vetted underground discussing improvements and weaponization of the leaked TreasureHunter source code. Notably, the original developer appears to be a Russian speaker who is proficient in English. Originally, this malware appears to have been developed for the notorious underground shop dump seller “BearsInc,” who maintained presence on various low-tier and mid-tier hacking and carding communities (below is a graphical representation of such an operation on the Deep & Dark Web). It’s unknown why the source code was leaked at this time.

A graphical representation of a typical cybercrime dump shop ecosystem.

Image 1: A graphical representation of a typical cybercrime dump shop ecosystem.

One Leak Can Spawn Many Variants

TreasureHunter behaves like many other point-of-sale malware samples. Once an attacker has access to a Windows-based server and the point-of-sale terminal, the malware is installed and it establishes persistence by creating a registry key that runs the malware at startup. It then enumerates running processes, and scans device memory looking for track data, including primary account numbers (PANs), separators, service codes, and more. It then establishes a connection with the attacker’s command and control server and sends the stolen data to the criminal.

The leak of the builder adds another dimension to the availability of the TreasureHunter payload and configurations. In the past, malware source code leaks such as the Zeus banking Trojan have spawned numerous variants, including Citadel, which cost organizations hundreds of millions in losses. PoS malware leaks have had similar effects, most notably with the 2015 leak of the Alina malware which led to the creation of the ProPoS and Katrina variants. The actor behind the TreasureHunter leak said:

“Besides alina, vskimmer and other sniffers, Treasure Hunter still sniffs ( not at a very high rate, but it still does ) and besides that , since now you have the source code, it can be update anytime for your own needs.”

For researchers, the availability of the source code opens the door into new avenues of analysis and proactive visibility into such activity on the underground. This affords organizations such as Flashpoint the ability to collaborate with others in the industry such as Cisco Talos in this case to improve existing protections and force attackers back to the drawing board.

Source-Code Level Insight

The code project appears to be called internally trhutt34C, and was written in pure C with no C++ features. It was compiled originally in Visual Studio 2013 on Windows XP. Based on analysis, researchers believe the developer intended to improve and redesign various features including anti-debugging, code structure improvement, and gate communication logic. With the goal of additional features to be improved, the developer hoped frustrate malware analysis and subsequent research; the actor left behind a note that said: “We want the malware researchers screamin’!”

A snapshot of the TreasureHunter source code.

Image 2: A snapshot of the TreasureHunter source code.

The unfinished project included continued improvement code snippets, below:

  • TO DO for the next version of the client (0.2 Beta):
    • Replace all Unicode versions of functions with ANSI versions. Now why did I ever go for wide-char in the first place?..
  • Improve the code structure:
    • Replace all the if – else constructs that are rendered needless by return commands;
    • Organize the includes;
    • Give the code proper commenting so that I am able to modify and improve it after not having seen it for some time (if such a thing happens).
    • Make scan exceptions and service codes configurable.
    • Add the following commands to the gate communication logic:
    • Download and execute for updating;
    • Remote CMD command execution;
    • Remote self-removal for emergency cases.
    • Add anti-debugging:
      • Use self-debugging by creating a child process (may be improved later by reversing the tables);
      • Improve the MD5 function and use it to find debuggers by signatures (maybe to be added in future versions);
      • Use GetTickCount to detect parts of code being stepped through (maybe to be added in a “heuristical” joint algorithm with the abovementioned);
      • Upon finding a debugger, destroy the critical section and/or start creating new threads infinitely until the application crashes.
      • Maybe also kill processes and delete debuggers and/or decompilers permanently. We want the malware researchers screamin’!
  • Add better persistency and timeouts to gate communication.
  • Add local saving of data if the gate can’t be reached for a certain period of time.
  • Add the option to run the program as a service on Windows XP.
  • Improve the code structure and add comments to avoid future confusion.
  • Add error handling and backup restart in case of crash or heap overflow (malloc fail).
  • Improve the Clingfish system (so that a clingfish thread doesn’t do the same thing as the main thread right after being spawned).
  • Debug the system information extraction mechanism further (on different OS versions).
  • Improve the track-finding algorithm to make it faster.

The stolen dump structure is as follows. The structure contains the following key elements used to collect and operate with stolen dumps, such as unique machine information and where scraped data is from:

typedef struct dumpsHolder {
TCHAR *lpFileName;
int lpFileNameLength;
int procID;
char *trackArr;
int trackArrLength;
} dumpsHolder;

The credit card process scan works in exception mode:

char *scanExceptions[SCANEXCEPTIONSNUM] = {“System32”, “SysWOW64”, “\Windows\explorer.exe”};

The malware focuses on scraping credit card track data, focusing on the following service codes:

char *serviceCodes[SERVICECODESNUM] = {“101”, “201”, “121”, “231”, “221”, “110”};

Registry persistence for autostart in HKLMMicrosoftWindowsCurrentVersionRun runs as “jucheck.”

A registry key created by the malware for persistence

Image 3: A registry key created by the malware for persistence.

The source code is consistent with the various samples that have been seen in the wild over the last few years. TreasureHunterconfig.h shows definite signs of modification over the lifespan of the malware. Early samples filled all of the configurable fields with FIELDNAME_PLACEHOLDER to be overwritten by the builder. More recent samples, and the source code, instead writes useful config values directly into the fields. This makes the samples slightly smaller and uses fresh compiles to create reconfigured files.

The post TreasureHunter Point-of-Sale Malware and Builder Source Code Leaked appeared first on Flashpoint.

Go to Source
Author: Flashpoint

New Point-of-Sale Malware Steals Credit Card Data via DNS Queries

pos-malware-dns

Cybercriminals are becoming more adept, innovative, and stealthy with each passing day. They are now adopting more clandestine techniques that come with limitless attack vectors and are harder to detect.

A new strain of malware has now been discovered that relies on a unique technique to steal payment card information from point-of-sale (PoS) systems.

Since the new POS malware relies upon User Datagram Protocol (UDP) DNS traffic for the exfiltration of credit card information, security researchers at Forcepoint Labs, who have uncovered the malware, dubbed it UDPoS.

Yes, UDPoS uses Domain Name System (DNS) queries to exfiltrate stolen data, instead of HTTP that has been used by most POS malware in the past. This malware is also thought to be first of its kind.

Besides using ‘unusual’ DNS requests to exfiltrate data, the UDPoS malware disguises itself as an update from LogMeIn—a legitimate remote desktop control service used to manage computers and other systems remotely—in an attempt to avoid detection while transferring stolen payment card data pass firewalls and other security controls.

“We recently came across a sample apparently disguised as a LogMeIn service pack which generated notable amounts of ‘unusual’ DNS requests,” Forcepoint researchers said in a blogpost published Thursday.

“Deeper investigation revealed something of a flawed gem, ultimately designed to steal magnetic stripe payment card data: a hallmark of PoS malware.”

The malware sample analyzed by the researchers links to a command and control (C&C) server hosted in Switzerland rather than the usual suspects of the United States, China, Korea, Turkey or Russia. The server hosts a dropper file, which is a self-extracting archive containing the actual malware.

It should be noted that the UDPoS malware can only target older POS systems that use LogMeIn.

Like most malware, UDPoS also actively searches for antivirus software and virtual machines and disable if find any. The researchers say it’s unclear “at present whether this is a reflection of the malware still being in a relatively early stage of development/testing.”

Although there is no evidence of the UDPoS malware currently being in use to steal credit or debit card data, the Forcepoint’s tests have shown that the malware is indeed capable of doing so successfully.

Moreover, one of the C&C servers with which the UDPoS malware sample communicates was active and responsive during the investigation of the threat, suggesting the authors were at least prepared to deploy this malware in the wild.

It should be noted that the attackers behind the malware have not been compromised the LogMeIn service itself—it’s just impersonated. LogMeIn itself published a blogpost this week, warning its customers not to fall for the scam.

“According to our investigation, the malware is intended to deceive an unsuspecting user into executing a malicious email, link or file, possibly containing the LogMeIn name,” LogMeIn noted.

“This link, file or executable isn’t provided by LogMeIn and updates for LogMeIn products, including patches, updates, etc., will always be delivered securely in-product. You’ll never be contacted by us with a request to update your software that also includes either an attachment or a link to a new version or update.”

According to Forcepoint researchers, protecting against such threat could be a tricky proposition, as “nearly all companies have firewalls and other protections in place to monitor and filter TCP- and UDP-based communications,” but DNS is still often treated differently, providing a golden opportunity for hackers to leak data.

Last year, we came across a Remote Access Trojan (RAT), dubbed DNSMessenger, that uses DNS queries to conduct malicious PowerShell commands on compromised computers, making the malware difficult to detect onto targeted systems.

Go to Source

Forever 21 Confirms Security Breach Exposed Customer Credit Card Details

 

Forever-21-breach

First notified in November of a data breach incident, popular clothing retailer Forever 21 has now confirmed that hackers stole credit card information from its stores throughout the country for several months during 2017.

Although the company did not yet specify the total number of its customers affected by the breach, it did confirm that malware was installed on some point of sale (POS) systems in stores across the U.S. at varying times between April 3, 2017, and November 18, 2017.

According to the company’s investigation, which is still ongoing, the malware was designed to search for and likely steal sensitive customer credit card data, including credit card numbers, expiration dates, verification codes and, in some cases, cardholder names.

Forever 21 has been using encryption technology since 2015 to protect its payment processing systems, but during the investigation, the company found that some POS terminals at certain stores had their encryption switched off, which allowed hackers to install the malware.

However, according to the company, not every POS terminal in affected stores was infected with the malware and not every store was impacted during the full-time period (roughly 8 months) of the breach.

In fact, in some cases, payment card data stored in certain system logs before April 3rd were also exposed in the breach.

“Each Forever 21 store has multiple POS devices, and in most instances, only one or a few of the POS devices were involved. Additionally, Forever 21 stores have a device that keeps a log of completed payment card transaction authorizations,” the company said while explaining the incident.

“When encryption was off, payment card data was being stored in this log. In a group of stores that were involved in this incident, malware was installed on the log devices that was capable of finding payment card data from the logs, so if encryption was off on a POS device prior to April 3, 2017, and that data was still present in the log file at one of these stores, the malware could have found that data.”

The company also assured its online customers that payment cards used on its website (forever21.com) were not affected by the breach.

Since payment processing systems outside of the United States work differently, it should not be impacted by the security breach, but the retailer said it’s still investigating whether non-US stores were affected or not.

Forever 21 advised customers who shopped at its stores to stay vigilant and keep an eye on their credit transactions for any suspicious activity, and immediately notify their banks that issued the card if found any.

The company has promised to continue working with “security firms to enhance” their security measures.

This breach is yet another embarrassing incident disclosed recently, followed by Disqus’ disclosure of a 5-year-old breach of over 17.5 million Disqus users and Yahoo’s revelation that 2013 data breach affected all of its 3 Billion users.

The recent incidents also include Equifax’s revelation of a breach of potentially 145.5 million customers, U.S. Securities and Exchange Commission (SEC) disclosure of a data breach that profited hackers, and Deloitte’s disclosure of a cyber attack that led to the theft of its clients’ private emails and documents.

Go to Source

Newly Uncovered ‘MoneyTaker’ Hacker Group Stole Millions from U.S. & Russian Banks

hacking-bank-account

Security researchers have uncovered a previously undetected group of Russian-speaking hackers that has silently been targeting Banks, financial institutions, and legal firms, primarily in the United States, UK, and Russia.

Moscow-based security firm Group-IB published a 36-page report on Monday, providing details about the newly-disclosed hacking group, dubbed MoneyTaker, which has been operating since at least May 2016.

In the past 18 months, the hacking group is believed to have conducted more than 20 attacks against various financial organisations—stolen more than $11 Million and sensitive documents that could be used for next attacks.

According to the security firm, the group has primarily been targeting card processing systems, including the AWS CBR (Russian Interbank System) and SWIFT international bank messaging service (United States).

Criminals stole documentation for OceanSystems’ FedLink card processing system, which is used by 200 banks in Latin America and the US.” Group-IB says in its report.

Group-IB also warned that the MoneyTaker attacks against financial organizations appear to be ongoing and banks in Latin America could be their next target.

MoneyTaker: 1.5 Years of Silent Operations

Since its first successful attack in May last year, MoneyTaker has targeted banks in California, Illinois, Utah, Oklahoma, Colorado, South Carolina, Missouri, North Carolina, Virginia and Florida, primarily targeting small community banks with limited cyber defenses.

Even after a large number of attacks against so many targets, MoneyTaker group managed to keep their activities concealed and unattributed by using various publicly available penetration testing and hacking tools, including Metasploit, NirCmd, psexec, Mimikatz, Powershell Empire, and code demonstrated as proof-of-concepts at a Russian hacking conference in 2016.

“To propagate across the network, hackers used a legitimate tool psexec, which is typical for network administrators.” Group-IB says in its report.

money-taker

Besides using open-source tools, the group has also been heavily utilizing Citadel and Kronos banking trojansto deliver a Point-of-Sale (POS) malware, dubbed ScanPOS.

“Upon execution, ScanPOS grabs information about the current running processes and collects the user name and privileges on the infected system. That said, it is primarily designed to dump process memory and search for payment card track data. The Trojan checks any collected data using Luhn’s algorithm for validation and then sends it outbound to the C&C server.”

The group uses ‘fileless’ malware only existing in RAM and is destroyed after reboot. To ensure persistence in the system MoneyTaker relies on PowerShell and VBS scripts – they are both difficult to detect by antivirus and easy to modify. In some cases, they have made changes to source code ‘on the fly’ – during the attack,

 “To escalate privileges up to the local administrator (or SYSTEM local user), attackers use exploit modules from the standard Metasploit pack, or exploits designed to bypass the UAC technology. With local administrator privileges they can use the Mimikatz program, which is loaded into the memory using Meterpreter, to extract unencrypted Windows credentials.

Moreover, MoneyTaker also makes use of SSL certificates generated using names of well-known brands—including as Bank of America, Microsoft, Yahoo and Federal Reserve Bank—to hide its malicious traffic.

hacking-banks

The hacking group also configure their servers in a way that malicious payloads can only be delivered to a predetermined list of IP addresses belonging to the targeted company. Also, it relies on PowerShell and VBS scripts to ensure persistence in the targeted system.

The very first attack, which Group-IB attributes to MoneyTaker was conducted in May 2016, when the group managed to gain access to First Data’s STAR—the largest U.S. bank transfer messaging system connecting ATMs at over 5,000 organizations—and stole money.

In January 2017, the similar attack was repeated against another bank.

Here’s how the attack works:

“The scheme is extremely simple. After taking control over the bank’s network, the attackers checked if they could connect to the card processing system. Following this, they legally opened or bought cards of the bank whose IT system they had hacked,” Group-IB explains.

“Money mules – criminals who withdraw money from ATMs – with previously activated cards went abroad and waited for the operation to begin. After getting into the card processing system, the attackers removed or increased cash withdrawal limits for the cards held by the mules.”

The money mules then removed overdraft limits, which made it possible for them to overdraw cash even with debit cards. Using these cards, they “withdrew cash from ATMs, one by one.”

According to the report, the average money stolen by MoneyTaker from United States banks alone was about $500,000, and more than $3 million was stolen from at least three Russian banks.

The report also detailed an attack against a Russian bank, wherein the MoneyTaker group used a modular malware program to target the AWS CBR (Automated Work Station Client of the Russian Central Bank)—a Russian interbank fund transfer system similar to SWIFT.

The modular tool had capabilities to search for payment orders and modify them, replace original payment details with fraudulent ones, and carefully erase malware traces after completing its tasks.

While it is still unclear how MoneyTaker managed to get its foothold in the corporate network, in one specific case, the entry point of compromise of the bank’s internal network was the home computer of the bank’s system administrator.

Group-IB believes that the hackers are now looking for ways to compromise the SWIFT interbank communication system, although it found no evidence of MoneyTaker behind any of the recent cyber attacks on SWIFT systems.

Go to Source