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

The Good | DoJ Indicts Cryptojacking Criminal and Botnet Operator Supporting Ransomware Actors

The DoJ doled out two indictments this week: the first announcing the arrest of Charles O. Parks III for his role in an elaborate cryptojacking scheme, the second, charging Alexander Lefterov, owner and operator of a major botnet.

Parks was charged with wire fraud, money laundering, and illegal transactions, tallying up to a maximum of 30 years in prison. According to the DoJ, the basis of Parks’ scheme was renting $3.5 million worth of cloud servers through a number of fake LLCs in order to mine nearly $1 million in cryptocurrency.

After tricking the cloud service providers (CSPs) into escalating his privileges, Parks was given access to services equipped with powerful graphics cards that were then used to mine Monero, Litecoin, and Ether. The mined funds were laundered through purchasing NFTs and converting them through traditional banks and various crypto exchanges to fund a lavish lifestyle.

Lefterov was indicted by a federal grand jury for aggravated identity theft, computer fraud, and conspiracy to commit wire fraud. Through the large-scale botnet he maintained, the Moldovan national and his associates have been linked to thousands of compromised computers across the U.S.

Source: FBI

Using credentials harvested from the infected computers, Lefterov and his co-conspirators targeted victims’ financial accounts across banking, payment processing, and retail platforms to steal money. In tandem, Lefterov allegedly leased his botnet to other cybercriminals for ransomware distribution, later receiving a share of the profits from successful attacks.

Following both of these indictments, U.S. law enforcement reiterates their commitment to cyber defense, stating that the FBI and its partners will continue to investigate and pursue those involved in malicious activities both domestically and internationally.

The Bad | Researchers Link Russian-Based Sandworm APT to Attacks on Water Supply Systems

GRU-linked APT known as Sandworm has recently taken a behind-the-scenes approach, conducting covert attacks through various online personas and posing as hacktivist groups to mask their activities. In a new report, cybersecurity researchers identified Sandworm’s presence in at least three Telegram channels created to conduct disruptive operations and amplify pro-Russian narratives.

Sandworm has operated since 2009 under Unit 74455 of the Main Intelligence Directorate of the Russian Federation (GRU). Known to employ adaptive and diverse methods for initial access and exploit supply chain vulnerabilities, Sandworm is thought by researchers to be one of Russia’s foremost “cyber sabotage units” as well as a “formidable” threat globally.

Most recently, Sandworm has begun using online personas to execute disruptive operations and enhance the image of the GRU’s cyber capabilities. The report tracks the APT groups’ activity across three Telegram channels: XakNet Team, CyberArmyofRussia_Reborn, and Solntsepek. While most of the activity centers around targeting Ukrainian entities, one of the channels this week claimed attacks on critical water supply centers in the U.S. and Poland, and a hydroelectric facility in France. The posted videos showed fake images of attackers manipulating the controls of water suppliers in Texas.

While Sandworm’s focus has shifted towards espionage and influence operations, it continues to conduct disruptive attacks, targeting electoral systems, conducting intelligence gathering, stealing credentials, and retaliating against perceived adversaries. Cyber defenders continue to warn of potential interference in upcoming national elections and political events across the world, with Ukraine remaining a primary target amid ongoing conflict.

The Ugly | Suspected Nation-State Actors Exploit Zero-Day Flaw in Palo Alto Network Firewalls

Over the weekend, state-sponsored threat actors were suspected of exploiting a zero-day vulnerability in Palo Alto Networks’ PAN-OS firewall software. Though the vulnerability was quickly disclosed and patched by the Californian cybersecurity company, exploit code has since emerged this week and is already being used in attacks. Despite earlier mitigations provided during initial discovery, Palo Alto Networks is now urging users to upgrade their software immediately as the most reliable solution.

Tracked as CVE-2024-3400, the maximum severity flaw enables unauthenticated remote code execution (RCE) via command injection in low-complexity attacks that do not require user interaction. It affects PAN-OS 10.2, PAN-OS 11.0, and PAN-OS 11.1 firewalls configured with GlobalProtect, both gateway or portal. Palo Alto Networks’ advisory confirms that Cloud NGFW, Panorama appliances, and Prisma Access are not impacted by this vulnerability.

Researchers that initially detected the flaw found that the threat actor was focused on exporting configuration data from compromised devices before leveraging them to move laterally into victim organizations. Noting the level of tradecraft and speed of the attacks, the report suggests that the threat actor is highly capable with a clear playbook – indications of a state-backed attack. Along with warnings to secure vulnerable devices, CISA has added the vulnerability to its Known Exploited Vulnerabilities catalog.

Malware workflow (Source: Volexity)

Internet-connected network devices are often running on outdated, unpatched firmware which makes them vulnerable to exploitation. This, along with the key role they play in network infrastructure, means such devices are considered low-hanging fruit to attackers looking for a way in. To mitigate risks, companies should prioritize regular patches, enforce robust access controls, and practice network segmentation to safeguard their networks against intrusion.

Insuring Cyber Health | Chubb’s Insight via SentinelOne Telemetry

In an expanding collaboration between Chubb, one of the largest publicly traded property and casualty insurance companies, and SentinelOne, a cybersecurity leader, clients of SentinelOne who are also Chubb policyholders can now share their enterprise cyber health assessment data with Chubb. This facilitates a more efficient and precise underwriting process.

With the increasing emphasis on cybersecurity investment, insurance carriers are seeking greater transparency into their insureds’ cybersecurity health. The collaboration not only offers policyholders streamlined access to SentinelOne’s cybersecurity solutions, but also enhances transparency into policyholders’ cyber health investments through SentinelOne’s Vital Signs Report.

This post captures a Q&A between Craig Guiliano, SVP of Threat Intelligence and Policyholder Services at Chubb, and Bridget Mead, Senior Manager of IR Cyber Risk at SentinelOne, as they address some frequently asked questions about the Vital Signs Report.

Q: What is the Vital Signs Report?

Chubb/Guiliano: The Vital Signs Report (VSR) is an assessment of our policyholders’ cybersecurity posture. This report is going to be a game changer for not only how we, as the carrier, assess our individual policyholder’s cybersecurity health, but for our ability to assess our portfolio exposure as one of the world’s largest insurance companies. Our underwriters are quickly moving away from checkboxes on a questionnaire and moving towards data-driven policy renewal decisions.

SentinelOne/Mead: The VSR is based on a collection of internal signals that we mapped to the Center for Internet Security’s (CIS) Critical Security Controls (CIS Controls) CIS18 framework. We make the report available to all SentinelOne clients at no charge. It displays the strength of a client’s digital environment in areas important to cyber security and the cyber insurance underwriting process. The graphic below shows the major categories included.

Q: How do clients access this report?

SentinelOne/Mead: We’ve made it easy for Chubb policyholders to share this report with Chubb. It’s just a few clicks away. Clients can access the VSR report by going to the Singularity Marketplace page and selecting the Cyber Insurance menu item. From the Cyber Insurance menu, they can select Chubb and consent to the sharing via an End-User License Agreement (EULA). Chubb will be notified on their end that the report has been shared.

Chubb/Guiliano: Once we receive the VSR on our end, our policyholders will be able to view the report with their insurance brokers and Chubb underwriters. We’re expecting more transparent and robust conversations around loss control strategies with our policyholders that share this data with us. In addition, participating policyholders may enjoy incentivized policy pricing, subject to applicable insurance laws and regulations, and more efficient underwriting.

Q: What happens after the SentinelOne client clicks through the EULA?

SentinelOne/Mead: From a technical perspective, once the SentinelOne client does the EULA click through, the VSR examines the client’s SentinelOne console, collects the appropriate data signals, and populates the report.

Chubb/Guiliano: The VSR will be available to view by Chubb in near real-time, allowing efficient and timely feedback to policyholders, brokers, and underwriters. Chubb and SentinelOne have also worked to minimize  the sensitivity of the data being shared with Chubb. We omit any sensitive information, including IP addresses associated with identified vulnerabilities.

Q: How can the VSR help organizations with risk transfer?

Chubb/Guiliano: Traditionally, our underwriters use a series of questions and attack surface information to evaluate a policyholder’s risk. They might also pull historical data from claims that the policyholder has submitted. However, this kind of risk assessment doesn’t give us the full picture and could include false positives. The VSR provides a clearer and more accurate and efficient mechanism for our policyholder’s Security Teams to communicate information and controls to our underwriting teams.

The report will reduce the time and overhead that our policyholder’s spend. Additionally, it gives the policyholder a chance to think critically about their cybersecurity through access to Chubb’s expertise on risk of loss indicators, such as known vulnerabilities and common attack vectors – expertise that is based on 20+ years of actual loss data.

SentinelOne/Mead: The VSR helps organizations with their risk transfer by bringing visibility to their telemetry. SentinelOne has configured and crafted the VSR to identify vulnerabilities, configurations, and asset management controls with Chubb’s review to help policyholders proactively identify exposures. The information provided by the VSR will enable the policyholders to remedy elements that may need improvement, enhance their cybersecurity posture, and ultimately lower risk profiles. The VSR allows policyholders to discuss renewals more confidently with Chubb and brings more transparency to those conversations.

Q: What benefits may accrue from participating in the VSR Program?

SentinelOne/Mead: From a technical perspective, the VSR is an accurate and efficient way to assess a company’s cyber security posture. Current SentinelOne clients can look at the VSR and craft clear action items to enhance their use of our tools.

Chubb/Guiliano: Any benefit to our policyholder’s risk profile is a benefit to Chubb at-large and we’re eager to see our policyholders develop greater insight into their cyber risk profile and thus gain more informed negotiating power within the cyber insurance marketplace and possible premium savings.

Learn More

On May 2, 2024 at 1:00PM ET, join SentinelOne, Chubb, Aon, and CyberAcuView for a webinar discussion on data-driven underwriting. Panelists will discuss how data has transformed underwriting and insurability assessments as businesses work with their carriers and brokers to improve their risk profiles.

Data Sharing in Cyber Insurance
Having the right telemetry streamlines underwriting and renewals, leading to benefits for the policyholders.

Chubb Disclosure: Chubb is the marketing name used to refer to subsidiaries of Chubb Limited providing insurance and related services. For a list of these subsidiaries, please visit our website at Insurance provided by ACE American Insurance Company and its U.S. based Chubb underwriting company affiliates. All products may not be available in all states. This material contains product summaries only. Coverage is subject to the language of the policies as actually issued. Surplus lines insurance sold only through licensed surplus lines producers. The material presented herein is advisory in nature and is offered as a resource to be used together with your professional insurance advisors in maintaining a loss prevention program. It is not intended as a substitute for legal, insurance, or other professional advice, but rather is presented for general information only. You should consult knowledgeable legal counsel or other knowledgeable experts as to any legal or technical questions you may have. Chubb, 202 Hall’s Mill Road, Whitehouse Station, NJ 08889-1600

PinnacleOne ExecBrief | Navigating International Conflict and Escalation Dynamics

Last week, PinnacleOne detailed how firms can navigate the era of AI in cybersecurity and emerging tools to keep pace with advancing threats.

This week, we focus on recent escalation dynamics in the ongoing conflict in the Middle East.

Please subscribe to read future issues — and forward this newsletter to interested colleagues.

Contact us directly with any comments or questions:

Insight Focus | Navigating International Conflict and Escalation Dynamics

Summary of Recent Events

Conflict between Israel and Iran simmered for decades before the most recent spike in tensions. The proximate cause for Iran’s assault on Israel this weekend was the result of that country violating well-established norms. Israel bombed an Iranian diplomatic facility adjacent to the main embassy in Syria killing senior Iranian generals. Embassies and their compounds are considered the sovereign land of the country that they represent – in the U.S., law enforcement agencies (like local police) are prohibited from stepping foot within their walls.

Israel’s decision to strike (without prior notice to the U.S.) Iran’s diplomatic facilities in Syria to kill multiple important Iranian military officers crossed that established red line. In response, Iran crossed a line in its relationship with Israel not seen in the last four decades. Missiles and swarms of drones from Iraq, Yemen, Syria, and Iran attacked Israel over the weekend.

The Iranian attack echoes the combined drone, cruise missile, and ballistic missile barrages that Russia uses against Ukraine. The attack even used the same Iranian drones and missiles. An Israeli military spokesman reported that the weekend attack involved more than 170 drones, 30 cruise missiles, and at least 110 ballistic missiles.

However, U.S. officials reported that about half of these ballistic missiles were successfully intercepted (by combined U.S., Israeli, French, British, and even Jordanian systems), and most of the remaining failed to launch or crashed – only a handful reached their targets, causing mostly cosmetic damage to Israeli military bases. This failure may be attributed to a combination of joint air defense systems, which were prepositioned in theater given strong intelligence on the telegraphed Iranian attack.

Iran’s April 13 barrage was larger than any single similar Russian strike on Ukraine, but the tactic was similar. Source: The Institute for the Study of War and the Critical Threats Project

While a bit of a sideshow, the night of the attack an Iranian affiliated hacking group known as the “CyberAv3ngers” claimed to have disrupted power infrastructure in Tel Aviv. While this was quickly disputed and no evidence of such a disruption materialized, a number of high profile accounts on X amplified the claims, which served to inject uncertainty into the already unsettled information environment.

It should be noted that the U.S. and Israeli governments last year attributed to the IRGC-affiliated CyberAv3ngers persona compromises of Unitronics Vision Series programmable logic controls used in water and wastewater and other industries. While no critical infrastructure was compromised in this weekend’s attack, that shouldn’t induce false confidence that Iranian threat actors lack the intent or capability to do so in the future.

U.S. Urges Restraint

The U.S. is reportedly urging Israel to not respond in-kind and has stated that the US military would not support offensive operations against Iranian territory. Analysts point to the defensibility, and frankly – widely telegraphed response that Iran’s assault constituted – as reason to not escalate further. Iran’s attacks were aimed at Israeli government facilities, overnight and on a weekend, to minimize the potential for significant casualties. Multiple U.S. and British assets engaged incoming Iranian missiles and drones, alongside Israeli defensive equipment. On the whole, Iran’s actions could have been more damaging and more deadly. After concluding their attacks, Iran’s mission to the United Nations stated that the matter had been resolved.

Domestic Politics and Escalation Pathways

Unfortunately, domestic politics in Israel offer potential incentives for escalation. The current Prime Minister Benjamin Netanyahu is unpopular and, before the Hamas attacks that led to the current conflict, was facing mass protests, government resignations, and opposition by other political parties. Owing to ongoing legal issues and based on his past strategies to benefit politically from conflict with Hamas, the current PM may decide that escalating further with Iran is likely to extend his time in power. Opposition politicians are calling for early elections in the fall of this year as the governing coalition is falling apart.

Netanyahu has strong incentives to hold onto power as long as possible, however. He is the defendant in an ongoing, long-delayed, and widespread corruption case. The current conflict has slowed down the prosecution. Netanyahu hopes that he cannot be convicted or sentenced while he is still in office. Extending the war and escalating with Iran into protracted conflict may be in his political interest. However, as the Israeli War Cabinet meets to deliberate on a response, Netanyahu is now facing intense pressure by G7 leaders to refrain or tightly calibrate any reaction, warning publicly that it could provoke an “uncontrollable regional escalation” and likely privately threatening to withhold financial and political support.

Israeli sources told CNN that plans to conduct a ground offensive in Rafah this week are on hold pending a decision on Iran: “Among the military options that are being considered, the war cabinet is considering an attack on an Iranian facility that would send a message, but would avoid causing casualties, one Israeli official said.”

Security Posture Recommendations

There are two key scenarios enterprises need to consider: 1) de-escalation to status quo ante and 2) tit-for-tat escalation.

In the first scenario, executives should maintain a heightened state of alert, with a tight loop between risk professionals and organization leaders in the region. In particular, executives should know that staff in Israel are well-acquainted with the realities of war. Many participated in mandatory military service in their youth and some may have been recently deployed for operations in Gaza. As a result, local staff are best equipped to determine their own safety protocols.

  • During the coming weeks, the company should exercise work from home flexibility as requested by employees.
  • Non-Israeli citizens in the country should be afforded the opportunity to leave if they have not already been offered such accommodations.
  • The company should closely monitor Israel’s announcements and changes in diplomatic security posture.

In the second scenario, the prospects for a more intense and destructive regional conflict (e.g., involving direct and large-scale Hezbollah-IDF engagements) become a primary concern. To prepare for this, executives with staff and/or business interests in the region should:

  • Expect significant disruptions to their workforce (e.g., call-up, family support, loss of life) and in-country operations (e.g., cascading impacts from attacks on Israeli infrastructure).
  • Re-examine business continuity plans and crisis response playbooks.
  • Prepare for large commercial spillovers to regional trade and energy markets.

Our current assessment is that the former scenario is more likely than the latter, but prudent executives should ask their teams: What is the plan if the situation deteriorates?

S Ventures Invests in Guardz to Revolutionize Cybersecurity for SMBs

We are thrilled to announce our latest S Ventures investment in Guardz, a unified cybersecurity platform built to empower MSPs to secure and insure small to medium-sized businesses (SMBs).

A Modern Approach to Cybersecurity for SMBs

SMBs today face a unique set of challenges when it comes to protecting against the evolving cybersecurity threat landscape. With cloud and SaaS adoption, SMBs’ IT infrastructures are becoming increasingly complex to manage. This is coupled with limited budgets and staff, making it difficult for SMBs to acquire and deploy best-in-class cybersecurity solutions. With 88% of the SMB market turning to Managed Service Providers (MSPs) for cybersecurity protection, there is a critical need to build a scalable, easy-to-use cybersecurity platform that is specifically tailored to the needs of MSPs and their SMB customers.

In comes Guardz – addressing this gap head-on and developing a modern approach for SMB cybersecurity. The Guardz platform combines a robust cybersecurity technology and deep insurance expertise that ensures MSPs and their SMB customers can proactively safeguard their digital assets against a myriad of cyber threats, mitigate cybersecurity risks, and prevent the next cybersecurity attack.

“Guardz offers a modern approach to protect the underserved SMB market, developing a  unified cybersecurity solution that is built for MSPs from day one. This investment underscores SentinelOne’s unwavering commitment to pioneering cybersecurity solutions and amplifies our partner-first philosophy.”

Ken Marks, Vice President, Worldwide Channels & MSSP

The Guardz platform is uniquely designed specifically for MSPs protecting their SMB customers. Instead of offering traditional point solutions that are hard to manage and deploy, Guardz offers a unified SaaS-based multi-tenant platform that integrates, collects, analyzes, and provides insights on top of a variety of security tools, ranging from email, endpoint, identity, browser filtering, cloud security and awareness and training programs.

Purpose-Built, Proactive Cybersecurity Supporting SMB Customers

With 43% of cyber attacks targeting SMBs and 61% of SMBs failing to get adequate cybersecurity insurance, the demand for a new approach specifically tailored to the needs of SMBs is stronger than ever. As a result, there is an increasing number of MSPs turning to provide cybersecurity solutions for their SMB customers. Cybersecurity spending for SMBs is going to reach $109B in 2026, accounting for 60% of the total spending on cyber security worldwide.

Powered by AI, Guardz is equipped with automated detection and response capabilities that enable MSPs to take a proactive approach to securing SMBs’ digital assets across emails, devices, data, and cloud applications. It is a cost-effective solution, offering full-stack cybersecurity from a single pane of glass.

With a low-touch, self-serve model, MSPs can now easily onboard their end users and attract new customers by leveraging the Guardz’s efficient prospecting capabilities, accurate reporting, and complete coverage insurance.

Why We Invested in Guardz

