Another week, another Triage Thursday blogpost! As always we have a bundle of new and updated detections to go over, but for our customers we’re also happy to announce the release of SAML integration! More on getting started with that below.
On the detection side of things this week:
- New signatures and configuration extractor for Danabot
- New signatures and configuration extractor for Sality
- Added support for the Emotet spam module
- Updated IcedID configuration extractor to cover additional fields available in some older versions
- Updated detections and extractor for the BumbleBee family
We have also been doing some work in the background to improve performance on the Private Cloud infrastructure - several users had reported recently that they were experiencing noticeable delays loading some pages, and we have finally managed to track down and fix the elusive bug that was causing it. You should now notice that things are a lot quicker there, but if you come across any more issues let us know.
As always if you have any comments, suggestions or other feedback about Triage feel free to get in touch with us. You can reach us directly through the website, on Twitter, or using the Feedback option on an analysis report page.
Not signed up yet? Head over to tria.ge to register for a free account!
SAML Support
Note: This feature is only relevant to private cloud customers. Only standard SSO via Google/Github etc. is available on the public cloud
SAML has, unsurprisingly, been heavily requested over time. We understand the ability to administer SaaS applications from a centralised point is extremely helpful for teams who have to look after complex environments so we’re happy to now support this. It will enable you to control authentication for Triage under your existing identity provider, simplifying the process of adding new users and taking away the need to worry about password requirements or MFA.
Out of the box, our SAML integration supports Okta, Microsoft Azure and Google as providers. If you need any others added please feel free to reach out to us and we’ll be happy to discuss adding them in - we aimed to cover the main ones to start with but fully expect there will be others needed.
How to get started
By default SAML will be disabled for your organisation, so if you want to continue using the current username/password authentication then you don’t need to do anything. If you do want to switch over to SAML then just contact support using the email below and we’ll be happy to get that started for you.
You can find more specific details for each provider in our documentation, and if you have any questions or would like help with any part of the process just reach out to us at support@hatching.io.
Danabot
Danabot is a banking trojan/stealer which has been in widespread usage since mid-2018. The malware itself is modular including functions for browser injections/network sniffing, stealing credentials stored locally by a range of software, and remote access capability.
The family has gone through several iterations since it first released, and it appeared on this blog back in January with some minor tweaks to its structure. This time we observed a new loader component which was not properly handled by our configuration extractor and appears to have popped up in the wild fairly recently. We’ve now updated to address this.
Analyses:
Sality
Sality is probably one of the oldest malware familes we’ve featured on this blog, with initial versions dating all the way back to 2003. It has however seen regular updates over the years which have kept it relevant, adding features and adjusting its approach to fit with the current landscape.
The family’s functionality is fairly straightforward, basically acting as a remote access trojan/backdoor to allow an attacker to download and install additional malware as well as integrating the machine into a botnet. Early versions were quite advanced for the time, leveraging a now quite dated approach called Entry Point Obscuration (EPO) to hide the infection. In effect this involved adding a jump to a legitimate file’s code, so that when that instruction is hit execution will move to the malicious code instead of the actual file. The randomness of the locations for this meant it was quite difficult to locate and remove.
Modern variants can communicate over peer-to-peer networks with other infected systems as part of the botnet functionality, and they spread by infecting files on the computer so that they will trigger an infection whenever opened - this makes it able to spread via removable media or email attachments quite effectively, often unwittingly carried by the victim without any further actions from the attacker. This is especially effective since in most cases the infection will not be evident to a user, so it could be present on a system for some time without them being aware.
We have been seeing an unusual number of Sality samples appearing lately, so we decided it was time to add dedicated support for those. We have now built signatures and a full configuration extractor for the family which can dump out the C2 addresses being used.
Analyses:
Emotet
We’re back on Emotet again this week to continue expanding on our coverage for it. This week we’re just adding in dedicated support for the spam module deployed by the family post-infection, so that it will be detected and reported properly if submitted on its own or downloaded by the malware during a normal execution run.
This module is used to run spam campaigns using email accounts and contact lists from the infected system, leveraging compromised machines to propagate the malware to additional victims. This is not an unusual technique, but is still pretty effective as users tend to put more trust into emails they receive from known contacts than unknown senders.
We have taken a look at examples we’ve come across on Triage lately, and have built new detections for them to augment the existing Emotet support. Most of these we do not have permission to share here, but a public example is below for reference.
Analysis:
IcedID
IcedID has appeared on this blog a few times so we won’t go into the background again today. You can find some quick details in an earlier blogpost here, and we also revisited it in March to address a time delay technique affecting the results on Triage.
This week we’re not actually looking at a new variant of change, but going back in time to some earlier versions. A user recently submitted a number of old versions which had more data hardcoded than the current iterations, so to make sure we have comprehensive coverage of the family we took a look at improving our extractor to support the additional fields.
Some examples of these versions are below.
Analyses:
BumbleBee
BumbleBee is currently a very active family, having burst onto the scene quite recently. It has come up in a couple of our recent blogposts so we won’t go over the background in detail again here - if you’d like more information on that you can check out our original post or a writeup by Google’s Threat Analysis Group here.
This week just sees a few improvements to our detections and configuration extractor, including the addition of the GroupID field to the data we are able to display. This field is basically used to identify and link different botnets, and can sometimes have multiple values.
Analyses: