Apr 15, 2024NewsroomCloud Security /SaaS Security

The threat actor known as Muddled Libra has been observed actively targeting software-as-a-service (SaaS) applications and cloud service provider (CSP) environments in a bid to exfiltrate sensitive data.

“Organizations often store a variety of data in SaaS applications and use services from CSPs,” Palo Alto Networks Unit 42 said in a report published last week.

“The threat actors have begun attempting to leverage some of this data to assist with their attack progression, and to use for extortion when trying to monetize their work.”

Muddled Libra, also called Starfraud, UNC3944, Scatter Swine, and Scattered Spider, is a notorious cybercriminal group that has leveraged sophisticated social engineering techniques to gain initial access to target networks.

“Scattered Spider threat actors have historically evaded detection on target networks by using living off the land techniques and allowlisted applications to navigate victim networks, as well as frequently modifying their TTPs,” the U.S. government said in an advisory late last year.

The attackers also have a history of monetizing access to victim networks in numerous ways, including extortion enabled by ransomware and data theft.

Unit 42 previously told The Hacker News that the moniker “Muddled Libra” comes from the “confusing muddled landscape” associated with the 0ktapus phishing kit, which has been put to use by other threat actors to stage credential harvesting attacks.

A key aspect of the threat actor’s tactical evolution is the use of reconnaissance techniques to identify administrative users to target when posing as helpdesk staff using phone calls to obtain their passwords.

The recon phase also extends to Muddled Libra, which performs extensive research to find information about the applications and the cloud service providers used by the target organizations.

“The Okta cross-tenant impersonation attacks that occurred from late July to early August 2023, where Muddled Libra bypassed IAM restrictions, display how the group exploits Okta to access SaaS applications and an organization’s various CSP environments,” security researcher Margaret Zimmermann explained.

The information obtained at this stage serves as a stepping stone for conducting lateral movement, abusing the admin credentials to access single sign-on (SSO) portals to gain quick access to SaaS applications and cloud infrastructure.

In the event SSO is not integrated into a target’s CSP, Muddled Libra undertakes broad discovery activities to uncover the CSP credentials, likely stored in unsecured locations, to meet their objectives.

The data stored with SaaS applications are also used to glean specifics about the infected environment, capturing as many credentials as possible to widen the scope of the breach via privilege escalation and lateral movement.

“A large portion of Muddled Libra’s campaigns involve gathering intelligence and data,” Zimmermann said.

“Attackers then use this to generate new vectors for lateral movement within an environment. Organizations store a variety of data within their unique CSP environments, thus making these centralized locations a prime target for Muddled Libra.”

These actions specifically single out Amazon Web Services (AWS) and Microsoft Azure, targeting services like AWS IAM, Amazon Simple Storage Service (S3), AWS Secrets Manager, Azure storage account access keys, Azure Blob Storage, and Azure Files to extract relevant data.

Data exfiltration to an external entity is achieved by abusing legitimate CSP services and features. This encompasses tools like AWS DataSync, AWS Transfer, and a technique called snapshot, the latter of which makes it possible to move data out of an Azure environment by staging the stolen data in a virtual machine.

Muddled Libra’s tactical shift requires organizations to secure their identity portals with robust secondary authentication protections like hardware tokens or biometrics.

“By expanding their tactics to include SaaS applications and cloud environments, the evolution of Muddled Libra’s methodology shows the multidimensionality of cyberattacks in the modern threat landscape,” Zimmermann concluded. “The use of cloud environments to gather large amounts of information and quickly exfiltrate it poses new challenges to defenders.”

Apr 06, 2024NewsroomSkimmer / Threat Intelligence

Threat actors have been found exploiting a critical flaw in Magento to inject a persistent backdoor into e-commerce websites.

The attack leverages CVE-2024-20720 (CVSS score: 9.1), which has been described by Adobe as a case of “improper neutralization of special elements” that could pave the way for arbitrary code execution.

It was addressed by the company as part of security updates released on February 13, 2024.

Sansec said it discovered a “cleverly crafted layout template in the database” that’s being used to automatically inject malicious code to execute arbitrary commands.

“Attackers combine the Magento layout parser with the beberlei/assert package (installed by default) to execute system commands,” the company said.

“Because the layout block is tied to the checkout cart, this command is executed whenever <store>/checkout/cart is requested.”