From day one of its inception, SentinelOne recognized the importance of supporting SMBs and our partners in their quest for cybersecurity resilience. Our investment in Guardz reflects our dedication to always being partner-first. By aligning with Guardz, we’re not only investing in a company, we’re championing a safer digital ecosystem for SMBs worldwide. Guardz’s market approach resonates with our vision of democratizing access to cutting-edge cybersecurity technologies, ensuring businesses of all sizes can defend themselves with the same level of sophistication and efficacy as larger enterprises.

Led by an experienced team with a track record building and scaling businesses for SMBs and MSPs, Guardz is well poised to set a new standard for SMB cybersecurity and we at S Ventures are excited to back such an important mission. As we embark on this journey together, our focus remains steadfast on innovating, empowering, and protecting businesses worldwide. Together, we look forward to a future where every SMB can operate with confidence.

S Ventures
Investing in the next generation of category-defining security and data companies.

Crickets from Chirp Systems in Smart Lock Key Leak

The U.S. government is warning that “smart locks” securing entry to an estimated 50,000 dwellings nationwide contain hard-coded credentials that can be used to remotely open any of the locks. The lock’s maker Chirp Systems remains unresponsive, even though it was first notified about the critical weakness in March 2021. Meanwhile, Chirp’s parent company, RealPage, Inc., is being sued by multiple U.S. states for allegedly colluding with landlords to illegally raise rents.

On March 7, 2024, the U.S. Cybersecurity & Infrastructure Security Agency (CISA) warned about a remotely exploitable vulnerability with “low attack complexity” in Chirp Systems smart locks.

“Chirp Access improperly stores credentials within its source code, potentially exposing sensitive information to unauthorized access,” CISA’s alert warned, assigning the bug a CVSS (badness) rating of 9.1 (out of a possible 10). “Chirp Systems has not responded to requests to work with CISA to mitigate this vulnerability.”

Matt Brown, the researcher CISA credits with reporting the flaw, is a senior systems development engineer at Amazon Web Services. Brown said he discovered the weakness and reported it to Chirp in March 2021, after the company that manages his apartment building started using Chirp smart locks and told everyone to install Chirp’s app to get in and out of their apartments.

“I use Android, which has a pretty simple workflow for downloading and decompiling the APK apps,” Brown told KrebsOnSecurity. “Given that I am pretty picky about what I trust on my devices, I downloaded Chirp and after decompiling, found that they were storing passwords and private key strings in a file.”

Using those hard-coded credentials, Brown found an attacker could then connect to an application programming interface (API) that Chirp uses which is managed by smart lock vendor, and use that to enumerate and remotely lock or unlock any door in any building that uses the technology.

Brown said when he complained to his leasing office, they sold him a small $50 key fob that uses Near-Field Communications (NFC) to toggle the lock when he brings the fob close to his front door. But he said the fob doesn’t eliminate the ability for anyone to remotely unlock his front door using the exposed credentials and the Chirp mobile app.

A smart lock enabled with Chirp. Image:

Also, the fobs pass the credentials to his front door over the air in plain text, meaning someone could clone the fob just by bumping against him with a smartphone app made to read and write NFC tags.

Neither August nor Chirp Systems responded to requests for comment. It’s unclear exactly how many apartments and other residences are using the vulnerable Chirp locks, but multiple articles about the company from 2020 state that approximately 50,000 units use Chirp smart locks with August’s API.

Roughly a year before Brown reported the flaw to Chirp Systems, the company was bought by RealPage, a firm founded in 1998 as a developer of multifamily property management and data analytics software. In 2021, RealPage was acquired by the private equity giant Thoma Bravo.

Brown said the exposure he found in Chirp’s products is “an obvious flaw that is super easy to fix.”

“It’s just a matter of them being motivated to do it,” he said. “But they’re part of a private equity company now, so they’re not answerable to anybody. It’s too bad, because it’s not like residents of [the affected] properties have another choice. It’s either agree to use the app or move.”

In October 2022, an investigation by ProPublica examined RealPage’s dominance in the rent-setting software market, and that it found “uses a mysterious algorithm to help landlords push the highest possible rents on tenants.”

“For tenants, the system upends the practice of negotiating with apartment building staff,” ProPublica found. “RealPage discourages bargaining with renters and has even recommended that landlords in some cases accept a lower occupancy rate in order to raise rents and make more money. One of the algorithm’s developers told ProPublica that leasing agents had ‘too much empathy’ compared to computer generated pricing.”

Last year, the U.S. Department of Justice threw its weight behind a massive lawsuit filed by dozens of tenants who are accusing the $9 billion apartment software company of helping landlords collude to inflate rents.

In February 2024, attorneys general for Arizona and the District of Columbia sued RealPage, alleging RealPage’s software helped create a rental monopoly.

Who Stole 3.6M Tax Records from South Carolina?

For nearly a dozen years, residents of South Carolina have been kept in the dark by state and federal investigators over who was responsible for hacking into the state’s revenue department in 2012 and stealing tax and bank account information for 3.6 million people. The answer may no longer be a mystery: KrebsOnSecurity found compelling clues suggesting the intrusion was carried out by the same Russian hacking crew that stole of millions of payment card records from big box retailers like Home Depot and Target in the years that followed.

Questions about who stole tax and financial data on roughly three quarters of all South Carolina residents came to the fore last week at the confirmation hearing of Mark Keel, who was appointed in 2011 by Gov. Nikki Haley to head the state’s law enforcement division. If approved, this would be Keel’s third six-year term in that role.

The Associated Press reports that Keel was careful not to release many details about the breach at his hearing, telling lawmakers he knows who did it but that he wasn’t ready to name anyone.

“I think the fact that we didn’t come up with a whole lot of people’s information that got breached is a testament to the work that people have done on this case,” Keel asserted.

A ten-year retrospective published in 2022 by The Post and Courier in Columbia, S.C. said investigators determined the breach began on Aug. 13, 2012, after a state IT contractor clicked a malicious link in an email. State officials said they found out about the hack from federal law enforcement on October 10, 2012.

KrebsOnSecurity examined posts across dozens of cybercrime forums around that time, and found only one instance of someone selling large volumes of tax data in the year surrounding the breach date.

On Oct. 7, 2012 — three days before South Carolina officials say they first learned of the intrusion — a notorious cybercriminal who goes by the handle “Rescator” advertised the sale of “a database of the tax department of one of the states.”

“Bank account information, SSN and all other information,” Rescator’s sales thread on the Russian-language crime forum Embargo read. “If you purchase the entire database, I will give you access to it.”

A week later, Rescator posted a similar offer on the exclusive Russian forum Mazafaka, saying he was selling information from a U.S. state tax database, without naming the state. Rescator said the data exposed included Social Security Number (SSN), employer, name, address, phone, taxable income, tax refund amount, and bank account number.

“There is a lot of information, I am ready to sell the entire database, with access to the database, and in parts,” Rescator told Mazafaka members. “There is also information on corporate taxpayers.”

On Oct. 26, 2012, the state announced the breach publicly. State officials said they were working with investigators from the U.S. Secret Service and digital forensics experts from Mandiant, which produced an incident report (PDF) that was later published by South Carolina Dept. of Revenue. KrebsOnSecurity sought comment from the Secret Service, South Carolina prosecutors, and Mr. Keel’s office. This story will be updated if any of them respond.

On Nov. 18, 2012, Rescator told fellow denizens of the forum Verified he was selling a database of 65,000 records with bank account information from several smaller, regional financial institutions. Rescator’s sales thread on Verified listed more than a dozen database fields, including account number, name, address, phone, tax ID, date of birth, employer and occupation.

Asked to provide more context about the database for sale, Rescator told forum members the database included financial records related to tax filings of a U.S. state. Rescator added that there was a second database of around 80,000 corporations that included social security numbers, names and addresses, but no financial information.

The AP says South Carolina paid $12 million to Experian for identity theft protection and credit monitoring for its residents after the breach.

“At the time, it was one of the largest breaches in U.S. history but has since been surpassed greatly by hacks to Equifax, Yahoo, Home Depot, Target and PlayStation,” the AP’s Jeffrey Collins wrote.

As it happens, Rescator’s criminal hacking crew was directly responsible for the 2013 breach at Target and the 2014 hack of Home Depot. The Target intrusion saw Rescator’s cybercrime shops selling roughly 40 million stolen payment cards, and 56 million cards from Home Depot customers.

Who is Rescator? On Dec. 14, 2023, KrebsOnSecurity published the results of a 10-year investigation into the identity of Rescator, a.k.a. Mikhail Borisovich Shefel, a 36-year-old who lives in Moscow and who recently changed his last name to Lenin.

Mr. Keel’s assertion that somehow the efforts of South Carolina officials following the breach may have lessened its impact on citizens seems unlikely. The stolen tax and financial data appears to have been sold openly on cybercrime forums by one of the Russian underground’s most aggressive and successful hacking crews.

While there are no indications from reviewing forum posts that Rescator ever sold the data, his sales threads came at a time when the incidence of tax refund fraud was skyrocketing.

Tax-related identity theft occurs when someone uses a stolen identity and SSN to file a tax return in that person’s name claiming a fraudulent refund. Victims usually first learn of the crime after having their returns rejected because scammers beat them to it. Even those who are not required to file a return can be victims of refund fraud, as can those who are not actually owed a refund from the U.S. Internal Revenue Service (IRS).

According to a 2013 report from the Treasury Inspector General’s office, the IRS issued nearly $4 billion in bogus tax refunds in 2012, and more than $5.8 billion in 2013. The money largely was sent to people who stole SSNs and other information on U.S. citizens, and then filed fraudulent tax returns on those individuals claiming a large refund but at a different address.

It remains unclear why Shefel has never been officially implicated in the breaches at Target, Home Depot, or in South Carolina. It may be that Shefel has been indicted, and that those indictments remain sealed for some reason. Perhaps prosecutors were hoping Shefel would decide to leave Russia, at which point it would be easier to apprehend him if he believed no one was looking for him.

But all signs are that Shefel is deeply rooted in Russia, and has no plans to leave. In January 2024, authorities in Australia, the United States and the U.K. levied financial sanctions against 33-year-old Russian man Aleksandr Ermakov for allegedly stealing data on 10 million customers of the Australian health insurance giant Medibank.

A week after those sanctions were put in place, KrebsOnSecurity published a deep dive on Ermakov, which found that he co-ran a Moscow-based IT security consulting business along with Mikhail Shefel called Shtazi-IT.

A Google-translated version of Shtazi dot ru. Image:

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

The Good | Police Unmask 200 LockBit Affiliates

Following the takedown of their operations earlier in the year, the inner workings of LockBit’s affiliate infrastructure have become clearer this week as investigations continue. The UK’s National Crime Agency, with assistance from the FBI, have reportedly matched a list of pseudonyms used by the ransomware gang to suspected cybercriminals.

So far, investigators have been able to link some 200 affiliates of LockBit who were using nondescript usernames to real world identities. The NCA’s senior officer on the case further confirmed that authorities have been able to connect specific affiliates back to particular cyberattacks. As the investigations carry on, all details collected are helping law enforcement to pursue more of the gang’s influential members, as well as any associated money launderers and malware developers.

Over the past three years, LockBit’s Ransomware-as-a-Service (RaaS) operations have left a long line of victims in its wake, with their ransom demands totalling at least $120 million.

Despite a dramatic takedown in February and having a senior administrator sentenced in March, LockBit lingers on through a new blog and data leak site, though lacking its prior momentum. Still, the gang’s ringleaders remain at large and cyber defenders continue to monitor for signs of rebranding – a strategy used by Hive and predecessors of BlackCat/ALPHV. Law enforcement’s efforts in matching up outstanding LockBit usernames to known criminals is a major step in disrupting LockBit’s new and future operations.

The Bad | New Phishing Campaign Drops Multi-Stage Malware via SVG Files

Security researchers this week reported on a complex cyberattack leveraging phishing emails to spread a wide range of malware, including Venom RAT, Remcos RAT, XWorm, NanoCore RAT, and a crypto wallet stealer.

In this wave of phishing attacks, the threat actor emails fake invoices in the form of Scalable Vector Graphics (SVG) files, which trigger the infection process after the victim engages. Researchers pegged this technique to the use of BatCloak malware obfuscation engines and a crypter called ScrubCrypt to deliver obfuscated batch scripts carrying the malware.

According to the report, the SVG file drops a ZIP archive containing a batch script, likely crafted using BatCloak, which unpacks the ScrubCrypt batch file to deploy Venom RAT. The remote access trojan then establishes control over compromised systems, executing commands from a command-and-control (C2) server.

The threat actors has been observed using various methods to distribute additional plugins, including NanoCore RAT, XWorm, and Remcos RAT, with Remcos RAT distributed through obfuscated VBS scripts, ScrubCrypt, and GuLoader PowerShell. Finally, a stealer component targets crypto wallets and applications like Atomic Wallet and Telegram to send stolen data to a remote server.

Accounting for the multiple layers of obfuscation and plugin deployment via different payloads, the campaign demonstrates threat actors’ efforts to stay versatile in their approach in order to persist and evade detection<. Pairing consistent monitoring capabilities with cyber hygiene surrounding email security continues to be an effective approach to minimizing threats from increasingly intricate phishing campaigns.

The Ugly | Bug in Rust Could Allow Command Injection Attacks

Codenamed BatBadBut, a new and critical vulnerability (CVE-2024-24576) could allow threat actors to target Windows systems and execute command injection attacks. The flaw, rated 10/10 CVSS, arises from weaknesses in OS command and argument handling in a number of programming languages, including Rust.

BatBadBut permits remote exploitation by unauthenticated attackers without user interaction. The bug only impacts Windows and only when programs or their dependencies execute batch files with untrusted arguments. In their security advisory, the Rust Security Response Working Group attributed the flaw to improper argument escaping when invoking batch files on Windows using the Command API.

The flaw affects all Rust versions prior to 1.77.2. Addressing the complexity of parsing rules in cmd.exe, Rust’s security team have since enhanced the escaping code and Command API to mitigate the risk. They have also introduced an InvalidInput error if the Command API fails to safely escape arguments during process spawning.

Maintainers of other languages have either updated their documentation or provided a patch, with the exception of Java, which currently has a status of ‘Won’t fix’.

Project Status
Erlang Documentation update
Go Documentation update
Haskell Patch available
Java Won’t fix
Node.js Patch available
PHP Patch available
Python Documentation update
Ruby Documentation update
Rust Patch available

The emergence of CVE-2024-24576 draws attention back to a February statement made by the National Cyber Director who called for widespread adoption of memory-safe programming languages (like Rust) to bolster their software security. A report released by the White House also promoted tech manufacturers to be proactive about reducing risk by adopting memory-safe programming languages in their operations.

Why CISA is Warning CISOs About a Breach at Sisense

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) said today it is investigating a breach at business intelligence company Sisense, whose products are designed to allow companies to view the status of multiple third-party online services in a single dashboard. CISA urged all Sisense customers to reset any credentials and secrets that may have been shared with the company, which is the same advice Sisense gave to its customers Wednesday evening.

New York City based Sisense has more than a thousand customers across a range of industry verticals, including financial services, telecommunications, healthcare and higher education. On April 10, Sisense Chief Information Security Officer Sangram Dash told customers the company had been made aware of reports that “certain Sisense company information may have been made available on what we have been advised is a restricted access server (not generally available on the internet.)”

“We are taking this matter seriously and promptly commenced an investigation,” Dash continued. “We engaged industry-leading experts to assist us with the investigation. This matter has not resulted in an interruption to our business operations. Out of an abundance of caution, and while we continue to investigate, we urge you to promptly rotate any credentials that you use within your Sisense application.”

In its alert, CISA said it was working with private industry partners to respond to a recent compromise discovered by independent security researchers involving Sisense.

“CISA is taking an active role in collaborating with private industry partners to respond to this incident, especially as it relates to impacted critical infrastructure sector organizations,” the sparse alert reads. “We will provide updates as more information becomes available.”

Sisense declined to comment when asked about the veracity of information shared by two trusted sources with close knowledge of the breach investigation. Those sources said the breach appears to have started when the attackers somehow gained access to the company’s Gitlab code repository, and in that repository was a token or credential that gave the bad guys access to Sisense’s Amazon S3 buckets in the cloud.

Customers can use Gitlab either as a solution that is hosted in the cloud at, or as a self-managed deployment. KrebsOnSecurity understands that Sisense was using the self-managed version of Gitlab.

Both sources said the attackers used the S3 access to copy and exfiltrate several terabytes worth of Sisense customer data, which apparently included millions of access tokens, email account passwords, and even SSL certificates.

The incident raises questions about whether Sisense was doing enough to protect sensitive data entrusted to it by customers, such as whether the massive volume of stolen customer data was ever encrypted while at rest in these Amazon cloud servers.

It is clear, however, that unknown attackers now have all of the credentials that Sisense customers used in their dashboards.

The breach also makes clear that Sisense is somewhat limited in the clean-up actions that it can take on behalf of customers, because access tokens are essentially text files on your computer that allow you to stay logged in for extended periods of time — sometimes indefinitely. And depending on which service we’re talking about, it may be possible for attackers to re-use those access tokens to authenticate as the victim without ever having to present valid credentials.

Beyond that, it is largely up to Sisense customers to decide if and when they change passwords to the various third-party services that they’ve previously entrusted to Sisense.

Earlier today, a public relations firm working with Sisense reached out to learn if KrebsOnSecurity planned to publish any further updates on their breach (KrebsOnSecurity posted a screenshot of the CISO’s customer email to both LinkedIn and Mastodon on Wednesday evening). The PR rep said Sisense wanted to make sure they had an opportunity to comment before the story ran.

But when confronted with the details shared by my sources, Sisense apparently changed its mind.

“After consulting with Sisense, they have told me that they don’t wish to respond,” the PR rep said in an emailed reply.

Update, 6:49 p.m., ET: Added clarification that Sisense is using a self-hosted version of Gitlab, not the cloud version managed by

Also, Sisense’s CISO Dash just sent an update to customers directly. The latest advice from the company is far more detailed, and involves resetting a potentially large number of access tokens across multiple technologies, including Microsoft Active Directory credentials, GIT credentials, web access tokens, and any single sign-on (SSO) secrets or tokens.

The full message from Dash to customers is below:

“Good Afternoon,

We are following up on our prior communication of April 10, 2024, regarding reports that certain Sisense company information may have been made available on a restricted access server. As noted, we are taking this matter seriously and our investigation remains ongoing.

Our customers must reset any keys, tokens, or other credentials in their environment used within the Sisense application.

Specifically, you should:
– Change Your Password: Change all Sisense-related passwords on
– Non-SSO:
– Replace the Secret in the Base Configuration Security section with your GUID/UUID.
– Reset passwords for all users in the Sisense application.
– Logout all users by running GET /api/v1/authentication/logout_all under Admin user.
– Single Sign-On (SSO):
– If you use SSO JWT for the user’s authentication in Sisense, you will need to update sso.shared_secret in Sisense and then use the newly generated value on the side of the SSO handler.
– We strongly recommend rotating the x.509 certificate for your SSO SAML identity provider.
– If you utilize OpenID, it’s imperative to rotate the client secret as well.
– Following these adjustments, update the SSO settings in Sisense with the revised values.
– Logout all users by running GET /api/v1/authentication/logout_all under Admin user.
– Customer Database Credentials: Reset credentials in your database that were used in the Sisense application to ensure continuity of connection between the systems.
– Data Models: Change all usernames and passwords in the database connection string in the data models.
– User Params: If you are using the User Params feature, reset them.
– Active Directory/LDAP: Change the username and user password of users whose authorization is used for AD synchronization.
– HTTP Authentication for GIT: Rotate the credentials in every GIT project.
– B2D Customers: Use the following API PATCH api/v2/b2d-connection in the admin section to update the B2D connection.
– Infusion Apps: Rotate the associated keys.
– Web Access Token: Rotate all tokens.
– Custom Email Server: Rotate associated credentials.
– Custom Code: Reset any secrets that appear in custom code Notebooks.

If you need any assistance, please submit a customer support ticket at and mark it as critical. We have a dedicated response team on standby to assist with your requests.

At Sisense, we give paramount importance to security and are committed to our customers’ success. Thank you for your partnership and commitment to our mutual security.


Sangram Dash
Chief Information Security Officer”

XZ Utils Backdoor | Threat Actor Planned to Inject Further Vulnerabilities

On Mar 29, 2024 details emerged about CVE-2024-3094, a vulnerability impacting the xz compression libraries used by Linux distributions.

The backdoor code was distributed to all rolling distributions. However, it was tailored to target distributions such as Debian and Fedora, which patch their SSH daemon with liblzma. Further, the backdoor scripts included system checks to guarantee that the object files were solely injected into Debian and Fedora distributions.

SentinelOne analyzed the technical implementation of the xz backdoor and the differences between the two versions. In this blog post, we describe and explore how subtle changes made by the threat actor in the code commits suggest that further backdoors were being planned.

XZ Compromise | A Technical Breakdown

In the first iteration of the compromise (version 5.6.0), the actor successfully added code to the xz repository that enabled injection of the backdoor on Debian and Fedora distributions. However, the second iteration (version 5.6.1) adds significantly more maturity by introducing the ability to execute additional shell scripts during the build phase via binary test blobs, presumably to make future updates to the backdoor less suspicious.

The injection of malicious shell scripts occurs during the execution of the configure command, which then inserts code inside the Makefile to build and replace object files with backdoor-infected counterparts.

Although the backdoor and its functionality remain the same across both versions, the setup to inject and replace object files differs. These discrepancies offer insights into the motivation and long-term plan of the threat actor.

Initial Setup

The first piece of the backdoor is the m4/build-to-host.m4 file. This file orchestrates minor modifications and conceals the extraction and execution of the Stage 1 backdoor file, bad-3-corrupt_lzma2.xz.

Note how the grep command matches one file in the source directory:

Only one file matches given bytes for both versions
Only one file matches given bytes for both versions

The actor introduced several new files that contributed to setting up Stage 2 of the backdoor in a later commit with the description, “Tests: Add a few test files”.

The next step extracts and stores the script from the bad-3-corrupt_lzma2.xz file within the variable gl_[$1]_config.

Here, the extracted script is executed, marking the progression towards the Stage 1 payload of the attack cycle.

Stage 1 Payload | System Checks & Extraction

The Stage 1 payload can be extracted from the bad-3-corrupt_lzma2.xz file via the following command:

cat bad-3-corrupt_lzma2.xz | tr "t -_" " t_-" | xz -d

This payload is responsible for extracting the Stage 2 payload from good-large_compressed.lzma and executing the setup script. There are several variables defined in this step that will be utilized in the later stages.

Another notable feature of this stage is the repeated use of the head command to discard 1024 bytes (1 KB) but use other 2048 bytes (2 KB) in a cyclic manner. This layer of obfuscation extracts another payload and removes junk data used to hide the payload, as shown in the following code from version 5.6.0:

This stage in version 5.6.1 has several differences from the previous version. One notable distinction is the inclusion of an operating system check to ensure that the backdoor is injected only when built on a Linux machine, which repeats five times.

Additionally, minor variations include changing the final byte count in the head command from 724 to 939, and adjusting the argument for the tr utility to account for this modified offset.

Diff of data extraction step in version 5.6.0 (left) and 5.6.1 (right)
Diff of data extraction step in version 5.6.0 (left) and 5.6.1 (right)

Following extraction, this payload is executed by piping it to bash, which advances the attack chain to Stage 2.

Stage 2 Payload | Injecting The Backdoor

The Second Stage Payload is responsible for the extraction, injection and cleaning of the backdoor files on Debian and Fedora builds. The script is broken in two execution phases:

  • Phase 1: executed during the configure command; injects code into the makefile
  • Phase 2: executed during the make command; injects the backdoor in object files

The script injects code in the makefile to execute the malicious code by running the make command. The script is aware of the phase it is executing in by checking the presence of config.status file and .libs/liblzma_la-crc64_fast.o.

This stage differs between versions. We believe the newer version seeks to make the backdoor modular so that other payloads could be injected down the line without adding new code to the build files. 048b064241f06b0975c2e20132379b5478af0247 cc23255b7c051d9c35d769d4e91d168e3f410c01

The script defines several environment variables that should be considered indicators of compromise when present on a system:

  • is_arch_extension_supported : a check that is replaced by _get_cpuid from a malicious object file
  • __get_cpuid: function that is replaced by malicious function exported in the backdoor object file
  • Good-large_compressed.lzma and bad-3-corrupt_lzma2.xz: Files that contain setup scripts for the backdoor

This step enables several checks which are performed before the backdoor is injected during the build process:

  • Checks that the GCC compiler is installed
  • Checks that the operating system is Linux and that the distribution is Debian or Fedora
  • Checks for the presence of a file named config.status

During this stage, the difference between versions 5.6.0 and 5.6.1 becomes significant. In 5.6.1, the threat actor introduced a code snippet aimed at enhancing the modularity of the backdoor. This modification enables the potential injection of different variants via test files in subsequent stages.

If any test file exists within the directory srcdir/tests/files/ and contains the magic bytes ~!:_ W and |_!{ -, the file will be unpacked and subsequently processed to execute the embedded scripts.

Diff showing new code added to version 5.6.1 (right)
Diff showing new code added to version 5.6.1 (right)

This enables the threat actor to deploy multiple backdoors in upstream packages through binary test files without arousing suspicion in the commit tree. These test binary blobs typically serve the purpose of stress-testing compression algorithms, pushing them to their limits by providing unconventional binary data for decompression.

This backdoor feature addresses a significant challenge faced by the threat actor during the development of the backdoor in version 5.6.0. The commit history shows the actor fabricated a pretext to commit new test files in order to update the backdoor.

Git commit history
Git commit history

Such functionality isn’t limited to a single instance. Another similar code snippet can be observed in the elif branch of the script executed during phase 2: make command execution. In this case, a check for magic bytes jV!.^% and %.R.1Z is performed, but the core extraction and execution of the script remain unchanged.

The remaining part of Stage 2 is consistent across both versions. The backdoored object file is extracted from the file good-large_compressed via an intricate awk command.

This segment is an implementation of a modified RC4 algorithm, which decrypts the payload after processing the compressed data, and writes it to liblzma_la-crc64-fast.o. The process remains identical in both versions, differing only in the bytes that are written.

The backdoor leverages ifunc resolvers, a feature of glibc and a recent addition to the xz project. These resolvers enable developers to have multiple implementations of a function and dynamically select which one to use at runtime through a resolver function. In this context, the backdoor replaces existing functions, i.e crc32_resolve() and crc64_resolve(), to execute different code discreetly. This mechanism provides an ideal means to execute the backdoor’s code without raising suspicion.

The script then proceeds to modify the source code of crc64_fast.c and compile it dynamically to incorporate ifunc resolvers, linking the backdoored liblzma_la-crc64_fast.o. Once the backdoor is successfully linked and set up, the script initiates cleanup to remove the artifacts used to build the backdoor.

Analysis of Attack Execution

The overall compromise spanned over two years. Under the alias Jia Tan, the actor began contributing to the xz project on October 29, 2021. Initially, the commits were innocuous and minor. However, the actor gradually became a more active contributor to the project, steadily gaining reputation and trust within the community.

  • Pressure emails
    While Jia Tan made active contributions to the project, the project maintainer Lasse Collin started receiving emails from different people that pressured Lasse to transfer maintainership of the project to Jia. It’s possible that these emails were orchestrated as part of the operation, purportedly originating from non-existent individuals.
  • Addition Of Modularity in 5.6.1 release
    As outlined above, features that allow the build scripts to directly execute code from test binary files were added in the 5.6.1 release to the backdoor. This change indicates the actor planned to infect the xz repository with other vulnerabilities as well. This statement is also supported by the later commit made to break the LandLock functionality in xz util (not liblzma).
  • Git Commit Forgery (disabling LandLock)
    The commit made February 28 2024 breaks the C program that is used to check support for LandLock. Landlock is a Linux kernel process sandboxing feature that restricts the rights of a set of processes, which would give the attacker more latitude to infect an impacted system. These commits are made under author Lasse Collin. It is possible commits were forged for these changes.


The attribution of the operation and the intended targeting are currently unknown. Based on the sophistication and long timeframe required to execute this attack, we believe the actor is likely a state-aligned entity. It is plausible that this operation was outsourced by someone without necessarily revealing the true target of interest.


The operation that led to the xz backdoor demonstrates the risk of supply chain attacks in Open Source Software (OSS) projects. Open Source is often deemed safe from such attacks, given its scrutiny by a multitude of contributors, making it improbable to implant malicious code without detection.

The operation exploited gaps in the reputation process and the absence of audits on released tarballs. Moreover, commits to the LandLock functionality, along with code changes between versions, underscored the actor’s intention to introduce additional backdoors and sustain access to the repository.

SentinelOne is closely monitoring this supply-chain attack. SentinelOne Singularity detects malicious behaviors attempted by an adversary via this backdoor.

Indicators of Compromise

5.6.0_stage_1_backdoor_blob.bin 96e42f5baf3f1bad129de247e9e0b30e6bcbd8fe
5.6.0_stage_1_backdoor_extracted.bin 1e14bb58eaa1c1ac3227fd999fe9c3aa80ab25d3
5.6.0_stage_2_backdoor_blob.bin bbeaeac4a1d3849098c2ebbaea526d2404171295 048b064241f06b0975c2e20132379b5478af0247
5.6.1_stage_1_backdoor_blob.bin 01e966ce1de7f847d2e44c52fea1eb58c081ea0d 894b62c59533996a4376743782e78426a52f8cbc
5.6.1_stage_2_backdoor_blob.bin dcc80761f84592b2c85ab71df2bc10b835121861 cc23255b7c051d9c35d769d4e91d168e3f410c01 72e8163734d586b6360b24167a3aff2a3c961efb 8a75968834fc11ba774d7bbdc566d272ff45476c 123e570ac3d28a9f7ce6c30fdb19e20a8c23efae
liblzma_la-crc64-fast.o 0ebf4b63737cdf3e084941c7d02f8eec5ca8d257
liblzma_la-crc64-fast.o cc5c1d8f9924a3939f932a50f666dba03531e6a9
liblzma_la_crc64_fast.o fb8b18fa39f198298c9f553496a18aa94fa75c03
SentinelOne Singularity XDR
See how SentinelOne XDR provides end-to-end enterprise visibility, powerful analytics, and automated response across your complete technology stack.

Twitter’s Clumsy Pivot to Is a Gift to Phishers

On April 9, Twitter/X began automatically modifying links that mention “” to read “” instead. But over the past 48 hours, dozens of new domain names have been registered that demonstrate how this change could be used to craft convincing phishing links — such as fedetwitter[.]com, which until very recently rendered as in tweets.

The message displayed when one visits, which Twitter/X displayed as in tweets and messages.

A search at shows at least 60 domain names have been registered over the past two days for domains ending in “,” although research so far shows the majority of these domains have been registered “defensively” by private individuals to prevent the domains from being purchased by scammers.

Those include, which Twitter/X truncated to when the domain appeared in user messages or tweets. Visiting this domain currently displays a message that begins, “Are you serious, X Corp?”

Update: It appears Twitter/X has corrected its mistake, and no longer truncates any domain ending in “” to “”

Original story:

The same message is on other newly registered domains, including (, (, (, ( and ( The message left on these domains indicates they were defensively registered by a user on Mastodon whose bio says they are a systems admin/engineer. That profile has not responded to requests for comment.

A number of these new domains including “” appear to be registered defensively by Twitter/X users in Japan. The domain (, to Twitter/X users) now displays a message saying it was “acquired to prevent its use for malicious purposes,” along with a Twitter/X username.

The domain mentioned at the beginning of this story — — redirects users to the blog of a Japanese technology enthusiast. A user with the handle “amplest0e” appears to have registered, which Twitter/X users would see as the CEO’s “” The domain “” already redirects to the real

Some of the domains registered recently and ending in “” currently do not resolve and contain no useful contact information in their registration records. Those include firefotwitter[.]com (, ngintwitter[.]com (, and webetwitter[.]com (

The domain, which Twitter/X until very recently rendered as “,” redirects to this blog post warning about the recent changes and their potential use for phishing.

Sean McNee, vice president of research and data at DomainTools, told KrebsOnSecurity it appears Twitter/X did not properly limit its redirection efforts.

“Bad actors could register domains as a way to divert traffic from legitimate sites or brands given the opportunity — many such brands in the top million domains end in x, such as webex, hbomax, xerox, xbox, and more,” McNee said. “It is also notable that several other globally popular brands, such as Rolex and Linux, were also on the list of registered domains.”

The apparent oversight by Twitter/X was cause for amusement and amazement from many former users who have migrated to other social media platforms since the new CEO took over. Matthew Garrett, a lecturer at U.C. Berkeley’s School of Information, summed up the Schadenfreude thusly:

“Twitter just doing a ‘redirect links in tweets that go to to instead but accidentally do so for all domains that end like eg going to’ is not absolutely the funniest thing I could imagine but it’s high up there.”