The CISA and FBI, along with cybersecurity agencies from Australia, Canada, New Zealand and the U.K., have released new guidance on outage communications for service providers dealing with major IT and OT outages. The guide calls for prompt, factual and audience-specific communication during disruptions caused by malicious cyber activity or non-malicious events.
Titled “Communicating Under Pressure: Best Practices for Service Providers,” the guidance says effective communication is critical to limiting operational impact when IT and OT outages affect customers, network defenders, critical infrastructure owners and operators, and the public. It recommends that organizations clearly communicate what is known, what remains unknown and what is still under investigation, while providing frequent updates as circumstances change.
Outage Communications Should Start With Facts
The agencies recommend that service providers establish an outage communications plan before an incident occurs. The plan should define incident thresholds, escalation paths, target audiences and procedures for status pages, customer and partner notices, and regulatory communications. Organizations are also advised to establish cross-functional incident teams involving engineering and operations, communications, legal, risk and compliance, and customer support.
The guidance calls for clearly defined roles, including an incident lead, communications lead and spokesperson. It also recommends parallel workstreams so technical teams can focus on diagnosing and remediating the root cause while communications teams manage external messaging and leadership handles strategy and regulatory requirements.
For organizations responding to cyber incidents, the guidance places particular emphasis on balancing transparency with operational security. If malicious activity is suspected or confirmed, external communications should not compromise investigations, containment efforts or other response activities. Organizations are also advised against making premature conclusions when the root cause remains under investigation.
Service Providers Urged to Tailor Messages
The guidance recommends segmenting communications for technical teams, executives and the public. Audiences can include enterprise IT teams and security operations centers, employees and customers, government partners and regulators, critical infrastructure owners and operators, as well as the media and general public.
During an outage, organizations should lead with a concise summary covering affected systems, user impact, scope and the known cause without speculation. The agencies also advise against vague descriptions such as “service degradation” and recommend messaging that can be understood quickly during high-pressure situations.
Transparency is another central principle. Service providers are advised to state what they know and do not know, use a single source of truth such as a status page, and focus communications on actionable guidance rather than reputation management. Customers should be told what actions they need to take or clearly informed when no action is required.
The guidance also calls for continuous, time-stamped updates that show the incident timeline, actions taken, and recovery milestones. Organizations should maintain a single status page and align external messaging with legal, contractual and sector-specific reporting obligations.
Agencies ultimately frame effective outage communications around five principles: immediate acknowledgement, technical and actionable information, transparency, accountability, and continuous updates. For service providers, the guidance positions communication as an important part of incident response, alongside technical remediation and recovery.
Recent AI security incidents involving model evaluations have raised questions about how securely frontier AI models are tested before deployment. Cybersecurity-focused AI company Irregular said an investigation into a publicly reported incident found that models in a small number of evaluation runs gained unintended internet access and carried out offensive security actions against real-world targets.
Irregular said the incidents traced back to a single evaluation scenario and were not separate events. The company said the issue was resolved before the initial public disclosure, affected parties were notified, and there are currently no active issues. Its broader audit remains ongoing.
AI Security Incidents Expose Internet Access Risks in AI Model Evaluations
Irregular said the AI security incidents occurred during AI model evaluations designed to test whether models could autonomously execute multi-stage cyber scenarios under realistic conditions.
The evaluations simulate real-world attack patterns and provide models with objectives such as reconnaissance, identifying private keys, gathering information, extracting data and attempting to avoid detection. According to Irregular, controlled internet access can be important to maintain realism because real-world attackers rely on the internet.
However, the company found that internet access controls allowed some models to move beyond the intended simulated environment.
In the evaluation at the center of the investigation, engineers selected a fictional company name that unknowingly matched a real domain. While models operated inside the simulation in most runs, a small number attempted to access the real domain despite receiving no instruction to do so.
Irregular said models subsequently exploited vulnerabilities, extracted credentials and obtained access to a production database. In another instance, a model moved to a website with a similar name and encountered publicly posted credentials.
The company said there is no evidence that a customer's systems were breached or that customer data was leaked.
Evaluation Environments Face Monitoring Challenges
Irregular said most of the problems identified during its investigation were connected to internet access controls. The company is introducing additional protocols for evaluation setup and strengthening its approach to containment.
The incident also highlighted challenges around model monitoring. Irregular said advanced simulations can generate extremely large volumes of traffic, while legitimate offensive actions performed by models can resemble malicious activity. The company said incidents occurred in fewer than one in 10,000 advanced simulations and often appeared hundreds of turns into an evaluation.
Irregular plans to expand manual review of model behavior, improve monitoring capabilities and establish a dedicated internal team focused on security, containment and model control.
The company also said evaluation environments need continuous review because fictional names used in scenarios can later overlap with newly created websites or real domains.
Security Experts Question Irregular's Response
The disclosure has drawn criticism from cybersecurity professionals.
Zack Korman, chief executive of cybersecurity-focused AI company Embroidery, called the post “such an embarrassing post-mortem” on the OpenAI/Anthropic security incidents and described it as “full of excuses.”
Justin Elze, chief technology officer at TrustedSec, questioned why the monitoring challenge had not been addressed earlier, saying the issue appeared closely connected to the purpose of the testing service.
Woodward also criticized the disclosure, arguing that the absence of dates, named owners for corrective measures and independently verifiable criteria limited its usefulness to researchers and security professionals.
Another cybersecurity commentator, BlackRoomSec, challenged Irregular's assessment of existing monitoring tools, arguing that security teams routinely tune monitoring systems to reduce noise and filter false positives.
Irregular said it is continuing its investigation and will share additional findings where relevant. The company also plans to publish an open whitepaper covering pre-deployment evaluations, including proposed best practices for internet access during testing.
[caption id="attachment_113686" align="aligncenter" width="555"] Image Source: X[/caption]
The discussion adds to wider scrutiny of how cyber evaluations are contained, monitored and disclosed as frontier AI models become increasingly capable. Irregular said the lessons from the incident will be used to develop stronger evaluation environments, monitoring capabilities, containment controls and response procedures.
Levi Strauss cyberattack has exposed certain corporate information after an unauthorized third party gained access to company files through compromised employee computers, according to a filing with the U.S. Securities and Exchange Commission.
Levi Strauss & Co. said it recently detected a cybersecurity incident involving unauthorized access to three company-issued computers. The company said the access was enabled through social engineering techniques, allowing the attackers to reach company files.
According to the filing, the company initiated its response protocols after detecting the incident and implemented containment measures. It also launched an investigation that remains ongoing and engaged third-party cybersecurity experts to assist with the response.
Levi Strauss Cyberattack Investigation Remains Ongoing
Based on preliminary findings, Levi Strauss said it believes certain corporate information was accessed and exfiltrated during the incident. However, the company said its rapid response efforts successfully contained and terminated the unauthorized access.
The company also stated that no consumer data had been impacted as of the date of the filing. Levi Strauss said the incident has not interrupted its business operations and that, based on the information currently available, it does not believe the incident has had or is reasonably likely to have a material impact on its business strategy, operations, financial condition, or results of operations.
The company said it has provided and will provide notifications to affected parties and applicable regulators as appropriate and in accordance with applicable law.
Levi Strauss & Co., headquartered in San Francisco, is known for its Levi's denim brand. The company reported net revenues of $6.3 billion for 2025, up 4% compared with fiscal year 2024 and 7% on an organic basis.
The company designs and markets jeans, casual wear and related accessories for men, women and children under the Levi's, Levi Strauss Signature, and Beyond Yoga brands. Its products are sold in approximately 120 countries through chain retailers, department stores, online sites, and approximately 3,300 retail stores and shop-in-shops.
Retail Cybersecurity Incidents Continue
The Levi Strauss cyberattack comes as several major retailers have reported cybersecurity incidents involving their own systems or third-party service providers.
In the first week of August 2026, the De Bijenkorf cyberattack affected the Dutch luxury department store chain after an incident involving one of its external logistics partners. The disruption affected order processing, deliveries, returns, and refunds, while the company said there was no evidence that its own infrastructure had been compromised.
In October 2025, Spanish fashion retailer Mango confirmed a Mango data breach after an external marketing service provider experienced unauthorized access to limited customer information. Mango said its corporate systems were not compromised and that financial or login details remained secure.
The exposed information included customers’ first names, countries, postal codes, email addresses, and phone numbers. The company said last names, banking information, credit card details, and passwords were not affected.
Retailers also faced law enforcement action following a series of attacks. In July 2025, the UK’s National Crime Agency arrested four people suspected of orchestrating cyberattacks against Marks & Spencer, Co-op, and Harrods. The suspects were detained in the West Midlands and London and faced charges under the Computer Misuse Act, blackmail, money laundering, and involvement in an organized crime group.
Meanwhile, in May 2025, Victoria’s Secret took down its U.S. website and some in-store services following what it described as a Victoria’s Secret security incident. The company said the precautionary shutdown was intended to address the incident while its team worked to restore operations. Its Victoria’s Secret and PINK stores remained open.
The latest incident involving Levi Strauss adds another case to a growing series of cybersecurity incidents affecting major retailers, with the company continuing its investigation into the access and information involved.
Because of the amount of data that can be obtained and the high impact that successful attacks may have, educational institutions are frequent targets of cybercriminals. Both public and private schools and universities rely on software for managing personally identifiable information (PII) that is often insecure or insufficiently tested against known vulnerabilities. In addition, machines used by multiple people without accountability can be vulnerable to insider threats.
The complexity of academic environments amplifies this risk. Unlike corporate networks, educational institutions have to provide a network that supports students, professors, researchers, administrative staff, third-party contractors, and visitors. Each of these groups has different security requirements and access control levels, making it difficult to enforce consistent security policies. A security breach can have severe consequences since it may expose vast amounts of sensitive information, such as social security numbers (CPF in Brazil), addresses, phone numbers, and even parents’ names. Armed with this information, attackers can attempt phishing attacks and impersonate the victims in SIM swapping attacks, a common practice in Brazil.
In this article, we provide details about attacks on educational institutions in Brazil observed by our Global Emergency Response Team (GERT) since 2025. We share general statistics, common threats, initial access vectors, and the impact of such violations. Additionally, we present some interesting cases encountered by our team and the identified TTPs. Finally, we offer recommendations to help institutions protect themselves against future attacks.
Key findings and statistics
Our dataset encompasses incident response cases from January 2025 to June 2026. As the chart below shows, the majority of attacks targeted institutions in São Paulo state, Brazil’s most populous state and a significant center of economic and financial activity. We also had cases in Rio de Janeiro and Pernambuco.
Geographical distribution of incident response requests at educational institutions (download)
Of the customers who requested incident response, 60% were private institutions and 40% were public institutions.
The most frequent reasons for requesting IR services were related to suspicious endpoint activities, encrypted files, and the presence of suspicious files.
The high-severity incidents were mainly related to ransomware attacks. Interestingly, private institutions were the most targeted by ransomware, while incidents in public institutions were mostly related to suspicious endpoint activity and privilege escalation attempts. The most common ransomware families found in our dataset were DragonForce and LockBit 3, whose builder was leaked back in 2022. By using the leaked LockBit builder with a valid privileged account, attackers can build variants capable of disabling defenses and erasing logs.
The most common initial access vectors included the use of valid accounts, exploitation of public-facing applications, and insiders.
For privilege escalation, the attackers often relied on Potato variants (GodPotato, SweetPotato, and BadPotato).
We also observed attackers using tools like AnyDesk for remote access, PsExec for lateral movement within compromised infrastructures, and AV-killer malware to terminate the system’s defenses. The latter was mainly used in ransomware-related incidents.
These data reveal an interesting pattern in the threat landscape affecting educational institutions in the region. Many incidents were not caused by highly sophisticated techniques but rather by the abuse of common weaknesses such as valid accounts, exposed applications, and inadequate patch management, as well as the use of publicly available tools that are well-known to the adversaries. The prevalence of ransomware in private institutions suggests a stronger financial motivation, likely because attackers assume these organizations are more capable of paying for data recovery than public schools and universities.
Most attacks were discovered promptly and lasted from a few minutes to a couple of hours. However, technical incident response activities averaged 9.6 hours. This indicates that the impact caused by an incident often extends beyond the timeframe of the active attack, requiring extensive triage and analysis by the forensic investigators to fully restore operations.
One interesting fact is that we are still observing the use of Windows 10 in the infrastructures of educational institutions, even after Microsoft’s official end-of-support date of October 2025. In addition, we found that some customer organizations were using Windows Server 2016 without security patches and fixes. Using outdated and unsupported operating systems increases the attack surface of an infrastructure because attackers can exploit publicly available vulnerabilities to access vulnerable systems and expand their presence in the network. In addition, legacy operating systems may be incompatible with modern evidence collection tools, necessitating extra time and alternative procedures for forensic acquisition.
In one case, we identified the use of a custom version of LockBit that was generated using the leaked builder. The ransomware was delivered to the organization’s infrastructure via a valid account that had been leaked. It encrypted the organization’s internal systems, including file servers and databases that stored student profiles and other data. There was no evidence of data exfiltration from the affected machines.
During our analysis of the LockBit sample, we were able to extract its configuration. Interestingly, it was configured without the impersonation and spreading options. This meant the attacker had to perform manual lateral movement to deploy the malware across the network.
Further analysis revealed that the attacker used PsExec for lateral movement. By analyzing the Update Sequence Number (USN) Journal, we were able to identify .KEY files associated with PsExec that showed us the previously compromised machines used by the attacker.
After gaining access to the target machines, the adversaries deployed a batch script to disable the system’s defenses. Our analysis of this artifact showed that they had the administrative credentials to disable the EDR in place. In addition, the script enabled RDP, which gave the attackers remote access to the target. The listing below shows an excerpt of the script:
Finally, by cross-checking the Prefetch files, we were able to identify the precise dates of PsExecSvc.exe and LBB.exe (LockBit) execution. This revealed that the attacker established the initial connection to the analyzed machine around 5:30am UTC and ran LBB.exe for the last time at 10am UTC on the same day, resulting in an activity window of approximately four hours and thirty minutes. We were able to identify the extent of the compromise and the additional machines that required network isolation for further forensic analysis, containment, and remediation.
Case 02 – DragonForce deployed via AnyDesk
In another incident, we identified a compromised user account that the adversaries used to install the AnyDesk software to enable remote access. Although the attacker erased the system logs after encrypting the victim’s files, we were able to identify the ransomware execution event via the Prefetch and Amcache.hve files, which provided us with the SHA-1 hash of the sample.
Once we obtained the SHA-1 of the malicious artifact (named by the attacker as 1.EXE), we were able to confirm that it was a DragonForce variant. Even though the lack of evidence made the analysis more difficult, this case shows that forensic investigators must be prepared to identify information that the attackers missed or left untouched.
Case 03 – Python keylogger used by an insider
The third incident illustrates how a series of bad practices enabled an insider to collect passwords from other users inside the infrastructure. First, the customer contacted us stating that a machine was exhibiting strange behavior: files containing passwords were being created. We started with triage collection on one of the affected machines.
Evidence from the Program Compatibility Assistant (PCA) showed the execution of two suspicious files, Windows Host Widgets.exe and Windows Host Widgets_.exe, both located in the C:\Users\<user>\.vscode\dlo directory, where <user> represents a user account shared by everyone who uses the machine. The same artifacts were identified within the Amcache.hve file, and multiple executions were also confirmed by analyzing the Prefetch files. Another interesting source of evidence, UserAssist, confirmed that the threat actor also executed both EXE files by double-clicking on them.
MFT analysis showed that multiple log files named cacheX.txt were created in the previously mentioned directory, where X was a number that increased with each malware execution. We then analyzed the EXE files to confirm their behavior. Luckily, both proved to be the same Python script, which we could easily decompile.
As shown in the listing below, the script contains methods and strings with Portuguese names. It is capable of hiding the log files from view in Explorer. The developer also set a procedure to identify when the Caps Lock key was pressed, in order to record the correct passwords.
def get_base_path():
...
def encontrar_proximo_nome(base='cache'):
...
def set_file_hidden(filepath):
...
ctypes.windll.kernel32.SetFileAttributesW(str(filepath), FILE_ATTRIBUTE_HIDDEN)
...
with open(log_file, 'a', encoding='utf-8') as f:
f.write(f'\n\n--- Registro iniciado em {datetime.datetime.now()} ---\n')
set_file_hidden(log_file)
...
def is_capslock_on():
return bool(ctypes.windll.user32.GetKeyState(20) & 1)
...
def on_press(key):
...
def on_release(key):
...
def main():
with keyboard.Listener(on_press=on_press, on_release=on_release) as listener:
listener.join()
if __name__ == '__main__':
main()
This simple script did not implement any persistence or automated data exfiltration mechanisms. Therefore, the insider likely had to manually retrieve the generated log files containing the text typed by the victims. By revisiting the previously collected evidence, we identified USB connections around the same time as the script’s executions. This suggests that removable media was probably used to collect the generated keylogging logs from the environment. As a result of the investigation, the customer changed the passwords of all affected accounts. However, without additional evidence or footage, it was not possible to conclusively attribute the activities to a specific individual and take the appropriate disciplinary and legal measures.
Conclusions and recommendations
The incidents highlighted in this article demonstrate that Brazilian educational institutions face a diverse set of threats, ranging from ransomware operations to insider activity. In many cases, the attackers relied on valid credentials, exposed services, remote access tools, poor patch management, and insufficient endpoint hardening rather than advanced malware or new techniques. Based on these findings, educational institutions should prioritize controls that reduce the likelihood of account compromise and the impact of ransomware deployment. They should also improve forensic visibility after an incident.
Institutions should enforce the use of multi-factor authentication (MFA) for all publicly accessible services, especially VPNs, remote access portals, and email accounts. Since valid accounts were one of the most common initial access vectors observed in our dataset, MFA can significantly reduce the likelihood that stolen or reused credentials alone will compromise the entire environment. We also recommend periodically reviewing privileged accounts, removing unnecessary administrative permissions, and avoiding shared accounts, especially on machines accessed by multiple users, since this makes accountability extremely difficult.
Each user should have their own account, following the principle of least privilege to prevent unauthorized software execution. Additionally, it is advisable to restrict and monitor the use of remote access tools such as AnyDesk or TeamViewer. Unexpected installations or executions of these tools should be treated as high-priority alerts.
To minimize the impact of ransomware, educational institutions should improve their backup and recovery strategy. Backups should be isolated from the primary environment (preferably in more than one location) and tested regularly. Centralized logging, extended EDR telemetry retention, and proper time synchronization across hosts can also improve the ability to reconstruct an attack timeline and implement the necessary response measures.
The use of outdated systems increases the attack surface, so we recommend that organizations adopt an effective update and patch management policy. It is also important to raise security awareness, since users must understand the risks associated with credential sharing, unknown executables, and unauthorized software.
From a digital forensics and incident response (DFIR) perspective, the reviewed incidents demonstrate that effective incident response activities require correlating multiple forensic artifacts in order to reconstruct the attacker’s actions. Investigators should be aware of how to find information even when logs are missing. Many other artifacts are preserved and can be used for this purpose, such as Amcache, PCA, Prefetch, UserAssist, MFT, and USN Journal. The attackers may fail to erase all traces of their activity, so taking a broad forensic approach is of the utmost importance for determining the scope of the compromise and supporting containment and remediation actions.
Observed TTPs
The table below shows the observed TTPs in our dataset, including cases not detailed in this post.
Recently, our teams in Latin America investigated a series of incidents involving misconfiguration, the deployment of BitLocker, and the exploitation of corporate printers. Attackers used the devices to notify organizations that their infrastructure had been compromised and they had to pay a ransom to recover their data.
This article analyzes two incidents that occurred in June in Colombia and in May in Mexico. We highlight the similarities in the attackers’ communications and outline emerging trends in ransom amounts.
Initial sign of an attack
In both cases, the affected users initially noticed a padlock icon next to their drives in Windows Explorer. This indicated that the drive was encrypted with BitLocker, blocking access to its contents.
Drive icon indicating that the drive is locked
A recovery key was required to unlock the drive.
Attempt to access the disk’s contents and the prompt for the BitLocker recovery key
This is not the first time we have seen such threats; a few years ago, our team discovered a threat known as ShrinkLocker, which utilized BitLocker to achieve its goals.
First case: abusing RDP to encrypt data
One of the incidents occurred in Colombia in June. The attackers exploited an internet-exposed RDP service on a machine connected to an 8 TB storage device containing mission-critical data. After taking control of the system and manipulating user credentials, the attackers enabled BitLocker exclusively on the drive that primarily stored financial data. Once the encryption was complete, they locked the drive and used the company’s printers to produce ransom notes.
Ransomware note
Unfortunately, it was not possible to obtain evidence in the case due to the company’s rush to restore the encrypted disk. The communication with the attackers revealed a demand for just $3,000, and the company considered paying the ransom. After that, the system was restored before the forensic team could take any action, eliminating the evidence needed to assess the incident.
Attacker’s reply to the victim’s email sent to the address in the printed ransom note
This attack was made possible by an internet-facing remote desktop service (RDP) with additional open ports, which employees used to access corporate information. By exploiting this network exposure and misconfiguration, attackers breached the system, identified an additional drive, and leveraged BitLocker to encrypt the data and demand a ransom payment. Leaving RDP ports open without proper security controls jeopardizes the security of systems and information, as highlighted in the our “Global Report: Anatomy of a Cyber World“.
Exposed ports identified in the system in recent months
The company confirmed that, due to compatibility issues with applications required for operation, EPP (Endpoint Protection Platform) protection was disabled on the system, making it easier for attackers to validate, enumerate, and execute applications without revealing malicious activity to central monitoring systems.
Second case: meet the XEntry Team
In another incident, which occurred in Mexico in May, our team identified how the threat actor gained initial access to the infrastructure. They exploited a misconfigured MSSQL service. This allowed them to execute commands on the system after obtaining the database login credentials from code insecurely published on GitHub.
XEntry team attack
In this incident, the attack began three months prior to detection, with the intruder discovering and verifying their access to the environment. After confirming their access and privilege level within the MSSQL server settings, which extended beyond the DBMS to the underlying operating system, the attackers initially focused on manipulating certain aspects of the web server configuration on the same system. They lowered the server’s security settings and created web shell files in the publicly accessible folders. Many of these attempts to manipulate the service or create malicious files were contained by existing EPP security controls, but despite the alerts, the necessary investigation to address the activity was not conducted.
Commands executed when attempting to manipulate the web server
The attackers subsequently confirmed their ability to execute commands locally and set up their attack infrastructure to transmit data via a communications bridge. By exploiting the MSSQL service, they gained access to each of the organization’s internal systems.
The database engine used by the company was Microsoft SQL Server 2019.0150.2160.04, misconfigured to allow operating system сommand execution via the xp_cmdshell extended stored procedure.
Due to this misconfiguration of an internet-exposed service, the attackers established a channel capable of executing any type of command directed at the server and the local infrastructure within its scope.
Attack path
One of the main objectives was to identify shared systems and resources that provided access to critical information. Our analysis confirmed the attackers’ access to systems storing configuration parameters for networking, enterprise management, and cloud services, among others.
A subset of the critical information identified and collected by the attackers
In early May, the attackers focused on running additional scans and deploying ManageEngine’s Endpoint Central RMM (Remote Monitoring and Management) to establish persistence and begin the final stages of their intrusion.
Scanning and RMM deployment
Further RMM-type applications, such as Mesh Agent and Tactical RMM, were installed in the days that followed. These were used to deploy scheduled tasks responsible for enabling the BitLocker service and individually encrypting the infrastructure’s disks, generating a key for each encrypted system.
Commands executed through RMM tools to collect Bitlocker keys
Finally, in mid-May, the attackers managed to execute a Group Policy Object (GPO) used to deploy activation and encryption tasks, as well as other policies responsible for continued deployment of RMM applications via scheduled tasks. The activity initially targeted critical systems but later spread to every system synchronized with the domain controller. Users became aware of the attack when their machines displayed a blue screen with the message “Hacked by XEntry Team”, and their credentials stopped working to access their systems.
A few hours later, ransom notes began emerging from office printers.
Ransom note printed by the XEntry team
These cases confirm that adversary’s objective is to gain access to infrastructure while avoiding investment in or partnership with ransomware groups. Instead, they leverage built-in Microsoft tools to facilitate data encryption and ransom payments. Monitoring and centralizing logs on protected resources, as well as promptly managing alerts, are critical to countering this type of intrusion.
Conclusions
Although the systems under review had security measures in place, there was a lack of proper alert management or inadequate decisions regarding application incompatibilities.
We strongly recommend configuring the Remote Desktop Protocol (RDP) in strict accordance with cybersecurity best practices to prevent unauthorized access. This is especially critical: according to our Global Report: Anatomy of a Cyber World, more than 13% of incidents are related to policy violations and configuration errors, confirming that misconfigurations continue to pose a significant risk.
Organizations should prioritize strict application control policies and active monitoring of network traffic for command-and-control (C2) communications. This is especially critical: according to the same report, more than 20% of incidents involved the abuse of RMM (Remote Monitoring and Management) tools for execution and C2 strategies. The fact that attackers used more than three distinct tools to gain control during a single incident further underscores the urgent need for these measures.
Some questions remain unanswered due to a lack of evidence and a hasty system restoration effort that bypassed critical stages of the incident response process. It is important to ensure an adequate incident response procedure, preserving evidence to confirm all related activities, and adjusting or proposing controls to prevent future incidents involving similar TTPs.
Although the ransom notes do not reveal a clear connection between the actors, certain words used in the messages, as well as the method of delivery and communication, may confirm a link:
“As a guarantee, we have no negative online reviews about non-fulfillment of our obligations…” (Ransom note from the first case)
“Our reputation is the guarantee that all content will be fulfilled…” (Ransom note from the second case)
Taiwan’s digital security authorities have identified five major areas of concern following hundreds of reported cybersecurity incidents involving government agencies in 2025. According to Taiwan’s Ministry of Digital Affairs, the country recorded 726 cybersecurity incidents this year, highlighting ongoing Taiwan cyber risk challenges tied to ransomware, fake software, supply chain weaknesses, and social engineering attacks.The Administration for Cyber Security said the total number of reported cases declined slightly compared to 2024, with 29 fewer incidents recorded year over year. However, officials warned that attack methods continue to expose weaknesses across government systems and digital infrastructure.
Cybersecurity Incidents in Taiwan
As reported by CNA and cited by UDN, most cybersecurity incidents were categorized as low-level threats under Taiwan’s classification system. However, authorities stressed that even minor breaches can create broader operational and national security concerns if left unresolved.Under Taiwan’s cybersecurity framework, incidents are divided into four levels based on their impact on confidentiality, integrity, and system availability. Level 1 incidents accounted for 87.33% of all reports in 2025, while Level 2 incidents represented 9.78%. Level 3 incidents made up 2.89% of the total. No Level 4 incidents — the most severe category — were reported during the year.Unauthorized access remained the most common issue among reported cybersecurity incidents, accounting for 68.6% of all cases. Equipment-related failures represented 15.43% of incidents, while denial-of-service attacks accounted for 4.96%. Website attacks made up another 2.48% of reported cases.Following a review of cyber threat patterns and incident reports from government agencies, Taiwan’s Administration for Cyber Security identified five major Taiwan cyber risk trends that officials believe require immediate attention.
Fake Messaging Apps Raise Taiwan Cyber Risk
One of the biggest cybersecurity risks highlighted by the administration involved fake communication software distributed through unofficial websites. According to UDN, some users unknowingly downloaded counterfeit messaging applications after replacing old devices or setting up new computers.Authorities said these downloads allowed attackers to install backdoor malware capable of compromising systems and sensitive information. The administration urged government agencies to implement stricter procedures for system modifications and software installations.Officials recommended that all software, hardware, and application installations receive prior approval before being used within agency systems. The administration warned that unofficial downloads continue to create major Taiwan cyber risk exposure across public sector networks.
Ransomware Tactics Become More Sophisticated
The second major concern centered on ransomware groups using customized software drivers to infiltrate systems and evade security detection tools. Authorities noted that attackers are becoming more advanced in bypassing conventional endpoint security measures.To reduce the likelihood of future cybersecurity incidents, the administration advised agencies to regularly scan websites for vulnerabilities, apply timely fixes, deploy web application firewalls, and ensure endpoint protection software remains updated.The ministry emphasized that outdated security tools and delayed patch management continue to increase Taiwan's cyber risk across both government and critical infrastructure networks.
Supply chain vulnerabilities were identified as the third major cybersecurity threat. Officials cited one case in which a maintenance contractor installed remote desktop software on a website server. Hackers later gained access to the system after successfully guessing the password linked to the remote access tool.The incident highlighted growing concerns about third-party vendors and contractor oversight. According to the administration, external maintenance work can create hidden entry points for cybercriminals if agencies fail to maintain strict security controls.The administration said agencies should strengthen supervision of vendors, improve password management practices, and enforce tighter restrictions on remote access systems to reduce Taiwan's cyber risk tied to supply chain operations.
What happened A ransomware attack on Sandhills Medical Foundation, a Federally Qualified Community Health Center in McBee, South Carolina, is now the subject of a class action investigation, nearly a year after the incident was first discovered. Sandhills Medical discovered the ransomware attack on May 8, 2025. A forensic investigation determined that an unauthorized third […]
What happened CTM360 researchers have uncovered a large-scale fraud operation using Telegram’s Mini App feature to run cryptocurrency scams, impersonate major brands, and distribute Android malware. The platform behind the operation, dubbed FEMITBOT based on a string found in API responses, uses Telegram bots and embedded Mini Apps to create convincing app-like experiences within the […]
What happened Frost Bank, San Antonio’s largest bank, is facing two proposed class-action lawsuits following a cyberattack attributed to the Everest ransomware group that allegedly exposed the sensitive personal data of an estimated 109,000 customers. The bank has not publicly confirmed the scope of the breach or reported it to the Texas Attorney General’s Office, […]
What happened A cybersecurity incident in late April 2026 targeted Sistemi Informativi, an Italian company wholly owned by IBM Italy that provides IT infrastructure management for public agencies and key private sector organizations. IBM confirmed the breach through an official statement, acknowledging it had identified and contained a cybersecurity incident and activated incident response protocols […]
What happened Cyberthint analysts have documented a structural shift in how cyberattacks are conducted, with threat actors now using artificial intelligence to discover and exploit zero-day vulnerabilities in minutes rather than months. The firm identified this transition in late 2024, noting that AI is operating not just as a research assistant but as an active […]
What happened A supply chain attack campaign attributed to TeamPCP, dubbed Mini Shai-Hulud, has compromised packages across the PyPI, NPM, and PHP ecosystems over a two-day period, affecting over 1,800 developer repositories containing stolen credentials. The campaign was first identified on April 29 when malicious versions of four SAP NPM packages were caught delivering information-stealing […]
What happened A third iteration of the ConsentFix attack technique has been circulating on hacker forums, introducing automation and scalability to a method that abuses Microsoft Azure’s OAuth2 authorization code flow to hijack accounts without passwords and despite multi-factor authentication being enabled. The original ConsentFix was documented by Push Security in December 2025 as an […]
What happened The FBI issued a public service announcement on April 30, 2026, warning the US transportation and logistics industry of a sharp rise in cyber-enabled cargo theft, with estimated losses in the United States and Canada reaching nearly $725 million in 2025. That represents a 60% increase over the prior year. Confirmed cargo theft […]
What happened Instructure, the company behind the Canvas learning management system, has disclosed that it recently suffered a cybersecurity incident perpetrated by a criminal threat actor and is now investigating its scope with the help of outside forensics experts. The disclosure was made by Chief Security Officer Steve Proud, who committed to transparency as the […]
What happened Ameriprise Financial has disclosed a data breach affecting nearly 48,000 individuals across the United States, following unauthorized access to stored company data and files that began on March 2, 2026. The company detected the intrusion on March 18, approximately 16 days after it began, and filed a breach notification with the Maine attorney […]
What happened An internet-connected coffee machine reportedly led to a significant corporate data breach after attackers used the device as an entry point into a secure network. A digital forensics investigator identified only as TR examined the incident after a client suspected a rival had infiltrated its systems. Instead of finding malware, the investigator found […]
A significant proportion of cyberincidents are linked to supply chain attacks, and this proportion is constantly growing. Over the past year, we have seen a wide variety of methods used in such attacks, ranging from creation of malicious but seemingly legitimate open-source libraries or delayed attacks in such seemingly legitimate libraries, to the simplest yet most effective method: compromising the accounts of popular library owners to subsequently release malicious versions of their libraries. Such libraries are used by developers everywhere and are included in many solutions and services. The consequences of an attack can vary widely, ranging from delivering malware to a developer’s device to compromising an entire infrastructure if the malicious library has made its way into the code of a service or product.
This is exactly what happened in March 2026, when attackers injected malicious code into the popular Python library LiteLLM, which serves as a multifunctional gateway for a large set of AI agents. The attackers released two trojanized versions of LiteLLM that delivered malicious scripts to the victim’s system. Both versions made their way into the PyPI repository for Python. A technical analysis revealed that the attackers’ primary targets were servers storing confidential data related to AWS, Kubernetes, NPM, etc., as well as various databases (MySQL, PostgreSQL, MongoDB, etc.). In the latter case, the attackers were primarily interested in database configurations. In addition, the malware’s logic included functionality for stealing confidential data from crypto wallets and techniques for establishing a foothold in the Kubernetes cluster.
Repository compromise
The compromise affected the package distribution channel via PyPI: on March 24, 2026, malicious LiteLLM versions litellm==1.82.7 and litellm==1.82.8 were uploaded to the registry. It was specifically the package’s distribution contents that were compromised: in version 1.82.7, the malicious code was embedded in proxy_server.py, and in 1.82.8, the file litellm_init.pth was added.
Technical analysis
Both versions of the library contained the same malicious code, but its execution was implemented differently. In version 1.82.7, it was executed only when the proxy functionality was imported, while in 1.82.8, a .pth file was added that was able to execute the code every time the interpreter started.
Example of the malicious code in proxy_server.py
The malicious code in the proxy_server.py and litellm_init.pth files contained Python code encoded in Base64. After execution, the infected script saved this code alongside itself as a p.py file and immediately executed it.
The p.py script launched the main payload – another script, also encoded in Base64 – without saving it to disk. At the same time, it wrote the output of this payload to a file in the directory from which it was launched. Before being written, the output was encrypted using the AES-256-CBC algorithm with a random key generated in the code, which was saved to the session.key file. The key file was also encrypted – using a pre-initialized public RSA key.
The encrypted key and the output were combined into a tpcp.tar.gz archive and sent to the attackers’ remote server.
What exactly happened within the malicious payload whose output was sent to the C2 server? After it was launched, a recursive scan of the working directories on the victim’s system (/root, /app/, /var/www, etc.) began. In each directory, the script scanned the contents of files, which it output to the stdout buffer, from where it was then saved to the aforementioned file as the result. Next, the script collected system information and also saved it to the file. After that, it proceeded to search for sensitive data. It was interested in the following data located on servers and within the infrastructures of various services:
SSH keys
GIT accounts
.env files
AWS, Kubernetes, email service, database, and WireGuard configurations
files related to Helm, Terraform, and CI
TLS keys and certificates
A notable feature of this malware is that it does not limit itself to stealing files and configurations from the disk but also attempts to extract runtime secrets from the cloud infrastructure.
The code above uses the addresses 169.254.169.254 and 169.254.170.2. The first corresponds to the AWS Instance Metadata Service (IMDS), through which an EC2 instance (a virtual server in AWS, a machine running in the cloud) can retrieve metadata and temporary IAM role credentials (an AWS account with a set of permissions that a service or application can use to obtain temporary credentials for calls to the AWS API). The second is used in Amazon ECS to issue temporary credentials to a container during execution. Thus, the malicious script targets not only static secrets but also those issued by the cloud that can grant direct access to AWS resources at the time of infection.
Additionally, the script searches for crypto wallet configurations, as well as webhooks associated with Slack and Discord messengers. The latter indicates that the attackers are interested not only in infrastructure secrets and accounts, but also in communication channels within the development team.
In the next stage, the malware moves from data collection to establishing a foothold in the Kubernetes cluster infrastructure: if it has sufficient access, it configures a privileged pod (the smallest execution unit in Kubernetes, containing one or more containers) by enabling the securityContext.privileged=true option and mounts the node’s root filesystem via hostPath. This allows it to escape the container and perform actions at the node level.
Next, the malware executes another stage of infection: it saves a Base64-encoded script disguised as a legitimate system component to the Kubernetes node’s disk at the path /root/.config/sysmon/sysmon.py, and registers it via systemd. After launching, the script waits for an initial delay of 300 seconds, then begins periodically contacting the C2 node checkmarx[.]zone/raw, retrieving a link to the next payload from there. If the received value differs from the state previously saved in /tmp/.pg_state, the script downloads a new file to /tmp/pglog, makes it executable, and runs it in the background. At this stage, the attackers gain a foothold in the system and are capable of regularly delivering updated payloads without the need for re-injection. Since the malicious payload is written not to the container’s temporary file directory but directly to the Kubernetes cluster node, the attackers will retain access to the infrastructure even after the container has terminated.
A similar scenario is used for local persistence: in the absence of Kubernetes, the sysmon.py script is deployed in the user’s directory at ~/.config/sysmon/sysmon.py and is also registered as a service via systemd.
OpenVSX version of the malware
While analyzing files communicating with the C2 server, we discovered malicious versions of two common Checkmarx software extensions: ast-results 2.53.0 and cx-dev-assist 1.7.0. Checkmarx is used for application security assessment. These trojanized extensions contained malicious code that delivered the NodeJS version of the malware described above.
This version is downloaded from checkmarx[.]zone/static/checkmarx-util-1.0.4.tgz using NodeJS package installation utilities and is named checkmarx-util. Its key difference from the Python version is that it does not attempt to elevate privileges to the Kubernetes node level and does not create a privileged pod for persistence. Instead, it implements local persistence within the current environment. This means that the NodeJS variant persists only where it is already running.
Additionally, the list of folders to search for and steal secrets from is significantly smaller in this version than in the Python variant.
Checkmarx extensions are used to scan code and infrastructure configurations, so their compromise is quite dangerous: an attacker gains access not only to project files but also to a significant portion of the development environment, tokens, and local configurations.
Victimology
While assessing the attack’s impact, we saw victims all over the world. Most infection attempts occurred in Russia, China, Brazil, the Netherlands, and UAE.
Conclusion
As the technical analysis shows, the malicious scripts found in the LiteLLM versions are dangerous not only because they steal files containing sensitive data, but also because they target multiple critical infrastructure components simultaneously: the local system, cloud runtime secrets, the Kubernetes cluster, and even cryptographic keys. Such a broad scope of data collection allows an attacker to quickly move from compromising a single system and Python environment to seizing service accounts, secrets, and entire infrastructures.
Prevention and protection
To protect against infections of this kind, we recommend using a specialized solution for monitoring open-source components. Kaspersky provides real-time data feeds on compromised packages and libraries, which can be used to secure the supply chain and protect development projects from such threats.
Home security solutions, such as Kaspersky Premium, help ensure the security of personal devices by providing multi-layered protection that prevents and neutralizes infection threats. Additionally, our solution can restore the device’s functionality in the event of a malware infection.
To protect corporate devices, we recommend using a complex solution such as Kaspersky NEXT, which allows you to build a flexible and effective security system. The products in this line provide threat visibility and real-time protection, as well as EDR and XDR capabilities for threat investigation and response.
At the time of writing, the compromised versions of LiteLLM had already been removed from PyPI and OpenVSX. If you have used them, and as a proactive response to the threat, we recommend taking the following measures on your systems and infrastructure:
Perform a full system scan using a reliable security solution.
Rotate all potentially compromised credentials: API keys, environment variables, SSH keys, Kubernetes service account tokens, and other secrets.
Check hosts and clusters for signs of compromise: the presence of ~/.config/sysmon/sysmon.py files and suspicious pods in Kubernetes.
Clear the cache and conduct an inventory of PyPI modules: check for malicious ones and roll back to clean versions.
Check for indicators of compromise (files on the system or network signs).
Entrar
Image Source: X[/caption]
The discussion adds to wider scrutiny of how cyber evaluations are contained, monitored and disclosed as frontier AI models become increasingly capable. Irregular said the lessons from the incident will be used to develop stronger evaluation environments, monitoring capabilities, containment controls and response procedures. 
