What can we learn from the Stealer Logs?
The last couple of months have been a wild ride in the breached credentials space. With the prevalence of 'stealer logs' distributed on telegram taking the spotlight. Stealer logs are records created by malware that is present on someone’s device recording the url, username/email, and password whenever they log into a website. These logs are then uploaded in real-time or near real-time to telegram to be used by cyber criminals. The criminals pay a weekly or monthly fee to get access to these telegram channels, which can be as low as $50 per month. As a side effect of some other research that we have been doing recently we got unpaid access to some of these services which has shown some interesting results! (Watch this space for another drop soon).
The majority of security research and tooling that is published online is US/Europe/China-centric. As a small nation New Zealand benefits massively from the open sharing of research by the community that we would never have the people power to complete all of on our own. However, in some cases the research doesn’t apply universally. A great example of this is in breaches and password lists. Often breaches effect sites that few or no New Zealanders use, and the password lists that are then generated from these breaches to be used in hashcracking contain terms that are highly unlikely to be in passwords from NZ users, while missing key terms that are more likely to be used or having slight variations.
Examples of terms less likely to be NZ passwords:
This research is still underway and not really finished yet, but it highlights the point of trying to get access to up to date, relevant password breaches to see what passwords Kiwis are using in practice. Initially we started with trying to use public breaches from recent years. However, after a little digging we were able to get access to some very up to date data that surprised even us. This included passwords that were as fresh as just a couple of days old. Further digging into the source of these credentials we found that they had come from stealer logs, of malware actively running on user’s devices.
The affected users didn’t appear to belong to any discernible group, spanned the world in terms origin, and included both technical and non-technical people. In short, it didn’t appear to be at all targeted. Instead going wide in terms of catchment. We were able to isolate some instances of credentials that belonged to New Zealand businesses through email domains.
The most interesting part was that the credentials largely appeared to be valid. After contacting some of the affected businesses to notify them that their users had been compromised they were able to verify that the credentials were valid and did provide access to both public-facing and internal systems. Several businesses noted that they had seen an uptick in login attempts against the specific user accounts that we found, but they had been unsure of why.
How did this happen?
You’re probably thinking “We have the best Endpoint Detection available, so there is no way this effects me”. You’re also probably wrong.
As mentioned in the first paragraph the credentials were being sourced from ‘stealer logs’ that come from malware infected devices. Malware can make its way onto the devices of you or your staff in hundreds of different ways. In an attachment on an email they run, that VS Code plugin that they downloaded from a seemingly trustworthy site that was “NEEDED” to do their job, or even from the cracked version of Hello Kitty Island Adventure that they ran on their personal computer before logging into their work email.
That last example might seem a little contrived, and the cracked software being Hello Kitty Island Adventure part is, but the core of it remains the truth behind a lot of the affected users. People are much more willing to download suspicious software on their personal devices than their work computers, or perhaps their kids downloaded the game? Only for them to log into their work email months later because they left their laptop at the office and had to send an update that they were sick for the day.
The point is that it isn’t always as simple as having a full hardened work device, to protect against being affected by malware.
What can we do to fix this?
User’s are going to get their accounts breached. It’s become a fact of modern security. We can and should provide users with meaningful security awareness training to help protect them from modern threats, but we should also assume that its going to fail and their passwords are going to get breached. Below we’ll discuss six key ways that you prevent, detect, and respond to accounts being breached.
Long Complex Unique Passwords and Password Managers
The best offense is a good defence. Preventative measures such as long complex unique passwords and MFA help to ensure that even if a password is compromised, the attacker can only use it against the one site it’s good for. Providing users with a password manager solution helps to remove the requirement of remembering passwords so that long complex unique passwords can be set for every service.
MFA
Requiring users to have MFA on all business systems means that even if their password gets stolen, attackers wouldn’t be able to get into the account without also compromising their MFA. Google started rolling out Yubikeys to all of their 50,000 staff in 2009, also noting a 92% reduction in support incidents.
Threat Intel
Accounts being breached has become a fact of life. It’s going to happen. But the sooner it is identified, the sooner corrective action can be taken. There are publicly available sources that can be used as a starting point. Such as HaveIBeenPwned NotifyMe, DomainSearch, and API. However, these services often have a barrier to entry, don’t include the latest logs, and won’t include the user’s password. This can make it difficult to verify the validity of the breach and whether it is an old password. Get in touch with us if you have a query and we can discuss getting access to higher fidelity and more up-to-date threat intel.
Monitoring
Once an attacker has got into an environment it’s not too late to detect and contain them. By using behavioural monitoring and anomaly detection it’s possible to detect when user’s behaviour differentiates from their normal routine. Get in touch with Cythera and they can provide you with an overview of how their detection works and its effectiveness at detecting real instances of compromise.
Blast Radius Reduction
If all else fails and the attackers have gotten in, the controls that limit access to systems and data can be what stops an attacker from accessing sensitive data. The number of completely flat networks in New Zealand organisations makes it often trivial to move from an initial breach to accessing database servers, OT environments, or taking over the domain. Consider running an internal network penetration test to find the issues and engaging a security engineer to help redesign the network to limit the ability for an attacker to move around.
Standard Operating Procedures
Having pre-planned and tested playbooks to help deal with incidents significantly reduces the stress of undergoing and incident. They can also make the difference in containing the threat or having them exfiltrate sensitive information when decisive action can be taken. Paolo Tonetti, our resident table-top exercise expert can help you run through these scenarios and to develop some response plans.
?
As a summary, the activities to implement as a priority if they aren’t already: