QR codes link the offline to the online. What started as a way to streamline manufacturing in the automotive industry is now a widespread technology helping connect the physical world to digital content. And as the world embraced remote, no-touch solutions during the Covid pandemic, QR codes became especially popular. QR codes offer convenience and immediacy for businesses and consumers, but cybercriminals also take advantage of them. Here’s what you need to know about QR codes and how to stay safe when using them.
Why QR codes?
Due to their size and structure, the two-dimensional black and white barcodes we call QR codes are very versatile. And since most people carry a smartphone everywhere, they can quickly scan QR codes with their phone’s camera. Moreover, since QR codes are relatively easy to program and accessible for most smartphone users, they can be an effective communication tool.
They also have many uses. For example, QR codes may link to a webpage, start an app or file download, share contact information, initiate a payment, and more. Covid forced businesses to be creative with touchless experiences, and QR codes provide a convenient way to transform a physical touchpoint into a digital interaction. During Covid, QR codes became a popular way to look at restaurant menus, communicate Covid policies, check in for an appointment, and view marketing promotions, among other scenarios.
As a communication tool, QR codes can transmit a lot of information from one person to another, making it easy for someone to take action online and interact further with digital content.
What hackers do with QR codes
QR codes are inherently secure, and no personally identifiable information (PII) is transmitted while you’re scanning them. However, the tricky part about QR codes is that you don’t know what information they contain until you scan them. So just looking at the QR code won’t tell you if it’s entirely trustworthy or not.
For example, cybercriminals may try to replace or sticker over a QR code in a high-traffic, public place. Doing so can trick people into scanning a malicious QR code. Or, hackers might send malicious QR codes digitally by email, text, or social media. The QR code scam might target a specific individual, or cybercriminals may design it to attract as many scans as possible from a large number of people.
Once scanned, a malicious QR code may take you to a phishing website, lead you to install malware on your device, redirect a payment to the wrong account, or otherwise compromise the security of your private information.
In the same way that cybercriminals try to get victims to click phishing links in email or social media, they lure people into scanning a QR code. These bad actors may be after account credentials, financial information, PII, or even company information. With that information, they can steal your identity or money or even break into your employer’s network for more valuable information (in other words, causing a data breach).
Pay attention to context. Where is the code available? What does the code claim to do (e.g., will it send you to a landing page)? Is there someone you can ask to confirm the purpose of the QR code? Did someone send it unprompted? Is it from a business or individual you’ve never heard of? Just like with phishing links, throw it out when in doubt.
Look closely at the code. Some codes may have specific colors or branding to indicate the code’s purpose and destination. Many codes are generic black and white designs, but sometimes there are clues about who made the code.
Check the link before you click. If you scan the QR code and a link appears, double-check it before clicking. Is it a website URL you were expecting? Is it a shortened link that masks the full URL? Is the webpage secure (HTTPS)? Do you see signs of a phishing attack (branding is slightly off, strange URL, misspelled words, etc.)? If it autogenerates an email or text message, who is the recipient and what information is it sending them? If it’s a payment form, who is receiving the payment? Read carefully before taking action.
Practice password security. Passwords and account logins remain one of the top targets of cyber attacks. Stolen credentials give cybercriminals access to valuable personal and financial information. Generate every password for every account with a random password generator, ideally built into a password manager for secure storage and autofill. Following password best practices ensures one stolen password results in minimal damage.
Layer with MFA. Adding multi-factor authentication to logins further protects against phishing attacks that steal passwords. With MFA in place, a hacker still can’t access an account after using a stolen password. By requiring additional login data, MFA can prevent cybercriminals from gaining access to personal or business accounts.
QR codes remain a popular marketing and communication tool. They’re convenient and accessible, so you can expect to encounter them occasionally. Though cyber attacks via QR codes are less common, you should still stay vigilant for signs of phishing and social engineering via QR codes. To prevent and mitigate attacks via QR codes, start by building a solid foundation of digital security with a trusted password manager.
TA558 is a likely financially motivated small crime threat actor targeting hospitality, hotel, and travel organizations.
Since 2018, this group has used consistent tactics, techniques, and procedures to attempt to install a variety of malware including Loda RAT, Vjw0rm, and Revenge RAT.
TA558’s targeting focus is mainly on Portuguese and Spanish speakers, typically located in the Latin America region, with additional targeting observed in Western Europe and North America.
TA558 increased operational tempo in 2022 to a higher average than previously observed.
Like other threat actors in 2022, TA558 pivoted away from using macro-enabled documents in campaigns and adopted new tactics, techniques, and procedures.
Overview
Since 2018, Proofpoint has tracked a financially-motivated cybercrime actor, TA558, targeting hospitality, travel, and related industries located in Latin America and sometimes North America, and western Europe. The actor sends malicious emails written in Portuguese, Spanish, and sometimes English. The emails use reservation-themed lures with business-relevant themes such as hotel room bookings. The emails may contain malicious attachments or URLs aiming to distribute one of at least 15 different malware payloads, typically remote access trojans (RATs), that can enable reconnaissance, data theft, and distribution of follow-on payloads.
Proofpoint tracked this actor based on a variety of email artifacts, delivery and installation techniques, command and control (C2) infrastructure, payload domains, and other infrastructure.
In 2022, Proofpoint observed an increase in activity compared to previous years. Additionally, TA558 shifted tactics and began using URLs and container files to distribute malware, likely in response to Microsoft announcing it would begin blocking VBA macros downloaded from the internet by default.
TA558 has some overlap with activity reported by Palo Alto Networks in 2018, Cisco Talos in 2020 and 2021, Uptycs in 2020, and HP in 2022. This report is the first comprehensive, public report on TA558, detailing activity conducted over four years that is still ongoing. The information used in the creation of this report is based on email campaigns, which are manually contextualized, and analyst enriched descriptions of automatically condemned threats.
Campaign Details and Activity Timeline
2018
Proofpoint first observed TA558 in April 2018. These early campaigns typically used malicious Word attachments that exploited Equation Editor vulnerabilities (e.g. CVE-2017-11882) or remote template URLs to download and install malware. Two of the most common malware payloads included Loda and Revenge RAT. Campaigns were conducted exclusively in Spanish and Portuguese and targeted the hospitality and related industries, with “reserva” (Portuguese word for “reservation”) themes. Example campaign:
The documents leveraged remote template URLs to download an additional RTF document, which then downloaded and installed Revenge RAT. Interestingly, the term “CDT” is in the document metadata and in the URL. This term, which may refer to a travel organization, appears throughout TA558 campaigns from 2018 to present.
In 2019, this actor continued to leverage emails with Word documents that exploited Equation Editor vulnerabilities (e.g. CVE-2017-11882) to download and install malware. TA558 also began using macro-laden PowerPoint attachments and template injection with Office documents. This group expanded their malware arsenal to include Loda, vjw0rm, Revenge RAT, and others. In 2019, the group began occasionally expanding targeting outside of the hospitality and tourism verticals to include business services and manufacturing. Example campaign:
Figure 3: Example TA558 Microsoft Word attachment from 2019
The documents leveraged a remote template relationship URL to download an additional RTF document. The RTF document (Author: obidah qudah, Operator: Richard) exploited the CVE-2017-11882 vulnerability to retrieve and execute an MSI file. Upon execution, the MSI file extracted and ran Loda malware.
In December 2019, Proofpoint analysts observed TA558 begin to send English-language lures relating to room bookings in addition to Portuguese and Spanish.
2020
In 2020, TA558 stopped using Equation Editor exploits and began distributing malicious Office documents with macros, typically VBA macros, to download and install malware. This group continued to use a variety of malware payloads including the addition of njRAT and Ozone RAT.
Hotel, hospitality, and travel organization targeting continued. Although the actor slightly increased its English-language operational tempo throughout 2020, most of the lures featured Portuguese and Spanish reservation requests. An example of a common attack chain in 2020:
The message contained a PowerPoint attachment that used template injection techniques and VBA macros which, if enabled, executed a PowerShell script to download a VBS payload from an actor-controlled domain. The VBS script in turn downloaded and executed Revenge RAT.
Figure 5: 2020 attack path example
TA558 was more active in 2020 than previous years and 2021, with 74 campaigns identified. 2018, 2019, and 2021 had 9, 70, and 18 total campaigns, respectively. So far in 2022, Proofpoint analysts have observed 51 TA558 campaigns.
Figure 6: Total number of TA558 campaigns over time
2021
In 2021, this actor continued to leverage emails with Office documents containing macros or Office exploits (e.g. CVE-2017-8570) to download and install malware. Its most consistently used malware payloads included vjw0rm, njRAT, Revenge RAT, Loda, and AsyncRAT.
Additionally, this group started to include more elaborate attack chains in 2021. For example, introducing more helper scripts and delivery mechanisms such as embedded Office documents within MSG files.
In this example 2021 campaign, emails purported to be, e.g.:
Emails masqueraded as Unimed, a Brazilian medical work cooperative and health insurance operator. These messages contained Microsoft Word attachments with macros which, if enabled, invoked a series of scripts to ultimately download and execute AsyncRAT.
Figure 7: Example TA558 email from 2021
Of note is the repeat use of the string “CDT” contained the replyto email address and C2 domain names.
AsyncRAT C2 domains:
warzonecdt[.]duckdns[.]org
cdt2021.zapto[.]org
Example PowerShell execution to download and execute AsyncRAT:
This was the actor’s least active year. Proofpoint observed just 18 campaigns conducted by TA558 in 2021.
2022
In 2022, campaign tempo increased significantly. Campaigns delivered a mixture of malware such as, Loda, Revenge RAT, and AsyncRAT. This actor used a variety of delivery mechanisms including URLs, RAR attachments, ISO attachments, and Office documents.
TA558 followed the trend of many threat actors in 2022 and began using container files such as RAR and ISO attachments instead of macro-enabled Office documents. This is likely due to Microsoft’s announcements in late 2021 and early 2022 about disabling macros by default in Office products, which caused a shift across the threat landscape of actors adopting new filetypes to deliver payloads.
Additionally, TA558 began using URLs more frequently in 2022. TA558 conducted 27 campaigns with URLs in 2022, compared to just five campaigns total from 2018 through 2021. Typically, URLs led to container files such as ISOs or zip files containing executables.
Figure 8: Campaigns using specific threat types over time
For example, this 2022 Spanish language campaign featured URLs leading to container files. Messages purported to be, e.g.:
The URL purported to be a legitimate 155 Hotel reservation link that led to an ISO file and an embedded batch file. The execution of the BAT file led to a PowerShell helper script that downloaded a follow-on payload, AsyncRAT.
Similar to earlier campaigns, persistence was achieved via a scheduled task:
In April 2022 Proofpoint researchers spotted a divergence from the typical email lure. One of the campaigns included a QuickBooks invoice email lure. Additionally, this campaign included the distribution of RevengeRAT which had not been observed in use by TA558 since December 2020. Messages purported to be:
From: Intuit QuickBooks Team <quickbooks@unimed-corporated.com>
The emails contained Excel attachments with macros that downloaded helper scripts via PowerShell and MSHTA. The execution of helper scripts ultimately led to the installation of RevengeRAT. Proofpoint has not seen this theme since April, and it is unclear why TA558 temporarily pivoted away from reservations themes.
Malware Use
Since 2018, TA558 has used at least 15 different malware families, sometimes with overlapping command and control (C2) domains. The most frequently observed payloads include Loda, Vjw0rm, AsyncRAT, and Revenge RAT.
Figure 10: Number of TA558 campaigns by malware type over time
Typically, TA558 uses attacker owned and operated infrastructure. However, Proofpoint has observed TA558 leverage compromised hotel websites to host malware payloads, thus adding legitimacy to its malware delivery and C2 traffic.
Language Use
Since Proofpoint began tracking TA558 through 2022, over 90% of campaigns were conducted in Portuguese or Spanish, with four percent featuring multiple language lure samples in English, Spanish, or Portuguese.
Figure 11: Campaign totals by language since 2018
Interestingly, the threat actor often switches languages in the same week. Proofpoint researchers have observed this actor send, for example, a campaign in English and the following day another campaign in Portuguese. Individual targeting typically differs based on campaign language.
Notable Campaign Artifacts
In addition to the consistent lure themes, targeting, message content, and malware payloads, Proofpoint researchers observed TA558 using multiple notable patterns in campaign data including the use of certain strings, naming conventions and keywords, domains, etc. For example, the actor appears to repeat the term CDT in email and malware attributes. This may relate to the CDT Travel organization and related travel reservation lure themes. Proofpoint researchers observed TA558 use the CDT term in dozens of campaigns since 2018, in C2 domains, replyto email addresses, payload URLs, scheduled task name, and Microsoft Office document metadata (i.e., Author, Last Saved By), and Microsoft Office macro language.
Throughout many of the 2019 and 2020 campaigns the threat actor used various URLs from the domain sslblindado[.]com to download either helper scripts or malware payloads. Some examples include:
microsofft[.]sslblindado[.]com
passagensv[.]sslblindado[.]com
system11[.]sslblindado[.]com
Like other threat actors, this group sometimes mimics technology service names to appear legitimate. For example, using terms in payload URLs or C2 domain names. Some examples include:
microsofft[.]sslblindado[.]com
firefoxsystem[.]sytes[.]net
googledrives[.]ddns[.]net
Another interesting pattern observed were common strings like “success” and “pitbull”. In several campaigns Proofpoint researchers spotted these strings in C2 domains. Some examples include:
successfully[.]hopto[.]org
success20[.]hopto[.]org
4success[.]zapto[.]org
From 2019 through 2020, TA558 conducted 10 campaigns used the keyword “Maringa” or “Maaringa” in payload URLs or email senders. Maringa is a city in Brazil. Examples include:
maringareservas[.]com[.]br/seila[.]rtf
maringa[.]turismo@system11[.]com[.]br
Possible Objectives
Proofpoint has not observed post-compromise activity from TA558. Based on the observed payloads, victimology, and campaign and message volume, Proofpoint assesses with medium to high confidence that this is a financially motivated cybercriminal actor.
The malware used by TA558 can steal data including hotel customer user and credit card data, allow lateral movement, and deliver follow-on payloads.
Open-source reporting provides insight into one possible threat actor objective. In July, CNN Portugal reported a Portuguese hotel’s website was compromised, and the actor was able to modify the website and direct customers to a fake reservation page. The actor stole funds from potential customers by posing as the compromised hotel. Although Proofpoint does not associate the identified activity with TA558, it provides an example of possible follow-on activity and the impacts to both target organizations and their customers if an actor is able to compromise hotel or transportation entities.
Conclusion
TA558 is an active threat actor targeting hospitality, travel, and related industries since 2018. Activity conducted by this actor could lead to data theft of both corporate and customer data, as well as potential financial losses.
Organizations, especially those operating in targeted sectors in Latin America, North America, and Western Europe should be aware of this actor’s tactics, techniques, and procedures.
Indicators of Compromise (IOCs)
The following IOCs represent a sample of indicators observed by Proofpoint researchers associated with TA558.
The issue in question is CVE-2022-22536, which has received the highest possible risk score of 10.0 on the CVSS vulnerability scoring system and was addressed by SAP as part of its Patch Tuesday updates for February 2022.
Described as an HTTP request smuggling vulnerability, the shortcoming impacts the following product versions –
SAP Web Dispatcher (Versions – 7.49, 7.53, 7.77, 7.81, 7.85, 7.22EXT, 7.86, 7.87)
“An unauthenticated attacker can prepend a victim’s request with arbitrary data, allowing for function execution impersonating the victim or poisoning intermediary web caches,” CISA said in an alert.
“A simple HTTP request, indistinguishable from any other valid message and without any kind of authentication, is enough for a successful exploitation,” Onapsis, which discovered the flaw, notes. “Consequently, this makes it easy for attackers to exploit it and more challenging for security technology such as firewalls or IDS/IPS to detect it (as it does not present a malicious payload).”
Aside from the SAP weakness, the agency added new flaws disclosed by Apple (CVE-2022-32893, and CVE-2022-32894) and Google (CVE-2022-2856) this week as well as previously documented Microsoft-related bugs (CVE-2022-21971 and CVE-2022-26923) and a remote code execution vulnerability in Palo Alto Networks PAN-OS (CVE-2017-15944, CVSS score: 9.8) that was disclosed in 2017.
CVE-2022-21971 (CVSS score: 7.8) is a remote code execution vulnerability in Windows Runtime that was resolved by Microsoft in February 2022. CVE-2022-26923 (CVSS score: 8.8), fixed in May 2022, relates to a privilege escalation flaw in Active Directory Domain Services.
“An authenticated user could manipulate attributes on computer accounts they own or manage, and acquire a certificate from Active Directory Certificate Services that would allow elevation of privilege to System,” Microsoft describes in its advisory for CVE-2022-26923.
The CISA notification, as is traditionally the case, is light on technical details of in-the-wild attacks associated with the vulnerabilities so as to avoid threat actors taking further advantage of them.
To mitigate exposure to potential threats, Federal Civilian Executive Branch (FCEB) agencies are mandated to apply the relevant patches by September 8, 2022.
Over the past few years, Google has observed that distributed denial-of-service (DDoS) attacks are increasing in frequency and growing in size exponentially. Today’s internet-facing workloads are at constant risk of attack with impacts ranging from degraded performance and user experience for legitimate users, to increased operating and hosting costs, to full unavailability of mission critical workloads. Google Cloud customers are able to use Cloud Armor to leverage the global scale and capacity of Google’s network edge to protect their environment from some of the largest DDoS attacks ever seen.
On June 1, a Google Cloud Armor customer was targeted with a series of HTTPS DDoS attacks which peaked at 46 million requests per second. This is the largest Layer 7 DDoS reported to date—at least 76% larger than the previously reported record. To give a sense of the scale of the attack, that is like receiving all the daily requests to Wikipedia (one of the top 10 trafficked websites in the world) in just 10 seconds.
Cloud Armor Adaptive Protection was able to detect and analyze the traffic early in the attack lifecycle. Cloud Armor alerted the customer with a recommended protective rule which was then deployed before the attack ramped up to its full magnitude. Cloud Armor blocked the attack ensuring the customer’s service stayed online and continued serving their end-users.
Figure 1: DDoS attack graph peaking at 46M requests per second.
What happened: Attack analysis and timeline
Starting around 9:45 a.m. PT on June 1, 2022, an attack of more than 10,000 requests per second (rps) began targeting our customer’s HTTP/S Load Balancer. Eight minutes later, the attack grew to 100,000 requests per second. Cloud Armor Adaptive Protection detected the attack and generated an alert containing the attack signature by assessing the traffic across several dozen features and attributes. The alert included a recommended rule to block on the malicious signature. The following is the alert showing details of the attack before it ramped to its peaks.
Figure 2: Cloud Armor Adaptive Protection alert listing the top region codes detected as a part of the attack.
Our customer’s network security team deployed the Cloud Armor-recommended rule into their security policy, and it immediately started blocking the attack traffic. In the two minutes that followed, the attack began to ramp up, growing from 100,000 rps to a peak of 46 million rps. Since Cloud Armor was already blocking the attack traffic, the target workload continued to operate normally. Over the next few minutes, the attack started to decrease in size, ultimately ending 69 minutes later at 10:54 a.m. Presumably the attacker likely determined they were not having the desired impact while incurring significant expenses to execute the attack.
Analyzing the attack
In addition to its unexpectedly high volume of traffic, the attack had other noteworthy characteristics. There were 5,256 source IPs from 132 countries contributing to the attack. As you can see in Figure 2 above, the top 4 countries contributed approximately 31% of the total attack traffic. The attack leveraged encrypted requests (HTTPS) which would have taken added computing resources to generate. Although terminating the encryption was necessary to inspect the traffic and effectively mitigate the attack, the use of HTTP Pipelining required Google to complete relatively few TLS handshakes.
Approximately 22% (1,169) of the source IPs corresponded to Tor exit nodes, although the request volume coming from those nodes represented just 3% of the attack traffic. While we believe Tor participation in the attack was incidental due to the nature of the vulnerable services, even at 3% of the peak (greater than 1.3 million rps) our analysis shows that Tor exit-nodes can send a significant amount of unwelcome traffic to web applications and services.
The geographic distribution and types of unsecured services leveraged to generate the attack matches the Mēris family of attacks. Known for its massive attacks that have broken DDoS records, the Mēris method abuses unsecured proxies to obfuscate the true origin of the attacks.
How we stopped the attack
The attack was stopped at the edge of Google’s network, with the malicious requests blocked upstream from the customer’s application. Before the attack started, the customer had already configured Adaptive Protection in their relevant Cloud Armor security policy to learn and establish a baseline model of the normal traffic patterns for their service.
As a result, Adaptive Protection was able to detect the DDoS attack early in its life cycle, analyze its incoming traffic, and generate an alert with a recommended protective rule–all before the attack ramped up. The customer acted on the alert by deploying the recommended rule leveraging Cloud Armor’s recently launchedrate limiting capability to throttle the attack traffic. They chose the ‘throttle’ action over a ‘deny’ action in order to reduce chance of impact on legitimate traffic while severely limiting the attack capability by dropping most of the attack volume at Google’s network edge.
Before deploying the rule in enforcement mode, it was first deployed in preview mode, which enabled the customer to validate that only the unwelcome traffic would be denied while legitimate users could continue accessing the service. As the attack ramped up to its 46 million rps peak, the Cloud Armor-suggested rule was already in place to block the bulk of the attack and ensure the targeted applications and services remained available.
Protecting your applications in the cloud
Attack sizes will continue to grow and tactics will continue to evolve. To be prepared, Google recommends using a defense-in-depth strategy by deploying defenses and controls at multiple layers of your environment and your infrastructure providers’ network to protect your web applications and services from targeted web attacks. This strategy includes performing threat modeling to understand your applications’ attack surfaces, developing proactive and reactive strategies to protect them, and architecting your applications with sufficient capacity to manage unanticipated increases in traffic volume.
With Google Cloud Armor, you are able to protect your internet facing applications at the edge of Google’s network and absorb unwelcome traffic far upstream from your applications.
Google Workspace (formerly G Suite) now has stronger protections for risky account actions, automatically blocking hijacking attempts with identity verification prompts and logging them for further investigation.
This added layer of security will block threat actors who gain access to a user’s account to protect personal data and sensitive information belonging to their organization.
The enhanced account protection capabilities are available to all Google Workspace customers, including legacy G Suite Basic and Business customers.
“Google will evaluate the session attempting the action, and if it’s deemed risky, it will be challenged with a ‘Verify it’s You’ prompt,” Google said.
“Through a second and trusted factor, such as a 2-step verification code, users can confirm the validity of the action.”
For instance, this new feature would block sensitive actions such as attempts to change the account’s name until “the true account owner can verify that this was intentional.”
Admins can disable it for users stuck behind login prompts
Google added that admins could also temporarily disable login challenges triggered on sensitive account actions for users who can’t get past the verification prompts.
“In the Admin console under Users > ‘UserName’> Security, admins can toggle login challenges OFF for ten minutes if a user gets stuck behind a ‘verify it’s you prompt’,” the company explained.
“We strongly recommend only using this option if contact with the user is credibly established, such as via a video call.”
It’s also important to mention that this feature only supports users using Google as their identity provider, blocking actions taken within Google products, with SAML users not being supported now.
This update builds on a previous Google Workspace security improvement announced in June, with new alerts added to inform of critical and sensitive changes to admin accounts.
Google has further secured Workspace users from attacks by rolling out new Google Drive warning banners in January to warn them of potentially suspicious files used for malware delivery and phishing attacks.
A new large-scale phishing campaign targeting Coinbase, MetaMask, Kraken, and Gemini users is abusing Google Sites and Microsoft Azure Web App to create fraudulent sites.
These phishing pages are promoted through comments posted to legitimate sites by a network of bots controlled by the threat actors. Posting links to phishing pages on various legitimate sites aims to increase traffic and boost the malicious site’s search engine rankings.
Furthermore, because the phishing sites are hosted in Microsoft and Google services, they aren’t flagged by automated moderator systems, allowing promotional messages to stay in the comment section for longer.
Comment containing multiple links to phishing pages(Netskope)
The new campaign was spotted by analysts at Netskope, who noted that this tactic has allowed some of the fraudulent sites to appear as the first result in Google Search.
Even worse, as shown below, Google has also included the phishing pages as featured snippets, giving them the highest exposure possible in the search results.
The first result for the given search term(Netskope)
Abusing legitimate services
Google Sites is a free web page creation tool, part of Google’s online service suite, allowing users to create websites and host them on Google Cloud or other providers.
Similarly, Microsoft’s Azure Web Apps is a platform helping users create, deploy, and manage web applications and websites.
Both services are trusted by internet security tools, offer competitive pricing and high availability, so they are a good option for creating phishing pages.
The crooks in the campaign seen by Netskope created sites that mimicked Metamask, Coinbase, Gemini, and Kraken, targeting people’s wallets and their assets.
The sites are just landing pages, and their visitors are redirected to the actual phishing sites when they click on the “login” buttons.
Landing page for Kraken phishing(Netskope)
Targeting wallets and services
The phishing campaign is currently attempting to steal MetaMask wallets and credentials for crypto exchanges, such as CoinBase, Kraken, and Gemini.
The MetaMask phishing site attempts to steal the user’s password and wallet’s secret recovery phrase (seed phrase). This information allows the threat actor to import the wallet on their own devices and drain the contents.
MetaMask phishing site asking the seed phrase(Netskope)
For the crypto exchange phishing pages, the threat actors attempt to steal their login credentials.
In all four cases, users who enter their credentials are redirected to a fake 2FA (two-factor authentication) page that requests the victim to provide their phone number.
After entering the code, the websites generate a fake error alleging unauthorized activity and authentication problems, prompting the victim to click on an “Ask Expert” button.
Bogus error message served to victims(Netskope)
This takes the victims to an online chat page where a scammer pretending to be a customer support agent promises to solve the problem by directing the victim to install the TeamViewer remote access tool.
The remote access is likely to allow the threat actors to retrieve the multi-factor authentication codes required to log in to the exchanges with the stolen credentials.
Don’t get phished
When attempting to log in to a crypto exchange, always make sure you are on the platform’s official website and not on a clone.
Users of locally installed cryptocurrency wallets, such as MetaMask, Phantom, and TrustWallet, should never share their recovery phrase on any website, regardless of the reason.
It is also important to remember that Google Ads can be abused, and Google Search SEO can be manipulated, so the ranking of the results shouldn’t be seen as a guarantee of safety.
Finally, protect your cryptocurrency exchange accounts with MFA and keep most of your crypto investments on cold wallets that are much more challenging to hack.
Google on Wednesday said it’s once again delaying its plans to turn off third-party cookies in the Chrome web browser from late 2023 to the second half of 2024.
“The most consistent feedback we’ve received is the need for more time to evaluate and test the new Privacy Sandbox technologies before deprecating third-party cookies in Chrome,” Anthony Chavez, vice president of Privacy Sandbox, said.
In keeping this in mind, the internet and ad tech giant said it’s taking a “deliberate approach” and extending the testing window for its ongoing Privacy Sandbox initiatives prior to phasing out third-party cookies.
Cookies are pieces of data planted on a user’s computer or other device by the web browser as a website is accessed, with third-party cookies fueling much of the digital advertising ecosystem and its ability to track users across different sites to show targeted ads.
Privacy Sandbox is Google’s umbrella term for a set of technologies that aim to improve users’ privacy across the web and Android by limiting cross-site and cross-app tracking and offering improved, safer alternatives to serve interest-based ads.
While Google had originally planned to roll out the feature in early 2022, it revised the timeline in June 2021, pushing its proposal to transition from third-party cookies over a three-month period, starting in mid-2023 and ending in late 2023.
“It’s become clear that more time is needed across the ecosystem to get this right,” the company noted at the time.
The second extension comes as Google announced Topics API as a replacement for FLoC (short for Federated Learning of Cohorts) in January 2022, following it up with a developer preview of Privacy Sandbox for Android in May.
In February 2022, the U.K. Competition and Markets Authority (CMA) formally accepted commitments from Google over how it develops the technology, pointing out the need to flesh out Privacy Sandbox such that it promotes competition and supports publishers to raise revenue from ads while also safeguarding consumer privacy.
Under the new plan, Privacy Sandbox trials are expected to be expanded to users globally next month, with the number of users included in the tests ramped up throughout the rest of the year and into 2023.
Google also emphasized that users will be shown a prompt to manage their participation, adding it intends to make the APIs generally available by Q3 2023, with third-party cookie support tentatively dropped in H2 2024.
The CMA, for its part, acknowledged today that it’s aware of “alternative proposals being developed by third-parties,” and that it’s “working with the [Information Commissioner’s Office] to better understand their viability and likely impacts.”
Posted by Matthew Maurer and Mike Yu, Android team
To help keep Android users’ DNS queries private, Android supports encrypted DNS. In addition to existing support for DNS-over-TLS, Android now supports DNS-over-HTTP/3 which has a number of improvements over DNS-over-TLS.
Most network connections begin with a DNS lookup. While transport security may be applied to the connection itself, that DNS lookup has traditionally not been private by default: the base DNS protocol is raw UDP with no encryption. While the internet has migrated to TLS over time, DNS has a bootstrapping problem. Certificate verification relies on the domain of the other party, which requires either DNS itself, or moves the problem to DHCP (which may be maliciously controlled). This issue is mitigated by central resolvers like Google, Cloudflare, OpenDNS and Quad9, which allow devices to configure a single DNS resolver locally for every network, overriding what is offered through DHCP.
In Android 9.0, we announced the Private DNS feature, which uses DNS-over-TLS (DoT) to protect DNS queries when enabled and supported by the server. Unfortunately, DoT incurs overhead for every DNS request. An alternative encrypted DNS protocol, DNS-over-HTTPS (DoH), is rapidly gaining traction within the industry as DoH has already been deployed by most public DNS operators, including the Cloudflare Resolver and Google Public DNS. While using HTTPS alone will not reduce the overhead significantly, HTTP/3 uses QUIC, a transport that efficiently multiplexes multiple streams over UDP using a single TLS session with session resumption. All of these features are crucial to efficient operation on mobile devices.
DNS-over-HTTP/3 (DoH3) support was released as part of a Google Play system update, so by the time you’re reading this, Android devices from Android 11 onwards1 will use DoH3 instead of DoT for well-known2 DNS servers which support it. Which DNS service you are using is unaffected by this change; only the transport will be upgraded. In the future, we aim to support DDR which will allow us to dynamically select the correct configuration for any server. This feature should decrease the performance impact of encrypted DNS.
Performance
DNS-over-HTTP/3 avoids several problems that can occur with DNS-over-TLS operation:
As DoT operates on a single stream of requests and responses, many server implementations suffer from head-of-line blocking3. This means that if the request at the front of the line takes a while to resolve (possibly because a recursive resolution is necessary), responses for subsequent requests that would have otherwise been resolved quickly are blocked waiting on that first request. DoH3 by comparison runs each request over a separate logical stream, which means implementations will resolve requests out-of-order by default.
Mobile devices change networks frequently as the user moves around. With DoT, these events require a full renegotiation of the connection. By contrast, the QUIC transport HTTP/3 is based on can resume a suspended connection in a single RTT.
DoT intends for many queries to use the same connection to amortize the cost of TCP and TLS handshakes at the start. Unfortunately, in practice several factors (such as network disconnects or server TCP connection management) make these connections less long-lived than we might like. Once a connection is closed, establishing the connection again requires at least 1 RTT.In unreliable networks, DoH3 may even outperform traditional DNS. While unintuitive, this is because the flow control mechanisms in QUIC can alert either party that packets weren’t received. In traditional DNS, the timeout for a query needs to be based on expected time for the entire query, not just for the resolver to receive the packet.
Field measurements during the initial limited rollout of this feature show that DoH3 significantly improves on DoT’s performance. For successful queries, our studies showed that replacing DoT with DoH3 reduces median query time by 24%, and 95th percentile query time by 44%. While it might seem suspect that the reported data is conditioned on successful queries, both DoT and DoH3 resolve 97% of queries successfully, so their metrics are directly comparable. UDP resolves only 83% of queries successfully. As a result, UDP latency is not directly comparable to TLS/HTTP3 latency because non-connection-oriented protocols have a different notion of what a “query” is. We have still included it for rough comparison.
Memory Safety
The DNS resolver processes input that could potentially be controlled by an attacker, both from the network and from apps on the device. To reduce the risk of security vulnerabilities, we chose to use a memory safe language for the implementation.
Fortunately, we’ve been adding Rust support to the Android platform. This effort is intended exactly for cases like this — system level features which need to be performant or low level (both in this case) and which would carry risk to implement in C++. While we’ve previously launched Keystore 2.0, this represents our first foray into Rust in Mainline Modules. Cloudflare maintains an HTTP/3 library called quiche, which fits our use case well, as it has a memory-safe implementation, few dependencies, and a small code size. Quiche also supports use directly from C++. We considered this, but even the request dispatching service had sufficient complexity that we chose to implement that portion in Rust as well.
We built the query engine using the Tokio async framework to simultaneously handle new requests, incoming packet events, control signals, and timers. In C++, this would likely have required multiple threads or a carefully crafted event loop. By leveraging asynchronous in Rust, this occurs on a single thread with minimal locking4. The DoH3 implementation is 1,640 lines and uses a single runtime thread. By comparison, DoT takes 1,680 lines while managing less and using up to 4 threads per DoT server in use.
Safety and Performance — Together at Last
With the introduction of Rust, we are able to improve both security and the performance at the same time. Likewise, QUIC allows us to improve network performance and privacy simultaneously. Finally, Mainline ensures that such improvements are able to make their way to more Android users sooner.
Acknowledgements
Special thanks to Luke Huang who greatly contributed to the development of this feature, and Lorenzo Colitti for his in-depth review of the technical aspects of this post.
Some Android 10 devices which adopted Google Play system updates early will also receive this feature. ↩
Google DNS and Cloudflare DNS at launch, others may be added in the future. ↩
DoT can be implemented in a way that avoids this problem, as the client must accept server responses out of order. However, in practice most servers do not implement this reordering. ↩
There is a lock used for the SSL context which is accessed once per DNS server, and another on the FFI when issuing a request. The FFI lock could be removed with changes to the C++ side, but has remained because it is low contention. ↩
ChromeOS Flex is a lightweight operating system from Google, which you can install on Windows, Mac, and Linux computers with older hardware, such as an old laptop or desktop computer. The operating system is based on Linux which uses web apps and the Chrome browser as the main interface.
The operating system also gives you security protection from threats such as malware and ransomware, and users will get a fast and modern work environment with background updates reducing downtime while boosting productivity.
Although Google offers many Chromebooks from different manufacturers that come preloaded with ChromeOS, the company now provides the ChromeOS Flex variant to give old computers a second life, especially for devices not compatible with Windows 11.
This guide will teach you the steps to install ChromeOS Flex on an old Windows-based computer.
Although Google only supports specific devices, you can still install the operating system on virtually any hardware as long as it meets the minimum requirements:
Processor: Intel or AMD x86-64-bit.
Memory: 4GB.
Storage: 16GB.
The requirements to run ChromeOS Flex are minimal, but Google says that processors and graphics made before 2010 may result in a poor user experience.
Aside from system requirements, you will also need a USB flash drive of at least 8GB to create the installation media.
Create ChromeOS Flex USB flash media
To create a ChromeOS Flex installation media, connect a USB flash drive of 8GB, and use these steps:
Click the Extension button and select the Chromebook Recovery Utility extension.
Click the Get started button.
Select the Google ChromeOS Flex option.
Select the ChromeOS Flex option.
Click the Continue button.
Select the USB flash media from the list.
Click the Continue button.
Click the Create now button.
Click the Done button.
Once you complete the steps, you can proceed with the clean installation of ChromeOS Flex.
Install ChromeOS Flex
To install ChromeOS Flex on a Windows device, use these steps:
Start the laptop with the ChromeOS Flex USB.Quick note: If the computer can’t boot from USB, you may need to update the BIOS/UEFI settings. This process usually requires pressing one of the function keys (F1, F2, F3, F10, or F12), the ESC, or the Delete key. For more accurate instructions, visit your PC manufacturer’s support website.
Click the Get Started button.
Select the “Try it first” option.Quick note: In this guide, we’ll use the “Try it first” option, but if you plan to dedicate the device to the operating system, select the “Install CloudReady 2.0” option.
Click the Next button.
Select the wireless network.
Confirm the Wi-Fi password.
Click the Connect button.
Click the Accept and continue button.
Select the You option to create an account.
Click the Next button.
Confirm your Gmail account.
Click the Next button.
Confirm the account password.
Click the Next button.
Complete the account verification.
Click the Next button.
Click the Accept and continue button.
After you complete the steps, the operating system will install on the computer.
A group of academics from the New Jersey Institute of Technology (NJIT) has warned of a novel technique that could be used to defeat anonymity protections and identify a unique website visitor.
“An attacker who has complete or partial control over a website can learn whether a specific target (i.e., a unique individual) is browsing the website,” the researchers said. “The attacker knows this target only through a public identifier, such as an email address or a Twitter handle.”
The cache-based targeted de-anonymization attack is a cross-site leak that involves the adversary leveraging a service such as Google Drive, Dropbox, or YouTube to privately share a resource (e.g., image, video, or a YouTube playlist) with the target, followed by embedding the shared resource into the attack website.
This can be achieved by, say, privately sharing the resource with the target using the victim’s email address or the appropriate username associated with the service and then inserting the leaky resource using an <iframe> HTML tag.
In the next step, the attacker tricks the victim into visiting the malicious website and clicking on the aforementioned content, causing the shared resource to be loaded as a pop-under window (as opposed to a pop-up) or a browser tab — a method that’s been used by advertisers to sneakily load ads.
This exploit page, as it’s rendered by the target’s browser, is used to determine if the visitor can access the shared resource, successful access indicating that the visitor is indeed the intended target.
The attack, in a nutshell, aims to unmask the users of a website under the attacker’s control by connecting the list of accounts tied to those individuals with their social media accounts or email addresses through a piece of shared content.
In a hypothetical scenario, a bad actor could share a video hosted on Google Drive with a target’s email address, and follow it up by inserting this video in the lure website. Thus when visitors land on the portal, a successful loading of the video could be used as a yardstick to infer if their victim is one among them.
The attacks, which are practical to exploit across desktop and mobile systems with multiple CPU microarchitectures and different web browsers, are made possible by means of a cache-based side channel that’s used to glean if the shared resource has been loaded and therefore distinguish between targeted and non-targeted users.
Put differently, the idea is to observe the subtle timing differences that arise when the shared resource is being accessed by the two sets of users, which, in turn, occurs due to differences in the time it takes to return an appropriate response from the web server depending on the user’s authorization status.
The attacks also take into account a second set of differences on the client-side that happens when the web browser renders the relevant content or error page based on the response received.
“There are two main causes for differences in the observed side channel leakages between targeted and non-targeted users – a server-side timing difference and a client-side rendering difference,” the researchers said.
While most popular platforms such as those from Google, Facebook, Instagram, LinkedIn, Twitter, and TikTok were found susceptible, one notable service that’s immune to the attack is Apple iCloud.
It’s worth pointing out the de-anonymization method banks on the prerequisite that the targeted user is already logged in to the service. As mitigations, the researchers have released a browser extension called Leakuidator+ that’s available for Chrome, Firefox, and Tor browsers.
To counter the timing and rendering side channels, website owners are recommended to design web servers to return their responses in constant time, irrespective of whether the user is provisioned to access the shared resource, and make their error pages as similar as possible to the content pages to minimize the attacker-observable differences.
“As an example, if an authorized user was going to be shown a video, the error page for the non-targeted user should also be made to show a video,” the researchers said, adding websites should also be made to require user interaction before rendering content.
“Knowing the precise identity of the person who is currently visiting a website can be the starting point for a range of nefarious targeted activities that can be executed by the operator of that website.”
The findings arrive weeks after researchers from the University of Hamburg, Germany, demonstrated that mobile devices leak identifying information such as passwords and past holiday locations via Wi-Fi probe requests.
In a related development, MIT researchers last month revealed the root cause behind a website fingerprinting attack as not due to signals generated by cache contention (aka a cache-based side channel) but rather due to system interrupts, while showing that interrupt-based side channels can be used to mount a powerful website fingerprinting attack.