Floki Bot is a new malware variant that has recently been offered for sale on various darknet markets. It is based on the same codebase that was used by the infamous Zeus trojan, the source code of which was leaked in 2011. Rather than simply copying the features that were present within the Zeus trojan “as-is”, Floki Bot claims to feature several new capabilities making it an attractive tool for criminals. As Talos is constantly monitoring changes across the threat landscape to ensure that our customers remain protected as threats continue to evolve, we took a deep dive into this malware variant to determine the technical capabilities and characteristics of Floki Bot.
During our analysis of Floki Bot, Talos identified modifications that had been made to the dropper mechanism present in the leaked Zeus source code in an attempt to make Floki Bot more difficult to detect. Talos also observed the introduction of new code that allows Floki Bot to make use of the Tor network. However, this functionality does not appear to be active for the time being. Finally, through the use of the FIRST framework during the analysis process, Talos was able to quickly identify code/function reuse between Zeus and Floki Bot. This made sample analysis more efficient and decreased the amount of time spent documenting various functions present within the Floki Bot samples we analyzed.
Talos worked in collaboration with Flashpoint during the analysis of Floki Bot. This collaborative effort allowed Talos and Flashpoint to quickly communicate intelligence data related to active campaigns distributing Floki Bot as well as data regarding the technical functionality present within the malware. Additionally, Talos is making scripts available to the open source community that will help malware analysts automate portions of the Floki Bot analysis process and make the process of analyzing Floki Bot easier to perform.
Talos is pleased to announce the release of the Function Identification and Recovery Signature Tool (FIRST). It is an open-source framework that allows sharing of knowledge about similar functions used across file types that IDA Pro can analyze. The aim is to create a community for the infosec analysts and reverse engineers that promotes the sharing of information.
The main idea behind FIRST is to preserve an engineer’s analysis of certain functions (name, prototype, comment, etc) by using methods like opcode hashing, mnemonic hashing, locality sensitive hashing, etc. By collecting and storing these signatures centrally the framework can provide them later to the community via the API/Plugin. The goal is to provide quick lookups for similar functions (see Fig. A) to avoid losing time with analysing a function which was already analysed before in another sample or by another engineer.
Talos is continuously analyzing email based malware always looking at how adversaries change and the new techniques that are being added on an almost constant basis. Recently we noticed some novel ways that adversaries are leveraging Google and Tor2Web proxies to spread a ransomware variant, Cerber 5.0.1.
This particular campaign looks to have started on November 24th and has been ongoing for the past several days. This campaign did not use advanced techniques that we sometimes see used by adversaries that include well written, professional looking emails, with legitimate signature blocks or other identifying characteristics. In this campaign, the emails were anything but professional. However, they did vary significantly with what we typically see from a ransomware distribution perspective.
Today, spam based ransomware infections are heavily skewed toward Locky. The majority of spam messages we see today are affiliates producing large amounts of spam that leverage various types of script-based file extensions to download the Locky executable and infect systems. This campaign looked different in that the messages didn’t contain an attachment and were extremely short and basic. What we found was a potential next evolution for ransomware distribution that relies more heavily on Tor to obfuscate their activity and hinder the ability to shut down servers that are hosting the malicious content.
Responsible disclosure of vulnerabilities is a key aspect of security research. Often, the difficulty in responsible disclosure is balancing competing interests – assisting a vendor with patching their product and notifying the general public to prevent a 0-day situation. It is uncomfortable to acknowledge that if a white hat team has discovered a vulnerability in a high value target, it stands to reason their adversaries may also be trying to exploit the same issue. Researchers must carefully balance the needs and capabilities of vendors to fix a product with the safety and security of our customers and the community as a whole.
Talos has been measuring the timelines, industry responsiveness, and end results with regard to our responsible disclosure policy and today, we are announcing a few changes. The full text of the Vendor Vulnerability Reporting and Disclosure Policy can be found here:
http://www.cisco.com/c/en/us/about/security-center/vendor-vulnerability-policy.html. These changes include timeline adjustments based on vendor feedback and industry changes since we last addressed our Disclosure Policy.
This post authored by Nick Biasini
Talos is constantly monitoring the threat landscape including the email threat landscape. Lately this landscape has been dominated with Locky distribution. During a recent Locky vacation Talos noticed an interesting shift in file types being used to distribute another well known malware family, Fareit.
We’ve discussed Fareit before, it’s a trojan used to steal credentials and distribute multiple different types of malware. The focus of this post will not be on Fareit but on a new way attackers are working to distribute it via email. Locky has been a case study in how to leverage different file extensions in email to distribute malware. The use of various file types such as .js, .wsf, and .hta have been used quite successfully for Locky. We’ve already noted other threats making use of .js for distribution largely due to Locky’s success. Recently we observed another uncommon file type associated with email and decided to dig a little further on the infection chain.
Crash triaging can be a long and complicated process; by using proper tools and having an optimal approach, we can make this a bit easier and less time consuming. In this post we describe a triaging strategy and toolset based on two examples of vulnerability classes:
- Stack based buffer overflow
- Heap based buffer overflow / Heap corruption