CySecurity News - Latest Information Security and Hacking Incidents

API Cloud Based Solutions Cyber Phishing Cyber Security cybersecurity research Cybersecurity Researchers Google Microsoft

Microsoft Tracks Cloud Intrusion Campaign Using Passkey Phishing and Graph API Abuse

Microsoft Security Research published a report on September 9, 2026, detailing active cloud-based intrusions spanning multiple accounts, in which unusual sign-ins were followed by threat actor-added authentication methods, high-volume Microsoft Graph activity, SharePoint and OneDrive downloads, and email collection through REST APIs.

According to Microsoft, the activity begins with identity-focused social engineering and impersonation infrastructure, then progresses through authentication persistence and cloud reconnaissance before culminating in targeted data access consistent with data collection and potential exfiltration. Microsoft Threat Intelligence assesses that the initial access techniques observed in this campaign are used by a range of threat actors, including Storm-3121, Storm-3032, and others.

The attack typically begins with what appears to be a routine call or message to a user's personal phone number from someone posing as the organization's IT helpdesk. Microsoft found that a "passkey" narrative is frequently used as a pretext, guiding victims through adversary-in-the-middle phishing or device-code authentication flows designed to hijack their session.

Once initial access is achieved, the actor's first priority is converting a temporary compromise into a persistent foothold. This is typically done by enrolling a new multi-factor authentication (MFA) method under the attacker's control, such as registering a new phone number, an authenticator app, or a software-based one-time password token. With MFA persistence established, the actor moves into an extensive internal reconnaissance phase, using Microsoft Graph to inventory users, groups, permissions, resources, and accessible content across the compromised tenant.

Following reconnaissance, the actor transitions into large-scale data collection across Microsoft 365 workloads. Microsoft observed significant volumes of FileAccessed and FileDownloaded events across SharePoint and OneDrive, indicating systematic retrieval of cloud-hosted documents and organizational data. Microsoft recommends that defenders investigate this attack sequence across identity, Microsoft Graph, SharePoint, OneDrive, and Exchange signals. For confirmed compromises, organizations should revoke active sessions and remove any unauthorized authentication methods added by the attacker.

Microsoft further advises enforcing phishing-resistant MFA through Conditional Access policies, along with Conditional Access rules requiring a managed, compliant device for access to Exchange, SharePoint, and Graph-privileged applications. Microsoft has published a list of indicators of compromise associated with the campaign. These include domains tied to fraudulent passkey support and setup lures, such as passkeyhelpdesk[.]com, secure-passkey[.]com, setupmypasskey[.]com, and add-passkey[.]com. Additional domains are linked to identity-provider sessions and key synchronization infrastructure, including oktasession[.]com, keysyncos[.]com, oskeysync[.]com, oskeysetup[.]com, oskeyregister[.]com, syncmykey[.]com, myconnectkey[.]com, and oskeyconnect[.]com. Other identified domains, validationsetupac[.]com and portalsetuphub[.]com, are associated with account validation and portal setup lures respectively.

Microsoft's report underscores the growing sophistication of identity-based attacks that blend social engineering with legitimate cloud APIs, making early detection across authentication and Graph activity critical for organizations defending Microsoft 365 environments.

Gigabud Android Trojan Uses App Cloning to Evade Fraud Detection



 

Gigabud

Android Trojan Banking Scam App Cloning Cyber Fraud Gigabud

Gigabud Android Trojan Uses App Cloning to Evade Fraud Detection

A new report says the Gigabud Android banking trojan has evolved to clone banking apps into a separate work profile, helping criminals evade fraud detection and make stolen transactions look like they came from a clean device. Group-IB says the campaign combines Gigabud with a weaponized app-cloning tool called Vwork, which it links to the GoldFactory group.

Gigabud is not a new threat, but this latest version shows how mobile banking fraud is becoming more sophisticated. The malware reportedly uses Android’s Work Profile feature to isolate a cloned banking app from the user’s personal profile, which can break the connection between a malware alert and the later payment activity.

According to the report, Vwork exposes cloning functions through an interface that other apps on the device can call, making it easier for Gigabud to automate the attack. The trojan includes commands to provision the profile, clone a target app, and report back what was copied, while requiring a token from an external authorization server before cloning begins.

The fraud chain was confirmed on devices in Indonesia, where Group-IB observed about 1,469 compromised devices and 1,281 potentially compromised logins between February and July 2026, with estimated losses of roughly $960,939. The samples were also found targeting 11 countries, including Brazil, Colombia, Egypt, Mexico, Thailand, and Turkiye.

To reduce risk, Group-IB recommends that banks watch for warning signs such as a work profile appearing on a phone the customer never configured, matching app markers across profiles, and suspicious accessibility access on apps that should not need it. For users, the safest habit is to install apps only from official stores and avoid suspicious links delivered through phishing sites, messengers, or social media.

The Four-Character Password Guarding Your Company's AI Keys



 

LiteLLM

AI keys API cloud environment Credential Theft CVE Cyber Security IAM Security LiteLLM

The Four-Character Password Guarding Your Company's AI Keys

Security researchers at Wiz scanned 3,074 internet-facing deployments of LiteLLM in February and found something that should embarrass more than a few engineering teams: 294 of them, just under 10 percent, accepted `sk-1234` as the administrator password. That is the exact value printed in LiteLLM's own quickstart guide, sitting above a comment telling operators to replace it with a long random value before any real use. As of September 9, the guide still reads that way.

The number sounds like a configuration slip, the kind that shows up in enterprise audits and gets quietly fixed. The consequences here are anything but quiet. LiteLLM sits between a company's applications and every AI provider it pays for. Whoever holds the master key can read every provider API key stored on the server, inspect every prompt and reply that moves through it, reach internal tools connected via the Model Context Protocol, and, as Wiz demonstrated, pull the cloud IAM credentials off the machine the gateway runs on. Researchers also found a code execution path that returned root access inside the container during testing. Attackers have since been seen using related flaws to install cryptocurrency miners and copy entire databases of provider credentials.

What LiteLLM Actually Is, and Why It Matters

LiteLLM is an open-source AI gateway. Companies use it as a single routing layer for more than 100 model providers, including OpenAI, Anthropic, AWS Bedrock, Azure, and Google Vertex AI. Rather than scattering API keys and budgets across every team and application, organizations push all their inference traffic through one place. That makes LiteLLM a centralized store for some of the most valuable secrets in a modern cloud environment.

According to Wiz's own cloud data, roughly one in three cloud environments already has a LiteLLM deployment. The project has more than 22,000 stars on GitHub. Many of those instances sit behind corporate networks and VPNs, unreachable from the internet. But the 3,074 Wiz found on Shodan in February were not.

The master key does two things at once, which is what makes a default value particularly dangerous here. It is the administrator credential for the proxy. It is also the secret LiteLLM uses to sign session JWTs with HS256. When it stays at `sk-1234`, anyone who knows that can forge arbitrary user sessions for the entire proxy without ever brute-forcing a password. They just already know it because they read the docs.

Of the 294 instances that accepted the default key, 191 had no master key set at all, meaning the server accepted any request. Before version 1.82.0-stable, gateways with no master key granted every incoming request full proxy administrator rights automatically, no credential needed.

How Far an Attacker Gets

Wiz researchers, working through LiteLLM's codebase with Claude Code, traced what an administrator credential actually unlocks beyond the obvious credential theft.

LiteLLM has a pass-through endpoint feature that lets administrators create proxy routes forwarding requests to any URL they choose. The target URL is never checked against private address ranges, localhost, or cloud metadata addresses. A researcher can point a route at the AWS instance metadata service and read back IAM credentials in a straightforward request chain. The feature works the same way against IMDSv2, which is supposed to require a specific token header to prevent exactly this kind of request. LiteLLM's header forwarding mechanism passes any header prefixed with `x-pass-` to the target with the prefix removed, so an attacker can send the IMDSv2 token request headers along for the ride.

Wiz describes this as arguably working as intended. LiteLLM's threat model treats administrators as trusted, and the project has not assigned it a CVE or issued a fix. The problem, as the researchers put it, is that the threat model has often been broken by deployments that never changed the default key.