The command in question is sed, which is used to insert a code execution backdoor that’s then responsible for delivering a Stripe payment skimmer to capture and exfiltrate financial information to another compromised Magento store.

The development comes as the Russian government has charged six people for using skimmer malware to steal credit card and payment information from foreign e-commerce stores at least since late 2017.

The suspects are Denis Priymachenko, Alexander Aseyev, Alexander Basov, Dmitry Kolpakov, Vladislav Patyuk, and Anton Tolmachev. Recorded Future News reported that the arrests were made a year ago, citing court documents.

“As a result, members of the hacker group illegally took possession of information about almost 160 thousand payment cards of foreign citizens, after which they sold them through shadow internet sites,” the Prosecutor General’s Office of the Russian Federation said.

A suspected Vietnamese-origin threat actor has been observed targeting victims in several Asian and Southeast Asian countries with malware designed to harvest valuable data since at least May 2023.

Cisco Talos is tracking the cluster under the name CoralRaider, describing it as financially motivated. Targets of the campaign include India, China, South Korea, Bangladesh, Pakistan, Indonesia, and Vietnam.

“This group focuses on stealing victims’ credentials, financial data, and social media accounts, including business and advertisement accounts,” security researchers Chetan Raghuprasad and Joey Chen said. “They use RotBot, a customized variant of Quasar RAT, and XClient stealer as payloads.”

Other commodity malware used by the group comprises a combination of remote access trojans and information stealers such as AsyncRAT, NetSupport RAT, and Rhadamanthys.

The targeting of business and advertisement accounts has been of particular focus for attackers operating out of Vietnam, with various stealer malware families like Ducktail, NodeStealer, and VietCredCare deployed to take control of the accounts for further monetization.

The modus operandi entails the use of Telegram to exfiltrate the stolen information from victim machines, which is then traded in underground markets to generate illicit revenues.

“CoralRaider operators are based in Vietnam, based on the actor messages in their Telegram C2 bot channels and language preference in naming their bots, PDB strings, and other Vietnamese words hard-coded in their payload binaries,” the researchers said.

Attack chains start with a Windows shortcut file (LNK), although there is currently no clear explanation as to how these files are distributed to the targets.

Should the LNK file be opened, an HTML application (HTA) file is downloaded and executed from an attacker-controlled download server, which, in turn, runs an embedded Visual Basic script.

The script, for its part, decrypts and sequentially executes three other PowerShell scripts that are responsible for performing anti-VM and anti-analysis checks, circumventing Windows User Access Control (UAC), disabling Windows and application notifications, and downloading and running RotBot.

RotBot is configured to contact a Telegram bot and retrieve the XClient stealer malware and execute it in memory, ultimately facilitating the theft of cookies, credentials, and financial information from web browsers like Brave, Cốc Cốc, Google Chrome, Microsoft Edge, Mozilla Firefox, and Opera; Discord and Telegram data; and screenshots.

XClient is also engineered to siphon data from victims’ Facebook, Instagram, TikTok and YouTube accounts, gathering details about the payment methods and permissions associated with their Facebook business and ads accounts.

“RotBot is a variant of the Quasar RAT client that the threat actor has customized and compiled for this campaign,” the researchers said. “[XClient] has extensive information-stealing capability through its plugin module and various modules for performing remote administrative tasks.”

The development comes as Bitdefender disclosed details of a malvertising campaign on Facebook that’s taking advantage of the buzz surrounding generative AI tools to push an assortment of information stealers like Rilide, Vidar, IceRAT, and a new entrant known as Nova Stealer.

The starting point of the attack is the threat actor taking over an existing Facebook account and modifying its appearance to mimic well-known AI tools from Google, OpenAI, and Midjourney, and expanding their reach by running sponsored ads on the platform.

One is imposter page masquerading as Midjourney had 1.2 million followers before it was taken down on March 8, 2023. The threat actors managing the page were mainly from Vietnam, the U.S., Indonesia, the U.K., and Australia, among others.

“The malvertising campaigns have tremendous reach through Meta’s sponsored ad system and have actively been targeting European users from Germany, Poland, Italy, France, Belgium, Spain, the Netherlands, Romania, Sweden, and elsewhere,” the Romanian cybersecurity company said.

Mar 15, 2024NewsroomHardware Security / Data Protection

