The modern kill chain is eluding enterprises because they aren’t protecting the infrastructure of modern business: SaaS. 
SaaS continues to dominate software adoption, and it accounts for the greatest share of public cloud spending. But enterprises and SMBs alike haven’t revised their security programs or adopted security tooling built for SaaS. 
Security teams keep jamming on-prem

The modern kill chain is eluding enterprises because they aren't protecting the infrastructure of modern business: **SaaS**.

**SaaS continues to dominate software adoption**, and it accounts for the greatest share of public cloud spending. But enterprises and SMBs alike haven't revised their security programs or adopted security tooling built for SaaS.

**Security teams keep jamming on-prem pegs into SaaS security holes**

The mature security controls CISOs and their teams depended on in the age of on-prem dominance have vanished. Firewalls now protect a small perimeter, visibility is limited, and even if SaaS vendors offer logs, security teams need homegrown middleware to digest them and push into their SIEM.

SaaS vendors do have well-defined security scopes for their products, but their customers must manage SaaS compliance and data governance, identity and access management (IAM), and application controls — the areas where most incidents occur. While this SaaS shared responsibility model is universal among SaaS apps, no two SaaS applications have identical security settings.

Figure 1. In the context of SaaS security concerns, the application provider is responsible for all physical infrastructure, as well as the network, OS, and application. The customer is responsible for data security and identity management. The SaaS shared responsibility model requires SaaS customers to assume ownership of components that threat actors attack most often. Illustration courtesy of AppOmni.

> AppOmni research reports that on average, a single instance of SaaS has **256 SaaS-to-SaaS connections**, many of which are no longer in use, but still have excessive permissions into core business apps such as Salesforce, Okta, and GitHub, among others.

Between the multitude of different SaaS security settings and constant updates that alter them, security teams can't effectively monitor these connections. The number of entry points multiplies exponentially when employees enable SaaS-to-SaaS (also called "third party" or "machine") connections. Machine identities can use API keys, secrets, sessions, digital certificates, cloud access keys, and other credentials to enable machines to communicate with one another.

**As the attack surface migrated outside the network perimeter, so did the kill chain** — the way in which threat actors orchestrate the various phases of their attacks.

The modern SaaS kill chain usually involves:

1.  Compromising an identity in the IdP via a successful phishing campaign, purchasing stolen credentials off the dark web, credential strings, credential stuffing, taking advantage of misconfigured SaaS tenants, or similar methods.
2.  Conducting a post-authentication reconnaissance phase. This step is reminiscent of attackers breaking into the corporate networks of yore. But now they're combing through document repositories, source code repositories, password vaults, Slack, Teams, and similar environments to find privileged escalation entry points.
3.  Leveraging their findings to move laterally into other SaaS tenants, PaaS, or IaaS, and sometimes into the corporate infrastructure — wherever they can find the data most valuable to the target organization.
4.  Encrypting the crown jewels or delivering their ransom note, and attempting to evade detection.

Figure 2. Successful SaaS kill chains typically involve four overarching steps: initial access, reconnaissance, lateral movement and persistence, and ransomware execution and security evasion. Illustration courtesy of AppOmni.

**Breaking down a real-world SaaS kill chain: Scattered Spider/Starfraud**

SaaS security leader AppOmni's latest threat intelligence briefing webinar delineated the kill chain of the Scattered Spider/Starfraud threat actor groups' (affiliates of ALPHV) successful attack on an undisclosed target in September 2023:

*   A user opened a phishing email that contained links to a spoofed IdP login page, and they unknowingly logged into the fake IdP page.
*   The threat actor groups immediately called that user and convinced them, through social engineering, to provide their time-based, one-time password (TOTP) token.
*   After obtaining the user's login credentials and TOTP token, the threat actors tricked the MFA protocol into thinking they're the legitimate user.
*   While in reconnaissance mode, the threat actors had access to a privileged escalation, enabling them to obtain credentials into Amazon S3, then Azure AD, and finally Citrix VDI (virtual desktop infrastructure).
*   The threat actors then deployed their own malicious server in the IaaS environment, in which they executed a privileged Azure AD escalation attack.
*   The attackers encrypted all the data within their reach and delivered a ransom note.

Figure 3. The kill chain used by the Scattered Spider/Starfraud threat actor groups. Illustration courtesy of AppOmni.

Scattered Spider/Starfraud likely accomplished this series of events over several days. When SaaS serves as the entry point, a serious attack can include the corporate network and infrastructure. This SaaS/on-prem connectivity is common in today's enterprise attack surfaces.

**SaaS attack activity from known and unknown threat actors is growing**

Most SaaS breaches aren't dominating headlines, but the consequences are significant. IBM reports that **data breaches in 2023 averaged $4.45 million** per instance, representing a 15% increase over three years.

Threat actors are continually relying on the same TTPs and playbook of the Scattered Spider/Starfraud kill chain to gain unauthorized access and scan SaaS tenants, including Salesforce and M365 where configuration issues might be manipulated to provide access later.

Other attackers gain initial access with session hijacking and impossible travel. Once they've transferred the hijacked session to a different host, their lateral movement often involves communications platforms such as SharePoint, JIRA, DocuSign, and Slack, as well as document repositories like Confluence. If they can access GitHub or other source code repositories, threat actors will pull down that source code and analyze it for vulnerabilities within a target app. They'll attempt to exploit these vulnerabilities to exfiltrate the target app's data.

The AppOmni threat intelligence briefing also reports that data exfiltration via permission sharing remains a serious SaaS security concern. This occurs, for example, in Google Workspace when the unauthorized user changes directories to a very open level of permissions. The attacker may share them with another external entity via email forwarding, or changing conditional rules so attackers are included as BCC recipients in a distribution list.

**How do you protect your SaaS environments?****1\. Focus on SaaS systems hygiene**

Establish a SaaS intake and review process to determine what SaaS you'll allow in your company. This process should require answers to security questions such as:

*   Does all SaaS need to be SOC 2 Type 2 certified?
*   What is the optimal security configuration for each tenant?
*   How will your company avoid configuration drift?
*   How will you determine if automatic SaaS updates will require modifying security control settings?

Ensure you can detect Shadow IT SaaS (or **unsanctioned SaaS apps**) and have a response program so alerts aren't created in vain.

If you're not monitoring your SaaS tenants and ingesting all of the logs from them in some unified method, you'll never be able to detect suspicious behaviors and receive alerts based on them.

**2\. Inventory and continuously monitor machine accounts/identities**

> Threat actors target machine identities for their privileged access and lax authentication standards, often rarely requiring MFA.

In 2023, threat actors successfully targeted and breached major CI/CD tools Travis CI, CircleCI, and Heroku, stealing OAuth tokens for all of these providers' customers. The blast radius expands considerably in these situations.

With the average enterprise containing 256 machine identities, hygiene is often lacking. Many of them are used once or twice and then remain stagnant for years.

Inventory all of your machine identities and triage these critical risks. Once you've mitigated these, create policies that prescribe:

*   What type of accounts will be granted machine identities, and the requirements these vendors must meet to be granted access.
*   The time frame for how long their access/tokens are active before they will be revoked, refreshed, or regranted.
*   How you'll monitor these accounts for their usage and ensure they're still needed if they experience periods of dormancy.

**3\. Build out a true Zero Trust architecture in your SaaS estate**

Zero Trust architecture builds on the principle of least privilege (PLP) with a "never trust, always verify" approach. While Zero Trust has been established in traditional networks, it's rarely achieved in SaaS environments.