The code execution path is a separate issue. LiteLLM lets administrators register custom Python guardrails, code that runs around every inference request to enforce policies like blocking sensitive prompts or filtering outputs. Before version 1.82.0-stable, the endpoint that registers a guardrail applied none of the safety checks present in the test interface. The test interface blocks `import`, `os`, `subprocess`, and strips Python's built-in functions before execution. The registration endpoint did neither. Submitted code ran with the full standard library, inside the container, at root, immediately on registration. Wiz showed this with a proof of concept returning `uid=0(root) gid=0(root)` in the guardrail's block reason field after a single chat completion call.

A second flaw, CVE-2026-40217, published in May, showed that even after the guardrail sandbox was added in 1.82.0, it could be escaped using Python bytecode techniques. That one affects versions 1.81.8 through 1.83.10. The same admin credential is the entry point for both.

The Disagreement Over Severity

Wiz and LiteLLM's maintainers describe the guardrail code execution flaw, CVE-2026-59821, in almost incompatible terms.

Wiz calls it post-authentication code execution at root level and shows test output to support that. LiteLLM's own advisory rates it as Low severity, with a CVSS score of 2.1, noting that the flaw requires a high-privilege account. Both are describing the same behavior. What they disagree on is how to weigh the significance of that requirement, given that high-privilege access was readily available on nearly 10 percent of public instances.

LiteLLM's published security policy categorizes attacks that depend on setup mistakes, such as leaving the master key at its default value, as explicitly out of scope and not treated as vulnerabilities. The project's position is that operators who do not follow the setup instructions have created their own exposure. That is a reasonable position for a software maintainer to take. It is a harder position to defend when the setup guide's own example value is still `sk-1234` months after researchers flagged the issue.

The Flaw Attackers Have Actually Used

The code execution and cloud credential paths described above are Wiz demonstrations. Real attackers have been doing something related but distinct, using a different set of flaws against the same product.

CVE-2026-59822, a separate flaw also found by Wiz, lets an unauthenticated attacker establish a valid MCP session using any Bearer token, including a single character. The authentication handler for LiteLLM's MCP endpoint catches a 401 error from a failed token validation and silently returns an empty authentication object, granting access as if the request were valid. CISA added this to its Known Exploited Vulnerabilities catalog on September 2, with a CVSS score of 8.8. Federal civilian agencies had until September 16 to address it. Wiz's honeypots first recorded it being used in the wild on July 7, in requests probing model listing endpoints with single-character tokens. The agency designation makes it an urgent patch for government networks; the active exploitation makes it pressing for everyone else.

CVE-2026-42271, a different flaw with a CVSS score of 8.7, let any authenticated user run commands on the host through two MCP test endpoints. Horizon3.ai reported in June that it could be chained with a Starlette host-header validation bypass, CVE-2026-48710, to achieve unauthenticated remote code execution on vulnerable instances. Wiz's honeypots recorded attackers using that chain to drop an XMRig cryptocurrency miner via an ELF binary, after first fingerprinting the host and killing competing mining processes.

Microsoft published a case in August where attackers went further. After getting command execution inside a LiteLLM gateway process, they read the container's environment variables for the master key, provider keys, and database connection string. They then used the database string to connect to the PostgreSQL backend and copy records from LiteLLM's model and virtual-key tables. Microsoft assessed with high confidence that the entry point matched the CVE-2026-42271 and CVE-2026-48710 chain. "Treat AI gateways as Tier-0 secrets stores," the company said.

These active attacks sit on top of a separate incident from earlier this year. In March 2026, attackers used stolen maintainer credentials to publish two backdoored versions of LiteLLM to PyPI, versions 1.82.7 and 1.82.8. The malicious packages collected SSH keys, AWS, GCP, and Azure credentials, Kubernetes secrets, and database configurations from any environment that pulled them as a dependency. DSPy, MLflow, CrewAI, and OpenHands all pulled the compromised versions. A subsequent analysis by Hudson Rock found a 153-gigabyte stolen archive linked to the incident, containing files attributed to roughly 2,500 corporate domains including AWS, Samsung, Cisco, and Salesforce. The supply chain attack and the authentication flaws are separate incidents, but they affect the same product, and some organizations are managing fallout from both simultaneously.

What Needs to Happen

Every flaw in the Wiz report is patched in version 1.84.0 or later. The upgrade covers the MCP authentication bypass, the guardrail code execution flaw, the sandbox escape, and the endpoint that let non-admin accounts reach the pass-through configuration. There is no patch for the pass-through route to instance metadata, because LiteLLM does not treat it as a vulnerability. Restricting outbound network access from the container and scoping the workload's cloud IAM role as narrowly as possible are the only controls available for that path.

Changing the master key from `sk-1234` to a long random value requires no upgrade at all and closes every attack path in Wiz's report that depends on holding it. One check is worth doing before rotating: if a separate salt key is set in the configuration, the rotation procedure differs, and using the wrong one can leave stored credentials unreadable.

Organizations that cannot upgrade immediately should block the `/mcp/` path and the two MCP test endpoints at their reverse proxy or API gateway. Blocking `POST /guardrails/test_custom_code` and restricting the guardrail creation and update endpoints to administrators are the workarounds in LiteLLM's own advisories.

If there is any chance an attacker had access, the guardrails list should be reviewed for entries that were not created by the team, and the process should be restarted to clear code held in memory. Guardrails an attacker registered and SSH keys they may have added persist through an upgrade. The provider keys, master key, and database credentials should all be rotated.

The underlying issue is structural and not unique to LiteLLM. AI gateways now hold credentials for every model provider, execute server-side code, connect to internal tools through MCP, and run with the cloud permissions of the workloads they are deployed in. They have become critical infrastructure that is often still being treated as a developer convenience. The security controls surrounding them have not caught up.

Critical Cisco Firewall Management Flaw Exploited in Attacks



 

Internet

Cisco Cyber Attacks Device Security firewall management Internet

Critical Cisco Firewall Management Flaw Exploited in Attacks

Cisco has alerted customers regarding a critical authentication bypass flaw inside the Secure Firewall Management Center (FMC) software that is being actively exploited in the attacks.

The vulnerability, known as CVE-2026-20079, is given a maximum CVSS score 10.0, which makes it one of the most dangerous flaws impacting Cisco’s firewall management products.

The flaw was first disclosed in March 2026 by Cisco, but on September 9, Cisco updated its security advisory to confirm about the active exploitation in August that its Product Security Incident Response Team (PSIRT) became aware about. Cisco has advised users to update impacted systems immediately.

About the vulnerability

The flaw impacts the web interface of Cisco Secure Firewall Management Center Software. When an improper system process is created after the starting of the impacted device, it results in the flaw.

The threat actor does not require authentic credentials to abuse the vulnerability. A remote attacker can escape verification by sending specially tailored HTTP requests to a compromised FMC device.

Cisco has listed the problem as authentication bypass using a different channel or path, or CWE-288. As the flaw can be abused remotely without user interaction or verification, Cisco has given it a CVSS score of 10.0.

Impacted products

Vulnerable products

According to Cisco, regardless of device configuration, the flaw impacts Cisco Secure FMC Software and Cisco Security Cloud Control (SCC) Firewall Management.

Not vulnerable products

The following products are not impacted by the vulnerability:

Firewall Device Manager (FDM)
Secure Firewall Adaptive Security Appliance (ASA) Software
Secure Firewall Threat Defense (FTD) Software
Security Cloud Control (SCC), formerly Defense Orchestrator

Impact on organizations

The flaw could have severe impact for enterprises using Cisco Secure Firewall Management Center for managing their security infrastructure

If a threat actor gains root access, they may modify system configurations, install additional malware, use the infected management system as a base for future attacks and run malicious commands.

The vulnerability could have serious consequences for organizations using Cisco Secure Firewall Management Center to manage their security infrastructure.

An attacker who gains root access could potentially alter system configurations, execute malicious commands, install additional malware or use the compromised management system as a foothold for further attacks.