A group of researchers has discovered a new data leakage attack impacting modern CPU architectures supporting speculative execution.

Dubbed GhostRace (CVE-2024-2193), it is a variation of the transient execution CPU vulnerability known as Spectre v1 (CVE-2017-5753). The approach combines speculative execution and race conditions.

“All the common synchronization primitives implemented using conditional branches can be microarchitecturally bypassed on speculative paths using a branch misprediction attack, turning all architecturally race-free critical regions into Speculative Race Conditions (SRCs), allowing attackers to leak information from the target,” the researchers said.

The findings from the Systems Security Research Group at IBM Research Europe and VUSec, the latter of which disclosed another side-channel attack called SLAM targeting modern processors in December 2023.

Spectre refers to a class of side-channel attacks that exploit branch prediction and speculative execution on modern CPUs to read privileged data in the memory, bypassing isolation protections between applications.

While speculative execution is a performance optimization technique used by most CPUs, Spectre attacks take advantage of the fact that erroneous predictions leave behind traces of memory accesses or computations in the processor’s caches.

“Spectre attacks induce a victim to speculatively perform operations that would not occur during strictly serialized in-order processing of the program’s instructions, and which leak victim’s confidential information via a covert channel to the adversary,” the researchers behind the Spectre attack noted in January 2018.

What makes GhostRace notable is that it enables an unauthenticated attacker to extract arbitrary data from the processor using race conditions to access the speculative executable code paths by leveraging what’s called a Speculative Concurrent Use-After-Free (SCUAF) attack.

A race condition is an undesirable situation that occurs when two or more processes attempt to access the same, shared resource without proper synchronization, thereby leading to inconsistent results and opening a window of opportunity for an attacker to perform malicious actions.

“In characteristics and exploitation strategy, an SRC vulnerability is similar to a classic race condition,” the CERT Coordination Center (CERT/CC) explained in an advisory.

“However, it is different in that the attacker exploits said race condition on a transiently executed path originating from a mis-speculated branch (similar to Spectre v1), targeting a racy code snippet or gadget that ultimately discloses information to the attacker.”

The net result is that it permits an attacker with access to CPU resources to access arbitrary sensitive data from host memory.

“Any software, e.g., operating system, hypervisor, etc., implementing synchronization primitives through conditional branches without any serializing instruction on that path and running on any microarchitecture (e.g., x86, ARM, RISC-V, etc.), which allows conditional branches to be speculatively executed, is vulnerable to SRCs,” VUSec said.

Following responsible disclosure, AMD said its existing guidance for Spectre “remains applicable to mitigate this vulnerability.” The maintainers of the Xen open-source hypervisor acknowledged that all versions are impacted, although they said it’s unlikely to pose a serious security threat.

“Out of caution, the Xen Security Team have provided hardening patches including the addition of a new LOCK_HARDEN mechanism on x86 similar to the existing BRANCH_HARDEN,” Xen said.

“LOCK_HARDEN is off by default, owing to the uncertainty of there being a vulnerability under Xen, and uncertainty over the performance impact. However, we expect more research to happen in this area, and feel it is prudent to have a mitigation in place.”

Mar 11, 2024The Hacker NewsCybersecurity / Browser Security

As the shift of IT infrastructure to cloud-based solutions celebrates its 10-year anniversary, it becomes clear that traditional on-premises approaches to data security are becoming obsolete. Rather than protecting the endpoint, DLP solutions need to refocus their efforts to where corporate data resides – in the browser.

A new guide by LayerX titled “On-Prem is Dead. Have You Adjusted Your Web DLP Plan?” (download here) dives into this transition, detailing its root cause, possible solution paths forward and actionable implementation examples. After reading the guide, security and IT professionals will be equipped with the relevant information they need to update and upgrade their DLP solutions.

Guide highlights include:

Why DLP

The guide commences with an explanation of the role of the DLP. DLPs protect data from unwanted exposure by classification, determining its sensitivity level, and enforcing protective action. This is supposed to allow organizations to detect and prevent data breaches and other malicious activities and meet compliance regulations.

What Has Changed for DLP and Corporate Data

However, DLPs were designed with on-prem environments in mind. In these scenarios, data that leaves the environment is usually attached to an email or a hardware device. Therefore, DLPs were traditionally placed on the gateway between the corporate network and the public Internet. The rise of SaaS apps and website use requires an approach that addresses corporate data in its new location: online.