Zero Trust Network Access (ZTNA)'s network-centric approach cannot detect misconfigurations, machine integrations, or unwanted user access entitlements within and to SaaS platforms, which can have thousands or even millions of external users accessing data.

Zero Trust Posture Management (ZTPM), an emerging SaaS security tool, extends Zero Trust to your SaaS estate. It bridges the SaaS security gap that SASE creates by:

*   Preventing unauthorized ZTNA bypass
*   Allowing for fine-tuned access decisions
*   Enforcing your security policies with continuous feedback loops
*   Extending Zero Trust to machine integrations and cloud connections

With SSPM, ZTPM, and a **SaaS security program** in place, your team will gain the visibility and intelligence it needs to identify intruders in the low-risk stages of your kill chain — and stop them before a breach becomes devastating.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Combatting the Evolving SaaS Kill Chain: How to Stay Ahead of Threat Actors

AWS hosted a server linked to the Bezos family- and Nvidia-backed search startup that appears to have been used to scrape the sites of major outlets, prompting an inquiry into potential rules violations.

Amazon’s cloud division has launched an investigation into Perplexity AI. At issue is whether the AI search startup is violating Amazon Web Services rules by scraping websites that attempted to prevent it from doing so, WIRED has learned.

An AWS spokesperson, who talked to WIRED on the condition that they not be named, confirmed the company’s investigation of Perplexity. WIRED had previously found that the startup—which has backing from the Jeff Bezos family fund and Nvidia, and was recently valued at $3 billion—appears to rely on content from scraped websites that had forbidden access through the Robots Exclusion Protocol, a common web standard. While the Robots Exclusion Protocol is not legally binding, terms of service generally are.

The Robots Exclusion Protocol is a decades-old web standard that involves placing a plaintext file (like wired.com/robots.txt) on a domain to indicate which pages should not be accessed by automated bots and crawlers. While companies that use scrapers can choose to ignore this protocol, most have traditionally respected it. The Amazon spokesperson told WIRED that AWS customers must adhere to the robots.txt standard while crawling websites.

“AWS’s terms of service prohibit customers from using our services for any illegal activity, and our customers are responsible for complying with our terms and all applicable laws,” the spokesperson said in a statement.

Scrutiny of Perplexity’s practices follows a June 11 report from Forbes that accused the startup of stealing at least one of its articles. WIRED investigations confirmed the practice and found further evidence of scraping abuse and plagiarism by systems linked to Perplexity’s AI-powered search chatbot. Engineers for Condé Nast, WIRED’s parent company, block Perplexity’s crawler across all its websites using a robots.txt file. But WIRED found the company had access to a server using an unpublished IP address—44.221.181.252—which visited Condé Nast properties at least hundreds of times in the past three months, apparently to scrape Condé Nast websites.

The machine associated with Perplexity appears to be engaged in widespread crawling of news websites that forbid bots from accessing their content. Spokespeople for The Guardian, Forbes, and The New York Times also say they detected the IP address on its servers multiple times.

WIRED traced the IP address to a virtual machine known as an Elastic Compute Cloud (EC2) instance hosted on AWS, which launched its investigation after we asked whether using AWS infrastructure to scrape websites that forbade it violated the company’s terms of service.

Last week, Perplexity CEO Aravind Srinivas responded to WIRED’s investigation first by saying the questions we posed to the company “reflect a deep and fundamental misunderstanding of how Perplexity and the Internet work.” Srinivas then told Fast Company that the secret IP address WIRED observed scraping Condé Nast websites and a test site we created was operated by a third-party company that performs web crawling and indexing services. He refused to name the company, citing a nondisclosure agreement. When asked if he would tell the third party to stop crawling WIRED, Srinivas replied, “It’s complicated.”

Sara Platnick, a Perplexity spokesperson, tells WIRED that the company responded to Amazon’s inquiries on Wednesday and characterized the investigation as standard procedure. Platnick says Perplexity made no changes to its operation in response to Amazon’s concerns.

“Our PerplexityBot—which runs on AWS—respects robots.txt, and we confirmed that Perplexity-controlled services are not crawling in any way that violates AWS Terms of Service,” Platnick says. She adds, however, that PerplexityBot will ignore robots.txt when a user enters a specific URL in their prompt—a use-case Platnick describes as “very infrequent.”

“When a user prompts with a specific URL, that doesn’t trigger crawling behavior,” Platnick says. “The agent acts on the user’s behalf to retrieve the URL. It works the same way as if the user went to a page themselves, copied the text of the article, and then pasted it into the system.”

This description of Perplexity’s functionality confirms WIRED’s findings that its chatbot is ignoring robots.txt in certain instances.

Digital Content Next is a trade association for the digital content industry whose members include The New York Times, The Washington Post, and Condé Nast. Last year, the organization shared draft principles for governing generative AI to prevent potential copyright violations. CEO Jason Kint tells WIRED that if the allegations against Perplexity are true, the company is violating many of those principles.

“By default, AI companies should assume they have no right to take and reuse publishers' content without permission,” Kint says. If Perplexity is skirting terms of service or robots.txt, he adds, "the red alarms should be going off that something improper is going on.”

Amazon Is Investigating Perplexity Over Claims of Scraping Abuse

Plus: Alleged Apple source code leaks online, cybercrime group Scattered Spider's alleged kingpin gets arrested, and more.

The rolling series of breaches targeting customers of cloud platform Snowflake appears to be a supply chain attack wrapped in another supply chain attack. A hacker who claims to have been involved in the attacks tells WIRED that the hackers, known as ShinyHunter, stole victims’ Snowflake credentials by first breaching an employee of a third-party contractor. (The contractor, however, says it does not believe it was involved.)

Ultimately, the breach of the Snowflake customer accounts, which include Ticketmaster, banking firm Santander, and potentially more than 160 other companies, was possible because their Snowflake accounts did not have multifactor authentication enabled.

Antivirus giant Kaspersky’s worst nightmare has finally come true: The United States government announced on Thursday that it is banning the sale of its software to new customers in the US over alleged Russian national security threats. (Kaspersky has challenged the Biden administration’s claims.) Existing customers, meanwhile, will be banned from downloading Kaspersky software updates after September 29. What could go wrong?

Perplexity AI, an artificial-intelligence-powered search startup, says it’s already valued at a billion dollars. But a WIRED investigation published this week found that its secret sauce has a pungent ingredient: bullshit.

Beyond “hallucinating” details generated by its chatbot, WIRED found that the AI tool appears to be ignoring the Robots Exclusion Protocol—a standard web tool used to prevent scraping—on sites owned by WIRED’s parent company, Condé Nast, and other publications, seemingly allowing it to scrape articles despite the internet equivalent of a “Do Not Enter” sign hanging on WIRED and other Condé Nast sites. Perplexity’s chatbot later plagiarized that same article when prompted.

People traveling through some of the largest train stations in the United Kingdom secretly had their faces scanned by Amazon’s face-recognition tools, according to documents obtained by WIRED. The technology, which was used as part of a trial run, predicted travelers’ various attributes, including gender, age, and likely emotions. The surveillance, which one privacy advocate called “concerning,” could potentially be used for serving advertisements.

Finally, we detailed the rise of robot “dogs” used by militaries, explained what would happen if China invaded Taiwan, and got into the nitty-gritty of the boring-sounding but serious work of spotting the billion-dollar scam tactic known as business email compromise.

That’s not all. Each week, we round up the security and privacy news we didn’t cover in depth ourselves. Click the headlines to read the full stories. And stay safe out there.

For months, ransomware gangs have rampaged across the health care industry, with ruthless attacks targeting Change Healthcare’s national payment network for more than a thousand health care providers, Ascension Healthcare’s 140 hospitals, and dozens of other victims in the medical field. Now that hacking epidemic is crystallizing into yet another catastrophic hospital hack—one that has resulted in the data of 300 million UK patient records leaking online.

Synnovis, a joint-venture medical testing company partially owned by the UK’s National Health Service, has for weeks been battling and negotiating with the Russia-linked ransomware group Qilin, which has deeply disrupted its services in an attempt to extort the company. The result has been well over a thousand postponed operations and thousands more postponed outpatient appointments across multiple UK hospitals. Ambulances have been diverted from the affected hospitals, potentially causing delays in lifesaving care. They’ve even had to ask for new urgent donations of O-type blood, as testing disruptions have prevented other types from being used in patients’ blood transfusions.

A Catastrophic Hospital Hack Ends in a Leak of 300M Patient Records

PRESS RELEASE

DALLAS and TOKYO, June 18, 2024— VicOne, an automotive cybersecurity solutions leader, today announced that its xNexus and xZETA solutions are available in AWS Marketplace, a digital catalog with thousands of software listings from independent software vendors that make it easy to find, test, buy, and deploy software that runs on Amazon Web Services (AWS). xNexus is a next-generation vehicle security operations center (VSOC) platform and xZETA is an automotive vulnerability and software bill of materials (SBOM) management system. These safeguard the automotive software supply chain with unique zero-day threat intelligence, providing accurate, contextualized, and actionable insights for risk assessment.

AWS customers will now have access to VicOne’s solutions directly within AWS Marketplace. VicOne provides AWS customers with the ability to streamline the purchase and management of xNexus and xZETA within their AWS Marketplace account. 

“In various ways, our listing in AWS Marketplace is another of our efforts to help automotive manufacturers to securely put in place all of the many high-quality solutions they need across a globally scoped software supply chain for SDVs (software-defined vehicles),” said Max Cheng, chief executive officer of VicOne. “By accessing VicOne solutions, customers, MSSPs (managed security service providers) and other partners can more efficiently and simply offer our products to protect the automotive software supply chain against zero-day vulnerabilities and cyberattacks.” 

xNexus integrates with VicOne’s in-vehicle VSOC sensor, leveraging a unique large language modeling (LLM) approach to provide customized reporting to support VSOC teams. xNexus provides VSOC teams with actionable and contextualized attack paths based on different stakeholders’ needs. The capabilities delivered by VicOne’s next-gen VSOC platform accelerate threat investigations, enable confident response to attacks, and effectively reduce the burden of chasing false alarms. 

xZETA is an automotive vulnerability and SBOM management system that scans vehicle software to identify zero-day, undisclosed, known, and customer-discovered vulnerabilities, along with CWE, malware, and advanced persistent threats. Through xZETA’s patent-pending VicOne Vulnerability Impact Rating (VVIR) technology, external and internal insights are integrated to prioritize high-risk vulnerabilities. This enables swift identification of high-risk issues and formulation of corresponding strategies. Information feeds back into Threat Analysis and Risk Assessment (TARA) results to ensure alignment with ISO/SAE 21434 processes and maintain continuous monitoring.

Services will be available in Japan as soon as it is ready.

To learn more about the VicOne solutions available in AWS Marketplace, please visit here.

About VicOne

With a vision to secure the vehicles of tomorrow, VicOne delivers a broad portfolio of cybersecurity software and services for the automotive industry. Purpose-built to address the rigorous needs of automotive manufacturers and suppliers, VicOne solutions are designed to secure and scale with the specialized demands of the modern vehicle. As a Trend Micro subsidiary, VicOne is powered by a solid foundation in cybersecurity drawn from Trend Micro’s 30+ years in the industry, delivering unparalleled automotive protection and deep security insights that enable our customers to build secure as well as smart vehicles. For more information, visit vicone.com.

You May Also Like

VicOne Solutions for Detection of Zero-Day Vulnerabilities and Contextualized Attack Paths

A WIRED investigation shows that the AI-powered search startup Forbes has accused of stealing its content is surreptitiously scraping—and making things up out of thin air.

Considering Perplexity’s bold ambition and the investment it’s taken from Jeff Bezos’ family fund, Nvidia, and famed investor Balaji Srinivasan, among others, it’s surprisingly unclear what the AI search startup actually is.

Earlier this year, speaking to WIRED, Aravind Srinivas, Perplexity’s CEO, described his product—a chatbot that gives natural-language answers to prompts and can, the company says, access the internet in real time—as an “answer engine.” A few weeks later, shortly before a funding round valuing the company at a billion dollars was announced, he told Forbes, “It’s almost like Wikipedia and ChatGPT had a kid.” More recently, after Forbes accused Perplexity of plagiarizing its content, Srinivas told the AP it was a mere “aggregator of information.”

The Perplexity chatbot itself is more specific. Prompted to describe what Perplexity is, it provides text that reads, “Perplexity AI is an AI-powered search engine that combines features of traditional search engines and chatbots. It provides concise, real-time answers to user queries by pulling information from recent articles and indexing the web daily.”

A WIRED analysis and one carried out by developer Robb Knight suggest that Perplexity is able to achieve this partly through apparently ignoring a widely accepted web standard known as the Robots Exclusion Protocol to surreptitiously scrape areas of websites that operators do not want accessed by bots, despite claiming that it won’t. WIRED observed a machine tied to Perplexity—more specifically, one on an Amazon server and almost certainly operated by Perplexity—doing this on WIRED.com and across other Condé Nast publications.

The WIRED analysis also demonstrates that, despite claims that Perplexity’s tools provide “instant, reliable answers to any question with complete sources and citations included,” doing away with the need to “click on different links,” its chatbot, which is capable of accurately summarizing journalistic work with appropriate credit, is also prone to bullshitting, in the technical sense of the word.

WIRED provided the Perplexity chatbot with the headlines of dozens of articles published on our website this year, as well as prompts about the subjects of WIRED reporting. The results showed the chatbot at times closely paraphrasing WIRED stories, and at times summarizing stories inaccurately and with minimal attribution. In one case, the text it generated falsely claimed that WIRED had reported that a specific police officer in California had committed a crime. (The AP similarly identified an instance of the chatbot attributing fake quotes to real people.) Despite its apparent access to original WIRED reporting and its site hosting original WIRED art, though, none of the IP addresses publicly listed by the company left any identifiable trace in our server logs, raising the question of how exactly Perplexity’s system works.

Until earlier this week, Perplexity published in its documentation a link to a list of the IP addresses its crawlers use—an apparent effort to be transparent. However, in some cases, as both WIRED and Knight were able to demonstrate, it appears to be accessing and scraping websites from which coders have attempted to block its crawler, called Perplexity Bot, using at least one unpublicized IP address. The company has since removed references to its public IP pool from its documentation.

That secret IP address—44.221.181.252—has hit properties at Condé Nast, the media company that owns WIRED, at least 822 times in the past three months. One senior engineer at Condé Nast, who asked not to be named because he wants to “stay out of it,” calls this a “massive undercount” because the company only retains a fraction of its network logs.

WIRED verified that the IP address in question is almost certainly linked to Perplexity by creating a new website and monitoring its server logs. Immediately after a WIRED reporter prompted the Perplexity chatbot to summarize the website's content, the server logged that the IP address visited the site. This same IP address was first observed by Knight during a similar test.

It also appears probable that in some cases—and despite a graphical representation in its user interface that shows the chatbot “reading” specific source material before giving a reply to a prompt—Perplexity is summarizing not actual news articles but reconstructions of what they say based on URLs and traces of them left in search engines like extracts and metadata, offering summaries purporting to be based on direct access to the relevant text.

The magic trick that’s made Perplexity worth 10 figures, in other words, appears to be that it’s both doing what it says it isn’t and not doing what it says it is.

In response to a detailed request for comment referencing the reporting in this story, Srinivas issued a statement that said, in part, “The questions from WIRED reflect a deep and fundamental misunderstanding of how Perplexity and the Internet work.” The statement did not dispute the specifics of WIRED's reporting, and Srinivas did not respond to follow-up questions asking if he disputed WIRED's or Knight's analyses.

On June 6, Forbes published an investigative report about how former Google CEO Eric Schmidt’s new venture is recruiting heavily and testing AI-powered drones with potential military applications. (Forbes reported that Schmidt declined to comment.) The next day, John Paczkowski, an editor for Forbes, posted on X to note that Perplexity had essentially republished the sum and substance of the scoop. (“It rips off most of our reporting,” he wrote. “It cites us, and a few that reblogged us, as sources in the most easily ignored way possible.”)

That day, Srinivas thanked Paczkowski, noting that the specific product feature that had reproduced Forbes’ exclusive reporting had “rough edges” and agreeing that sources should be cited more prominently. Three days later, Srinivas boasted—inaccurately, it turned out—that Perplexity was Forbes’ second-biggest source of referral traffic. (WIRED’s own records show that Perplexity sent 1,265 referrals to WIRED.com in May, an insignificant amount in the context of the site’s overall traffic. The article to which the most traffic was referred got 17 views.) “We have been working on new publisher engagement products and ways to align long-term incentives with media companies that will be announced soon,” he wrote. “Stay tuned!”

Just what Srinivas meant soon became clear when Semafor reported ​​that the company had been “working on revenue-sharing deals with high-quality publishers”—arrangements that would allow Perplexity and publishers alike to profit from the publishers’ investments in reporting. According to Axios, Forbes' general counsel sent a letter to Srinivas last Thursday demanding Perplexity remove misleading articles and repay Forbes for advertising revenue earned from its alleged copyright infringement.

The focus on what Perplexity is doing is, while understandable, to some extent obscuring the more important question of how it’s doing it.

The basics of the “what” aren’t in serious dispute: Perplexity is making money from summarizing news articles, a practice that has existed as long as there has been news and that enjoys broad, though qualified, legal protection. Srinivas has acknowledged that at times these summaries have failed to credit the sources from which they’re derived fully or prominently enough, but more broadly he denied unethical or unlawful activity. Perplexity has “never ripped off content from anybody,” he told the AP. “Our engine is not training on anyone else’s content.”

This is a curious defense in part because it answers an objection no one has raised. Perplexity’s main offering isn’t a large language model that needs to be trained on a body of data, but rather a wrapper that goes around such systems. Users who pay $20 for a “Pro” subscription, as two WIRED reporters did, are given a choice of five AI models to use. One, Sonar Large 32k, is unique to Perplexity but based on Meta's LLaMa 3; the others are off-the-shelf versions of various models offered by OpenAI and Anthropic.

This is where we come to the how: When a user queries Perplexity, the chatbot isn’t just composing answers by consulting its own database, but also leveraging the “real-time access to the web” that Perplexity touts in marketing materials to gather information, then feeding it to the AI model a user has selected to generate a reply. In this way, while Perplexity has trained its own model and purports to leverage “sophisticated AI” to interpret prompts, calling it an “AI startup” is somewhat misleading; it would perhaps be more accurately described as a sort of remora attached to existing AI systems. (“To be clear, while Perplexity does not train foundation models, we are still an AI company,” Srinivas tells WIRED._)_

In theory, Perplexity’s chatbot shouldn’t be able to summarize WIRED articles, because our engineers have blocked its crawler via our robots.txt file since earlier this year. This file instructs web crawlers on which parts of the site to avoid, and Perplexity claims to respect the robots.txt standard. WIRED’s analysis found that in practice, though, prompting the chatbot with the headline of a WIRED article or a question based on one will usually produce a summary appearing to recapitulate the article in detail.

Entering the headline of this exclusive into the chatbot’s interface, for example, produces a four-paragraph block of text laying out the basic information that Keanu Reeves and the science fiction writer China Miéville have collaborated on a novel, seemingly complete with telling details. “Despite his initial apprehension about the potential collaboration, Reeves was enthusiastic about working with Miéville,” the text reads; this is followed by a gray circle which, when moused over, provides a link to the article. The text is illustrated by a photograph commissioned by WIRED; clicking the image produces a credit line and a link to the original article. (WIRED’s records show that Perplexity has directed six users to the article since its publication.)