“To determine if this vulnerability may have been exploited, use the zgrep "package_info.*license" messages* CLI command in expert mode,” Cisco said.

According to Cisco, if organizations suspect exploit, they should reach out to the Cisco Technical Assistance Center (TAC) for help with recovery options.

India Orders Google to Remove 57 Firebase Sites Linked to Cyber Scams



 

Phising Scam

Android Trojan Cyber Fraud Google Firebase I4C Notices India Phising Scam

India Orders Google to Remove 57 Firebase Sites Linked to Cyber Scams

The Indian government has directed Google to take down dozens of websites and databases hosted on Firebase after finding that cybercriminals were allegedly using the platform to impersonate banks, distribute malware, and steal sensitive financial data. According to notices from the Indian Cyber Crime Coordination Centre (I4C), at least 57 Firebase-hosted properties were targeted for removal in August. The case highlights how attackers are increasingly leaning on legitimate cloud services to make scams look more trustworthy.

Investigators said several of the sites were designed to resemble official online services of major Indian banks such as SBI, ICICI Bank, and Axis Bank. Seven of the 57 were reportedly phishing pages built to trick users into entering credentials, while others were used to collect information stolen from victims’ smartphones. The tactics were carefully layered, with fake pages, malicious links, and data collection systems all working together to make the fraud harder to spot.

The I4C also said some campaigns used Android malware disguised as legitimate banking or financial apps. Victims were allegedly lured with offers for new credit cards, reward redemptions, or higher credit limits before being asked to install an app. Once installed, the malware could steal card details, one-time passwords, and other sensitive information, then send it to attacker-controlled infrastructure. Another campaign reportedly abused the PM-KISAN government scheme by promising help with payments and pushing users to download a malicious app.

Security researchers have described similar malware families as “Android God Mode” because they can gain broad access to infected devices and the data stored across multiple apps. In this case, the appeal of Firebase appears to have been its database features and free or low-cost hosting options, which can be abused to create scalable scam operations. That makes legitimate cloud platforms a growing concern for regulators and cybersecurity teams alike.

Google said it has strict policies against phishing, malware, and financial fraud and works with law enforcement agencies, including the I4C, to review abuse reports and remove harmful content. The notices reportedly gave Google just three hours to act, warning of legal action if the flagged links remained live. The episode is another reminder that users should verify banking apps carefully, avoid sideloading unknown APKs, and treat urgent payment or reward messages with caution.

Turner Discloses Data Breach Exposing Salary Info, Bank Accounts, and SSNs



 

leaked sensitive data

cybercrime gang Cybercrime Groups data attacks Data Breach Data Leak data security Employee Personal Information leaked sensitive data

Turner Discloses Data Breach Exposing Salary Info, Bank Accounts, and SSNs

Turner Construction has notified at least 6,098 people of a data breach that uncovered social security numbers, salaries, dates of birth and bank account information used for direct deposit, a filing with the California Office of Attorney General showed. The New York City-based firm found unauthorized access to its systems occurred between July 2 and July 15, the filing with the California Office of Attorney General said.

Turner confirmed on July 27 that files that contained personal information had been accessed without authorization, and some of the files that were accessed may have also included individuals' passport numbers. Ransomware group Payouts King claimed responsibility for the attack, alleging that the data that had been breached extended far beyond personal data to include engineering documents, military project files, contracts and non-disclosure agreements, a post on ClaimDEPOT, a class-action lawsuit tracking website, said.

Turner issued a statement that after discovering that unauthorized access to certain files had occurred, the company engaged third-party cybersecurity and forensic experts and that those experts continue to review the files that were accessed. The company said it would notify impacted individuals and other parties as necessary and provide complimentary identity protection services. Turner added it would not comment on claims made by criminal organizations.

According to ClaimDEPOT, Payouts King first posted information relating to an unidentified victim on July 24 and publicly naming Turner on August 11. The group posted the claims on a Tor network site, which hides the users' locations and identifies, claiming it had obtained 27.2 terabytes of data. Apart from the file types stated in the California attorney general filing, Payouts King claimed it had also accessed documents that were protected under International Traffic in Arms Regulations, which are US government rules regulating the export and import of military items, technology and services. Turner is offering five years of identity protection services through IDShield and IDX, the notices filed with the California AG's office said.

One of the two notices set a November 18 deadline for affected individuals to enroll. The incident comes amid a wave of attacks targeting construction-related domains, an August 6 post on Google's Threat Intelligence blog identifying potentially compromised sites said. Turner is the largest contractor in the industry by revenue and focuses on data centers and advanced technology construction. The booming data center sector drove the firm to build a $44.3 billion backlog by the end of 2025.

Several law firms have since posted notices of investigations into the Turner incident, seeking plaintiffs for potential class-action lawsuits. Turner also reported that at least 38 Vermont residents were affected by the breach, according to the Office of the Vermont Attorney General.

Google Just Patched a Chrome Security Flaw That Hackers Were Already Exploiting



 

Zero Day exploits

Chrome Google Linux vulnerabilities and exploits Web Browser Windows Zero Day exploits

Google Just Patched a Chrome Security Flaw That Hackers Were Already Exploiting

Before getting into the specifics, it helps to understand what makes this kind of vulnerability different from a regular software bug.

A "zero-day" is a security flaw that attackers find and exploit before the software maker has had a chance to fix it. The name comes from the fact that the developer has had zero days to respond. By the time a patch is released, real damage may already be happening somewhere.

In this case, Google confirmed in a security advisory that "an exploit for CVE-2026-87491 exists in the wild," meaning someone built a working attack tool using this flaw and used it. Google has not said who was targeted, how many people were affected, or who was behind the attacks.

The vulnerability sits inside a part of Chrome called V8, the component responsible for running JavaScript on every webpage you visit. JavaScript is the programming language that powers most of the interactive features on the modern internet, from buttons and forms to video players and live chats. V8 runs all of it, on every tab you open, on every website you visit.

The specific flaw is what security researchers call an out-of-bounds write. Think of it this way: imagine a program is given a box that holds exactly ten items. This bug lets an attacker force the program to keep placing items into that box even after it is full, pushing data into the digital space next to it. In a browser, that neighboring space holds other sensitive information and instructions. Corrupting it gives an attacker the ability to take control of what the browser is doing.

What makes this especially concerning is how simple it is to trigger. According to the National Vulnerability Database, an attacker just needs to get a target to visit a specially built webpage. That could come through a phishing link in an email, a malicious advertisement on a legitimate website, or a compromised page the victim had no reason to distrust.

A University Student Found the Flaw

The vulnerability was discovered by Jihyeon Jeong, a research intern at Seoul National University's Compsec Lab in South Korea, who reported it to Google on August 6. Google rewarded Jeong with a $2,500 bug bounty for the responsible disclosure and began working on a fix.

The patch arrived on September 8, roughly 33 days after it was reported. During that window, someone else was apparently already using the flaw in real attacks. Whether attackers found the bug on their own or learned about it another way is something Google has not publicly addressed.

The US Government Is Treating This Seriously Too

The Cybersecurity and Infrastructure Security Agency, the federal body responsible for protecting US government systems from cyber threats, added this vulnerability to its official list of Known Exploited Vulnerabilities on the same day Google released the fix.

That listing comes with a hard deadline: federal civilian agencies must apply the patch by September 23, 2026. While that mandate only formally applies to government networks, companies and organizations across the private sector regularly use CISA's list as a guide for their own patching priorities. When CISA flags something as actively exploited, most security teams pay attention regardless of their sector.

This Is the Second Chrome Attack in Less Than a Week

Just five days earlier, on September 3, Google fixed a different Chrome vulnerability that was also being exploited in active attacks. That flaw, tracked as CVE-2026-85046, was also inside V8. Two exploited vulnerabilities in the same component of the same browser, patched within five days of each other.

Across all of 2026, seven Chrome flaws have now been confirmed exploited in the wild and patched. Three of those seven were inside V8 specifically. For comparison, Google patched eight Chrome zero-days across the entire 12 months of 2025.

