Lurk: Retracing the Group’s Five-Year Campaign

by Fyodor Yarochkin and Vladimir Kropotov (Senior Threat Researchers)

Fileless infections are exactly what their namesake says: they’re infections that don’t involve malicious files being downloaded or written to the system’s disk. While fileless infections are not necessarily new or rare, it presents a serious threat to enterprises and end users given its capability to gain privileges and persist in the system of interest to an attacker—all while staying under the radar. For instance, fileless infections have been incorporated in a targeted bot delivery, leveraged to deliver ransomware, infect point-of-sale (PoS) systems, and perpetrate click fraud. The key point of the fileless infection for the attacker is to be able to evaluate each compromised system and make a decision whether the infection process should continue or vanish without a trace.

The cybercriminal group Lurk was one of the first to effectively employ fileless infection techniques in large-scale attacks—techniques that arguably became staples for other malefactors. A typical Lurk infection uses browser exploits to deliver non-persistent payloads to potential victims, probing their targets before deploying additional malware. The infection chain had multiple stages, and was accomplished using bodiless/fileless exploit payloads executed in-memory without additional persistence mechanisms. No traces were left on affected systems apart from files from the exploit process if the target machine wasn’t interesting to the Lurk operators. This eponymous lurking behavior would earn them notoriety until their operations were stymied and the perpetrators arrested. Lurk was believed to have siphoned over $45 million from financial organizations, ultimately disrupting the victims’ operations, reputation, and bottom line.

How did Lurk evolve from a clique of threat actors to a full-fledged cybercriminal group? What other techniques were they known for—that other cybercriminals emulated? How did their operations shift from targeting Russian end users to banks and enterprises? Our observations of the group were based on code artifacts we analyzed as well as network traffic and URL patterns our intrusion detection systems monitored within several organizations in the Russian Internet segment during Lurk’s five-year campaign.

2011 to early 2012: Humble Beginnings?

Lurk’s web-based attacks were the first signs of their campaigns. The group already implemented certain mechanisms to prevent AV detection. Requests during a time period or from a source IP address that didn’t match their preferred distribution area, for instance, would yield a redirect to a third-party site such as Google.

Lurk compromised systems by exploiting web browser vulnerabilities via drive-by download attacks. Malicious iframe content was injected to high-profile Russian websites, which then served as watering holes to attack unsuspecting end users. Malvertising and poisoning of content-serving application components, such as memcached cache poisoning, were also part of their traffic redirection methods.

Stealth was already a fixture in their operations. Before additional malware was served to a victim, the victim machine was first verified and validated with a bodiless payload (executed in memory) that collected information from the compromised machine.

During this time we developed URL-based signatures and used them to detect Lurk-related network traffic. The signature pattern ^[A-Z0-9]{4}$ was particularly effective in detecting URL patterns employed by Lurk from 2011 to 2013. The average TTL (Time To Live – the period of time these signatures were effective) for these signatures was two to three months. The validity time of the signatures also allowed us to identify the group’s software upgrade cycles.

Mid-2012 to mid-2014: Honing the Craft

Lurk was most prolific during this period, with its series of URL redirection campaigns in Russia becoming more extensive. High-profile and high-volume websites were used as intermediate platforms for diverting unknowing visitors to their exploit kit, known as XXX.

Lurk also targeted programmatic advertising infrastructures to increase the scale of their operations. In February 2012, for instance, the ad server of news agency RIA Novosti, ria[.]ru, was found serving iframe redirects to Lurk’s systems. The campaign delivered the actual payload only to a select range of IP addresses.

By August 2012, we were able to observe sequences of HTTP requests during and after infection, including command and control (C&C) communication from compromised machines. When 2014 rolled in, Lurk started exhibiting some patterns similar with the Angler exploit kit. For example, Lurk increasingly used indexm[.]html as their landing URL pattern; this would also shortly appear in one of Angler’s payloads.

Figure 1. Exploit loading sequence in ria[.]ru (February 2012)

Figure 2. [bg].ru (February 2012) found redirecting victims to Lurk’s exploit kit

Figure 3. Redirects to the Lurk landing page from adfox[.]ru banner network

Figure 4. Malicious iframe content served by tks[.]ru (August 2013)