3 Data Protection Paths Forward

To address this gap, there are three ways security and IT teams can operate.

1. No Change – Using DLPs solutions as they are while limiting data uploads to insecure online locations. As explained, this solution is partially effective.

2. CASB DLP – Inspecting files with SaaS apps and enforcing policies between apps and devices and apps. This solution is effective for some sanctioned apps, but not for all or for unsanctioned ones.

3. Browser DLP – Monitoring data activity at the transaction point. This solution enforces policies across all vectors – devices, apps and the browser.

Since the browser is the interface between the device and websites and SaaS apps, it is the optimal location for placing the DLP. An enterprise browser extension can operate as a browser DLP, thanks to its ability to deeply monitor user activities and the web page execution. It can also enforce actions like alerting and blocking dangerous user actions.

Example Browser DLP Policies

Here are some examples of DLP policies that are designed to answer data location in a cloud environments:

• Alert about confidential files being attached to email web apps.
• Blocking confidential file uploads to personal Google Drives.
• Blocking confidential file downloads to unmanaged devices.

This guide is an essential read for any organization dealing with data that is online. You can read it here.

More than a decade ago, the concept of the ‘blameless’ postmortem changed how tech companies recognize failures at scale.

John Allspaw, who coined the term during his tenure at Etsy, argued postmortems were all about controlling our natural reaction to an incident, which is to point fingers: “One option is to assume the single cause is incompetence and scream at engineers to make them ‘pay attention!’ or ‘be more careful!’ Another option is to take a hard look at how the accident actually happened, treat the engineers involved with respect, and learn from the event.”

What can we, in turn, learn from some of the most honest and blameless—and public—postmortems of the last few years?

GitLab: 300GB of user data gone in seconds

What happened: Back in 2017, GitLab experienced a painful 18-hour outage. That story, and GitLab’s subsequent honesty and transparency, has significantly impacted how organizations handle data security today.

The incident began when GitLab’s secondary database, which replicated the primary and acted as a failover, could no longer sync changes fast enough due to increased load. Assuming a temporary spam attack created said load, GitLab engineers decided to manually re-sync the secondary database by deleting its contents and running the associated script.

When the re-sync process failed, another engineer tried the process again, only to realize they had run it against the primary.

What was lost: Even though the engineer stopped their command in two seconds, it had already deleted 300GB of recent user data, affecting GitLab’s estimates, 5,000 projects, 5,000 comments, and 700 new user accounts.

How they recovered: Because engineers had just deleted the secondary database’s contents, they couldn’t use it for its intended purpose as a failover. Even worse, their daily database backups, which were supposed to be uploaded to S3 every 24 hours, had failed. Due to an email misconfiguration, no one received the notification emails informing them as much.

In any other circumstance, their only choice would have been to restore from their previous snapshot, which was nearly 24 hours old. Enter a very fortunate happenstance: Just 6 hours before the data loss, an engineer had taken a snapshot of the primary database for testing, inadvertently saving the company from 18 additional hours of lost data.

After an excruciatingly slow 18 hours of copying data across slow network disks, GitLab engineers fully restored service.

What we learned

1. Analyze your root causes with the “Five whys.” GitLab engineers did an admirable job in their postmortem explaining the incident’s root cause. It wasn’t that an engineer accidentally deleted production data, but rather that an automated system mistakenly reported a GitLab employee for spam—the subsequent removal caused the increased load and primary<->secondary desync.

The deeper you diagnose what went wrong, the better you can build data security and business continuity systems that address the long chain of unfortunate events that might cause failure again.

1. Share your roadmap of improvements. GitLab has continuously operated with extreme transparency, which applies to this outage and data loss. In the aftermath, engineers have created dozens of public issues discussing their plans, like testing disaster recovery scenarios for all data not in their database. Making those fixes public gave their customers precise assurances and shared learnings with other tech companies and open-source startups.

1. Backups need ownership. Before this incident, no single GitLab engineer was responsible for validating the backup system or testing the restoration process, which meant no one did. GitLab engineers quickly assigned one of their team with rights to “stop the line” if data was at risk.

Read the rest: Postmortem of database outage of January 31.

Tarsnap: Deciding between safe data vs. availability

What happened: One morning in the summer of 2023, this one-person backup service went completely offline.