Why does V8 keep coming up? Because it is one of the most attractive targets available to an attacker. It processes code from every website a person visits, it is extremely complex under the hood, and the programming language it is built in does not have built-in protections against the kind of memory errors that lead to these vulnerabilities. For sophisticated attackers, finding a flaw in V8 is like finding a master key.

Monday's Update Fixed 230 Security Flaws Total

The zero-day was not the only problem addressed in Monday's release. Chrome 153 fixed 230 security vulnerabilities in total, five of which were rated critical. Four of the critical issues were in WebGL, the part of Chrome that handles 3D graphics in the browser. A fifth critical flaw was found in the Cast component, which handles streaming to devices like Chromecast.

Interestingly, one of the high-severity bugs in the same update was credited to OpenAI Codex Security, an AI-powered security tool, suggesting that artificial intelligence is increasingly being used to find browser vulnerabilities alongside human researchers.

Google said it internally identified 195 of the 230 total flaws through its own security tools before they could be found and exploited by outsiders.

How to Update Chrome Right Now

Google's update will reach most users automatically over the coming days or weeks, but given that this flaw is already being exploited, waiting for the automatic rollout is not the right call.

Here is how to force the update immediately:

1. Open Google Chrome

2. Click the three dots in the top right corner of the browser window

3. Select Help, then click About Google Chrome

4. Chrome will automatically check for and download any available update

5. Once it finishes, click Relaunch to complete the installation

The safe versions are 153.0.8010.36 or higher for Windows and Linux, and 153.0.8010.37 for Mac. If your browser already shows one of those numbers on the About Chrome screen, you are protected.

Google has not named who was behind the attacks exploiting this vulnerability. In past years, Chrome zero-days have been linked to commercial spyware makers and government-backed hacking groups. For now, the company says it is keeping details about the attacks restricted while the patch continues rolling out to users worldwide.

Microsoft Patches Nearly 1,000 Vulnerabilities in September Update



 

Zero Day Vulnerabilities

CVE 2026 Cybersecurity Microsoft Patch Tuesday Microsoft Vulnerabilities Remote Code Execution Vulnerabilities and Exploits Windows Security Updates Zero Day Vulnerabilities

Microsoft Patches Nearly 1,000 Vulnerabilities in September Update

A significant security update was released by Microsoft on Patch Tuesday in September, addressing 974 vulnerabilities across the company's software portfolio in unusual quantities. Additionally, this update contains two Windows flaws that have been confirmed to be exploited in the wild, highlighting the urgency of fixing the vulnerabilities. The vulnerabilities span several Microsoft product categories, including Windows, Office, SQL Server and Development Tools.

Microsoft Windows accounted for 723 flaws, while Microsoft Office and Office 2016 contained 111, SQL had 62, and Developer Tools contained 22 more. There have been over 110 critical vulnerabilities rated as critical. Among the most critical issues addressed in this month's release are privilege escalation, remote code execution and information disclosure. Besides Microsoft's own vulnerabilities, the company also patched 25 non-Microsoft vulnerabilities as part of the September update, which brings the total number of vulnerabilities covered to 999.

The two actively exploited Windows vulnerabilities are CVE-2026-85880 and CVE-2026-81963, both with a CVSS score of 7.8. The CVE-2026-85880 vulnerability is a heap-based buffer overflow in the Advanced Local Procedure Call (ALPC) function of Windows. The vulnerability can be exploited by an attacker with authorization to gain SYSTEM-level access by escalating privileges.

CVE-2026-81963 is a vulnerability that affects the Windows Update Stack and involves improper link resolution. Authorized attackers are also capable of exploiting this vulnerability for escalating local privileges and gaining system access.

By exploiting CVE-2026-85880, Microsoft stated that code running inside an AppContainer that has low privileges may escape its sandbox and gain full privileges on the affected Windows system. The attack does not require additional interaction from the user. This vulnerability has attracted significant attention due to its location within the Windows Update Stack.

There have been reports of vulnerabilities in this component that could have serious implications, especially since the update mechanism itself is responsible for the modification of system components. Microsoft has released fixes for CVE-2026-81963, however, across supported versions of Windows.

Both vulnerabilities have been exploited by Microsoft, but the company has not provided information regarding who the attackers are, how many systems were targeted, or whether successful compromises have been confirmed. According to the Cybersecurity and Infrastructure Security Agency (CISA), both vulnerabilities have been added to its catalog of known exploited vulnerabilities. There is a deadline of September 22, 2026, for federal agencies to apply available security updates.

The September release addresses several high-severity security vulnerabilities across Microsoft enterprise products in addition to the two exploited zero-days. This vulnerability could allow an unauthorized attacker to execute code remotely if exploited by an attacker. It has been rated 8.1 by the Center for Vehicular Defense.

A vulnerability rated 8.8 in SharePoint has been reported, as well as a vulnerability in SQL Server called CVE-2026-65669, which can result in network-based code execution. The vulnerability is particularly severe and carries a CVSS score of 9.6, enabling privilege escalation. Several critical vulnerabilities affect Windows Remote Desktop Services, Windows DNS Server, Windows DHCP Server, Windows Shell, and Windows Services for NFS ONCRPC XDR Driver, carrying the maximum CVSS score of 9.8.

In addition to reflecting the growing number of security vulnerabilities reported, the scale of the September release also reflects the rising number of security flaws reported by TrendAI's Zero Day Initiative. As of the beginning of 2026, Microsoft has patched 2,760 security vulnerabilities. Among Tenable's analysts, Satnam Narang noted that the September release alone brings the yearly count above 2,600 vulnerabilities, more than twice the previous record of 1,245 vulnerabilities recorded in 2020.

It is important to note, however, that the raw number of CVEs does not necessarily indicate a company's level of risk. There may be patches that do not affect a particular environment, while others require specific configurations or local access for exploitation to occur. In the immediate future, it is important to identify vulnerabilities in deployed systems that are able to be exploited realistically.

Since the two Windows zero-day vulnerabilities have already been confirmed as exploited and have been added to CISA's KEV catalog, they should be remedied sooner rather than vulnerabilities with no known exploitation activity.

F5 BIG-IP APM Malware Installs a PHP Web Shell Into Memory, Escaping Disk Scans



 

Sophos

F5 BIG-IP APM Linux Linux RootKit malware PHP Web Shell Sophos

F5 BIG-IP APM Malware Installs a PHP Web Shell Into Memory, Escaping Disk Scans

Sophos X-Ops has found an advanced Linux rootkit that can conceal a PHP web shell completely in server memory, which makes it harder for traditional security tools to detect.

The malware was analyzed in infected environments consisting of F5 BIG-IP Access Policy Manager (APM) and was discovered by Sophos as Linux/Agnt-IC. “The malware targets deployments featuring Apache, libphp, APR module loading, BIG-IP APM webtop components, and BIG-IP upgrade workflows, suggesting it was developed for specific environments,” Sophos reported.

About the research

The research was posted on September 7, 2026, and shows how the rootkit interferes with the PHP runtime and Apache web server to deploy malicious code without making major modifications to authentic PHP files stored on the device.

A Web Shell That Does Not Remain on Disk

One significant feature of the malware is that it can install malicious PHP code directly into the running web server’s memory.

Generally, threat actors planting a PHP web shell would also modify or make a PHP file on the server. Security teams can then detect the malicious file via antivirus scans, manual investigation, or file-integrity monitoring.

The rootkit detailed by Sophos takes another approach. It changes how PHP files are shown to the running Apache process while the original files on disk are left unchanged.

This means that a file scan could demonstrate that a PHP is authentic even when the server is actively running malicious code.

Rootkit Hooks PHP and Apache

Researchers at Sophos discovered that the implant deploys various sophisticated approaches to take command over the web server. It integrates into the device’s startup process and surveys Apache activity to find out when the PHP module is loaded.

After this, the malware can bring its own web-shell functionality and change the in-memory PHP environment.

The installed web shell gets specially tailored HTTP requests and runs commands given by the threat actor. Sophos also found the implant deploying a Unix domain to socket to offer another path of communicating with an infected system and launching a shell.

