What happens when the best practice protection that you worked hard to implement, such as MFA, is not helping protect your users’ accounts from being taken-over by hackers? In this post we will dive into exactly such a case, describing the different steps taken to detect and analyze the attack, including the analysis of a custom built malware, and the flow that helped the fraudster bypass all standard safety measures, such as MFA and forced password resets, to get control over multiple accounts and monetize by siphoning from these accounts funds and equivalents such as digital goods, loyalty points, karma or cashback.

If you are familiar with the concepts of account takeover (ATO) and want to get to the technical details of this specific attack, you can skip directly to "The Story of an ATO".

To understand the severity of this attack, we’ll start with a quick preview of ATOs.

The story of account takeover is one that is as old as the Internet, and most of the time, that story isn’t very technically complex: phishing, dictionary attacks, and credential stuffing all rely on underlying user behavior and are common exactly because they are simple, scalable, and effective. Because of this, the gold standard of mitigating account takeovers has been multi-factor authentication (MFA). This approach has been very common in enterprise settings in protecting employee accounts, and in highly regulated and sensitive industries such as banking or healthcare. In other consumer-facing websites, adoption has been slow due to the inherent friction, cost, and privacy issues.

So what happens when a consumer-facing website does adopt MFA? The attacks don’t disappear; attacks don’t happen because they’re simple to do, rather the simplest attack that works is that one that happens. Attacks happen because of the inherent cost/benefit of doing them, and as long as they’re inexpensive enough they will continue happening. But they will get more sophisticated, like the cookies parasite in our story. Malware, which unfortunately means that there is a lot more collateral damage than with the simpler attacks — costing both victims and website operators a much steeper price.

This malware circumvents MFA by not targeting the credentials themselves (user-name + password) but rather the results of the authentication (the HTTP cookie that the client browser gets once authentication is complete). This means that how you authenticate is really not relevant anymore, and since the attackers have already made the investment of putting malware on the victim’s machine - they can now steal additional information, which ends up being “collateral damage” such as cryptocurrency or credentials to other websites.

This has really far-reaching implications. First, due to this cat-and-mouse reality, the standard operational responses to account takeover by the website operators (such as forcing a password reset and an out of band authentication) are no longer relevant. Also, there is a need to figure out when to re-enable the account after suspending it. How do you know when the victim’s device is clean? The new reality challenges the familiar cyber security approach with new and diverse attack methods. This ATO-to-cookie-stealing method marks another chapter in the long history of the cat-and-mouse in the cyber security field. Surely not the last.

The Story of an ATO

Our story starts with the usual suspect — spam messages. Well-crafted spam messages inside platforms have been much more successful than usual phishing attempts, since users tend to trust in-platform messages more, while in fact, in most cases those platforms have fewer capabilities and experience in blocking personal phishing attempts (they usually focus on blocking regular spam).

Once the victim falls for the phishing attempt, either by downloading a file and executing it, or browsing to a website serving n-day exploits for unpatched browsers. Once successfully targeted, the attacker can infect the device with malware like the cookies parasite.

Having in place a good bot-mitigation solution will usually block any automation tools from performing that phase, leaving the scene for the dedicated fraudsters willing to do the manual work of crafting and sending phishing attempts.

So, we have our fraudster(s) send a link, downloaded by an unsuspecting user, and minutes later multiple accounts have been hacked. How did this happen?

Working with a customer of ours to identify and block those accounts from being hacked, we got a hold of a copy of the malware from one of the spam messages. After running it in a secured sandbox, and a bit of reverse engineering, we identified who was running the operation and how.

The fraudsters used a variation of the “Collector Toolkit”, a solid one-time malware collecting a lot of information used for logging into accounts.

The malware used a few common AV evasion techniques. One of those was “bloating”: unzipped, the malware was “bloated” to over 600mb, and its md5 (both zipped and unzipped) was unknown to any AV vendor at the time.

The malware sends all browsers’ active cookies, and specifically looks for the following passwords and tokens: AutoFill, Passwords, Cookies, Cards, Atomic, Armory, Bytecoin, BitcoinCore, DashCore, Litecoin, Electrum, Zcash, Ethereum, Authy (2FA), FileZilla, NordVPN, Telegram, Discord, PSI, Wallet, Pidgin, Steam.

The collected data was sent to http://plarius.space/collect.php where the operator would use the authentication cookies to log in from a different device within the active 30-minute window in which the tokens are valid, changing the security settings by removing the email alerts and siphoning the funds from the account.

Browsing to the website we were welcomed by this page:

As shown in the screenshot above, the fraudsters didn’t even bother hiding themselves, boasting their Telegram channel.

So… we took the red pill and tried joining the channel. Now we move from identifying the malware, to attempting attribution on who is behind it.

https://t.me/getmineteam

Reading the channel and following the leads we were able to piece together the actual timeline of the malware.

Timeline:

1. Jun 20, 2020 — hackjopi (username) introduced a malware called “Collector” — Native stealer on a Russian crackers marketplace named “lolz.guru” for 600 Rubles/week.
   The thread reached over 28 million views.
   hackjopi shared the same telegram group (“collectorcrack”) mentioned in the response from the C&C (command and control) server (f0566304.xsph.ru).
   This was the only server that responded with that Telegram group “https://lolz.guru/threads/1695028/”.
2. Sep 20, 2020 — the original malware is identified by Anti-Viruses as Win32/Tnega!ml.
3. Feb 6, 2021 — NCP (username), a user with a long history of fraud reports and even being banned for failure to deliver promises to clients, re-joined the marketplace with a new nickname and published that he cracked the Collector — Native stealer, and gave it for free.
   NCP shared the same telegram group (“getmineteam”) mentioned in the response from the C&C server (plarius.space and six other servers).
4. Feb 7, 2021 — Hack_jopi admits that Collector — Native Stealer was cracked by NCP.
5. Mar 2, 2021 — NCP is trying to leverage the exposure to new prospects and buyers and offer a variety of hacking services.
6. Mar 16, 2021, NCP gets blocked again after the forum admins notice it’s the same user from early blocks.
7. Jun to Aug, 2021 — One of NCP’s free clients downloads the Collector — Native Stealer cracked version, changes the build name and destination server, and attacks users using social engineering and phishing subdomains.

Identified C&C servers

Looking via various sources (such as publicwww and httparchive) for the webserver C&C signature we discovered a few more targets, some new and some already known by AV vendors.

Final thoughts

While the technical details are fascinating and frightening, what is the long-term lesson here? We, cybersecurity and fraud professionals, are usually highly technical people (you have to be, because the security threats and the fraud is highly technical). As technical people we are tempted to solve the problem of fraud and account takeover through technical means such as stronger authentication or validation. Unfortunately while these tools are an essential part of any response toolkit, they don’t come without cost — stronger authentication often comes as a significant burden to consumers causing abandonment and direct damage to the business (unlike employees who have no choice). This cost is compounded by threats like those detailed in this post — which render the significant investment moot, and cause more damage in the long run and increase operational costs to boot.

Online fraud and account takeover are at heart a behavioral issue. Legitimate users act in a certain way, and that behavior can be taken advantage of by attackers. The fraudsters also behave in a certain manner, which ultimately is the only way to recognize and defeat them. The only conclusion one can reach is that any comprehensive solution must require behavioral analytical analysis of user behavior, in order to mitigate threats and to have a reasonable and cost-effective operational response.