Corey Ham //
Use a password manager instead of browser storage for passwords, credit card numbers, and other autofill items.
Personal security: Do not save anything sensitive in your browser, especially credentials. This data will probably be spread further than you realize, and it can be accessed by malware. Consider deleting all credentials and autofills from your browser of choice.
Enterprise security: Prevent users from both saving credentials in browser credential stores and consider preventing users from logging into their browsers on enterprise-managed hosts. Enforce access controls that prevent users from signing into browsers on non-managed hosts, if possible. Monitor for credential abuse.
I do red team engagements for BHIS. These engagements are designed to cover the widest attack surface possible for a target entity. We operate with broad scoping — meaning we can attack any user, computer, application, or fax machine we identify as owned by the target, unless explicitly provided as out-of-scope ahead of time.
During a recent red team engagement, I gained access to employee credentials, browser cookies, screenshots of a user’s desktop, and some interesting files on the first day of testing. Now, you might be thinking this sounds like a brag about my god-tier hacker skills or that the target had terrible security if I managed to get that far on day one. The truth is, I probably didn’t even have command-and-control infrastructure set up yet, and the target had excellent security. So how did this happen? I found all this data in some Stealer Logs.
I first became aware of stealer logs at WWHF Deadwood 2022, where I had a great conversation with Mishaal Khan after his talk where he demonstrated using them for OSINT. I’m something of an OSINT fan myself, and the main data breach wrangler at BHIS, so I resolved to get my hands on some of this data and check it out for myself. I eventually managed to get heaps and heaps of it, totaling over 10TB of data. I then worked to process as much of the data as possible to make it searchable. I’ll spare you the boring details of this, but suffice it to say that black hat hackers are absolutely TERRIBLE at organizing files. Let me know if you’d like to see a separate blog post or webcast detailing how I processed the data and made it searchable in our private breach database.
For a quick overview of what the logs themselves look like, check out this excellent blog from IntelTechniques (https://inteltechniques.com/blog/2022/07/06/new-breach-data-lesson-ii-stealer-logs/).
A brief overview:
The malware doesn’t stick around for long, but grabs what it can and sends it off to a central server for processing. Once there, each victim’s data is packaged, and the data is sold on forums and telegram groups, often in large collections. They are not particularly expensive, with the average victim’s data costing cents or even fractions of a cent. For reference, a victim’s folder might look something like this:
The contents are pretty much self-explanatory. Some variants list what anti-virus programs are present, whether the process is elevated, and what UAC permissions the user has.
The screenshots of victim’s desktops are equal parts sad and hilarious. Some of them make me feel like I am way over-engineering my payloads…
So. back to the story.
As you’d probably imagine, reconnaissance is a huge part of a red team. I personally enjoy the recon process, as I use it to gather the situational awareness and confidence I need to execute attacks later on. The more I know about how the target entity operates, the more I can use it against them, especially during social engineering and post-exploitation. After I started processing stealer logs, I added searching for them to my recon workflow on all engagements; specifically, searching for client domains in the host field and username fields. This started turning up results almost immediately, but here’s a specific story that I think illustrates the risks well.
I discovered a result where one of the captured credentials had a URL like https://citrix.client.com/vpn/login. The username captured for this site appeared to be a valid username, but the password saved was a six digit number. This was likely a temporary MFA code, and we were unable to access the Citrix interface using the captured information.
I extracted and browsed through the user’s entire log folder, which contained roughly 67 sets of credentials but no other information we could leverage for initial access. We launched a long-running credential stuffing campaign targeting this user, using all the credentials listed in the stealer log. Bad for us (but good for the client), this attack was unsuccessful, and we hit smart lockout on that user’s account in all data centers.
Once we admitted defeat on using the data for initial access, we contacted the client to inform them of the situation, and to have them put us in touch with the victim. I wanted to provide the user with the full stealer log file archive, so they could attempt to invalidate all the information that had been disclosed. However, I was not comfortable with sharing the entire dump with the victim’s employer, given the personal nature of the data. At the same time, our client would not want to be responsible for transmitting and storing the user’s personal data. Eventually, we settled on sending the contents within an encrypted zip file, with the password being verbally exchanged over the phone. The victim was very polite and appreciative of the heads up, which I found admirable.
The part that surprised me the most was that the victim had no awareness that their computer was compromised, or even that their data was exposed. I asked if they had received spurious MFA push notifications, suspicious login notifications, or any other indicators of compromise, but they were aware of none. The malware executed over a year before I discovered it during this engagement. This leads me to believe that the attackers that collect this data must triage it and only act against the most valuable targets — those with credit cards, cryptocurrency wallets, and other information that can lead to quick and direct financial gain.
As for how the victim was infected, one of their children managed to infect the family computer while installing cracked software. The victim mentioned to me during our conversation that they would be having a “family meeting” to work together to change all the affected passwords, and use it as a teachable moment, which is great. At this point we went our separate ways, and we continued our red team engagement.
As we concluded the engagement and moved to reporting, I began to consider what the client could do to prevent this kind of thing from happening again.
First, I considered the technical mechanism that led to this data leakage in the first place. I do not have enough evidence to prove exactly what happened, but I thought of some possibilities:
In all cases, personal and work data would be commingled, leading to potential data leakage.
For years, I have been reporting “browser credential storage allowed” as a finding, mainly when we use tools like SharpChromium and SharpDPAPI during post-exploitation, and discover users saving their passwords in browser credential storage as opposed to a password manager. The recommendation there is to use GPO or MDM to fully disable this functionality in all browsers. There is a possibility that this would have prevented the user from saving the password in the first place, if they only ever logged into the Citrix interface from a managed computer.
This situation brought up the possibility of an additional recommendation, which is to prevent users from signing into their browsers at all. While I considered this, it could reduce the efficiency of some workers that switch between approved devices often. It also is the kind of security solution that I hate — one that blocks a bunch of useful features to prevent a subset of them from being abused.
User Security Awareness?
As much as I hesitate to pull this lever so often, I think making users aware of the implications of browser sync is helpful for the employee and the employer. This goes way beyond security; I think most people would not want their browser history shared with their spouse or close friends, let alone their employer. As more applications move to the web client model, we put more sensitive data into our browsers than ever before.
Although breached data might seem outside of our control, monitoring and detection can prevent this data from being abused.
Knowing exactly what data is breached in the first place goes a long way, both for companies and individuals. At the time of writing, there is no public site I am aware of that is like HaveIBeenPwned but for stealer logs. If you know of a good one, please get in touch.
Companies should also monitor for credential stuffing attacks and respond accordingly, especially if a valid login occurs. Defenders should also be aware of the security implications of browser data.
Thanks for reading!
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。