This combination allows attackers several ways of maintaining access while covering the traces left on the filesystem.

Hard to detect

The attack has become a problem for experts as the malware does not always have to alter files to attack a server. Security teams should check beyond traditional file-integrity check and analyze memory activity, network traffic and running processes.

Sophos recommends that security teams look beyond conventional file-integrity checks and examine network traffic, running processes and memory activity.

DoppelCart Fake-Shop Network Found Operating Across 119,000 Domains



 

fake websites

Cyber Security cybersecurity research Domain E-commerce Websites Compromised Fake Domains fake network fake URLs fake websites

DoppelCart Fake-Shop Network Found Operating Across 119,000 Domains

A newly published investigation has uncovered what may be the largest documented fake-shop network to date, spanning roughly 119,000 domains and dubbed "DoppelCart" by researchers at nebty. The cluster's .shop domains alone account for 2.72 percent of the entire .shop domain population captured in a September 2026 snapshot — roughly one in every 37 domains registered under that extension.

The investigation, led by Benedikt Scheungraber and published September 7, began not as a large-scale probe but as routine work handling individual customer complaints. Researchers found fake shops targeting several clients and arranged for their removal, but noticed the same infrastructure patterns recurring across unrelated takedowns and monitoring cases. Using publicly accessible website scans from urlscan, the team began connecting domains and quickly realized the scale far exceeded a handful of isolated scam sites — eventually tracing around 119,000 associated domains back to a single technical foundation dressed up as countless different brand identities.

To put the discovery in context, researchers compared it to other publicly documented fake-shop networks. BogusBazaar, reported by SRLabs in 2024, spanned more than 75,000 domains over several years, with about 22,500 active at any one time. FraudWear, documented by CTM360 in 2026, involved over 30,000 domains with roughly 8,000 simultaneously active. Malwarebytes identified a cluster of more than 20,000 domains in March 2026, while Netcraft's Fibergrid investigation found 16,700 active fake shops on connected hosting infrastructure in April 2026.

DoppelCart's scale surpasses all of these prior cases. What makes the fake shops convincing, according to the investigation, is their use of genuine material lifted from real businesses. Examined storefronts featured product descriptions copied word for word from legitimate online stores, including detailed explanations of product features and construction. In some cases, the fake sites even embedded images directly from the legitimate brand's own image servers, pairing authentic-looking product photos with advertised discounts of 65 percent to create a convincing illusion of a genuine sale.

The fallout lands squarely on the copied businesses. Because many fake shops list the legitimate store's real support address, customers who never receive their orders end up contacting the authentic company, forcing its support staff to untangle orders they never placed or received payment for — all while trust in the real brand suffers.

To help affected companies respond, the researchers are publishing the full investigation database, allowing businesses to search for their own brand name or domain and review classifications and evidence for each entry. Journalists and security researchers can request the underlying raw data, including archived HTML pages, by contacting the team directly. While takedowns pursued so far have kept removed stores offline, the majority of the DoppelCart cluster reportedly remains active.

One WeChat Call Was Enough to Hijack Accounts Across iPhone and Android



 

Windows

Account Hijacking Android Apple Zero-Day Vulnerabilities iOS Malicious calls Vulnerabilities and Exploits WeChat Windows

One WeChat Call Was Enough to Hijack Accounts Across iPhone and Android

A new wave of WeChat vulnerability can turn an incoming voice call into a zero-click account takeover, enabling a compromised account to target another contact without requiring the recipient to answer the call or interact with the device.

Security researchers at Calif developed the exploit and demonstrated its worm-like propagation across an iPhone and two Android devices. In the test, an Android phone called an iPhone and compromised its WeChat account while the incoming call was still ringing. The compromised iPhone then called a second Android phone, allowing the researchers to repeat the takeover.

The attack depends on the caller already being listed as a WeChat contact of the target. Calif said this is not necessarily a strong protection because compromising one account can give an attacker access to that user's trusted contacts, creating opportunities to propagate the attack through existing relationships.

The recipient does not need to answer the call. Calif said answering it also does not prevent exploitation, with the victim hearing nothing while the attack continues. Rejecting the call stops that individual attempt, but an attacker can simply place another call later. This could allow repeated attempts when a target is unavailable, including while the person is asleep.

According to Calif, the vulnerability affects WeChat's VoIP functionality and involves memory corruption. Successful exploitation provides control over the victim's WeChat account, allowing an attacker to read and send messages, make calls and operate the account as its owner. The researchers stressed that the vulnerability by itself does not provide control of the entire smartphone. Chaining it with separate device vulnerabilities could, however, potentially extend an attack beyond the application.

Calif has not released the exploit's technical details and plans to present its full research at a security conference. The company said its researchers used an AI-assisted system designed to explore attack surfaces in messaging applications to identify the vulnerability. Calif said its engineering team identified the bug on July 23, completed an Android exploit on July 30 and demonstrated the worm on August 11. It separately described the initial exploit development as taking about two days, followed by roughly another week to build the worm.

The researchers disclosed the issue to Tencent in July. Tencent subsequently released WeChat 8.0.77 for Android and 8.0.76 for iOS on August 21. Calif said those updates mitigated its exploit and that it confirmed on August 28 that Tencent had also blocked the attack on its servers. On September 4, Calif said Tencent confirmed that the vulnerability could be exploited for remote command execution.

The server-side mitigation means users do not necessarily need to install an update for the specific exploit to be blocked. Keeping the application updated remains advisable, particularly because Tencent has not published a complete list of affected versions. Calif said it tested against Android 8.0.76 and iOS 8.0.75, including iOS 26.6 and older Android releases.

Tencent has not publicly issued a security advisory describing the vulnerability, while its release notes characterize the relevant updates as bug fixes. The company also distributes WeChat clients for HarmonyOS, Windows, macOS and Linux, but Calif has not disclosed whether those versions were tested.

The risk extends beyond private conversations because WeChat incorporates services including payments, official accounts and mini programs. Tencent reported 1.439 billion combined monthly active users for WeChat and Weixin as of June 30, 2026, giving an account-level compromise potential consequences beyond ordinary messaging.

There is currently no indication that the flaw was used in attacks against WeChat users. Calif has not reported an active campaign, and the researchers have not published indicators that defenders could use to identify exploitation. As of September 8, checks also found no CVE identifier for the vulnerability and no corresponding advisory on Tencent's security response site.

The discovery adds to a continuing security concern around zero-click vulnerabilities in communications software. Such attacks can exploit data automatically processed by an application before a user accepts an incoming communication, removing the conventional requirement for a victim to click a malicious link or open an attachment.

Calif's demonstration therefore presents two distinct risks: the immediate compromise of a WeChat account and the possibility of automated propagation through trusted contacts. While Tencent has blocked the demonstrated exploit, the absence of a public technical analysis means users cannot independently determine from the available information whether older or alternative WeChat builds were vulnerable.

LG Targets Residential Proxies in New Smart TV Security Move



 

WebOS Apps

Connected Device Security Cyber Security LG Smart TV Proxy SDKs Residential Proxies Residential Proxy Networks Smart TV Security WebOS Apps

LG Targets Residential Proxies in New Smart TV Security Move

Several webOS apps using residential proxy technology are being suspended by LG Electronics for routing third-party traffic through smart TVs. The company is working with developers to remove proxy functionality, and apps that fail to do so will be suspended. According to research conducted by security firm Spur, residential proxy software is embedded in a significant number of LG and Samsung smart TV apps.

A proxy SDK was identified in 2,058 of 6,038 examined applications, raising concerns about how television owners' internet connections may be exploited without clear awareness of the activity. As a result of the study, more than 42% of LG webOS apps examined contained residential proxy functionality, while 26.5% of Samsung Tizen apps did not. As a result of such software, a device's connection to the internet and public IP address can be used as part of residential proxy networks.

Web data collection, advertisement verification, optimization monitoring and market research are some of the legitimate business uses of residential proxies. However, the same infrastructure can also be misused for the purpose of concealing malicious activity. Recent takedowns of large residential proxy networks have demonstrated the dangers associated with the use of compromised consumer devices as proxy nodes.

A particular concern is associated with smart TVs because proxy software can continue to operate while connected to the internet. According to Spur researchers, unclear consent mechanisms can lead users to be unaware that their connection has been shared with other parties or that their IP address may be exposed to third parties.

In a statement provided by LG Senior Vice President John Taylor, the company is working with developers to eliminate the residential proxy option from webOS applications. While the company has not provided a specific deadline for developers, apps that retain the functionality will be suspended. In Spur's research, some SDKs remain active after the associated TV app has been closed, making the concern even more serious when the proxy is running in the background.

Some applications are presented as alternatives to advertisements using the TV's internet connection. This model allows apps to remain ad-free and utilize the internet connection to perform activities such as web indexing while using the television's internet connection as an alternative to advertisements. This model poses a security risk that goes beyond exposing the household IP address.

A smart TV is connected to a local network that includes routers, printers, cameras, and storage units. It is possible for the TV to provide a path to other systems on a network if proxy traffic is permitted to reach private network addresses or if filtering mechanisms are not effective. Spur's analysis also observed different implementations of proxy SDKs that enforce these boundaries.

In the sample of Bright Data, restrictions were established for private and reserved IP ranges; however, comparable protections were not observed for the local versions of Massive and Honeygain/Oxylabs SDKs examined. It is therefore necessary to rely heavily on filtering on the provider's end, customer screening, and abuse controls to prevent this type of misuse. The wider platform policies add another level to this problem.

While Amazon explicitly prohibits the use of proxy services for third parties, Roku has also been reported to restrict similar software. LG and Samsung previously did not institute a public restriction that would prevent proxy-enabled applications from using their TV platforms. Instead of relying solely on store descriptions or permission prompts, the research involved an analysis of actual LG webOS and Samsung Tizen application packages.

A team of researchers analyzed the applications to confirm fingerprints associated with residential proxy SDKs, such as Bright Data, Massive, and Honeygain/Oxylabs components, and has denied the suggestion that proxy networks are intrinsically unsafe. The data provider mentioned consent, customer vetting, and governance measures, whereas Massive stated that their network employs KYC checks, server-side controls, and consent checks.

In addition, Oxylabs said it implements filtering and local-network restrictions using both infrastructure and SDK-level controls. However, LG's issue is now more complex than the removal of individual applications alone. Through its scheduled review of webOS apps, the company may determine whether residential proxy functionality is subjected to greater scrutiny during the approval process for the platform's apps.

As a result of this change, smart TV applications are also required to disclose background network activity and obtain consent for services that continue to operate after an app is closed. It is LG's intention to take action on its planned plans that illustrates the need for clearer disclosures, stronger app review policies, and effective controls surrounding residential proxy services.

Ransomware Affiliate Pretends to be Recovery Service for Extortion



 

Ransomware

Cyber Security Extortion Ransom Busters Ransom Payments Ransomware

Ransomware Affiliate Pretends to be Recovery Service for Extortion

An alleged ransomware affiliate is pretending to be a ransomware recovery service named “Ransom Busters,” reaching out to victims before the attacks become public and claims it can delete stolen data and provide decryption keys for some fees.

Fake ransomware recovery service

The activity was discovered by GuidePoint Security’s Research and Intelligence Team (GRIT) after it responded to various cases where targets got emails apparently from Ransom Busters, contacting to provide help in recovering from the ransomware attack.

This seems suspicious because cybersecurity firms usually contact ransomware victims to offer recovery services or consulting after the attack has happened and becomes public knowledge. But in this case, Ransom Busters’ knowledge about the attack that was not yet public raises questions.

GRIT believes Ransom Busters to be working across various ransomware operations, and have taken a new extortion approach.

The group contacted victims via emails, requesting to get in touch with their CEO or IT leadership.

According to GRIT, the email said “I am a representative of a project that assists victims of cyberattacks. We have been identifying vulnerabilities and infiltrating the servers of criminal groups for over three years. On the server we recently accessed, we discovered data stolen from your company [...] We can return your files to you and destroy all backups held by the group. Additionally, we have gained access to the encryption key storage and can help you regain access to your encrypted files.”

Extortion tactic

In the communications after this mail, Ransom Busters said they found the flaws in the admin panels of various ransomware-as-a-service (RaaS) operations. It offered to remove the stolen data from ransomware servers such as Settra, DragonForce, and Anubis, for a fee of $20,000 to $60,000.

But evidence from the two incidents has led GRIT to suspect that Ransom Busters is the group responsible for the attacks.

In both incidents, the threat actors used the same software such as s5cmd, Remotely remote monitoring tool, and SoftPerfect Network Scanner. The group also used the same approach to create a local backdoor account via the same threat actor-controlled hostname 'DESKTOP-BBETH6K' and password Numlock!123'.

The attacker claimed this access gave them command over “almost all of their infrastructure,” according to GRIT. The aim of Ransom Busters seems to be financial, like other RaaS groups.

Impact on ransomware victims

Ransomware groups such as Ransom Busters cannot be trusted as they use deceptive tactics for extortion payments. In these incidents, it is observed that even payments to these gangs does not guarantee recovery of stolen data and if it will be deleted. If your organization receives such mails, it should be immediately reported to the response team.

Critical FreeIPA Bug Can Let Attackers Take Over Admin Rights



 

Vulnerabilities and Exploits

Administrative Privilege FreeIPA LDAP Red Hat Vulnerabilities and Exploits

Critical FreeIPA Bug Can Let Attackers Take Over Admin Rights

FreeIPA users and Red Hat Identity Management administrators should treat CVE-2026-76578 as a critical authentication-bypass flaw that can lead to full administrative compromise. Red Hat says a remote attacker with only LDAP network access can exploit the issue without credentials or user interaction, and NVD echoes the same core description.

The weakness sits in FreeIPA’s self-managed OTP token ACI, which does not require authentication and does not properly restrict extra attributes added with a token entry. In Red Hat’s advisory, that flaw is chained with a separate directory-server ACI evaluation problem so an attacker can create an arbitrary Kerberos principal and get it placed into the administrators group.

That matters because administrator-group membership in FreeIPA is not symbolic; it grants real control over identity and directory operations. Red Hat says the attacker can perform privileged reads, create or delete entries, and potentially disrupt the directory, while SID-enabled deployments may extend the blast radius to other IdM services. External security writeups also describe the issue as affecting default FreeIPA installations and rate it 9.8 Critical.

Red Hat lists the CVSS v3.1 vector as AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, which matches a network-only attack with no privileges or user interaction required. The company also notes that the original collision-based technique was independently reproduced on a stock FreeIPA installation, underscoring that the issue is practical rather than theoretical. NVD’s record shows the same vulnerability text and links back to Red Hat as the source.

The immediate defensive advice is to restrict LDAP ports 389 and 636 to trusted hosts using firewall rules or segmentation. Red Hat also says disabling anonymous LDAP binds can block this attack path, but administrators should verify that doing so will not break any legitimate anonymous-bind workflows first. The FreeIPA project’s fix is reported in version 4.13.4 by external coverage, and that update is the cleanest long-term remediation path.

Hackers Turn ScreenConnect Into Its Own Infection Vector in New Worm-Like Campaign



 

trojans

ConnectWise ScreenConnect malware Huntress Huntress cybersecurity IT department LockBit malware trojans

Hackers Turn ScreenConnect Into Its Own Infection Vector in New Worm-Like Campaign

A remote access tool built for IT departments and help desks is now being weaponized against them. Researchers at Huntress say they've found hacked versions of ConnectWise's ScreenConnect software that don't just give attackers a foothold on one machine, they use that foothold to infect whoever connects to it next, turning a single compromised endpoint into a launching pad for further attacks.

Huntress said its Security Operations Center issued three critical incident alerts in late August after spotting the same unusual pattern across customer networks that had nothing else in common. In each case, a rogue ScreenConnect client had been planted through social engineering, and once running, it began quietly automating an infection chain that most victims never saw coming.