Tarsnap is run by Colin Percival, who’s been working on FreeBSD for over 20 years and is largely responsible for bringing that OS to Amazon’s EC2 cloud computing service. In other words, few people better understood how FreeBSD, EC2, and Amazon S3, which stored Tarsnap’s customer data, could work together… or fail.

Colin’s monitoring service notified him the central Tarsnap EC2 server had gone offline. When he checked on the instance’s health, he immediately found catastrophic filesystem damage—he knew right away he’d have to rebuild the service from scratch.

What was lost: No user backups, thanks to two smart decisions on Colin’s part.

First, Colin had built Tarsnap on a log-structured filesystem. While he cached logs on the EC2 instance, he stored all data in S3 object storage, which has its own data resilience and recovery strategies. He knew Tarsnap user backups were safe—the challenge was making them easily accessible again.

Second, when Colin built the system, he’d written automation scripts but had not configured them to run unattended. Instead of letting the infrastructure rebuild and restart services automatically, he wanted to double-check the state himself before letting scripts take over. He wrote, “‘Preventing data loss if something breaks’ is far more important than ‘maximize service availability.'”

How they recovered: Colin fired up a new EC2 instance to read the logs stored in S3, which took about 12 hours. After fixing a few bugs in his data restoration script, he could “replay” each log entry in the correct order, which took another 12 hours. With logs and S3 block data once again properly associated, Tarsnap was up and running again.

What we learned

1. Regularly test your disaster recovery playbook. In the public discourse around the outage and postmortem, Tarsnap users expressed their surprise that Colin had never tried his recovery scripts, which would have revealed multiple bugs that significantly delayed his responsiveness.

1. Update your processes and configurations to match changing technology. Colin admitted to never updating his recovery scripts based on new capabilities from the services Tarsnap relied on, like S3 and EBS. He could have read the S3 log data using more than 250 simultaneous connections or provisioned an EBS volume with higher throughput to shorten the timeline to full recovery.

1. Layer in human checks to gather details about your state before letting automation do the grunt work. There’s no saying exactly what would have happened had Colin not included some “seatbelts” in his recovery process, but it helped prevent a mistake like the GitLab folks.

Read the rest: 2023-07-02 — 2023-07-03 Tarsnap outage post-mortem

Roblox: 73 hours of ‘contention’

What happened: Around Halloween 2021, a game played by millions every day on an infrastructure of 18,000 servers and 170,000 containers experienced a full-blown outage.

The service didn’t go down all at once—a few hours after Roblox engineers detected a single cluster with high CPU load, the number of online players had dropped to 50% below normal. This cluster hosted Consul, which operated like middleware between many distributed Roblox services, and when Consul could no longer handle even the diminished player count, it became a single point of failure for the entire online experience.

What was lost: Only system configuration data. Most Roblox services used other storage systems within their on-premises data centers. For those that did use Consul’s key-value store, data was either stored after engineers solved the load and contention issues or safely cached elsewhere.

How they recovered: Roblox engineers first attempted to redeploy the Consul cluster on much faster hardware and then very slowly let new requests enter the system, but neither worked.

With assistance from HashiCorp engineers and many long hours, the teams finally narrowed down two root causes:

• Contention: After discovering how long Consul KV writes were blocked, the teams realized that Consul’s new streaming architecture was under heavy load. Incoming data fought over Go channels designed for concurrency, creating a vicious cycle that only tightened the bottleneck.
• A bug far downstream: Consul uses an open-source database, BoltDB, for storing logs. It was supposed to clean up old log entries regularly but never truly freed the disk space, creating a heavy compute workload for Consul.

After fixing these two bugs, the Roblox team restored service—a stressful 73 hours after that first high CPU alert.

What we learned

1. Avoid circular telemetry systems. Roblox’s telemetry systems, which monitored the Consul cluster, also depended on it. In their postmortem, they admitted they could have acted faster with more accurate data.

1. Look two, three, or four steps beyond what you’ve built for root causes. Modern infrastructure is based on a massive supply chain of third-party services and open-source software. Your next outage might not be caused by an engineer’s honest mistake but rather by exposing a years-old bug in a dependency, three steps removed from your code, that no one else had just the right environment to trigger.

Read the rest: Roblox Return to Service 10/28-10/31, 2021

Cloudflare: A long (state-baked) weekend

