Google Chrome Zero-Day Bugs Exploited Weeks Before Patch!

Google Chrome Zero-Day Bugs Exploited Weeks Before Patch!

2 separate campaigns from different threat players targeted users with the same exploit kit for more than a month before the company fixed an RCE flaw found in Feb.

Korean threat players exploited a remote code execution (RCE) zero-day vulnerability in Google’s Chrome web browser weeks before the bug was discovered & patched, states researchers.

4 Days Later

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

Google TAG now revealed it believes 2 threat groups—the activity of which has been publicly tracked as Operation Dream Job & Operation AppleJeus, exploited the issue as early as Jan. 4 in “campaigns targeting US based organisations across news media, IT, cryptocurrency & fintech industries,” according to a blog post published Thurs. by Google TAG’s Adam Weidemann. Other organisations & countries also may have been targeted, he commented.

Security Researchers

“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 N. Korea used an elaborate social-engineering campaign to set up trusted relationships with security researchers with the ultimate goal of infecting their organisations’ systems with custom backdoor malware.

The 2 groups, although 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 & deploy different techniques,” Weidemann suggested. It is also possible that other N. Korean govt.-backed attackers have access to the same kit, he added.

2 Campaigns, 1 Exploit

Researchers revealed specific details about both Operation Dream Job & Operation Apple Jeus. The former targeted more than 250 people working for 10 different news media, domain registrars, web hosting providers & 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 & 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, & ziprecruiters[.]org.

Operation Dream Job

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

Operation Apple Jeus, the work of a separate N. Korean threat group, targeted more than 85 users in cryptocurrency & fintech industries leveraging the same exploit kit.

Hidden iframes

Attackers compromised at least 2 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 1 dozen sites including: blockchainnews[.]vip, financialtimes365[.]com & giantblock[.]org, according to the post.

Exploit Kit Revealed

Researchers managed to recover key aspects of the functionality of the exploit kit used in both campaigns, which employed multiple stages & 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. & then sent it back to the exploitation server.”

Chrome RCE Exploit

If the data sent to the server met a set of unknown requirements, the client would be served a Chrome RCE exploit & 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 stated.

Unique IDs

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

This would allow the exploit kit to only be served once, Weidemann commented.

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 concluded.

 

SHARE ARTICLE