Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

12/13/2019
03:15 PM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

Visa Warns of Targeted PoS Attacks on Gas Station Merchants

At least two North American chains have been hit in sophisticated new campaigns for stealing payment card data.

Point of Sale (PoS) systems belonging to at least two North American gas station merchants and a hospitality chain have been attacked over the last few months by what Visa this week described as sophisticated cybercrime groups looking to harvest payment card data.

Unlike card theft operations where criminals attach hidden skimmers to card readers at gas pumps and other PoS systems, the latest attacks have involved the use of malware on the backend systems that merchants use to process card transactions. As a result, the attacks were a lot more sophisticated, Visa said in an alert.

"It is important to note that this attack vector differs significantly from skimming at fuel pumps, as the targeting of POS systems requires the threat actors to access the merchant’s internal network, and takes more technical prowess than skimming attacks," Visa's alert said.

Visa's payment fraud division have identified at least three separate attacks targeting PoS systems since August. Two of them appear to have been carried out by FIN8, a threat group that has previously been associated with numerous attacks on PoS systems.

In one of the attacks that Visa identified this summer, the breach began when an employee at one of the gas station chains that was hit, clicked on a link in a phishing email and accidentally downloaded a Remote Access Trojan. The attackers used the Trojan to conduct reconnaissance on the breached network and eventually to move laterally into the merchant's PoS environment where they deployed a RAM memory scraper for harvesting payment card data.

The modus operandi was similar in the second incident as well, but investigators have so far been unable to determine how the attackers got initial access to the merchant's network, Visa said. In the second incident, the targeted gas station merchant accepted both chip transactions and magnetic stripe payments for in-store payments and only magnetic stripe payments at the gas pumps. Visa's analysis shows the attackers specifically targeted the mag stripe data, the company said.

Visa's alert did not mention how the attackers gained initial access to the network of the hospitality company though in that case as well, the attackers targeted the PoS system.

Sophisticated Cybercrime Groups

Telemetry from both of the latter two incidents suggested that FIN8 was involved, Visa said.  The command and control server used in the attack on the second merchant and the file used to store stolen payment card data for instance, have both been previously linked to FIN8. Similarly, the malware that was used in the hospitality chain attack is also something that FIN8 has used in the past.

Visa's alert did not identify the cybercrime group behind the first attack. But in the past it has warned about a group called FIN6 compromising multiple PoS environments via a malware tool called Trinity POS or FrameworkPOS.

Card-stealing attacks against gas station chains in particular are increasing because many have yet to implement the EMV smartcard standard for payment transactions, Visa said. Chip cards offer significantly better protection against card data theft and cloning, compared to cards using magnetic stripes to store account and cardholder information.

Visa, MasterCard, American Express, and other card companies have for some time required all organizations accepting payment card transactions to cut over to EMV chip card technology. The migration has been happening in a phased manner across industry sectors for several years. Fuel merchants have until October 2020 to enable chip acceptance at fuel pumps. After that date, the liability for breaches will shift to the merchants that experience the breach.

Visa and the other major credit card associations have also recommended the use of point-to-point encryption, tokenization and other measures for protecting card data. Some of these measures are mandatory requirements under the Payment Card Industry Data Security Standard (PCI DSS).

Despite such measures, the US payment card infrastructure has lagged considerably behind other countries that have long ago moved to Chip and PIN technology.  The continued use of magnetic stripes has made the US payment environment an attractive target for criminals in recent years.

“EMV chips were created to make it expensive to manufacture counterfeit cards or steal money by tampering with a card or a transaction," says Craig Young security threat researcher at Tripwire.

Chip-and-PIN enabled cards provide stronger defenses against misuse when lost or stolen though neither implementation eliminates the RAM scraping threats described in the Visa alert, he says. "Elimination of magnetic stripes would force adversaries to adjust their tradecraft," but not completely eliminate the threat he says.

Related Content:

Check out The Edge, Dark Reading's new section for features, threat data, and in-depth perspectives. Today's top story: "The Next Security Silicon Valley: Coming to a City Near You?"

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
6196200
50%
50%
6196200,
User Rank: Apprentice
12/16/2019 | 10:18:40 AM
Educated
Thank you very much for sharing helpful articles.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/28/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Can you smell me now?
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-11844
PUBLISHED: 2020-05-29
There is an Incorrect Authorization vulnerability in Micro Focus Service Management Automation (SMA) product affecting version 2018.05 to 2020.02. The vulnerability could be exploited to provide unauthorized access to the Container Deployment Foundation.
CVE-2020-6937
PUBLISHED: 2020-05-29
A Denial of Service vulnerability in MuleSoft Mule CE/EE 3.8.x, 3.9.x, and 4.x released before April 7, 2020, could allow remote attackers to submit data which can lead to resource exhaustion.
CVE-2020-7648
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.72.2 are vulnerable to Arbitrary File Read. It allows arbitrary file reads for users who have access to Snyk's internal network by appending the URL with a fragment identifier and a whitelisted path e.g. `#package.json`
CVE-2020-7650
PUBLISHED: 2020-05-29
All versions of snyk-broker after 4.72.0 including and before 4.73.1 are vulnerable to Arbitrary File Read. It allows arbitrary file reads to users with access to Snyk's internal network of any files ending in the following extensions: yaml, yml or json.
CVE-2020-7654
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.73.1 are vulnerable to Information Exposure. It logs private keys if logging level is set to DEBUG.