banking threats
The trial of the creators of the Lurk banking Trojan is finally over. They were stopped as a result of an unprecedented joint operation between a multitude of authorities and the aid of our experts. The criminals were arrested in 2016, but the investigation and court case dragged on for another five years. This is hardly surprising, since the number of suspects and victims involved was unprecedented. Lurk’s members had to be transported to the court by the busload. And the case files ran to 4000 volumes (one volume = 250 pages). The amount of work was colossal and time-consuming, suspects analyzed every record and statement with a fine-tooth comb, but in 2018, 27 defendants faced the trial.
Kaspersky has been monitoring the group’s activities since 2011. I first heard about Lurk when I joined the company back in 2013. I remember thinking to myself: “Catch them and you can retire easily. Consider your career complete.” Compared to the usual cybercriminals of the day, they seemed really sophisticated, both technically and organizationally. That said, if I encountered Lurk today, I’d probably be less impressed and just see them as a group that followed best practices.
The courts verdict is a good excuse to cast a retrospective eye over what was so special about their cybercriminal activity.
Infection scheme
We should start with the infection vector. The attackers used a watering-hole tactic, posting a redirect to an exploit kit on several business media websites. The method itself was not new, but in this case, to get infected, the victim (always an accountant) had to visit the site during their lunch break (and only at this time). The exploit kit downloaded a bodiless Trojan onto their computer, which was used solely for spying.
The cybercriminals first studied what programs were running on the machine, whether there were banking software or any traces of investigation software, and what subnets the machine was working in (the primary focus was on banking and government networks). In other words, they assessed the computer’s “interestingness” — and knew exactly who they wanted to infect.
The main malware was downloaded only if the computer was indeed of interest. Otherwise, they would steal all the passwords that they could lay their hands on, just in case, and removed the malware from the victim’s machine.
Communication with C&C
No less remarkable was the process of information exchange between the Trojan and the command-and-control (C&C) server. The majority of Trojans of the time contained the hardcoded C&C address. The authors simply specified the domain name, leaving themselves the option, if need be, to change the server’s IP address: that is, if they lost control over the main C&C address, they could simply replace it with a backup one. All told, it was a rather primitive security mechanism. Lurk was very different in this regard: the group employed a method worthy of a spy novel.
Before a communication session, Lurk calculated the address of the C&C server. The cybercriminals went on Yahoo and looked at the share price of a particular company (during our research, this was McDonald’s). Depending on the value of the stock at a specific point in time, they generated a domain name and accessed it. That is, to control the Trojan, the cybercriminals looked at the share price at that moment in time and registered a domain name based on these figures. In other words, it was impossible to know in advance which domain name would be used for the C&C server.
This raises a legitimate question: if the algorithm was embedded in the Trojan, what prevented a researcher from generating such a sequence, registering a domain name before the cybercriminals, and simply waiting for the Trojan to connect to it? Alas, Lurk’s creators had taken precautions. They used asymmetric cryptography. That is, a key pair was generated, whereupon the bot, accessing the C&C server, would use the public key to check whether it really belonged to its owners (by verifying the digital signature). This is impossible to forge without knowing the secret key. So, only the owner of the secret key can receive requests from bots and issue commands — no outside researcher can mimic the C&C server. Other cybercriminals did not use this method of protection back then, so if we spotted a private key protection on the server, we could be sure that it was a Lurk attack.
Organized infrastructure
The set-up of Lurk’s processes deserves a separate mention. If other cybercriminal groups back then were just a random bunch of forum users (one did the programming, another the cashing out, a third was the coordinator), then, by contrast, Lurk was almost a fully-fledged IT company. It’s more accurate to compare them with a large software corporation than a cybercriminal group. What’s more, in terms of organizational level, they remain a model for many groups to this day.
Lurk was run by true professionals (most likely with strong development experience) who built a highly organized infrastructure with managers and HR staff. Unlike most gangs, they paid their employees a salary (rather than a percentage of the proceeds). They even used to hold weekly briefings, which in those days was completely unheard-of. In short, it was an exemplary evil corporation.
They even had a clearly structured role-based system for restricting access to information. After their arrest, some group members got to read the correspondence of their bosses and only then realized that they were not being treated fairly.
They meticulously documented all their activities, far more so than many IT companies today. This, of course, greatly aided the investigation. And perhaps led ultimately, to their downfall: the more systematic your approach is, the easier you are to trace. Here are some examples.
Knowledge bases
The Lurk group maintained a detailed knowledge base, clearly divided into projects. Each project was accessible only to a certain circle of people, that is, the participants in one project did not know about the activities of another. The projects varied greatly in scope, from highly technical to organizational. And the technical projects were subdivided into levels too. For example, the Trojan developers had access to the knowledge base only on related topics: how to bypass antiviruses, how to test, and so on. But there were also general databases on operational security (similar to real security regulations in large companies). These provided information about how Lurk employees should set up their workstations to avoid detection and how to use anonymization tools.
Access to information
To gain access to the Lurk’s information resource, cybercriminals needed to connect to some server through several VPNs. Even then they only received access to bot management. Next, each employee got their own certificate and their own account with different rights. In other words, it was like a regular corporate network set up for remote working. By and large, if it hadn’t been for their lack of 2FA, they could have been considered a model company.
Physically, all the servers were located at different data centers and in different countries. When you reach one of them at the virtual level through a VPN, you don’t know the server’s real IP address. It was largely what made the group so hard to sniff out.
Development
The Lurk group had proper source-code repositories, automated build and multi-step testing procedures, a production server, a test server and a development server. They were essentially making a serious software product: at any moment in time they had a production, testing and developers’ version of the Trojan.
The average C&C server of a typical Trojan back then could receive requests from bots, log them in a database and provided an admin panel to manage them. All this was effectively implemented on a single page. Lurk implemented the admin panel and database separately, while the mechanism for sending responses for bots was completely obscured by an intermediary service.
Exploit kits
Lurk had three exploit kits, each of which had three different names: one internal, made up by its developers; one for clients and partners; and one assigned by researchers. The thing is, not only did Lurk’s authors use their own developments, but they also sold exploit kits on the side, to other cybercriminals. Moreover, the versions for “partners” had different code — clearly an attempt to disguise them as another very popular exploit kit.
The fall of Lurk
In the end, all the tricks the cybercriminals pulled were of little help. Most members of the group ended up being arrested. But only after the damage was done: during their long career, the attackers managed to steal around US$45 million. Our experts were studying their methods for almost six years (which, incidentally, provided valuable experience that we continue to employ to defeat cybercrime).
For those interested in the business-relevant takeaways from this saga, we recommend this post. And a detailed technical analysis is available in our Securelist post.
Tips