Lurk’s transition from simple web-browser-exploiting crooks to organized cybercriminals also stood out. Range and frequency were added to their operations. Serving criteria were often modified, malicious payloads were often updated. While Lurk only exploited a certain set of browser vulnerabilities, the exploit code also often changed. Larger payloads (in number of bytes) typically translated to more functionality being embedded in them, while a smaller change indicated a repacked payload.

True to its namesake, Lurk developed techniques to evade sandbox-based detection. Aside from serving malicious content only once per IP address, the group limited the range of IP addresses to a subset of targets of interest. Payload execution was done in multi-tier, chained fashion, and only components delivered at later stages had persistence mechanisms. The initial bodiless payload was designed to be triggered by the exploit kit shellcode, which performed routine checks in the infected machine. It would then call back to the group’s C&C server in the form of a Windows executable that, in turn, performs another analysis of the affected system and collected system information, such as installed software packages and their versions, operating system information and so on. This information was sent back to the C&C server which made decisions on what to do next. This exhaustive scrutiny, along with the campaign’s objective, determines whether additional modules would be dropped to the system.

Sourcing samples from this was a challenge because the payload’s behavior was mostly influenced by the environment where it was executed. Acquiring additional modules of the group’s malware, for instance, was nearly impractical if the exploit URLs were loaded in a sandboxed environment.

Malicious content were also often distributed during lunchtime (Moscow’s timezone), and in very short intervals. We surmise this as their way to hide from automated scraping sandbox detection. Geographical information of each visiting IP address was actively crosschecked against their regions of interest—Russia and the Commonwealth of Independent States (CIS). Exploits were also served with higher frequency on certain days of the week: Fridays, and days before public holidays.

Lurk’s infrastructure also exhibited new capabilities. Among them were distinct patterns used in the HTTP requests and hosting providers. Based on the hosting providers they used and timing of their hosting migrations, we observed the group compromising websites of software distribution companies and tampered their software installation files.

Their attacks also exploited a number of vulnerabilities that included authentication portal bypass flaws in programmatic ad servers, and those in web servers and other web components. The mechanisms of redirections were different for each intermediate victim. Some included ad banner networks or actual sites—while the website content-serving component was poisoned in others.

2012 2013 2014
3dnews[.]ru 3dnews[.]ru 3dnews[.]ru
adriver[.]ru adriver[.]ru adfox[.]ru
akdi[.]ru adv[.]vz[.]ru auto[.]ru
bg[.]ru aif[.]ru avtovzglyad[.]ru
com[.]adv[.]vz[.]ru akdi[.]ru drive[.]ru
fobos[.]tv gazeta[.]ru glavbukh[.]ru
gazeta[.]ru glavbukh[.]ru inosmi[.]ru
rian[.]ru infox[.]ru irr[.]ru
newsru[.]com klerk[.]ru nalogoved[.]ru
target-m[.]ru mn[.]ru news[.]mail[.]ru
tks[.]ru newsru[.]com ria[.]ru
torrogrill[.]ru rg[.]ru riarealty[.]ru
tvrain[.]ru servernews[.]ru nk[.]ru
uik-ek[.]ru slon[.]ru rusplt[.]ru
ura[.]ru tks[.]ru smotri[.]com
slon[.]ru topnews[.]ru sport[.]mail[.]ru
vesti[.]ru tvrain[.]ru tks[.]ru
vesti[.]ru utro[.]ua

Figure 5. Lurk’s intermediate targets by year

2014 to 2016: Going Global

2014 was a significant year in Lurk’s history. A number of high-profile, intermediate victims were still at their fingertips, giving them footholds into the user’s systems. In a word, they were on a roll. Why not go global to turn in more profit?

Most of the domains Lurk used during this time were purchased from third-party resellers and paid with webmoney checks and other anonymous forms of payment available in Russia. The activities we observed indicated dry runs of malicious injections in banner networks outside Russia and CIS. In April, we saw Lurk using redirects via mail[.]ru, possibly through malicious injections to its ad server content. From June to September, Lurk’s landing pages hinted at the group migrating their infrastructure and readying a global campaign.

By the second half of the year, Lurk’s geographical distribution drastically changed. Russian/CIS-based targets were now sparser, and victims within .ru domains were manually inspected. Lurk then launched a new URL pattern that served payloads round-the-clock, eschewing pre-filtering of IP address locations in favor of targeting global IP addresses.

While Lurk favored Java exploits that were used extensively from 2011 to 2012, Flash/swf content was introduced. An obfuscated Flash file exploiting CVE-2013-5330 was spotted in December 2014. It was delivered only if the victim’s source IP address (and time) met Lurk’s parameters—otherwise users received a 404 error response.

