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.

Risk

10/1/2008
09:26 PM
George V. Hulme
George V. Hulme
Commentary
50%
50%

Authorities May Know Identity Of Gpcode Author

The author of the so-called ransomware virus Gpcode may have made a serious mistake when he or she recently approached Kaspersky Lab to attempt to sell a tool that would decrypt victims' files.

The author of the so-called ransomware virus Gpcode may have made a serious mistake when he or she recently approached Kaspersky Lab to attempt to sell a tool that would decrypt victims' files.You may have heard of, hopefully secondhand, the well-known (but not so widely spread) hunk of ransomware which will encrypt a wide range of files -- DOC, TXT, PDF, XLS, images, and other file types -- and then demand a "ransom" payment for the key necessary to decrypt the files.

Well, according to a story that ran in The Register today, the author messed up:

Kaspersky Labs [sic] was recently contacted by someone claiming to offer a decryption tool for the latest variant of the malware, Techworld reports. This tool turned out to be genuine, establishing that the scammer had access to the master keys used by the malware. This, in turn, prompted Kaspersky analysts to search for the IP address of the author.

Although he used compromised machines and proxies, enough circumstantial evidence was obtained in order to pin down a probable suspect in Russia. Techworld reports that no action has been taken as yet.

Unfortunately, it doesn't look like the Russian authorities are interested in hoping on the case. From the Techworld story referenced by The Register:

Tracking down the owners of these PCs proved extremely difficult, with service provider Yahoo, for one, allegedly refusing to cooperate with the investigation on privacy grounds. Foreign police were informed, however, as were the Russian authorities. Armed with enough circumstantial evidence, "they were interested," the Kaspersky source confirmed.

To date, it is not clear what if any action the authorities plan to take.

We covered Gpcode earlier this year, here and here.

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
Why Vulnerable Code Is Shipped Knowingly
Chris Eng, Chief Research Officer, Veracode,  11/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-16123
PUBLISHED: 2020-12-04
An Ubuntu-specific patch in PulseAudio created a race condition where the snap policy module would fail to identify a client connection from a snap as coming from a snap if SCM_CREDENTIALS were missing, allowing the snap to connect to PulseAudio without proper confinement. This could be exploited by...
CVE-2018-21270
PUBLISHED: 2020-12-03
Versions less than 0.0.6 of the Node.js stringstream module are vulnerable to an out-of-bounds read because of allocation of uninitialized buffers when a number is passed in the input stream (when using Node.js 4.x).
CVE-2020-26248
PUBLISHED: 2020-12-03
In the PrestaShop module "productcomments" before version 4.2.1, an attacker can use a Blind SQL injection to retrieve data or stop the MySQL service. The problem is fixed in 4.2.1 of the module.
CVE-2020-29529
PUBLISHED: 2020-12-03
HashiCorp go-slug before 0.5.0 does not address attempts at directory traversal involving ../ and symlinks.
CVE-2020-29534
PUBLISHED: 2020-12-03
An issue was discovered in the Linux kernel before 5.9.3. io_uring takes a non-refcounted reference to the files_struct of the process that submitted a request, causing execve() to incorrectly optimize unshare_fd(), aka CID-0f2122045b94.