Three break-ins, one playbook

The entry points varied, but the outcome didn't. On August 20, Huntress caught a case that started with a classic tech support scam: someone called a victim claiming their computer had been hacked, then walked them through opening Quick Assist, the remote help tool that ships with Windows, and handing over control. Once inside, the attacker installed a ScreenConnect client wired to call home to a server at 45.13.237[.]190, an address that VirusTotal had tied to a domain called tele-sync.opik[.]net earlier that same month.

A second incident, logged the same day, took a different path in. The victim ran a file called ScreenConnect.ClientSetup.msi straight out of a Microsoft Edge downloads folder, almost certainly after clicking through a phishing email. That installer set up a client pointed at a separate server, 131.123.40[.]98, over port 8041. Huntress later found the same machine reaching out to several more IP addresses tied to the campaign's infrastructure.

The third case, on August 24, started with something almost mundane: a person searching online for a Geek Squad refund form. Instead of a form, they got a rogue ScreenConnect.Client.exe that connected back to a domain named borertors92.anondns[.]net. Huntress shut this one down quickly enough that it never progressed past the initial script execution.

Different bait, same result. Once the ScreenConnect client landed on a machine, it began repeatedly calling wscript.exe, the built-in Windows scripting engine, to fire off four files named, plainly, 1.vbs, 2.vbs, 3.vbs and 4.vbs.

What the four scripts actually do

Huntress pulled the scripts apart and found a loader designed to feel its way around a system before deciding what to drop on it.

The first script checks whether ScreenConnect is already installed, looks for security software including Huntress's own agent, CrowdStrike, SentinelOne, Sophos, Malwarebytes and Cisco AMP, and checks how much memory the machine has, likely a crude way of ruling out sandboxes and virtual machines used by researchers. It boils all of that down into a three-digit code and drops it into a file called value.txt in the Windows temp folder.

The second script waits for that file to appear, then fetches a link from Dropbox, decodes it and stores the result as a lookup table. Each possible three-digit combination in that table maps to a different payload and a different AES decryption key. The third script reads the table, matches it against the code generated earlier, and downloads whichever payload fits. The fourth script grabs the matching decryption key, builds a PowerShell script from scratch inside the VBScript itself, and runs it with Windows' script execution safeguards switched off.

That PowerShell script does the actual unwrapping, decrypting the downloaded file and handing control to a second, more capable PowerShell script that Huntress found renamed as PyTorchFix.ps1. Depending on which of the three outcomes the profiling scripts settled on, the victim ends up with either a bare-bones backdoored ScreenConnect client, a version bundled with tools for privilege escalation and persistence, or the full package: tunneling software and a cryptocurrency miner thrown in as well.

One small detail stood out to the researchers. A comment buried in the third script spells out the payload table's format in plain, tutorial-style language, the kind of explanatory note that reads less like something a human attacker jotted down and more like something an AI coding tool generated on the fly.

How the infection spreads on its own

This is the part that makes the campaign unusual. Buried in the backdoored ScreenConnect client is code that watches ScreenConnect's own connection list for new sessions. The moment somebody new connects, whether that's another victim, a technician, or anyone else routed through the same infrastructure, the client repackages all four VBScript files, hands them to ScreenConnect's built-in file transfer feature, flags them to run automatically, and pushes them straight to the new arrival.

Huntress described it as the modified client using the server's own connection status data to figure out who just showed up, then quietly loading them up with the same infection. The client keeps a short memory of which sessions it has already hit so it doesn't repeat itself mid-session, but that memory resets once someone disconnects, meaning a second visit from the same person can trigger the whole thing over again.

The heavier version of the payload came with extras: a copy of the tunneling tool wstunnel disguised under the filename Themes.exe, reaching out to homehub.opik[.]net over port 443; an XMRig cryptocurrency miner renamed SearchIndex.exe; and a known vulnerable driver called WinRing0, saved as svcdrv64.sys, which attackers commonly use to get code running with elevated privileges. The malware also went after Windows Defender directly, disabling its reporting and notifications and switching off a hardware-level protection called Hypervisor-Protected Code Integrity. In at least one case, the attackers also dropped a second remote access tool, UltraViewer, apparently as a fallback in case ScreenConnect got pulled.

Huntress caught and stopped all three original incidents before the attackers finished the job, but the firm says it has continued to see the same pattern show up elsewhere since. Because the malware digs in so deep, wiping the affected machines and rebuilding them from clean media is what Huntress is telling customers to do rather than trying to clean an infected system in place.

Where ConnectWise fits in, and where it doesn't

Huntress says it's been talking with ConnectWise throughout the investigation, and on September 3, ConnectWise published its own advisory describing a problem with file transfer behavior in ScreenConnect's Remote Access, Support and Access sessions, affecting both the cloud-hosted version and self-hosted, on-premises deployments.

The company said a CVE number and an official patch are coming within the week. In the meantime, it's telling ScreenConnect administrators to go into Administration, then Security, then Roles, and check whether the TransferFiles permission, called TransferFilesInSession in older builds, is switched on for any assigned role. If it is, ConnectWise says to turn it off, a change that doesn't require updating ScreenConnect itself and can be applied right away.

One thing worth being precise about: ConnectWise has not said the file transfer issue is technically the same vulnerability the Huntress campaign is exploiting. The advisory and the Huntress research came out around the same time and clearly describe related territory, file transfer abuse inside ScreenConnect sessions, but the company has stopped short of confirming a direct link between the two.

Huntress, for its part, is telling anyone running ScreenConnect on-premises to take a closer look at their deployments regardless. The firm recommends digging through ScreenConnect's server-side audit logs for RunFiles or RanFiles entries tied to a Guest process, especially any referencing unfamiliar VBScript or PowerShell activity, and treating that as an immediate red flag. Huntress also cautioned that the exact filenames tied to this campaign will likely change as the attackers adjust, so the underlying behavior, scripted execution launched through a ScreenConnect session, matters more than the specific file names.

Not the first time ScreenConnect has been a target

This isn't ScreenConnect's first brush with mass exploitation. In February 2024, ConnectWise disclosed a pair of vulnerabilities in the product, an authentication bypass rated a perfect 10 on the CVSS scale and a path traversal flaw alongside it, that let attackers create administrator accounts on exposed servers without needing valid credentials. Proof-of-concept code for those bugs went public within days, and Huntress's own CEO at the time called it the makings of what could be the biggest cybersecurity incident of that year, given that a single exploited server could hand attackers control over thousands of downstream endpoints managed through it.

What followed was a scramble. Security vendors including Sophos and Darktrace tracked ransomware built from a leaked LockBit builder tool being dropped through the exploited servers, alongside Cobalt Strike beacons and remote access trojans. The Cybersecurity and Infrastructure Security Agency later added one of the two flaws to its Known Exploited Vulnerabilities catalog. More recently, other research teams have logged waves of signed ScreenConnect droppers used in financial sector phishing campaigns, and industry researchers have generally flagged remote monitoring and management software as one of the more consistently abused categories of legitimate IT tooling over the past couple of years, precisely because it's designed to do the thing attackers want: get full control of a machine without tripping the alarms a piece of unfamiliar malware would.

The current campaign fits that same pattern in terms of how attackers get in, but the automated, self-spreading distribution mechanism built into the client itself is new territory, and it's the detail that has researchers paying closer attention this time around.

Liquid Network Attacker Returns 85% of Stolen Bitcoin After Blockstream Patches Bug



 

Hacker attack

Bitcoin Bitcoin Hacker Bitcoin Security Bitcoin Theft Blockchain Blockchain Security Cyber Attacks Hacker attack

Liquid Network Attacker Returns 85% of Stolen Bitcoin After Blockstream Patches Bug

The attacker who stole 4,000 bitcoin (BTC) from Liquid Network’s federation wallet on the weekend has returned 85% of the funds after Blockstream announced that its bridge nodes had been patched. The abovementioned white-hat hacker communicated with the exchange via Bitcoin OP_RETURN and PGP encrypted text. On block 965,875, the criminal warned Blockstream to “fix the bug first” and patch all bridge nodes before asking for the funds to be returned.