As mentioned earlier, the XXX Exploit Kit used by Lurk demonstrated several URL-serving patterns and fileless infection capabilities that would later be seen in Angler. By early 2015, the difference in Lurk and Angler’s activities began to blur—many of their patterns, exploit techniques, and distribution volume overlapped. Correlation via hosting IP addresses wasn’t very helpful, because Lurk and Angler were often seen hosted on the same service providers. Lurk also employed dynamically generated domain names for their landing pages.

2016: Lurk’s Downfall

Lurk’s active compromise of financial institutions led to a series of enquiries that culminated in the arrest of over 50 individuals involved in its operations across Russia. The ripple effect led other cybercriminal groups to lie low for the rest of the year. Other exploit kits like Neutrino and Magnitude either shut down or went private. By then, Angler’s activities already ceased. Coincidence? Based on the similarities of Angler and XXX’s exploit-serving URL patterns and malware delivery techniques (particularly their use of fileless infection) as well as shared infrastructure, we can construe a correlation of both their operations.

In a way, the rise and fall of Lurk also reflected the evolution of the threat landscape. We can only predict the constant development of seemingly novel and unforeseen techniques for evading traditional security systems, which is exacerbated by how these can become commercially available to other bad guys. Unfortunately, Lurk is just one of the many cybercriminal groups looking to profit from organizations and end users.

Best Practices

Lurk’s story demonstrates the aptitude of cybercriminals for honing in on specific victims and profiting from them. Whether spying for profit, pilfering credentials, emptying bank accounts, or misinforming an unknowing public, bad guys will progressively develop attacks that can neuter traditional defenses.

These threats pose greater challenges to security and IT administrators in terms of how their organization’s perimeter can be secured. A multilayered approach is key, along with security-minded practices: apply the latest patches, block malware-hosting sites, implement URL categorization, employ firewalls and IDSs, and foster a culture of security in the workplace. Defense in depth should also be considered—there are no silver bullets, no single network defense tool that can be used to deal with these threats.

End-user systems can serve as main gateways for attackers, which is why hardening them is critical. This includes whitelisting and monitoring suspicious applications and processes, as well as well applying least privilege principles on the systems. The attack surface—which can come in the form of software packages (including their extensions and plugins) that can interact with untrusted components—must also be reduced. Unused browser plugins and any functionality that lets browsers execute third-party code should be inspected and disabled. In Lurk’s case, the group favored exploiting vulnerabilities in Flash and Java plugins for web browsers.

To mitigate intrusions, direct internet access to the organization’s internal network should be disabled, and users should be obliged to utilize application proxies instead when accessing external network resources. This should be especially enforced for HTTP and HTTPS protocols that cybercriminals frequently leverage for their attacks. URLs and URL content (i.e. mime-types) should be stringently analyzed. Likewise, all executable content should be considered with a grain of salt—especially if they’ve been downloaded from unknown sources.

Continuously monitoring the network for spikes of suspicious behavior—or those that may first appear as benign—can also help detect intrusion attempts. For instance, a significant number of machines within the organization’s network suddenly attempting to resolve and connect to a domain name never observed before can indicate a network infection or exploit. Network detection and endpoint security systems can also help notify system administrators and direct them to artifacts left by successful or failed exploit attempts.

End users must ultimately keep pace: regularly update the system, and take caution against random or socially engineered links from suspicious or spoofed emails and websites.

Trend Micro Solutions

Trend Micro™ Deep Security™ and Vulnerability Protection provide virtual patching that protects endpoints from threats such as fileless infections and those that abuse unpatched vulnerabilities. OfficeScan’s Vulnerability Protection shields endpoints from identified and unknown vulnerability exploits even before patches are deployed. Trend Micro™ Deep Discovery™ provides detection, in-depth analysis, and proactive response to attacks using exploits through specialized engines, custom sandboxing, and seamless correlation across the entire attack lifecycle, allowing it to detect similar threats even without any engine or pattern update.

A list of pertinent Indicators of Compromise (IoCs) can be found in this appendix.

Post from: Trendlabs Security Intelligence Blog – by Trend Micro

Lurk: Retracing the Group’s Five-Year Campaign

Read more: Lurk: Retracing the Group’s Five-Year Campaign

Story added 6. February 2017, content source with full text you can find at link above.