TrickBot Adds ‘Cookie Grabber’ Information Stealing Module
Cofense Intelligence™ has identified a new credential information stealing module for the TrickBot banking trojan being used to gather web browser cookie data. Previous versions of TrickBot allowed for minimal web browser data theft; however, this ability was within the main functionality of the trojan platform and not a stand-alone module as it is now. This new module, dubbed ‘Cookie Grabber,’ has an added feature that allows for further control and manipulation of the victim’s host.
TrickBot is a modular banking trojan that targets financial information within an infected host. The threat actors behind TrickBot are always re-tooling and adapting to threat mitigation controls. By moving the web browser credential harvesting feature to a standalone module, threat actors trim down their initial footprint of infection. This adaption allows for fewer detections and the ability to download specific modules for better results after the infected host has been fingerprinted.
Safeguarding against this attack requires educating users about the importance of not saving credentials in the browser. For protection against other attacks, use technology to limit the number of times this type of payload gets to end users and educate them on the impacts these executables can have.
The ‘Cookie Grabber’ module is downloaded in the same fashion as the other modules used by TrickBot. This module’s stark difference is the ability to parse through web browser databases locally to extract the targeted information. The module is placed within the %APPDATA%/Roaming directory with the other downloaded modules, all of which include ‘cookiesDll64’ in the naming convention.
This information stealing module targets Firefox, Chrome, and Internet Explorer web browsers. With Internet Explorer, the module targets the text files that store browser cookie information located within the user profile directories, as shown in Figure 1 (Appendix A). Additionally, it targets Firefox and Chrome cookie information that is housed within a SQLite database on the local host. The ‘Cookie Grabber’ module appears to have pre-defined SQL queries to gather the targeted information from both Firefox and Chrome. This module also makes use of a SQLite 3 embedded engine to allow for further database manipulation from the threat actor.
Once the infection has taken hold on the victim’s machine and the modules have been downloaded, decoded, and injected into svchost.exe, the sample then attempts to exfiltrate the gathered information using two HTTP POST commands.
- The first HTTP POST is a form-data content-type to the Command and Control (C2) server containing other credentials harvested outside of the web browsers. Appended to the C2 URL is a unique string identifier containing host fingerprint information. This POST contains two distinct sections of information, one is the harvested credentials, the other is the source of the credentials. Figure 2 (Appendix B) shows the first HTTP POST to the C2 and contains FTP credentials gathered from the legitimate application, WinSCP.
- The second HTTP POST to the C2, shown in Figure 3 (Appendix B), has a different User-Agent string, which has changed from a legitimate value to ‘dpost.’ The dpost value comes from the name of the configuration file used and serves as an identifying marker for the TrickBot’s network traffic used while exfiltrating the data. The destination port has also changed from 80 to 8082. This second HTTP POST includes the harvested web browser information, which is base64 encoded. The encoded information appears to contain the user profile name, the browser the information was harvested from, the URL, user name, password, time last used, and time created. These values are separated by a pipe (‘|’) and resemble the format below:
‘User Profile | Web Browser | URL | User Name | Password | Timestamp | Timestamp |/’
Each record collected by TrickBot and exfiltrated through the HTTP POST is separated by a forward slash (‘/’) character. In both HTTP POSTs, the C2 server was named ‘Cowboy’ and replied with a HTTP 200 OK containing a small text response of ‘/1/’. Figure 2 (Appendix B) shows the first HTTP POST to the C2, while Figure 3 (Appendix B) shows the second HTTP POST to the same C2. Notice the User-Agent value differences as well as the base64 encoded data strings within the second HTTP POST.
CofenseTM encourages organizations to train users to be cautious in clicking links or opening attachments that could lead to harmful malware being installed on their machine. It’s also important to encourage users to report a suspicious message even if they clicked on the link or opened the attachment as malware can still get installed in the background.
The appendices below contain figures related to this sample of TrickBot. For more information please contact [email protected]
Figure 1: Locations that ‘Cookie Grabber’ searched for Internet Explorer cookies
Figure 2: The First HTTP POST to the C2 containing gathered non-web browser related credentials
Figure 3: The second HTTP POST to the C2 containing the base64 encoded credential strings
HOW COFENSE CAN HELP
89% of phishing threats delivering malware payloads analyzed by the Cofense Phishing Defense CenterTM bypassed email gateways. Consume phishing-specific threat intelligence to proactively defend your organization against evolving threats with Cofense IntelligenceTM.
Following are links to other blog posts on Trickbot:
All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks.