Google Chrome Zero-Day Bugs Exploited Weeks Ahead of Patch

North Korean threat actors exploited a remote code execution (RCE) zero-day vulnerability in Google’s Chrome web browser weeks before the bug was discovered and patched, according to researchers.

Google Threat Analysis Group (TAG) discovered the flaw, tracked as CVE-2022-0609, on Feb. 10, reporting and patching it four days later as part of an update. Researchers said at the time that an exploit for the flaw–a use-after-free vulnerability in Chrome’s animation component–already existed in the wild.

Google TAG now revealed it believes two threat groups—the activity of which has been publicly tracked as Operation Dream Job and Operation AppleJeus, respectively—exploited the flaw as early as Jan. 4 in “campaigns targeting U.S. based organizations spanning news media, IT, cryptocurrency and fintech industries,” according to a blog post published Thursday by Google TAG’s Adam Weidemann. Other organizations and countries also may have been targeted, he said.

“One of the campaigns has direct infrastructure overlap with a campaign targeting security researchers which we reported on last year,” he wrote. In that campaign, hackers linked to North Korea used an elaborate social-engineering campaign to set up trusted relationships with security researchers with the ultimate goal of infecting their organizations’ systems with custom backdoor malware.

The two groups, though separate, used the same exploit kit in their campaigns, which signals that they may work for the same entity with a shared supply chain. However, “each operate with a different mission set and deploy different techniques,” Weidemann said. It’s also possible that other North Korean government-backed attackers have access to the same kit, he added.

Two Campaigns, One Exploit

Researchers revealed specific details about both Operation Dream Job and Operation AppleJeus in the post. The former targeted more than 250 individuals working for 10 different news media, domain registrars, web hosting providers and software vendors.

“The targets received emails claiming to come from recruiters at Disney, Google and Oracle with fake potential job opportunities,” Weidemann explained. “The emails contained links spoofing legitimate job-hunting websites like Indeed and ZipRecruiter.”

If victims clicked on the link, they would be served a hidden browser iframe that would trigger the exploit kit, he wrote. Fake job domains owned by attackers that were used in the campaign included: disneycareers[.]net, find-dreamjob[.]com, indeedus[.]org, varietyjob[.]com, and ziprecruiters[.]org.

Exploitation URLs associated with Operation Dream Job used in the campaign included: https[:]//colasprint[.]com/about/about.asp, a legitimate but compromised website; and https[:]//varietyjob[.]com/sitemap/sitemap.asp.

Operation AppleJeus, the work of a separate North Korean threat group, targeted more than 85 users in cryptocurrency and fintech industries leveraging the same exploit kit.

Attackers compromised at least two legitimate fintech company websites to host hidden iframes that served the exploit kit to visitors to the site, researchers revealed. Google TAG also observed fake websites–already set up to distribute trojanized cryptocurrency applications—that hosted malicious iframes pointing their visitors to the exploit kit, Weidemann wrote.

Attacker-owned websites observed in Operation AppleJeus included one dozen sites including: blockchainnews[.]vip, financialtimes365[.]com and giantblock[.]org, according to the post.

Exploit Kit Revealed (Partially)

Researchers managed to recover key aspects of the functionality of the exploit kit used in both campaigns, which employed multiple stages and components to target users. Links to the exploit were placed in hidden iframes on websites that attackers either owned or had previously compromised, Weidemann wrote.

“The kit initially serves some heavily obfuscated javascript used to fingerprint the target system,” he explained. “This script collected all available client information such as the user-agent, resolution, etc. and then sent it back to the exploitation server.”

If the data sent to the server met a set of unknown requirements, the client would be served a Chrome RCE exploit and some additional javascript. If the RCE was successful, the javascript would request the next stage referenced within the script as “SBX,” which is a common acronym for Sandbox Escape.

Researchers were unable to recover the stages of exploit that followed the initial RCE because attackers took care to protect their exploits, deploying various safeguards, Weidemann said.

Those tactics included only serving the iframe at specific times–presumably when attackers knew an intended target would be visiting the site, he said. In some email campaigns, attackers also sent targets links with unique IDs that potentially were used to enforce a one-time-click policy for each link. This would allow the exploit kit to only be served once, Weidemann said.

Attackers also used Advanced Encryption Standard (AES) encryption for each stage, including the clients’ responses using a session-specific key. Finally, additional stages of the exploit were only served if the previous one was successful; if not, the next stage was not served, researchers found.

Moving to the cloud? Discover emerging cloud-security threats along with solid advice for how to defend your assets with our FREE downloadable eBook, “Cloud Security: The Forecast for 2022.” We explore organizations’ top risks and challenges, best practices for defense, and advice for security success in such a dynamic computing environment, including handy checklists.