The Blockstream representatives, led by Adam Back, informed the hacker that their bridge nodes have been patched and it was safe to return the money. The message, signed with their key, was attached to a PGP-signed on-chain note. This key was verified against the security key, published on the blockchain by Blockstream. Consequently, the hacker transferred 3,400 BTC to the federation address on block 965,950. Thus, about 598.5 BTC (or $47.3 million at the time of writing) remained in the hands of the attacker.

In the previous message, on block 965,822, the hacker proposed to return most of the bitcoin to the federation address. Earlier, Blockstream contacted the unknown party initiating the security team. The conversation began after Liquid announced on September 6 that 4,000 BTC (about $320 million at the time) was stolen from its treasury. Notably, the SideSwap Peg-out Authorization Key was used to initiate the withdrawal, but it was not hacked. On X, SideSwap announced that the attack involved 4,000 LBTC, which the company’s peg-out service burned.

The Liquid Federation transferred 3,996 BTC to the customer’s bitcoin address as payment for the 4,000 LBTC. According to SideSwap, the error occurred because of an “elements software issue or bug,” resulting in the creation of the 4,000 LBTC. Nevertheless, the trading platform claimed that its servers were not breached, and its peg-out authorization key was secure. Liquid Network advised to stop all blockchain activities, including the bridge, and suspended LBTC deposits and withdrawals at exchanges.

Meanwhile, SideSwap stated that it would pause swaps, peg-ins, and peg-outs of its proof-of-reserve token until the network resumes operations. White-hat hackers are common in the cryptocurrency industry, especially when large sums of money are at risk. In most cases, crypto heists end with the attackers disappearing with a small portion of the stolen funds. However, dealing with “white hats” can be challenging for projects in many ways.

Notably, in the past years, several projects have seen an increase in attacks, followed by negotiations about returning the majority of the hijacked crypto. Some projects even offer rewards to cryptos, threatening to take legal action if they do not provide evidence of cracking their systems. It remains unclear when Liquid Network and Blockstream will resume operations. However, until the resumption of operations, the attacker can enjoy a tidy sum of money – about $47.3 million.

PEEP Turns Chrome and Edge Into Hidden Backdoors



 

PEEP

Browser Security Chrome Backdoor Credential Theft Edge Extension malware PEEP

PEEP Turns Chrome and Edge Into Hidden Backdoors

Cybersecurity researchers have uncovered PEEP, a Chromium-based post-exploitation toolkit that turns Chrome and Edge into stealthy backdoors after an attacker already has access to a system. The malware poses as a bookmarks extension and uses browser trust to slip past ordinary checks.

PEEP is built to operate after compromise rather than to break in on its own, which means it depends on some earlier intrusion or code execution step. Once installed, it injects itself into browser profiles and forges Chromium Secure Preferences values to bypass warnings, making it harder for users and defenders to notice.

The extension continuously checks its command server for tasks and quietly sends back browsing history, active tabs, cookies, and other session details. It can also steal credentials, hijack sessions, alter web pages, and use a native-messaging helper to run host-level commands and manage files outside the browser sandbox.

Researchers say PEEP appears to be based on RedExt, an open-source browser analysis and red-teaming framework, but it adds stronger persistence and more operational features. It uses multiple delivery and survival methods, including sideloading, enterprise force-install policies, preference tampering, and scripts such as install_silent.ps1, patch_secure_prefs.ps1, and force_enable.ps1.

The safest response is to treat unexpected browser extensions as a serious incident signal, especially if they appear outside the Chrome Web Store or are installed through policy or sideloading. Security teams should inspect browser profiles, review extension force-install settings, monitor for suspicious native-messaging hosts, and check for abnormal outbound traffic to unknown command servers; users should keep browsers updated, remove unknown extensions, use least-privilege accounts, and report signs of session theft or credential abuse immediately.

Attackers Exploit TeamCity Flaw to Breach JetBrains Cadence



 

Vulnerabilities and Exploits

AWS Credentials CI/CD Security Cloud Security CVE-2026-63077 Cybersecurity Breach JetBrains Cadence TeamCity Vulnerability Vulnerabilities and Exploits

Attackers Exploit TeamCity Flaw to Breach JetBrains Cadence

JetBrains has revealed a security incident involving its Cadence cloud development service after attackers gained access through an unpatched TeamCity server. The compromise exposed sensitive credentials, source code, and service information, causing concerns regarding the security of development environments connected to cloud computing resources.

During this incident, CVE-2026-63077, a critical TeamCity On-Premises vulnerability, was exploited by an unauthenticated attacker, allowing him to execute operating system commands on an affected server without any authentication.

A flaw disclosed by JetBrains on July 27 was exploited soon after by vulnerable TeamCity installations. In the case of Cadence, it was api.cadence.jetbrains.com, the infrastructure used to support JetBrains' cloud computing service for PyCharm, which was vulnerable.

A malicious attacker is believed to have begun attacking on August 8 JetBrains discovered the intrusion on August 23 and taken the affected server offline the following day, putting the confirmed incident window between August 8 and August 24. Cadence integrates with PyCharm through an optional plugin that provides access to cloud-based computing resources for development projects.

As TeamCity managed those workloads behind the service, the compromised system was part of a closely related environment involving software development and execution. JetBrains acknowledged that the server should have been patched immediately following the disclosure of the TeamCity vulnerability, but remained unpatched.

Following the discovery of the critical vulnerability in TeamCity, the company has previously advised organizations to update vulnerable TeamCity deployments. In addition, the breach became more significant because attackers obtained a complete backup of Cadence server data from 2024. In addition, JetBrains confirmed that several Amazon Web Services IAM users and their credentials were compromised, including those belonging to Cadence employees.

The backup may contain credentials, configuration data, artifacts, and logs. A compromised backup contained more than routine service data. It also contained configuration information and credentials associated with cloud and development resources. Researchers also discovered that JetBrains customers' own buckets were accessed through S3 buckets within JetBrains' Amazon Web Services environment.

The extent of customer access to these buckets is unknown. There were several aspects of the development infrastructure exposed, including access to AWS IAM accounts, source-control access, package and container registry credentials, API tokens, SSH and deployment keys, service accounts and signing credentials, among others.

In the event of valid credentials remaining after the compromise, such access could provide a path into connected systems. JetBrains has not identified a specific threat actor as responsible for the activity, and no custom malware has been identified. Instead of exploiting a TeamCity vulnerability, the attacker used legitimate credentials and cloud services to conduct the intrusion. This method can make it difficult to distinguish malicious activity from normal administrative activity. This incident demonstrates the security implications of continuous integration and continuous delivery.

Using TeamCity environments, you can access source repositories, build artifacts, deployment systems, package registries, and cloud resources. Thus, a compromise on this level can lead to credential theft, unauthorized changes, and software supply chain attacks beyond the affected server. According to JetBrains, access tokens for the Cadence plugin in PyCharm have been invalidated, and users are encouraged to revoke or rotate credentials and secrets that were potentially used during Cadence executions.

In addition, Cadence inputs and outputs derived from this period should be viewed as potentially untrusted. As a result of the TeamCity vulnerability, a CVSS score of 9.8 has been assigned to it; it affects on-premises installations not updated to the latest version. The JetBrains patch version 2025.11.7 and version 2026.1.3, along with a security patch plugin, are available for environments in which immediate upgrades are not possible.

After exploitation was observed in the wild, CISA added the flaw to its catalog of Known Exploited Vulnerabilities. JetBrains has begun to assess the impact of the Cadence breach and has prompted a broader review of the affected environment. Upon completing the investigation, the company will contact affected users if further information is discovered that requires action.

According to the company, the incident is limited to the data associated with the Cadence host identified. It illustrates how critical it is to keep the CI/CD infrastructure patched, particularly when development systems are connected to the cloud and sensitive credentials.

Search This Blog

Sections

Popular Posts

Blog Archive

Labels

About Me

Footer About