What happened: A few days before Thanksgiving Day 2023, an attacker used stolen credentials to access Cloudflare’s on-premises Atlassian server, which ran Confluence and Jira. Not long after, they used those credentials to create a persistent connection to this piece of Cloudflare’s global infrastructure.

The attacker attempted to move laterally through the network but was denied access at every turn. The day after Thanksgiving, Atlassian engineers permanently removed the attacker and took down the affected Atlassian server.

In their postmortem, Cloudflare states their belief the attacker was backed by a nation-state eager for widespread access to Cloudflare’s network. The attacker had opened hundreds of internal documents in Confluence related to their network’s architecture and security management practices.

What was lost: No user data. Cloudflare’s Zero Trust architecture prevented the attacker from jumping from the Atlassian server to other services or accessing customer data.

Atlassian has been in the news for another reason lately—their Server offering has reached its end-of-life, forcing organizations to migrate to Cloud or Data Center alternatives. During or after that drawn-out process, engineers realize their new platform doesn’t come with the same data security and backup capabilities they were used to, forcing them to rethink their data security practices.

How they recovered: After booting the attacker, Cloudflare engineers rotated over 5,000 production credentials, triaged 4,893 systems, and reimaged and rebooted every machine. Because the attacker had attempted to access a new data center in Brazil, Cloudflare replaced all the hardware out of extreme precaution.

What we learned

1. Zero Trust architectures work. When you build authorization/authentication right, you prevent one compromised system from deleting data or operating as a stepping-stone for lateral movement in the network.

1. Despite the exposure, documentation is still your friend. Your engineers will always need to know how to reboot, restore, or rebuild your services. Your goal is that even if an attacker learns everything about your infrastructure through your internal documentation, they still shouldn’t be able to create or steal the credentials necessary to intrude even deeper.

1. SaaS security is easier to overlook. This intrusion was only possible because Cloudflare engineers had failed to rotate credentials for SaaS apps with administrative access to their Atlassian products. The root cause? They believed no one still used said credentials, so there was no point in rotating them.

Read the rest: Thanksgiving 2023 security incident

What’s next for your data security and continuity planning?

These postmortems, detailing exactly what went wrong and elaborating on how engineers are preventing another occurrence, are more than just good role models for how an organization can act with honesty, transparency, and empathy for customers during a crisis.

If you can take a single lesson from allthese situations, someone in your organization, whether an ambitious engineer or an entire team, must own the data security lifecycle. Test and document everything because only practice makes perfect.

But also recognize that all these incidents occurred on owned cloud or on-premises infrastructure. Engineers had full access to systems and data to diagnose, protect, and restore them. You can’t say the same about the many cloud-based SaaS platforms your peers use daily, like versioning code and managing projects on GitHub or deploying lucrative email campaigns via Mailchimp. If something happens to those services, you can’t just SSH to check logs or rsync your data.

As shadow IT grows exponentially—a 1,525% increase in just seven years—the best continuity strategies won’t cover the infrastructure you own but the SaaS data your peers depend on. You could wait for a new postmortem to give you solid recommendations about the SaaS data frontier… or take the necessary steps to ensure you’re not the one writing it.

U.S. President Joe Biden has issued an Executive Order that prohibits the mass transfer of citizens’ personal data to countries of concern.

The Executive Order also “provides safeguards around other activities that can give those countries access to Americans’ sensitive data,” the White House said in a statement.

This includes sensitive information such as genomic data, biometric data, personal health data, geolocation data, financial data, and certain kinds of personally identifiable information (PII).

The U.S. government said threat actors could weaponize this information to track their citizens and pass that information to data brokers and foreign intelligence services, which can then be used for intrusive surveillance, scams, blackmail, and other violations of privacy.

“Commercial data brokers and other companies can sell this data to countries of concern, or entities controlled by those countries, and it can land in the hands of foreign intelligence services, militaries, or companies controlled by foreign governments,” the government said.

In November 2023, researchers at Duke University revealed that it’s trivial to “obtain sensitive data about active-duty members of the military, their families, and veterans, including non-public, individually identified, and sensitive data, such as health data, financial data, and information about religious practices” from data brokers for as low as $0.12 per record.

Stating that the sale of such data poses privacy, counterintelligence, blackmail, and national security risks, it added hostile nations could collect personal information on activists, journalists, dissidents, and marginalized communities with the goal of restricting freedom of expression and curbing dissent.

