Cyber attackers continue to up their game. One new tactic hackers have been using is to steal cookies from current or recent web sessions to bypass multi-factor authentication (MFA).
The new attack method, reported by Sophos researchers yesterday, is already growing in use. The “cookie-stealing cybercrime spectrum” is broad, the researchers wrote, ranging from “entry-level criminals” to advanced adversaries, using various techniques.
Cybercriminals collect cookies or buy stolen credentials “in bulk” on dark web forums. Ransomware groups also harvest cookies and “their activities may not be detected by simple anti-malware defenses because of their abuse of legitimate executables, both already present and brought along as tools.”
It’s not a surprising target for hackers given that the vast majority of activities are now web-based. Even cloud infrastructures rely on cookies to authenticate their users.
There’s a huge market for stolen credentials and various angles of attack to clone web sessions or spoof existing logins through specific instances. Depending on the objectives, such initial access can be particularly attractive for adversaries who need to exfiltrate valuable data, to obtain corporate secrets or blackmail victims into paying ransom demands.
How Hackers Steal Cookies
Browsers allow users to maintain authentication, remember passwords and autofill forms. That might seem convenient, but attackers can exploit this functionality to steal credentials and skip the login challenge.
Behind the scenes, browsers use SQLite database files that contain cookies. These cookies are composed of key-value pairs, and the values often contain critical information such as tokens and expiration dates.
Adversaries know the exact name and location of these files for all major browsers such as Chrome, Firefox, and even Brave, on various operating systems. That’s why the attack can be scripted. It’s not uncommon to find such scripts along with other modules in info-stealing and other malware.
For example, the latest version of the Emotet botnet targets cookies and credentials stored by browsers, which include saved credit cards. According to the Sophos researchers, “Google’s Chrome browser uses the same encryption method to store both multi-factor authentication cookies and credit card data.”
To gain initial access, attackers can also perform phishing and spear-phishing campaigns to implant droppers that can deploy cookie-stealer malware stealthily.
The cookies are then used for post-exploitation and lateral movements. Cybercriminals can use them to change passwords and emails associated with user accounts, or trick the victims into downloading additional malware, or even deploy other exploitation tools such as Cobalt Strike and Impacket kit.
How Users Can Protect Access
Users should not use built-in features to save passwords unless the browser encrypts them with, at least, a master password. It’s recommended that users uncheck the setting called “remember passwords,” and users should probably not allow persistent sessions as well.
It’s not the default behavior, but it’s usually possible to tweak the settings to prevent the browser from asking you whether or not you want to save the password every time you sign in. You can also delete all cookies automatically when you close the browser.
While it may sound pretty inconvenient, password managers can remove the hassle of typing your credentials, because you will have to reauthenticate sessions. Bear in mind it’s not bulletproof, though, as some malware could still install tricked extensions or processes that could intercept local traffic and data sent by your password manager.
Nevertheless, it’s still a much better strategy than using your browser to maintain authentication for days on end, even if you use security-enhanced solutions such as Brave.
Researchers noted that some applications like Slack use persistent cookies and remain open indefinitely in some environments, even if session-specific cookies are cleared when the browser is closed.
Other applications may be vulnerable to cookie thefts because they use their own cookie stores, sometimes without an expiration date.
Cookies from the Developer’s Perspective
Some MFA implementations are poor, exposing the system to various kinds of forgery. Developers can be part of the problem if they don’t secure authentication cookies properly.
Such cookies must have a short expiration date. Otherwise, the persistent authentication could turn into a persistent threat.
You can have great security processes and still get hacked because the cookies do not have the necessary flags (e.g., HttpOnly, Secure attribute). For example, authentication cookies must be sent using SSL/TLS channels. Otherwise the data could be sent in plain text and attackers would only have to sniff traffic to intercept credentials.
Some apps store information in cookies with reversible hashes, allowing cybercriminals to predict and forge tokens. There’s no way the app can distinguish whether requests come from a legitimate user or a forger if the algorithm has been cracked.
It’s essential to have an appropriate CORS policy to prevent malicious injections that can be achieved remotely.
Security as Part of the Business Culture
A significant part of cybersecurity is based more on common sense than on deep technical knowledge. Cybersecurity awareness training can teach many employees better practices.
For example, they may not close their session to “speed up” work, but it is easy to see why that’s a huge security risk. Every time employees sacrifice security over convenience, it’s one less hurdle for attackers.
Authentication points are dangerous spots by nature, and organizations should enable MFA every time it is possible, even if it can be bypassed. The techniques may vary a great deal, but it’s always the same tactic.
If a security system is too strong, determined adversaries will focus on the human factor. Reauthenticating is not the most time-consuming task in reality, and many operations can be automated through techniques such as master passwords, auto-filling and auto-clearing.