Attacks/Breaches

12/20/2017
05:36 PM
Kelly Sheridan
Kelly Sheridan
Slideshows
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%

9 Banking Trojans & Trends Costing Businesses in 2017

New Trojans appeared, old ones resurfaced, and delivery methods evolved as cybercriminals set their sights on financial data.
Previous
1 of 10
Next

(Image: Muratart via Shutterstock)

(Image: Muratart via Shutterstock)

Banking Trojans have been a recurring theme in security news this year as criminals find new ways to steal money and data from their victims.

"We have started to see the re-emergence of banker Trojans," says Bogdan Botezatu, senior e-threat analyst at Bitdefender, noting that banking Trojans had their heyday between 2012 and 2013. "But we could have sworn the trend was otherwise."

It's interesting to see banking Trojans resurface because of the resources they need to work. Unlike comparatively simple attacks like ransomware, banking malware requires several players and is difficult to launch and monetize. Botezatu suggests the rise could be attributed to both code leaks of other banking Trojans and an oversaturation of the ransomware market.

Many of the banking Trojans we've seen this year are reminiscent of those we've seen in the past. Others are old threats being distributed in new ways, targeting new victims.

Terdot, a banking Trojan first seen in October 2016, takes its inspiration from source code of the Zeus banking Trojan following Zeus' source code leak in 2011. IcedID, another new banking Trojan that emerged in September, shares traits with Gozi, Zeus, and Dridex.

"Overall, this is similar to other banking Trojans, but that's also where I see the problem," says Limor Kessem, executive security advisor for IBM Security, of IcedID. It's rare to see banking Trojans that don't share qualities with existing variants. Attackers are copying one another and adding new features like anti-evasion techniques to further advance the malware.

Here, we look back on the new and evolved ways banking Trojans targeted victims in 2017. Any threats we missed that should've made the list? Which do you think will stick around next year? Feel free to leave your thoughts in the comments and read on for more.

 

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance & Technology, where she covered financial ... View Full Bio

Previous
1 of 10
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
White House Cybersecurity Strategy at a Crossroads
Kelly Jackson Higgins, Executive Editor at Dark Reading,  7/17/2018
Lessons from My Strange Journey into InfoSec
Lysa Myers, Security Researcher, ESET,  7/12/2018
What's Cooking With Caleb Sima
Kelly Jackson Higgins, Executive Editor at Dark Reading,  7/12/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-14339
PUBLISHED: 2018-07-19
In Wireshark 2.6.0 to 2.6.1, 2.4.0 to 2.4.7, and 2.2.0 to 2.2.15, the MMSE dissector could go into an infinite loop. This was addressed in epan/proto.c by adding offset and length validation.
CVE-2018-14340
PUBLISHED: 2018-07-19
In Wireshark 2.6.0 to 2.6.1, 2.4.0 to 2.4.7, and 2.2.0 to 2.2.15, dissectors that support zlib decompression could crash. This was addressed in epan/tvbuff_zlib.c by rejecting negative lengths to avoid a buffer over-read.
CVE-2018-14341
PUBLISHED: 2018-07-19
In Wireshark 2.6.0 to 2.6.1, 2.4.0 to 2.4.7, and 2.2.0 to 2.2.15, the DICOM dissector could go into a large or infinite loop. This was addressed in epan/dissectors/packet-dcm.c by preventing an offset overflow.
CVE-2018-14342
PUBLISHED: 2018-07-19
In Wireshark 2.6.0 to 2.6.1, 2.4.0 to 2.4.7, and 2.2.0 to 2.2.15, the BGP protocol dissector could go into a large loop. This was addressed in epan/dissectors/packet-bgp.c by validating Path Attribute lengths.
CVE-2018-14343
PUBLISHED: 2018-07-19
In Wireshark 2.6.0 to 2.6.1, 2.4.0 to 2.4.7, and 2.2.0 to 2.2.15, the ASN.1 BER dissector could crash. This was addressed in epan/dissectors/packet-ber.c by ensuring that length values do not exceed the maximum signed integer.