The government said the countries of concern have a “track record of collecting and misusing data on Americans.” According to the U.S. Justice Department, the countries that fall under this category include China, Russia, Iran, North Korea, Cuba, and Venezuela.

The Executive Order directs the federal agencies to issue regulations that establish clear protections for sensitive personal and government-related data from access and exploitation, as well as set high-security standards to limit data access via commercial agreements.

Additionally, the order requires the Departments of Health and Human Services, Defense, and Veterans Affairs to ensure that Federal grants, contracts, and awards are not misused to facilitate access to sensitive data.

“The Administration’s decision to limit personal data flows only to a handful of countries of concern, like China, is a mistake,” Senator Ron Wyden said in a statement, and that the argument that the U.S. government cannot be banned from buying Americans’ data is no longer valid.

“Authoritarian dictatorships like Saudi Arabia and U.A.E. cannot be trusted with Americans’ personal data, both because they will likely use it to undermine U.S. national security and target U.S. based dissidents, but also because these countries lack effective privacy laws necessary to stop the data from being sold onwards to China.”

The latest attempt to regulate the data broker industry comes as the U.S. added China’s Chengdu Beizhan Electronics and Canadian network intelligence firm Sandvine to its Entity List after the latter’s middleboxes were found to be used to deliver spyware targeting a former Egyptian member of parliament last year.

A report from Bloomberg in September 2023 also found that Sandvine’s equipment had been used by governments in Egypt and Belarus to censor content on the internet.

Access Now said Sandvine’s internet-blocking technologies facilitated human rights violations by repressive governments around the world, including in Azerbaijan, Jordan, Russia, Turkey, and the U.A.E., noting it played a “direct role” in shutting down the internet in Belarus in 2020.

“Sandvine supplies deep packet inspection tools, which have been used in mass web-monitoring and censorship to block news as well as in targeting political actors and human rights activists,” the U.S. Department of State said, explaining its rationale behind adding the company to the trade restriction list. “This technology has been misused to inject commercial spyware into the devices of perceived critics and dissidents.”

Feb 28, 2024The Hacker NewsWebinar / Privacy

In today’s digital era, data privacy isn’t just a concern; it’s a consumer demand. Businesses are grappling with the dual challenge of leveraging customer data for personalized experiences while navigating a maze of privacy regulations. The answer? A privacy-compliant Customer Data Platform (CDP).

Join us for a transformative webinar where we unveil Twilio Segment’s state-of-the-art CDP. Discover how it champions compliant and consented data use, empowering you to craft a holistic customer view and revolutionize engagement strategies.

What Will You Learn?

• Strategies for ethically democratizing data across your organization.
• The power of first-party data in unlocking profound customer insights.
• The pivotal role of a CDP in fostering compliant and consented data utilization.
• Proven customer engagement methodologies from industry leaders.

Why Should You Attend?

Twilio Segment’s State of Personalization Report reveals a compelling truth: 63% of consumers welcome personalization, provided it stems from directly shared data.

However, the phasing out of third-party cookies, the advent of privacy-centric browsers, and stringent regulations like GDPR have left businesses pondering how to personalize effectively within a privacy-first framework.

Don’t Miss Out!

In an age where data privacy and compliance are not just buzzwords but imperatives, mastering the ethical management of customer data is crucial for businesses striving for excellence.

Circle your calendar for “Building Your Privacy-Compliant Customer Data Platform (CDP) with First-Party Data.” Secure your spot now for an enlightening session you can’t afford to miss!

Feb 23, 2024NewsroomPrivacy / Regulatory Compliance

The U.S. Federal Trade Commission (FTC) has hit antivirus vendor Avast with a $16.5 million fine over charges that the firm sold users’ browsing data to advertisers after claiming its products would block online tracking.

In addition, the company has been banned from selling or licensing any web browsing data for advertising purposes. It will also have to notify users whose browsing data was sold to third parties without their consent.

The FTC, in its complaint, said Avast “unfairly collected consumers’ browsing information through the company’s browser extensions and antivirus software, stored it indefinitely, and sold it without adequate notice and without consumer consent.”

It also accused the U.K.-based company of deceiving users by claiming that the software would block third-party tracking and protect users’ privacy, but failing to inform them that it would sell their “detailed, re-identifiable browsing data” to more than 100 third-parties through its Jumpshot subsidiary.