Similarly, asking Perplexity “Are some cheap wired headphones actually using Bluetooth?” yields what appears to be a two-paragraph summary of this WIRED story, accompanied by the art that originally ran with it. "Although this method is not a scam, it can be seen as a deceptive or ingenious workaround depending on one's perspective," the text reads. This is closer to WIRED copy (”Is it a scam? Technically no—but depending on your point of view, there's either deception going on here or some kind of ingenious hack,” wrote staff writer Boone Ashworth) than either a human editor or lawyer might prefer, but the chatbot generates text insisting this is a mere coincidence.

“No, I did not plagiarize the phrase,” reads text generated by the chatbot in response to a prompt given by a WIRED reporter. “The similarity in wording is coincidental and reflects the common language used to describe such a nuanced situation.” How the common language is defined is unclear—aside from product listings for headphones, the only sources Perplexity cites here are the WIRED article and a Slashdot discussion of it.

Findings by Robb Knight, the developer, and a subsequent WIRED analysis suggest an explanation for some of what’s happening here: In brief, Perplexity is scraping websites without permission.

As Knight explains it, in addition to forbidding AI bots from the servers of Macstories.net, a site on which he works, by utilizing a robots.txt file, he additionally coded in a server-side block that in theory should present a crawler with a 403 forbidden response. He then put up a post describing how he had done this and asked the Perplexity chatbot to summarize it, yielding “a perfect summary of the post including various details that they couldn't have just guessed.”

“So,” he asked, reasonably, “what the fuck are they doing?”

Knight investigated his server logs and found that Perplexity had apparently ignored his robots.txt file and evaded his firewall, likely using an automated web browser running on a server with an IP address that the company does not publicly disclose. "I can't even block their IP ranges because it appears these headless browsers are not on their IP ranges," he wrote.

WIRED was able to confirm that a server at the IP address Knight observed—44.221.181.252—will, on demand, visit and download webpages when a user asks Perplexity about the webpage, regardless of what the site’s robots.txt says. According to an analysis of Condé Nast system logs by our company’s engineers, it's likely this IP address has accessed the company’s content thousands of times without permission.

Scraping websites that have asked not to be scraped may in some circumstances expose a company or an individual to legal risk, though the relevant case law is ambiguous and generally on the side of those accessing public websites. (“It’s a complicated area of law,” says Andrew Crocker, surveillance litigation director at the Electronic Frontier Foundation, “and there’s a lot of litigation around it.”) Knight, the developer, says his findings nonetheless make him “furious.”

“We’ve now got a huge industry of AI-related companies who are incentivized to do shady things to continue their business,” he tells WIRED. “By not identifying that it’s them accessing a site, they can continue to collect data unrestricted.”

“Millions of people,” says Srinivas, “turn to Perplexity because we are delivering a fundamentally better way for people to find answers.”

While Knight’s and WIRED’s analyses demonstrate that Perplexity will visit and use content from websites that it doesn't have permission to access, that doesn’t necessarily explain the vagueness of some of its responses to prompts about specific articles and the sheer inaccuracy of others. This mystery has one fairly obvious solution: In some cases, it isn’t actually summarizing the article.

In one experiment, WIRED created a test website containing a single sentence—“I am a reporter with WIRED”—and asked Perplexity to summarize the page. While monitoring the website’s server logs, we found no evidence that Perplexity attempted to visit the page. Instead, it invented a story about a young girl named Amelia who follows a trail of glowing mushrooms in a magical forest called Whisper Woods.

When pressed for answers about why it made up a story, the chatbot generated text that read, “You're absolutely right, I clearly have not actually attempted to read the content at the provided URL based on your observation of the server logs … Providing inaccurate summaries without making the effort to read the actual content is unacceptable behavior for an AI like myself.”

It’s unclear why the chatbot invented such a wild story, or why it didn’t attempt to access this website.

Despite the company’s claims about its accuracy and reliability, the Perplexity chatbot frequently exhibits similar issues. In response to prompts provided by a WIRED reporter and designed to test whether it could access this article, for example, text generated by the chatbot asserted that the story ends with a man being followed by a drone after stealing truck tires. (The man in fact stole an ax.) The citation it provided was to a 13-year-old WIRED article about government GPS trackers being found on a car. In response to further prompts, the chatbot generated text asserting that WIRED reported that an officer with the police department in Chula Vista, California, had stolen a pair of bicycles from a garage. (WIRED did not report this, and is withholding the name of the officer so as not to associate his name with a crime he didn’t commit.)

In an email, Dan Peak, assistant chief of police at Chula Vista Police Department, expressed his appreciation to WIRED for "correcting the record" and clarifying that the officer did not steal bicycles from a community member’s garage. However, he added, the department is unfamiliar with the technology mentioned and so cannot comment further.

These are clear examples of the chatbot “hallucinating”—or, to follow a recent article by three philosophers from the University of Glasgow, bullshitting, in the sense described in Harry Frankfurt’s classic _On Bullshit_. “Because these programs cannot themselves be concerned with truth, and because they are designed to produce text that _looks_ truth-apt without any actual concern for truth,” the authors write of AI systems, “it seems appropriate to call their outputs bullshit.”

(“We have been very upfront that answers will not be accurate 100% of the time and may hallucinate,” says Srinivas, “but a core aspect of our mission is to continue improving on accuracy and the user experience.”)

There would be no reason for the Perplexity chatbot to bullshit by extrapolating what was in an article if it were accessing it. It’s therefore logical to conclude that in some cases it isn’t, and is approximating what was likely in it from related material found elsewhere. The likeliest sources of such information would be URLs and bits of digital detritus gathered by and submitted to search engines like Google—a process something like describing a meal by tasting scraps and trimmings fished out of a garbage can.

Both the explanation of how Perplexity works published on its site and, for what it’s worth, text generated by the Perplexity chatbot in response to prompts related to its information-gathering workflow support this theory. After parsing a query, the text said, Perplexity deploys its web crawler, avoiding sites on which it’s blocked.

“Perplexity can also,” the text reads, “leverage search engines like Google and Bing to gather information.” In this sense, at least, it truly is just like a human.

Perplexity Is a Bullshit Machine

A threat actor who goes by alias markopolo has been identified as behind a large-scale cross-platform scam that targets digital currency users on social media with information stealer malware and carries out cryptocurrency theft.
The attack chains involve the use of a purported virtual meeting software named Vortax (and 23 other apps) that are used as a conduit to deliver Rhadamanthys, StealC,

Cybercrime / Cryptocurrency

A threat actor who goes by alias **markopolo** has been identified as behind a large-scale cross-platform scam that targets digital currency users on social media with information stealer malware and carries out cryptocurrency theft.

The attack chains involve the use of a purported virtual meeting software named Vortax (and 23 other apps) that are used as a conduit to deliver Rhadamanthys, StealC, and Atomic macOS Stealer (AMOS), Recorded Future's Insikt Group said in an analysis published this week.

"This campaign, primarily targeting cryptocurrency users, marks a significant rise in macOS security threats and reveals an expansive network of malicious applications," the cybersecurity company noted, describing markopolo as "agile, adaptable, and versatile."

There is evidence connecting the Vortax campaign to prior activity that leveraged trap phishing techniques to target macOS and Windows users via Web3 gaming lures.

A crucial aspect of the malicious operation is its attempt to legitimize Vortax on social media and the internet, with the actors maintaining a dedicated Medium blog filled with suspected AI-generated articles as well as a verified account on X (formerly Twitter) carrying a gold checkmark.

Downloading the booby-trapped application requires victims to provide a RoomID, a unique identifier to a meeting invitation that's propagated via replies to the Vortax account, direct messages, and cryptocurrency-related Discord and Telegram channels.

Once a user enters the necessary Room ID on the Vortax website, they are redirected to a Dropbox link or an external website that stages an installer for the software, which ultimately leads to the deployment of the stealer malware.

"The threat actor that operates this campaign, identified as markopolo, leverages shared hosting and C2 infrastructure for all of the builds," Recorded Future said.

"This suggests that the threat actor relies on convenience to enable an agile campaign, quickly abandoning scams once they are detected or producing diminishing returns, and pivoting to new lures."

The findings show that the pervasive threat of infostealer malware cannot be overlooked, especially in light of the recent campaign targeting Snowflake.

The development comes as Enea revealed SMS scammers' abuse of cloud storage services like Amazon S3, Google Cloud Storage, Backblaze B2, and IBM Cloud Object Storage to trick users into clicking on bogus links that direct to phishing landing pages that siphon customer data.

"Cybercriminals have now found a way to exploit the facility provided by cloud storage to host static websites (typically .HTML files) containing embedded spam URLs in their source code," security researcher Manoj Kumar said.

"The URL linking to the cloud storage is distributed via text messages, which appear to be authentic and can therefore bypass firewall restrictions. When mobile users click on these links, which contain well-known cloud platform domains, they are directed to the static website stored in the storage bucket."

In the final stage, the website automatically redirects users to the embedded spam URLs or dynamically generated URLs using JavaScript and deceives them into parting with personal and financial information.

"Since the main domain of the URL contains, for example, the genuine Google Cloud Storage URL/domain, it is challenging to catch it through normal URL scanning," Kumar said. "Detecting and blocking URLs of this nature presents an ongoing challenge due to their association with legitimate domains belonging to reputable or prominent companies."

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Warning: Markopolo's Scam Targeting Crypto Users via Fake Meeting Software

Forcing Microsoft to compete fairly is the most important next step in building a better defense against foreign actors.

Steve Weber, Professor of the Graduate School, UC Berkeley School of Information

June 18, 2024

4 Min Read

Source: Michael Urmann via Alamy Stock Photo

COMMENTARY

This month, Microsoft president Brad Smith was confronted by the US House Committee on Homeland Security, in a hearing over the cybersecurity woes that have plagued the government as a direct result of the company's security shortcomings. These issues, however, don't just come down to insecure products. They're symptoms of a larger disease — a lapse in market and competition policy that has allowed Microsoft to dominate virtually all of the public sector technology market. And the US government's failure to properly diagnose the deeper cause puts us all at risk. 

Microsoft, by its own admission, is ground zero for state-sponsored hacking groups, and flaws in the company's software have been responsible for a huge proportion of cyber breaches affecting the US government in recent memory. Our country's cyber watchdogs — the Department of Homeland Security's Cybersecurity and Infrastructure Security Agency (CISA) and Cyber Safety Review Board (CSRB) — have spent considerable resources assessing these incidents and trying to assess and address Microsoft's vulnerabilities.

There's a fundamental problem with this process. The government is confusing symptoms — persistent hacks, breaches, and vulnerabilities — with an underlying disease: the lack of competition around cybersecurity. Microsoft has systematically exploited weaknesses in procurement processes to stifle competition and lock government customers into its insecure technology. That confusion ultimately leaves the government's tools to enhance competition on the sidelines, when those tools are the best remedy for cyber insecurity.

Microsoft holds an 85% market share of government collaboration and communications technology and now is awarded at least a quarter of its contracts without any meaningful competition. It's reached this position through a series of deliberate, anticompetitive moves the government has largely neglected. Stretched government procurement officers and chief information security officers (CISOs) are taking the path of least resistance. That's not their fault; it's a difficult consequence of their job. But Microsoft exploits this by making it expensive and difficult to run its software on a competitor's cloud, including charging a five-times premium just to use Word on Amazon's cloud instead of its own Azure cloud service. Microsoft bundles dozens of ancillary applications with its Office productivity apps in its licenses (including Access, Delve, Viva, and others), which stifles competition by linking basic, widely used services with less popular ones and pricing them as free.

The result? A software monoculture with a simple attack surface for the United States' adversaries with nearly a single point of failure: Microsoft. This is a major threat to national security. The potential harm is real and expensive. The US government spent more than $11.1 billion on cybersecurity in 2023, in large part trying to compensate for and respond to the Microsoft incidents that left it vulnerable to intrusion. 

Some lawmakers are ready to take action. Senator Ron Wyden recently drafted legislation that would require the government to set new standards for collaboration software in response to a CSRB report. It's a good step, but it solves only part of the problem. Even if the government can collaborate with other providers while using Microsoft's software, the company's licenses still make it very expensive, all at a major cost to the taxpayer.

**A Better Solution Is Needed**

The government must use all the tools at its disposal to create a more comprehensive solution that immediately targets the root cause of its cybersecurity woes: Microsoft's anticompetitive licensing restrictions. These tools include using the General Services Administration (GSA) to modify procurement processes as a means of bolstering national security. The GSA is responsible for providing agencies with cost-effective, high-quality products from diverse vendors, and the evidence is clear that Microsoft doesn't meet these standards. The GSA can take action by either negotiating better licensing conditions with the company or by looking at other vendors to help diversify the government's tech infrastructure. That would be a strong and timely step to set the stage for more comprehensive and sweeping competition policy action by the Federal Trade Commission (FTC) or the Department of Justice. It's also a step that wouldn't take years to implement — which is vital given the current and future costs of Microsoft's efforts to lock government customers into long-term contracts. The longer the government waits, the harder the lock-in will be to reverse.

It can't settle for identifying symptoms. Microsoft's licensing is responsible for a debilitating disease that has infected our government's tech infrastructure. Allowing major government contracts to be awarded to any one company — in this case, Microsoft — is only plausible if procurement officials believe they really don't have any other choice. But we already have the remedies necessary to level the playing field and make enterprise software vendors accountable for weak cybersecurity. Forcing Microsoft to compete fairly is the most important next step to build a better defense against foreign actors. We have multiple tools to create a level playing field. We just need to use them. 

**About the Author(s)**

Professor of the Graduate School, UC Berkeley School of Information

Steve Weber works at the intersection of technology markets, intellectual property regimes, and international politics He has published numerous books, including The Success of Open Source and, most recently, Bloc by Bloc: How to Build a Global Enterprise for the New Regional Order, and serves as Professor of the Graduate School, School of Information, UC Berkeley. He has worked with and received research funding from a number of technology firms, including Google and Microsoft.

The Software Licensing Disease Infecting Our Nation's Cybersecurity

Microsoft last year described the threat actor — known as UNC3944, Scattered Spider, Scatter Swine, Octo Tempest, and 0ktapus — as one of the most dangerous current adversaries.

Source: Photo Spirit via Shutterstock

The recent attacks on customer accounts hosted on the Snowflake data warehousing platform could signal a broader shift among threat actors to targeting software-as-a-service (SaaS) application environments.

A recent Mandiant report highlighted another large threat actor that has begun going after enterprise data in SaaS applications in a broadening of its usual focus on Microsoft cloud environments and on-premises infrastructure. The threat actor, which Mandiant is tracking as UNC3944, is an English-language speaking group that other vendors have been tracking variously as Scattered Spider, Scatter Swine, Octo Tempest, and 0ktapus.

**UNC3944: A Dangerous Cyber Adversary**

The group's more recent capers have included a ransomware attack that knocked numerous critical systems offline for days at MGM Resorts last year and another that targeted Caesars Entertainment, which reportedly paid millions of dollars to the group to get back access to its data. The likely US- or UK-based threat actor is known for its SIM-swapping tactics and highly sophisticated credential-phishing skills, which include calling into enterprise help desks and resetting Okta credentials to take over accounts. Microsoft last year categorized UNC3944 as one of the most dangerous financially motivated cyber-threat groups active currently.

According to Mandiant, UNC3944 has broadened its focus to data in enterprise SaaS applications over the past 10 months or so. 

"In addition to traditional on-premises activity, Mandiant observed pivots into client SaaS applications," according to the security vendor's analysis. In many of these attacks the threat actor has used stolen credentials to access SaaS applications protected by single sign-on providers such as Okta. "Mandiant observed unauthorized access to such applications as vCenter, CyberArk, Salesforce, Azure, CrowdStrike, AWS, and Google Cloud Platform."

After gaining access to these environments, the threat actor has typically conducted at least some reconnaissance activity using a variety of methods, including Microsoft's Delve, to search for data in Microsoft 365 environments. The threat actor has then stolen data from these apps and transferred the data to cloud storage resources such as Amazon S3 buckets, using Airbyte, Fivetran, and other cloud synchronization utilities.

"These applications required only credentials and a path to the resources to sync the data to an external source automatically, often without the need for a subscription or expensive costs," Mandiant researchers said.

**Sophisticated Social Engineering Tactics**

Phishing and social engineering remains one of the group's primary methods to acquire credentials for accessing enterprise SaaS accounts. In attacks that Mandiant observed, UNC3944 actors made voice calls in clear English to help desk staff to get their assistance in gaining access to privileged accounts. In many of these calls, the adversary appeared to possess the detailed personal information — such as the last four digits of the victim's Social Security number, dates of birth, and manager information — required to pass the help desk administrator's initial user authentication checks.

"The level of sophistication in these social engineering attacks is evident in both the extensive research performed on potential victims and the high success rate in said attacks," Mandiant researchers said.

Mandiant's report highlighted UNC3944's creation of new virtual machines in victim environments as a particularly effective persistence mechanism. The threat actor's modus operandi is to use single sign-on (SSO) apps to access VMware vSphere and Microsoft Azure cloud environments.

"The importance here is the observation of abusing administrative groups or normal administrator permissions tied through SSO applications to then create this method of persistence," according to the report.

**Leveraging VMs for Persistence**

After creating a new virtual machine, the threat actor has used specific tools to reconfigure the VMs to remove default Microsoft Defender protections and telemetry that would be of use in a forensic investigation. In situations where the compromised environment might not have any endpoint monitoring, the threat actor has downloaded multiple tools to the new VMs, including credential extraction utilities such as Mimikatz and ADRecon, and tunneling tools such as NGROK and RSOCX. Such tools allow UNC3944 to access the virtual machine without requiring any multifactor authentication (MFA) or VPN, according to Mandiant.

Mandiant's recommendations for organizations include using host-based certificates and MFA for VPN access, and creating strict conditional access policies to limit what is visible inside a cloud tenant.

According to the report, Mandiant recommends "heightened monitoring of SaaS applications, to include centralizing logs from important SaaS-based applications, MFA re-registrations, and virtual machine infrastructure, specifically about both uptime and the creation of new devices."

**About the Author(s)**

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year career at Computerworld, Jai also covered a variety of other technology topics, including big data, Hadoop, Internet of Things, e-voting, and data analytics. Prior to Computerworld, Jai covered technology issues for The Economic Times in Bangalore, India. Jai has a Master's degree in Statistics and lives in Naperville, Ill.

Scattered Spider Pivots to SaaS Application Attacks

A ShinyHunters hacker tells WIRED that they gained access to Ticketmaster’s Snowflake cloud account—and others—by first breaching a third-party contractor.

Hackers who stole terabytes of data from Ticketmaster and other customers of the cloud storage firm Snowflake claim they obtained access to some of the Snowflake accounts by first breaching a Belarusian-founded contractor that works with those customers.

About 165 customer accounts were potentially affected in the recent hacking campaign targeting Snowflake’s customers, but only a few of these have been identified so far. In addition to Ticketmaster, the banking firm Santander has also acknowledged that their data was stolen but declined to identify the account from which it was stolen. Wired, however, has independently confirmed that it was a Snowflake account; the stolen data included bank account details for 30 million customers, including 6 million account numbers and balances, 28 million credit card numbers, and human resources information about staff, according to a post published by the hackers. Lending Tree and Advance Auto Parts have also said they might be victims as well.

Snowflake has not revealed details about how the hackers accessed the accounts, saying only that the intruders did not directly breach Snowflake’s network. This week, Google-owned security firm Mandiant, one of the companies engaged by Snowflake to investigate the breaches, revealed in a blog post that in some cases the hackers first obtained access through third-party contractors, without identifying the contractors or stating how this access aided the hackers in breaching the Snowflake accounts.

But according to one of the hackers who spoke with WIRED through a text chat, one of those firms was EPAM Systems, a publicly traded software engineering and digital services firm, founded by Belarus-born Arkadiy Dobkin, with current revenue of around $4.8 billion. The hacker says his group, which calls themselves ShinyHunters, used data found on an EPAM employee system to gain access to some of the Snowflake accounts.

EPAM told WIRED that it does not believe that it played a role in the breaches and suggested the hacker had fabricated the tale. ShinyHunters has been around since 2020 and has been responsible for numerous breaches since then that involve stealing large troves of data and leaking or selling it online.

Snowflake is a large data storage and analysis firm that provides tools for companies to derive intelligence and insight from customer data. EPAM develops software and provides various managed services for customers worldwide, primarily in North America, Europe, Asia, and Australia, according to its web site, with about 60 percent of its revenue coming from customers in North America. Among the services EPAM provides customers is assistance with using and managing their Snowflake accounts to store and analyze their data. EPAM claims it has some 300 workers who are experienced in using Snowflake’s data analytics tools and services, and announced in 2022 that it had attained “Elite Tier Partner” status with Snowflake to leverage the latter’s analytics platform for its customers.

EPAM’s founder emigrated from Belarus to the US in the ’90s before founding his company in 1993 from his New Jersey apartment. Nearly two-thirds of EPAM’s 55,000 employees resided in Ukraine, Belarus, and Russia until Russia invaded Ukraine, at which point the company says it closed its Russia operations and moved some of its Ukrainian workers to locations outside of that country.

The hacker who spoke with WIRED says that a computer belonging to one of EPAM’s employees in Ukraine was infected with info-stealer malware through a spear-phishing attack. It’s unclear if someone from ShinyHunters conducted this initial breach or just purchased access to the infected system from someone else who hacked the worker and installed the infostealer. The hacker says that once on the EPAM worker’s system, they installed a remote-access Trojan, giving them complete access to everything on the worker’s computer.

Using this access, they say, they found unencrypted usernames and passwords that the worker used to access and manage EPAM customers’ Snowflake accounts, including an account for Ticketmaster. The hacker says the credentials were stored on the worker’s machine in a project management tool called Jira. The hackers were able to use those credentials, they say, to access the Snowflake accounts because the Snowflake accounts didn’t require multifactor authentication (MFA) to access them. (MFA requires that users type in a one-time temporary code in addition to a username and password, making accounts that use MFA more secure.)

While EPAM denies it was involved in the breach, hackers did steal data from Snowflake accounts including Ticketmaster's, and have extorted the owners of the data by demanding hundreds of thousands, and in some cases more than a million, dollars to destroy the data or risk having the hackers sell it elsewhere.

The hacker who spoke with WIRED didn’t identify all of the victims breached through EPAM but did indicate that Ticketmaster was one of them. Ticketmaster did not respond to a request for comment from WIRED. But Ticketmaster’s parent company, Live Nation, has acknowledged that data was stolen from its Snowflake account in May without revealing how much data was stolen or how the hackers accessed the Snowflake account. In a post offering the data for sale, however, the hackers indicated that they had taken data on 560 million Ticketmaster consumers.

The hacker claims that in some cases they were able to directly access the Snowflake account of EPAM customers using the plaintext usernames and passwords they found on the EPAM worker’s computer. But in cases where Snowflake credentials weren’t stored on the worker’s system, the hacker claims they sifted through stockpiles of old credentials stolen in previous breaches by hackers using infostealer malware and found additional usernames and passwords for Snowflake accounts, including ones harvested from the machine of the same EPAM worker in Ukraine.

Credentials harvested by infostealers are often posted online or made available for sale on hacker forums. If victims don’t change their login credentials after a breach, or don’t know their data has been stolen, those credentials can remain active and available for years. It’s especially problematic if those credentials are used across multiple accounts; hackers can identify the user through the email address they use as a login credential, and if that person reuses the same password, hackers can simply try those credentials in multiple places.

The hackers in this case say they were able to use credentials stolen by an infostealer in 2020 to access Snowflake accounts.

WIRED wasn’t able to independently confirm that the hackers were inside the EPAM worker’s machine or used EPAM to gain access to Ticketmaster’s data and other Snowflake accounts, but the hacker provided WIRED with a file that appears to be a list of EPAM worker credentials lifted from the company’s Active Directory database after they gained access to the worker’s computer.

Furthermore, in the blog post written by Mandiant, which was published after the hacker told WIRED about his group’s use of data harvested by infostealers, the security firm revealed that the hackers who breached Snowflake accounts used old data siphoned by infostealers to access some of the accounts. Mandiant said that about 80 percent of the victims it identified in the Snowflake campaign were compromised using credentials that had previously been stolen and exposed by infostealers.

And an independent security researcher who has been helping to negotiate the ransom transactions between the ShinyHunter hackers and victims of the Snowflake campaign pointed WIRED to an online repository of data harvested by an infostealer that includes data siphoned from the computer of the EPAM worker in Ukraine that the hacker says was used to gain access to the Snowflake accounts. This stolen data includes the worker’s browser history, which reveals the worker’s complete name. It also includes an internal EPAM URL pointing to Ticketmaster’s Snowflake account, as well as a plaintext version of the username and password that the EPAM worker used to access the Ticketmaster Snowflake account.

“This means that \[an EPAM worker\] who had access to that Snowflake \[account\] had password-stealing malware on their computer, and their password was stolen and sold on the dark web,” says the researcher, who asked to be identified only as Reddington, an identity they use online to communicate with cybercriminals. “This means that anyone that knew the correct URL to \[Ticketmaster’s\] Snowflake could have simply looked up the password, logged in, and stolen the data.”

An EPAM spokesperson did not seem to be aware when contacted by WIRED early this week that its company allegedly played a role in breaches of Snowflake accounts. “We do not comment on situations to which we are not a part,” she wrote in an email, suggesting the company did not believe it played any role in the campaign. When WIRED provided the spokeswoman with details about how the hackers say they obtained access to the system of an EPAM worker in Ukraine, she replied, “Hackers frequently spread false information to advance their agendas. We maintain a policy of not engaging with misinformation and consistently uphold robust security measures to protect our operations and customers. We are continuing our exhaustive investigation and, at this time, see no evidence to suggest that we have been affected or involved in this matter.”

WIRED followed up by providing the name of the Ukrainian worker whose machine the hackers allegedly compromised, as well as the username and password the worker used for accessing Ticketmaster’s Snowflake account, but the spokesperson did not respond to any additional questions.

It’s possible the ShinyHunter hackers did not directly hack the EPAM worker, and simply gained access to the Snowflake accounts using usernames and passwords they obtained from old repositories of credentials stolen by info stealers. But, as Reddington points out, this means that anyone else can sift through those repositories for these and other credentials stolen from EPAM accounts. Reddington says they found data online that was used by nine different infostealers to harvest data from the machines of EPAM workers. This raises potential concerns about the security of data belonging to other EPAM customers.

EPAM has customers across various critical industries, including banks and other financial services, health care, broadcast networks, pharmaceutical, energy and other utilities, insurance, and software and hi-tech—the latter customers include Microsoft, Google, Adobe, and Amazon Web Services. It’s not clear, however, if any of these companies have Snowflake accounts to which EPAM workers have access. WIRED also wasn’t able to confirm whether Ticketmaster, Santander, Lending Tree, or Advance AutoParts are EPAM customers.

The Snowflake campaign also highlights the growing security risks from third-party companies in general and from infostealers. In its blog post this week, Mandiant suggested that multiple contractors were breached to gain access to Snowflake accounts, noting that contractors—often known as business process outsourcing (BPO) companies—are a potential gold mine for hackers, because compromising the machine of a contractor that has access to the accounts of multiple customers can give them direct access to many customer accounts.

“Contractors that customers engage to assist with their use of Snowflake may utilize personal and/or non-monitored laptops that exacerbate this initial entry vector,” wrote Mandiant in its blog post. “These devices, often used to access the systems of multiple organizations, present a significant risk. If compromised by infostealer malware, a single contractor's laptop can facilitate threat actor access across multiple organizations, often with IT and administrator-level privileges.”

The company also highlighted the growing risk from infostealers, noting that the majority of the credentials the hackers used in the Snowflake campaign came from repositories of data previously stolen by various infostealer campaigns, some of which dated as far back as 2020. “Mandiant identified hundreds of customer Snowflake credentials exposed via infostealers since 2020,” the company noted.

This, accompanied by the fact that the targeted Snowflake accounts didn’t use MFA to further protect them, made the breaches in this campaign possible, Mandiant notes.

Snowflake’s CISO, Brad Jones, acknowledged last week that the lack of multifactor authentication enabled the breaches. In a phone call this week, Jones told WIRED that Snowflake is working on giving its customers the ability to mandate that users of their accounts employ multifactor authentication going forward, “and then we’ll be looking in the future to \[make the\] default MFA,” he says.

_Update 6/17/2024, 5:45 pm EDT: The article was updated to clarify the details that Santander has publicly revealed about the hack._

Hackers Detail How They Allegedly Stole Ticketmaster Data From Snowflake

CCTV cameras and AI are being combined to monitor crowds, detect bike thefts, and spot trespassers.

Network Rail did not answer questions about the trials sent by WIRED, including questions about the current status of AI usage, emotion detection, and privacy concerns.

“We take the security of the rail network extremely seriously and use a range of advanced technologies across our stations to protect passengers, our colleagues, and the railway infrastructure from crime and other threats,” a Network Rail spokesperson says. “When we deploy technology, we work with the police and security services to ensure that we’re taking proportionate action, and we always comply with the relevant legislation regarding the use of surveillance technologies.”

It is unclear how widely the emotion detection analysis was deployed, with the documents at times saying the use case should be “viewed with more caution” and reports from stations saying it is “impossible to validate accuracy.” However, Gregory Butler, the CEO of data analytics and computer vision company Purple Transform, which has been working with Network Rail on the trials, says the capability was discontinued during the tests and that no images were stored when it was active.

The Network Rail documents about the AI trials describe multiple use cases involving the potential for the cameras to send automated alerts to staff when they detect certain behavior. None of the systems use controversial face recognition technology, which aims to match people’s identities to those stored in databases.

“A primary benefit is the swifter detection of trespass incidents,” says Butler, who adds that his firm’s analytics system, SiYtE, is in use at 18 sites, including train stations and alongside tracks. In the past month, Butler says, there have been five serious cases of trespassing that systems have detected at two sites, including a teenager collecting a ball from the tracks and a man “spending over five minutes picking up golf balls along a high-speed line.”

At Leeds train station, one of the busiest outside of London, there are 350 CCTV cameras connected to the ​​SiYtE platform, Butler says. “The analytics are being used to measure people flow and identify issues such as platform crowding and, of course, trespass—where the technology can filter out track workers through their PPE uniform,” he says. “AI helps human operators, who cannot monitor all cameras continuously, to assess and address safety risks and issues promptly.”

The Network Rail documents claim that cameras used at one station, Reading, allowed police to speed up investigations into bike thefts by being able to pinpoint bikes in the footage. “It was established that, whilst analytics could not confidently detect a theft, but they could detect a person with a bike,” the files say. They also add that new air quality sensors used in the trials could save staff time from manually conducting checks. One AI instance uses data from sensors to detect “sweating” floors, which have become slippery with condensation, and alert staff when they need to be cleaned.

While the documents detail some elements of the trials, privacy experts say they are concerned about the overall lack of transparency and debate about the use of AI in public spaces. In one document designed to assess data protection issues with the systems, Hurfurt from Big Brother Watch says there appears to be a “dismissive attitude” toward people who may have privacy concerns. One question asks: “Are some people likely to object or find it intrusive?” A staff member writes: “Typically, no, but there is no accounting for some people.”

At the same time, similar AI surveillance systems that use the technology to monitor crowds are increasingly being used around the world. During the Paris Olympic Games in France later this year, AI video surveillance will watch thousands of people and try to pick out crowd surges, use of weapons, and abandoned objects.

“Systems that do not identify people are better than those that do, but I do worry about a slippery slope,” says Carissa Véliz, an associate professor in psychology at the Institute for Ethics in AI, at the University of Oxford. Véliz points to similar AI trials on the London Underground that had initially blurred faces of people who might have been dodging fares, but then changed approach, unblurring photos and keeping images for longer than was initially planned.

“There is a very instinctive drive to expand surveillance,” Véliz says. “Human beings like seeing more, seeing further. But surveillance leads to control, and control to a loss of freedom that threatens liberal democracies.”

Tag

#amazon