What’s more, data buyers could associate non-personally identifiable information with Avast users’ browsing information, allowing other companies to track and associate users and their browsing histories with other information they already had.

The misleading data privacy practice came to light in January 2020 following a joint investigation by Motherboard and PCMag, calling out Google, Yelp, Microsoft, McKinsey, Pepsi, Home Depot, Condé Nast, and Intuit as some of Jumpshot’s “past, present, and potential clients.”

A month before, web browsers Google Chrome, Mozilla Firefox, and Opera removed Avast’s browser add-ons from their respective stores, with prior research from security researcher Wladimir Palant in October 2019 deeming those extensions as spyware.

The data, which includes a user’s Google searches, location lookups, and internet footprint, was collected via the Avast antivirus program installed on a person’s computer without seeking their informed consent.

“Browsing data [sold by Jumpshot] included information about users’ web searches and the web pages they visited – revealing consumers’ religious beliefs, health concerns, political leanings, location, financial status, visits to child-directed content and other sensitive information,” the FTC alleged.

Jumpshot described itself as the “only company that unlocks walled garden data,” and claimed to have data from as many as 100 million devices as of August 2018. The browsing information is said to have been collected since at least 2014.

The privacy backlash prompted Avast to “terminate the Jumpshot data collection and wind down Jumpshot’s operations, with immediate effect.”

Avast has since merged with another cybersecurity company NortonLifeLock to form a new parent company called Gen Digital, which also includes other products like AVG, Avira, and CCleaner.

“Avast promised users that its products would protect the privacy of their browsing data but delivered the opposite,” said Samuel Levine, director of the FTC’s Bureau of Consumer Protection. “Avast’s bait-and-switch surveillance tactics compromised consumers’ privacy and broke the law.”

Feb 06, 2024NewsroomDark Web / Cybercrime

Employment agencies and retail companies chiefly located in the Asia-Pacific (APAC) region have been targeted by a previously undocumented threat actor known as ResumeLooters since early 2023 with the goal of stealing sensitive data.

Singapore-headquartered Group-IB said the hacking crew’s activities are geared towards job search platforms and the theft of resumes, with as many as 65 websites compromised between November 2023 and December 2023.

The stolen files are estimated to contain 2,188,444 user data records, of which 510,259 have been taken from job search websites. Over two million unique email addresses are present within the dataset.

“By using SQL injection attacks against websites, the threat actor attempts to steal user databases that may include names, phone numbers, emails, and DoBs, as well as information about job seekers’ experience, employment history, and other sensitive personal data,” security researcher Nikita Rostovcev said in a report shared with The Hacker News.

“The stolen data is then put up for sale by the threat actor in Telegram channels.”

Group-IB said it also uncovered evidence of cross-site scripting (XSS) infections on at least four legitimate job search websites that are designed to load malicious scripts responsible for displaying phishing pages capable of harvesting administrator credentials.

ResumeLooters is the second group after GambleForce that has been found staging SQL injection attacks in the APAC region since late December 2023.

A majority of the compromised websites are based in India, Taiwan, Thailand, Vietnam, China, Australia, and Turkey, although compromises have also been reported from Brazil, the U.S., Turkey, Russia, Mexico, and Italy.

The modus operandi of ResumeLooters involves the use of the open-source sqlmap tool to carry out SQL injection attacks and drop and execute additional payloads such as the BeEF (short for Browser Exploitation Framework) penetration testing tool and rogue JavaScript code designed to gather sensitive data and redirect users to credential harvesting pages.

The cybersecurity company’s analysis of the threat actor’s infrastructure reveals the presence of other tools like Metasploit, dirsearch, and xray, alongside a folder hosting the pilfered data.

The campaign appears to be financially motivated, given the fact that ResumeLooters have set up two Telegram channels named 渗透数据中心 and 万国数据阿力 last year to sell the information.

“ResumeLooters is yet another example of how much damage can be made with just a handful of publicly available tools,” Rostovcev said. “These attacks are fueled by poor security as well as inadequate database and website management practices.”

“It is striking to see how some of the oldest yet remarkably effective SQL attacks remain prevalent in the region. However, the tenacity of the ResumeLooters group stands out as they experiment with diverse methods of exploiting vulnerabilities, including XSS attacks.”