Search This Blog
Powered by Blogger.

Blog Archive

Labels

Footer About

Footer About

Labels

Load More
Trendy Right Now

Popular Posts

Vulnerabilities and Exploits
CVE-2026-81578 CVE-2026-82078 PaperCut MF vulnerability PaperCut NG vulnerability PaperCut security Vulnerabilities and Exploits

PaperCut NG and MF Flaws Exploited in the Wild, Prompting Emergency Security Patch

 

Malicious attackers are actively exploiting newly disclosed vulnerabilities in PaperCut NG and PaperCut MF that can allow unauthorized remote code execution on vulnerable servers. In response, PaperCut has issued another emergency update for versions 24, 25 and 26, incorporating additional security hardening.

"This vulnerability gives an unauthenticated attacker remote control over PaperCut's trusted configuration, which could be used to execute arbitrary Java code inside the application's process," Huntress researchers John Hammond and Andrew Brandt said.

The attack involves sending specially crafted, unauthenticated requests that manipulate server configuration settings. According to Huntress, the flaw stems from an authorization weakness that can cause PaperCut's security checks to validate the page being displayed rather than the underlying component responsible for carrying out an action.

In vulnerable versions, attackers can exploit this behavior to alter server configurations and gain access to sensitive administrative endpoints. Those endpoints can then be abused to perform unsafe operations and ultimately execute attacker-controlled code.

PaperCut has identified two vulnerabilities linked to the attacks:

  • CVE-2026-82078 (CVSS 9.4): An unsafe dynamic class-loading flaw in the database connection utilities of PaperCut MF and NG. The software loads database driver classes according to configurable driver names without checking them against an approved allowlist.
  • CVE-2026-81578 (CVSS 8.8): An improper access-control vulnerability in the web management interface. Under certain circumstances, unauthenticated remote requests can reach administrative backend functions before access checks have been fully completed.

The latest update follows PaperCut's release of a second emergency patch for versions 24, 25 and 26, which the company described as containing "additional hardening beyond the original emergency patch." PaperCut has not yet disclosed detailed information about the threat actors or their broader objectives.

However, the company has provided several indicators of compromise (IoCs) that organizations can use to investigate potentially affected systems.

Potential indicators in server.log include:

  • DB URL: jdbc:derby:memory:pwn;create=true
  • Database error looking up cardID: VALUES CAST(X'cafebabe
  • Database error looking up cardID: VALUES CAST('
  • DB URL: jdbc:no:x DB Driver: <5-char random name>

Security teams should also check for files such as:

  • <install>\server\lib\<5-char-name>.class
  • <install>\server\data\content\<5-char-name>.cmd
  • <install>\server\data\content\<5-char-name>.out
PaperCut warned that attackers may delete these files during the course of an intrusion, meaning that their absence cannot be treated as evidence that a system was not compromised.

Other activity observed by researchers includes the PaperCut application process spawning shell processes such as cmd.exe and executing commands including "whoami & ver". Investigators have also identified the deployment of remote-access software, including SimpleHelp and AnyDesk, potentially to maintain access to compromised systems.

"At this time, we don't have enough evidence to determine the threat actors' ultimate end goal," John Hammond, senior principal security researcher at Huntress, told The Hacker News. "Based on what we observed, the activity appears consistent with early-stage reconnaissance or validation, including commands to identify the victim’s user account and operating system."

Researchers at preemptive exposure management company watchTowr said the two vulnerabilities can be combined to bypass authentication and achieve remote code execution.

"CVE-2026-81578 allows you to bypass authentication, and from there, you can edit a configuration file to exploit CVE-2026-82078 and gain Remote Code Execution," Jake Knott, head of threat intelligence at watchTowr, told The Hacker News.

watchTowr also reported finding several techniques capable of bypassing the initial security fixes, along with another authentication bypass issue. One of the identified bypasses has been addressed in PaperCut's second emergency update, although researchers say additional bypasses affecting the newest patched version have also been discovered.

Huntress similarly reported a bypass affecting the first emergency patch. After reviewing the latest update, the company said "analyzing this second set of emergency patches, we do see security improvements that remediate parts of the attack chain as we understand it."

Huntress has observed limited exploitation across two customer environments. In those incidents, attackers used Base64-encoded commands on compromised servers to gather basic system information, including the logged-in user and operating system, using "whoami & ver".

Attackers were also seen deploying a Java .class file capable of running across both Windows and Linux environments. The file can execute commands, identify characteristics of the compromised machine and generate directory listings. The resulting information was saved as Udydn.out under the /data/content/ directory relative to the PaperCut installation.

After collecting the information, the malicious Java file removed Udydn.out, the server's server.log, and /data/internal/derby.log, potentially reducing evidence available for forensic investigation.

In a separate incident observed on August 27, 2026, attackers reportedly deployed another version of the Java file that expanded its reconnaissance capabilities by adding the running-process list through the command "whoami & ver & tasklist".

Organizations running PaperCut NG or MF should immediately eliminate unnecessary public internet exposure and install the latest security updates. Administrators should also consider limiting access to the PaperCut Application Server web interface to trusted IP addresses or placing it behind a VPN or another controlled administrative access mechanism.

"PaperCut is a prime target for attackers of every motivation, as not only is it an internet-facing pivot into a corporate environment, but it is a sensitive information treasure trove if printed documents can be stored and exfiltrated," Knott said in a statement shared with The Hacker News.

"Organizations with vulnerable internet-facing instances of PaperCut need to remove public internet access where possible, and begin hunting for signs of compromise, such as looking for 'Database error looking up cardID: VALUES CAST' errors in log files."
Read more »
Microsoft Edge
browser data Chrome Extension Chrome Web Store cryptocurrency malware Microsoft Edge

Chrome, Edge Extensions Found Stealing Cryptocurrency and Browser Data

 



Nineteen browser extensions for Google Chrome and Microsoft Edge were used to deliver a modular malware framework capable of draining cryptocurrency wallets, stealing credentials and account data, extracting browser history, and displaying ClickFix-style lures.

Application security company Socket identified 18 malicious Chrome extensions and one Microsoft Edge extension as part of a campaign it says may have been operating since February 2024. The extensions contained separate JavaScript modules for different forms of data theft and could receive additional payloads from attacker-controlled infrastructure.

Several of the extensions initially provided the functionality described on their store listings and did not contain malicious code when first published. Socket found that five legitimate extensions were later acquired from their original developers and modified to include the malware. Malicious functionality was then distributed through updates, allowing existing users to receive the altered code without installing a new extension.

One affected extension, “Enable Right Click & Copy — Smart Unlock + OCR,” had at least 70,000 Chrome users when the malicious version appeared. Its Microsoft Edge version had around 10,000 users at the time.

The extensions connect to command-and-control servers through encrypted WebSocket connections. The servers can provide JavaScript modules to the extensions, allowing the operators to add or change functionality without replacing the entire extension. Socket found that the downloaded modules were encrypted before being stored locally and that the framework could use changing C2 infrastructure.

The malware also interferes with protections built into websites. It removes Content Security Policy headers from pages visited by the user, weakening restrictions that can prevent unauthorized scripts and other resources from executing. It then injects malicious JavaScript into websites using hidden HTML elements, giving the attackers a way to interact with pages opened by the victim.

Socket identified 16 malicious modules with different capabilities.

One group of modules targets cryptocurrency wallets across Ethereum Virtual Machine-compatible networks, Solana and Tron. The malware can interfere with legitimate “Connect Wallet” and “Swap” buttons, redirecting transactions or wallet connections to attacker-controlled destinations.

Another module targets users visiting Ledger and Trezor websites. Instead of allowing the legitimate pages to operate normally, the malware can replace them with convincing phishing pages designed to obtain wallet recovery seed phrases. Access to a seed phrase can give an attacker control over the associated cryptocurrency wallet.

The framework also targets cryptocurrency services including Coinbase, Binance, Kraken, OKX, MEXC, KuCoin, Bybit and MetaMask. Its modules can collect session information, authentication tokens, account details and wallet balances from these services.

Credential theft extends beyond cryptocurrency platforms. A separate component can record information entered into forms across websites, including usernames, passwords and other form data. Additional modules collect information associated with Facebook and LinkedIn accounts, while another extracts browser history.

The campaign also incorporates ClickFix-style social engineering. The malware can display fake browser-update messages that instruct users to perform actions on their computers. In the observed implementation, the attacker can place a command in the clipboard and persuade the victim to paste and execute it. This technique shifts part of the attack from automated browser compromise to user-assisted execution.

The extension acquisition strategy adds another layer to the campaign. Browser extensions can receive updates after installation, meaning users who originally downloaded a legitimate utility may later receive altered code. Chrome's extension update process can automatically check for and install updates, so the user does not necessarily need to revisit the Chrome Web Store for the malicious version to reach an existing installation.

Google removed the identified malicious extensions from the Chrome Web Store. Socket also reported the Microsoft Edge extension to Microsoft. At the time of Socket's investigation, however, the Edge version remained available and its operators had changed the C2 domain used by the malware.

Socket said the 16 modules it identified may not represent the framework's complete capabilities. Its modular design allows operators to introduce additional functionality and deploy new payloads through the C2 infrastructure.

Users who installed any of the affected extensions should remove them and treat credentials entered while the extensions were active as potentially exposed. Passwords for affected accounts should be changed, with additional authentication protections enabled where available.

Cryptocurrency users whose wallets may have been exposed should consider the wallet compromised and transfer remaining assets to a newly created wallet with a newly generated recovery phrase.

Read more »
Zero-Day Flaw
Emergency Patch PaperCut Vulnerabilities and Exploits Zero-Day Flaw

PaperCut Zero-Days Exploited, Emergency Patch Released

 

PaperCut Software has released a second emergency patch after confirming that attackers exploited two zero-day vulnerabilities in its NG and MF print management products. The flaws can be abused by unauthenticated attackers to bypass authentication and achieve remote code execution on affected PaperCut instances. 

The two issues are tracked as CVE-2026-81578 and CVE-2026-82078. CVE-2026-81578 is a high-severity authentication bypass that lets a remote attacker modify certain system configurations, while CVE-2026-82078 is a critical weakness tied to unsafe dynamic class loading in the database connection utilities. 

PaperCut said that if an attacker can manipulate system configuration parameters, arbitrary Java bytecode on the application classpath may execute under the security context of the PaperCut server process. The company first issued a security bulletin on August 27, then released an emergency patch on August 28 for versions 25 and 26, followed by a second patch later the same day to add more hardening, including support for version 24. 

Security firms monitoring the exploitation, including Huntress and WatchTowr, helped clarify that the incident involved two zero-days rather than one. WatchTowr said it found multiple patch bypasses and an additional authentication bypass flaw, which appears to have driven the need for the second emergency release. Huntress reported attacks against at least two customers, with the first exploitation attempts seen on August 26. The observed activity has so far focused on system discovery, and investigators have not seen secondary malware, command-and-control traffic, or signs of persistence from the recovered payload. 

PaperCut continues to update its advisory and is still working on a full official release that patches both vulnerabilities. The vendor also published indicators of compromise, giving defenders additional artifacts to search for across exposed systems. The wider risk is significant because PaperCut has been targeted before, and CISA’s Known Exploited Vulnerabilities catalog already includes three other PaperCut flaws, two of which were used in ransomware attacks. ShadowServer data suggests roughly 1,000 PaperCut instances are exposed on the internet, with most located in North America and Europe, making timely patching and exposure review essential for organizations running these print management platforms.
Read more »
Red Team
AI AI Pentesting GLM-5.3 LLM cybersecurity Pentesting Red Team

How We Find Critical Vulnerabilities with GLM 5.3 and Red Clippy

Over the last few months our red team exercises for BFSI customers have been run with an AI coding agent sitting in the loop. The findings that came out of them were the usual serious ones: broken authentication, unauthenticated access to sensitive data, an OTP bypass, SSRF, stored XSS, a login form that let us straight in with the password field left empty, a customer search that handed back the entire database when given a wildcard, and on one engagement a payment gateway secret key shipped inside a JavaScript bundle that every visitor's browser downloads.

None of that is exotic. Testers have been finding these things for twenty years. What changed for us was how the work got done, and more importantly, how it got kept.

Give a coding agent a shell and it turns into a fast, tireless tester. It runs the same tools you do. It will read a four megabyte minified bundle line by line without complaining, which is a thing no human on the team volunteers for. It will enumerate an API surface while you are still reading the scope document.

The trouble starts about forty minutes in. The context window fills up. The session compacts, or it ends and you start a fresh one the next morning, and the engagement goes with it. The new session re-scans hosts it already cleared. It re-tests things it already ruled out. Ask it which parts of the scope have been covered and it cannot tell you, because it does not know. And somewhere in a transcript nobody kept there is a confirmed injection that never made it into the report.

That is the problem Red Clippy(https://github.com/CSPF-Founder/red-clippy) exists to solve.

An engagement overview. All the screenshots here come from the project's demo database, not from a customer engagement.

It is not an AI pentesting framework

Red Clippy has no scanning engine of its own, no autonomous attack logic, and no opinion about what should be tested next. It will not find a vulnerability for you.

What it does is keep the record of an engagement while an agent does the testing and you direct it. Targets, scope, what has already been tested, findings, evidence. That is the whole job.

It is built for testers who already know what they are doing and want to use Claude Code, Codex CLI, or any other MCP-compatible client alongside their normal workflow. You define the target and scope in the panel, or paste the customer's scope list into the chat and let the agent enter it. From there you guide the agent however you like, the same way you would guide a junior on the team, and it writes down what it did as it goes.

That turns out to be useful for four things: knowing what has already been tested, checking the same finding across multiple domains and assets, keeping engagement history for periodic retesting, and not having to rely on the model remembering everything or on a folder of text files pretending to be a database.

The setup

Three pieces, all on one machine. GLM 5.3 from z.ai does the reasoning. Claude Code is the client, providing the shell, the file access and the agent loop. Red Clippy holds the record and connects to Claude Code over MCP.

Because it is a client rather than a model, and z.ai serves an Anthropic-compatible endpoint, you can point one at the other and keep the agent harness you already know. The setup is documented on the project page, so we will not repeat it here.

MCP runs client-side, so Red Clippy does not know which model is behind the agent and the tools behave the same either way. That means the discipline of the engagement is not tied to a model you happen to be using this quarter. If we move off GLM next year, the record, the coverage and the findings all survive the move.

The rules arrive before the first tool call

This is the part most people skip when they wire an agent into a workflow, and it is the one that changed our output the most.

An agent that has to ask for the rules of engagement generally will not bother. So Red Clippy hands over a Red Team Instructions document during the MCP handshake, before the agent makes its first tool call. It is one document, not a system prompt maintained in five places, and the most specific one wins: a per-engagement override if there is one, otherwise the organization default, otherwise the built-in.

The Red Team Instructions document, served to every agent on connect and overridable per organization and per engagement.

Most of it is unglamorous. The line that matters most on BFSI work is the one about taking the minimum access needed to show impact. An agent that proves an unauthenticated data exposure by retrieving three records and stopping has given you a finding. An agent that helpfully retrieves the whole table has given you a very different conversation with the customer.

The rest is tradecraft, and that is where several of our critical findings actually came from: read the main bundle rather than grepping it, trigger errors deliberately and read the whole response, strip the auth header and retry, then change the identifiers and see whose data comes back.

None of that is new methodology. It is what a competent tester does anyway. The difference is that it is in the agent's context on every connect, without anyone remembering to paste it in.

Setting up an engagement

You create the pentest, paste in the scope from the engagement letter, mark the in-scope domains and ranges, and mark the exclusions. You can type them yourself or let the agent enter them from the customer's list. Either way you read them before anything gets touched.

Scope units are assets, each with its own checklist, reachability marking and in or out of scope flag.

After that you drive, and the instructions are duller than people expect. "Do the initial recon first, subdomain enumeration across the in-scope domains." "Now go through the asset list, pick up whatever is still untested, and mark the checks off as you clear them." The agent runs its own tools from its own shell, the way it would anyway, and posts the results back as it works. Raw scanner output goes in with a single call and gets parsed automatically, whether it came from nmap, Burp, Nessus, OpenVAS, masscan, naabu or subfinder. The things you are actually testing become assets. Everything else stays an observation attached to an asset. Findings go in with severity, a CVSS vector, a proof of concept and the evidence that backs it.

There are 82 MCP tools, which is nearly everything the panel itself can do. That matters more than it sounds, because a tool set that only covers half the application forces you back into the browser mid-session to finish what the agent started. Anything the agent writes you can write yourself, and anything you write it can read. You can run the engagement entirely by hand, entirely through the agent, or switch between the two in the middle of a session.

What a record does that a transcript cannot

The interesting part is not that the agent is fast, although it is. It is that the work survives the session it was done in.

Recon noise stays out of the scope list, which is why it survives

Every content discovery run produces hundreds of paths. Every bundle you read produces endpoints, internal hostnames, technology fingerprints and, now and then, a secret. Throw all of that into an asset list and the asset list is useless by lunchtime.

Red Clippy separates the two. The things you are testing are assets. Everything else is an observation hanging off the asset it came from, with a kind and the tool that found it.


A few observations are findings in their own right, like a key that should never have been public. Most are leads, and the leads are what pay off later. On our engagements, unauthenticated access to sensitive data came from an API path pulled out of a bundle, called with no auth header, that returned data.

In a transcript that path scrolls away. As an observation it is still there tomorrow, attached to the right host, with the tool that found it recorded alongside.

Correlating things that happened days apart

The findings that matter are rarely one observation. They are usually two, made hours or days apart, that mean something together.

Reading the front-end bundle early in an engagement turns up internal hostnames. They go into the record and testing moves on. Days later, a parameter that fetches a remote image turns out to make outbound requests.

An SSRF is only worth what you can reach with it, and the hostnames from the first day are what you point it at. Making that connection requires the first day's record to still be there, and searchable, when you need it days later. That is exactly what a context window does not give you.

Red Clippy makes those joins explicit. Every finding carries tags for the asset it affects and the check it came from, so it files itself under both. The attack graph lets you link any two things, an observation, an asset or a finding, with a label of your own, then follow the links out from one or trace the route between two. The chain from "hostname found in the bundle" to "reachable through SSRF" to "admin interface behind it" is saved, rather than something to piece back together when the report is written.

Correlating across engagements

A customer is rarely one engagement. There is this quarter's, last quarter's, and the retest after that.

Because those engagements share a record, any host or IP can be asked about across all of them at once. Have we tested this before? What did we find? Was it reachable last time?

That pays off twice over. A critical bug in one API is a question about every other API the customer has: we confirmed one in a session, and a later session testing a different domain found the same bug there, because the first finding was something to check the new asset against rather than a paragraph in a transcript nobody reopened. And a host that was blocked last quarter but answers this one has almost never changed. It is a source address or a VPN, and knowing that saves an hour of chasing a WAF that is not there.

The same goes for paths. Whatever was recorded for a host in an earlier engagement can be pulled into the current one, so you get last round's content discovery for free and can see at once whether what you reported then is still live.

Coverage you can query instead of remember

There are 135 built-in checks mapped to OWASP WSTG, plus recon, network, cloud and OSINT checks, tracked per asset.


This is the best defence we have found against the way agent-driven testing actually goes wrong. It is not hallucination. It is skimming. An agent that stumbles onto an interesting SQL injection in the first twenty minutes will happily spend the rest of the session on it and then report a thoroughly successful engagement.

Asking what is left on an asset gives you the current state of every check, so "what have I not looked at on this host" becomes a question with an answer. Marking a check as not applicable counts as resolved, and that matters: "we looked, there is no file upload here" is a genuine testing outcome and belongs in the record rather than sitting in the untested pile forever.

The auth, authz and session categories are where OTP bypass and broken authentication live, and they are exactly the checks an excited agent skips on its way to something noisier. The blank password came out of exactly that part of the list: a login check nobody would call interesting, and a form that issued a valid session when the password field was submitted empty. Nothing would have gone back to that check if the record had not been sitting there saying it was untested. A count of resolved checks against the total is an honest statement about where an engagement stands. "I tested the application thoroughly" is not.

Findings that hold up to review

A finding has to stand on its own, because whoever reviews it will not have the tester sitting next to them explaining what they meant.



A finding carries severity and status, a CVSS vector, CWE and CVE, and separate fields for details, impact, proof of concept and remediation, because those are what a report needs and what a reviewer checks.


The proof of concept field is the one that does the work. It either contains steps that reproduce or it does not, and a reviewer can tell which without asking anyone. Evidence attaches to the finding itself rather than living in a folder someone has to match up later.


The rules for writing a finding sit inside the tool the agent calls to file one, so it reads them as it writes rather than somewhere far back in the session. They tell it to keep each field to a paragraph, keep hostnames out of the title, and say what needs to change in the remediation instead of pasting config and version numbers that may be wrong for the customer's stack.

What the human still does

The agent is fast and it is sometimes wrong, and the workflow assumes both. Everything it writes is an ordinary row in the browser that you can edit, reclassify or delete, and it picks up your corrections the next time it reads.

Three habits do the work. We read the findings themselves rather than the agent's account of them, because the finding rows are what the customer actually gets. We check the coverage before believing any of it, because an agent can come back with six findings having cleared nine checks out of 135. Findings are not coverage. And we set the severity ourselves, because whether something is a finding at all, and how bad it is, is a call a human should make.

The thing that does not change is responsibility. Scope marking and the Red Team Instructions are guardrails, not authorisation. Red team exercises run under a signed engagement letter, and the agent acts entirely on your authority. Everything it does is yours.

What the model does and what the record does

GLM 5.3 does the reasoning. Reading a minified bundle and noticing that a string is a live key. Stripping the auth header off a request and noticing the data still comes back. Putting a single wildcard into a customer search field, then reading the response closely enough to work out that it had returned every customer in the database rather than an error. Going back at an OTP flow after the obvious attempt failed. That is a model capability question, and a better model gives you better testing.

Red Clippy is what makes that add up to an engagement. It contributes memory, correlation, coverage and evidence discipline, and it contributes them identically regardless of what is driving the agent. The two together are why a session ending no longer takes the engagement with it.

Red Clippy was originally our own internal tool, built for our engagements. We have now put it out publicly, because we think other testers will get the same use out of it. It is open source, from the Cyber Security and Privacy Foundation. Source is at github.com/CSPF-Founder/red-clippy and the documentation, including how to set all of this up, is at cspf-founder.github.io/red-clippy. Bug reports and any other contributions are welcome.
Read more »
Fingerprint
biometric data privacy Cyber Security data security Device Security Face ID Face ID security Fingerprint

Face ID and Fingerprint Unlocks May Put Your Privacy at Risk

 

Face ID and fingerprint unlock features allow for more convenient smartphone and account access but offer less privacy in the case of forced disclosure. According to PCMag , the police can compel an individual to unlock a phone using biometrics but not with a pin or password. The debate over the convenience versus safety of biometric verification became a heated topic this year after the FBI stormed the home of Washington Post reporter Hannah Natanson. 

The court records obtained by the 404 Media revealed that the bureau was unable to open Natanson’s iPhone due to it being protected by Lockdown mode. However, a federal judge later issued a warrant compelling Natanson to unlock her computer using fingerprint. Facial recognition and fingerprint scans are termed biometrics. They can be used to authorize access to computers, phones, and other technology. With passkeys, one can also digitally unlock online accounts and services. 

A passkey can be generated using biometrics or a passcode on a device with lock options. PCmag points out that there is nothing wrong with wanting convenience over security. On the contrary, those at higher risk of government and corporate surveillance and thus prone to coercion should consider using a passcode or passphrase instead of biometric verification. iPhone users can also consider using Lockdown mode. This setting is useful in preventing unauthorized access to the device by eliminating the option of attaching files through messages, installing device management configuration profiles, calls, and FaceTime. 

The option is available in Settings under Privacy and Security. Android also has a lockdown setting that can be used to disable biometric options to secure the smartphone in cases where the owner is fearful that their fingerprint or facial scan might be compromised. Android 13 and later versions offer Advanced Protection mode which requires hardware security keys or passkeys to access Google accounts. It also prevents the downloading of malicious apps and files and stops unauthorized access to Google services by third-party apps. Those wishing to turn off biometric verification can delete their prints or scans from their devices. 

According to PCmag , fingerprints and facial scans are saved on the phone or computer and not on the cloud. Android users can delete their biometric data by heading to Security and Privacy and tapping Device unlock/Biometrics and setting a passcode. iPhone users can go to Face ID/Touch ID & Passcode and reset Face ID or delete their fingerprint. 

PCMag contends that phone security is only a small component of personal security. One should also read the terms and conditions of technology companies, close online accounts that are not necessary, reduce digital footprints, and utilize different strong passwords to gain more control of personal data.
Read more »
Sensitive Employee Data
Corporate Data Breach Cybersecurity Incident Data Breach Employee Data Breach Employee Personal Information Hasbro Cyberattack Sensitive Employee Data

Hasbro Data Breach Impacts Employee Personal Information


The Hasbro Company has notified its employees that their personal information could have been exposed as a result of a data breach involving one of their compromised employee accounts. The company informed the Massachusetts Attorney General's Office of the incident in breach notification letters. 

As indicated in the notices, the information involved varies according to the individual and can include names, email addresses, postal addresses, phone numbers, national identification numbers, and financial information. Hasbro has not provided any information about the number of individuals affected or the date of discovery of the breach. It has been reported that, according to records published by the Massachusetts Attorney General's Office, 436 residents of the state were affected. 

The company has approximately 4,600 employees worldwide, with a significant number based in the United States. Hasbro may have suffered a cyber attack in late March that resulted in the company shutting down several systems. While working to contain the cyberattack, the disruption affected its operations. 

Immediately following the incident, Hasbro disabled the compromised employee account, terminated unauthorized access, and implemented additional security measures. There has been no public disclosure of how the account was compromised or whether attackers were able to access the exposed information. Among the information affected by the breach in Massachusetts was the social security number of the employee, financial account details, credit card information, and driver's license data. 

Details of Hasbro Breach Remain Limited 

It has not been disclosed by Hasbro how the employee account was compromised, the duration of the unauthorized access, or whether the information was actually removed from its systems. Based on the company's notification, it appears that the information involved differs between affected individuals, making it difficult to establish the exact scope of the exposure. Furthermore, it has been raised that the incident may have extended beyond employee records. 

Public reporting has not established whether customer information was accessed, nor has a ransom demand or the identity of the attackers been confirmed. The employee data incident occurs months after Hasbro released a separate cyberattack on March 28 that compromised its data. Due to that attack, some of the company's systems were taken offline, disrupting manufacturing, shipping and order processing. 

Hasbro warned that delays could continue for weeks and hired third-party forensic specialists to investigate the incident. Although there is no indication that the March attack was directly related to the employee data breach, the available reporting does not suggest a direct link. If Hasbro does not provide evidence linking the two incidents, it is more accurate to treat the two incidents as separate events. 

Hasbro's disruption extended beyond corporate systems, affecting the company's ability to produce products, ship orders, and process new orders as well. However, the March attack nonetheless illustrates the broader impact a compromise can have on a major manufacturer. In the case of employees whose Social Security numbers, financial details, payment card information, or driver's license data was compromised, the consequences could extend beyond the initial disclosure.

Identity theft, fraudulent transactions, targeted phishing campaigns, and attempts to gain access to other accounts can all be perpetrated using this information. As a result of the compromised employee account being disabled, unauthorized access was ended, and additional safeguards were implemented. There have been no additional public details provided by the company regarding the technical cause of this compromise or the procedure used to determine the full extent to which the data was exposed. 

Hasbro Provides Protection Services to Affected Employees

Upon conducting an investigation with the assistance of external cybersecurity specialists, Hasbro concluded that personal information belonging to current and former employees may have been accessed during the incident. Hasbro reported that there are no indications of misuse of the exposed information at the time. As a precaution, Hasbro is offering identity protection services to affected individuals through a third-party provider. 

The company advised those affected to monitor their account statements as well as obtain their free credit reports in order to detect any unusual activity. Following the investigation, Hasbro said additional safeguards were implemented. The circumstances surrounding the exposure remain unclear. Hasbro has not confirmed whether customer information was exposed, nor has it made any disclosure as to whether ransom was demanded by the attackers. 

A threat actor has also not been publicly identified by the company. A question was made regarding whether the employee-data exposure was related to the March cyberattack, but Hasbro did not confirm an association between the two incidents. Hasbro suffered significant financial losses as a result of the earlier attack. Approximately $25 million was lost from revenue as a result of operational disruptions, and approximately $11 million was spent responding to and cleaning up the incident directly. 

As no further information has been released regarding the compromised account or the number of individuals affected, it is unclear as to the extent of the employee-data exposure. Despite Hasbro's latest disclosure confirming employee information was compromised, key questions about the intrusion and its relationship with the earlier cyberattack remain unanswered. 

In light of this incident, it becomes evident that compromised employee accounts pose serious risks as well as the potential impact of unauthorized access to sensitive workforce data. In order to determine the full scope of the breach, Hasbro will need to conduct a thorough investigation and implement protective measures.
Read more »
Royal Navy
British Military Chinese Cameras cyber espionage Cyber Security K3 Surveillance Drones Royal Navy

British Navy Drones Flagged Over China Link

 

British military drones have come under attention after a report claimed that Chinese-made cameras fitted in Royal Navy K3 surveillance drones were sending signals to an internet address in China. The drones were part of a defense package linked to Britain’s plans to help secure freedom of navigation in the Strait of Hormuz, and they had already been used in preparations for the Gulf mission. 

According to the report, the issue was found in drones used by the elite Royal Marines and supplied through Kraken Technology Group, a British defense contractor. The cameras were obtained from a third-party supplier that had given assurances about their security, but an investigation later found “heartbeat communications” from the devices to an IP address in China. Those signals were said to confirm that the cameras were online and functioning normally. 

The Ministry of Defence has rejected the suggestion that sensitive information was exposed. An MoD spokesperson said a routine cyber vulnerability assessment found an issue involving a Kraken Unmanned Surface Vessel subsystem, but that a thorough investigation found no evidence that MoD data or systems were accessed, compromised, or transmitted externally. After the problem was identified, internet connectivity was removed from the cameras. 

The report has revived wider concerns in Britain about Chinese-linked components in strategic systems. The K3 Scout model has also been bought by the US Special Operations Command and has taken part in NATO trials in the Baltic, which has added to the sensitivity around the case. Conservative figures have called for an urgent audit of military equipment for hidden Chinese parts and other vulnerabilities. 

The controversy also fits into a longer pattern of British security warnings about China. The UK banned Huawei from its 5G network in 2020 over national security concerns, while MI5 later warned lawmakers that Chinese intelligence services were trying to interfere with and influence Parliament. In that context, the drone-camera episode is likely to intensify pressure on the government to tighten supply-chain checks and reassure allies that Britain’s military systems remain secure.
Read more »
Russia
agentic AI AI Systems Aurora Cursor Cyber Attacks Hackers ransomware Russia

Russian-Speaking Hackers Used Cursor AI Agent to Target Seven Companies

 


Russian-speaking cybercriminals from the emerging Aur0ra ransomware group used Cursor's AI coding agent to assist attacks against at least seven companies earlier this year, exploiting the system's safeguards by repeatedly presenting malicious activity as an authorised security simulation.

The campaign, dissected by cybersecurity researchers at Gambit Security, provides another example of commercial AI agents being repurposed to accelerate cyberattacks. The incident also demonstrates a growing security problem for agentic AI systems: attackers may not need to defeat technical controls directly if they can persuade an AI system that a harmful operation is legitimate.

Gambit uncovered the activity after locating an internet-exposed server belonging to Aur0ra. Researchers were able to examine 28 conversations between the attackers and a Cursor AI agent, covering activity from April 8 through May 21.

The conversations showed the attackers directing the agent through hundreds of operations associated with intrusion activity, including credential theft, password discovery, account takeover and exploitation of vulnerable systems. The operators used short, direct commands and repeatedly represented the activity as a controlled test environment.

In one exchange, the attackers instructed the agent to locate administrator credentials and working passwords. Elsewhere, the agent assisted with network access and password cracking. After a vulnerable system was identified within German garage-door manufacturer Teckentrup's network, the agent recommended a known offensive security tool and assessed the likelihood of successful exploitation as very high.

The activity affected organisations across several countries and industries. Reuters identified Belgian hygiene and cleaning-products manufacturer Christeyns, Teckentrup in Germany, Scotland's Helideck Certification Agency, an Argentine pharmaceutical distributor, an Italian manufacturer and Louisiana-based title insurance company Bayou Title among the victims. Aur0ra's activity indicated at least 20 victims overall, although it remains unclear how many were compromised using Cursor.

The available evidence also does not establish that every intrusion resulted in successful data theft or extortion. Bayou Title, however, appeared on Aur0ra's data-leak site, a development generally associated with ransomware operations in which attackers seek leverage over victims.

A central feature of the campaign was the attackers' ability to circumvent the AI agent's refusals. According to Gambit, Cursor occasionally rejected requests it considered harmful or illegal. The operators frequently responded by restarting conversations and reiterating that they were conducting a legitimate simulation.

The chat records therefore point to a form of social engineering directed at the AI itself. Rather than exploiting a software vulnerability, the attackers manipulated the agent's interpretation of the task until its safeguards permitted activity that would otherwise have been rejected.

Gambit estimated that the AI assistance could have made the operators between 30% and 50% faster by reducing the amount of manual work required during the intrusions. The researchers said the agent was powered by Anthropic's Claude Sonnet 4.5. Neither Anthropic nor Cursor responded to Reuters' requests for comment.

The timing adds another layer to the incident. Cursor officially became part of SpaceX on August 14, following an acquisition process that began earlier in the year. Cursor describes its agents as capable of performing real development work, while its security documentation states that terminal commands and sensitive actions are subject to approval controls by default. The company also warns that AI agents can behave unexpectedly because of prompt injection and other failures.

Those safeguards are therefore only one part of the security boundary. The Aur0ra campaign illustrates the difficulty of distinguishing legitimate security testing from malicious activity when an AI agent relies heavily on instructions supplied through conversation.

The incident arrives amid increasing evidence that AI systems are becoming useful components of offensive cyber operations. As agents gain the ability to execute commands, access files, interact with networks and perform multistep tasks, their usefulness to legitimate developers can also increase their value to attackers.

For security teams, the case reinforces the need to treat AI agents as privileged software rather than ordinary productivity tools. Restricting network access, limiting credentials and secrets exposed to agents, requiring human approval for sensitive operations and maintaining detailed activity logs can reduce the consequences if an agent is manipulated.

As Gambit's Curtis Simpson put it, the relationship between AI providers and malicious users is likely to remain a continuous contest. The Aur0ra campaign suggests that this contest is no longer limited to developing better models. It increasingly concerns whether AI agents can reliably distinguish the user's stated purpose from what the user is actually attempting to accomplish.

Read more »
Vulnerabilities and Exploits
Blockchain Exploit blockchain hacks Cosmos Blockchain Security Cosmos EVM Vulnerability Cosmos Labs cryptocurrency security EVM Vulnerability Vulnerabilities and Exploits

Attackers Exploit Cosmos EVM Flaw Affecting Multiple Blockchain Networks


Cosmos EVM Flaw Exploited After Widespread Blockchain Exposure Was Confirmed It has been revealed that Cosmos Labs has disclosed exploiting a critical vulnerability in its shared Cosmos EVM module, which resulted in the exploitation of funds from six blockchain networks between August 20 and August 25, 2026. GHSA-7g4w-cg88-2cq2 affects Cosmos EVM versions below 0.6.2 and versions between 0.7.0 and 0.7.1 

Cosmos Labs has classified the issue as Critical, however the advisory is not accompanied by a CVE, weakness classification, or CVSS score. In the versions 0.6.2 and 0.7.2 patches, state-breaking changes were introduced, so affected chains were required to perform coordinated network upgrades. Cosmos Labs has advised operators that if they cannot complete an immediate upgrade, they should cease operations, rather than proceed with governance-based upgrades while remaining exposed. 

A vulnerability was reported by the company on April 25 through a bug bounty program. Following a failure by Cosmos Labs to reproduce the issue on networks using 18-decimal configurations, the team initially concluded that the issue did not pose a threat to funds on live networks. It turned out that assessment was incorrect as the team established on August 13 that the vulnerability affected Cosmos EVM chains regardless of their decimal configurations. 

After the flaw was discovered, Cosmos Labs developed a public silent-patch process, which was designed to address vulnerability that does not present a risk of fund loss on production networks. The patch was released on August 19, one day prior to the first reported exploit. It has since been revealed that several affected blockchains have halt their chains following successful attacks on their funds. KiiChain and TAC have halted their chains as a result, while MANTRA has temporarily closed its mainnet and later restarted it after the fix has been applied. 

Three Networks Confirm Cosmos EVM Exploitation

A security incident was reported by MANTRA among the first networks. The team initially described the incident as a result of an upstream dependency, which led to a halt of the chain. The team said user balances were not impacted, while two wallets controlled by MANTRA were compromised. The vulnerable component was identified by MANTRA as the Cosmos EVM module and reported that version 8.4.0 had been released to address the issue, resulting in the normal block production process returning. 

In August, KiiChain confirmed a direct exploitation of the vulnerability. The attacker reportedly utilized the same technique 18 times, draining 148,326,583.15 KII before the network was halted at block 9,355,723 by validators. According to KiiChain, the vulnerability can only be found in the Cosmos EVM module rather than in its own chain-specific implementation of the Cosmos EVM module. This network has been suspended and is expected to resume via coordinated binary upgrades at a predetermined block height, with validators applying the new versions simultaneously. 

TAC also suspended its network at block 24,671,475 on August 22 after an attacker drained funds from a single account. The team attributed the vulnerability to the Cosmos EVM module instead of TAC-specific code. Cosmos Labs has informed affected teams that they should contact their security contact, and a more comprehensive incident report will be released once the situation has been resolved. The company has not disclosed what caused the vulnerability. 

Flaw Allowed Balance Manipulation Across Affected Chains

This vulnerability is associated with the way Cosmos EVM reconciles Ethereum-style account balances with Cosmos SDK's x/bank module. The EVM tracks the balance of an account, and vesting accounts may also contain funds that remain locked. Staking functions are still capable of delegating locked funds. 

An underflow of balance could occur if a vesting account delegated more than its available spendable balance. In lieu of rejecting the transaction, the calculation wrapped the balance into an extremely large UINT256 value. Cosmos EVM was then able to interpret the altered balance as newly created funds during reconciliation. The same mechanism could also be used against another account. Attackers could transfer artificially inflated amounts to victims' accounts, resulting in the subsequent reconciliation process burning their legitimate balances. 

By creating vesting accounts without permission, the attack was successful. Using a contract deployed at a predetermined address, the attack was completed in a single transaction. This was a result of an underflow check introduced in May that was then backported to the release branches affected by the issue. The handling of locked balances has also been corrected, and a separate safeguard has restricted modifications to module accounts involving balance modifications. 

Patch Distribution Drew Scrutiny

Along with the technical issue, Cosmos Labs' handling of the vulnerability has become a major concern. Cosmos Labs confirmed on August 13 that the issue affected Cosmos EVM networks regardless of their decimal configuration, however, a silent patch process was used to apply the patch. 

Shortly after the patched releases became available on August 19, a public pull request was made in Push Chain's Cosmos EVM fork, describing the vulnerability and its exploitation method. A less than 12-hour period later Cosmos Labs reported the first reported attack on MANTRA. It is believed that six networks have been exposed to the exploit.

On the basis of information provided by the affected chains, approximately $2.87 million worth of assets were traded through decentralized exchanges, while another $2.85 million was traded through centralized exchanges. The figures have not been independently audited. 

Cosmos Labs reports that 11 Cosmos EVM deployments that had not registered security contacts were discovered during the incident. The incident has also highlighted difficulties in reaching downstream operators. Due to the fact that there are over 115 public blockchains in the Cosmos ecosystem and no database of the networks that run its software, distributing urgent security updates remains a complex effort.
Read more »
Malicious Software
Cyber Attacks Cyber Security Ransomware Attacks Cyber Threat Intelligence financial attack Google Microsoft Hacker attack Malicious Software

Storm-1175 Deploys StormEncryptor Ransomware After N-able N-central Vulnerability Exploitation

 

Financially motivated hackers believed to be based in China are using a new ransomware for the first time after targeting a vulnerability in the N-central remote monitoring and management software. The threat group, which goes by the name Storm-1175, started deploying C++ StormEncryptor ransomware on August 2, following several months of inactivity since April, Microsoft Threat Intelligence said today. 

It marks a departure from the Medusa ransomware previously used by the group. Microsoft says that Storm-1175 most likely used a publicly known zero-day vulnerability, CVE-2026-18577, which was identified as the weakness Storm-1175 attackers used to gain unauthorized access to N-central. N-central is a remote monitoring and management solution used to track and patch servers and endpoints, Microsoft says. 

It means that successful exploitation of the vulnerability allows the attackers to target downstream organizations managed by the N-central server. N-able released a statement saying that it identified active exploitation of the zero-day vulnerability for the first time on July 31. Its initial advisory underestimated the scope of the problem, while the first patch was ineffective against active attacks. The company later released two additional emergency patches. 

Rapid7 reports that CVE-2026-18577 was published on August 2, following an ineffective attempt to address another authentication bypass vulnerability, CVE-2026-18556. The newly discovered weakness has a CVSS score of 8.2 and was added to the CISA Known Exploited Vulnerabilities catalog on August 3. Huntress says that attackers could abuse Take Control Manager to deploy Cloudflare-based tunnels on the N-central servers and gain access to downstream managed endpoints as well as the initial compromise via Take Control Manager.  

Microsoft notes that Storm-1175 actors are accelerating the ransomware lifecycle and are already targeting downstream victims for ransom within 24 hours of initial access. The group is using AnyDesk or SimpleHelp, Advanced IP Scanner for reconnaissance, and Mimikatz to dump credentials from the LSASS process. Storm-1175 ransomware encrypts files and demands payment, threatening to release the data within three days. Several organizations, including companies involved in e-commerce, fintech, healthcare, and home security, have been reported on the group’s ransomware site. Storm-1175’s ransomware activity is similar to the Medusa ransomware campaigns previously attributed to the same hacking group. 

Microsoft says in its report that Storm-1175 actors are also abusing legitimate remote monitoring and management software in order to maintain persistent access to the corporate network and downstream organizations. The company says that attackers can use Take Control Manager to deploy additional implants, establish alternate C2 channels, and interact with the compromised servers or endpoints. 

Attackers could use Remote Desktop Protocol (RDP) to connect to the domain controllers and install software such as PSExec or Windows Management Instrumentation to access other computers. With the domain controllers compromised, the attackers would be able to steal Active Directory data, including user credentials and the hashes of passwords, to gain more visibility and control over the corporate network.
Read more »
water infrastructure
Cyber Attacks FBI cyberattack Kansas water sector cyberattack Micro-Comm ransomware attack water infrastructure

FBI Investigates Cyberattack on Kansas Water Technology Firm

 

The FBI is investigating a cyberattack targeting Micro-Comm, a Kansas-based company that develops technology used by water and wastewater utilities, adding to concerns over the security of America’s critical water infrastructure.

The incident at the Olathe, Kansas, company was confirmed by both Micro-Comm and the FBI. It does not appear to be connected to a suspected Iran-linked cyber campaign that targeted water facilities in Minnesota and several other U.S. states beginning in July. However, the breach underscores the broader cybersecurity risks facing water systems and the technology providers that support them.

A ransomware operation known as Barracuda, which describes itself as financially motivated and independent of government sponsorship, claimed responsibility for the attack. On August 6, the group released what it said were nearly 850,000 company files, totaling about 644 gigabytes of data.

Micro-Comm produces programmable logic controllers (PLCs), computerized systems that help control machinery used in critical infrastructure, including wastewater treatment facilities.

The attack came as U.S. authorities were already dealing with a series of intrusions targeting PLCs in Minnesota and at least six other states in late July. Cybersecurity specialists have linked those incidents to an ongoing campaign allegedly associated with Iran.

On July 30, the FBI and the Cybersecurity and Infrastructure Security Agency (CISA) warned that cybercriminals were actively targeting PLCs manufactured by U.S.-based Rockwell Automation, France’s Schneider Electric and Germany’s Siemens.

CISA later reported on August 19 that attackers were using artificial intelligence to make attacks against Siemens systems more efficient. Siemens said it was working with CISA and maintained that its products remain secure.

Dixon Land, a spokesperson for the FBI’s Kansas City field office, said in an email that the bureau was in communication with Micro-Comm and working alongside other law enforcement agencies. CISA directed questions about the incident to Micro-Comm.

Jim Cote, a co-owner of Micro-Comm, said the company detected the intrusion on July 31. According to Cote, the information released by the attackers did not contain sensitive data such as customer passwords or credentials, which are retained by individual clients. He also said the exposed material did not include information about Micro-Comm’s ability to remotely access its equipment.

In a client newsletter dated August 8, Micro-Comm described the incident as a limited malware attack and said sensitive information within the affected files had been encrypted. The company stated that the incident was "in no way related to water system hacks currently being reported on the news."

Cote said the FBI informed the company that the attack appeared to be opportunistic rather than a targeted operation against Micro-Comm. Despite that assessment, the company recommended that customers change their passwords as a precaution.

Data from internet-monitoring platform Censys indicates that around 200 deployments of Micro-Comm’s SCADAview CSX systems in the U.S. remain accessible online. Meanwhile, an index maintained by cybercrime research platform eCrime.ch reportedly contains references to public-sector customers, including municipalities and a U.S. military facility, as well as employee names and technical information such as system diagrams.

Tom Hegel, a senior threat researcher at cybersecurity company SentinelOne, said the leaked information does not suggest that any water facility experienced an operational shutdown. However, he warned that the information could potentially provide useful intelligence to malicious actors in the future.
Read more »
Hacker attack
Berlin Commissioner Data Breach data security Data Theft Government Network Security Hacker attack

Berlin Confirms Extortion Attempt After Network Compromise as Manchester Airports Group Reports Customer Data Theft

 

The state of Berlin confirms that it is the victim of an extortion attempt after allegedly having its network hacked back in August. Authorities say they will not give in to the hackers’ demands. 

Forensic analyses of the network of the Senate Department of Mobility, Transport, Climate Protection and the Environment have revealed additional data thefts outside the network in the period between August 7 and 12. The department had first noticed data loss on August 7 and had been cut off on August 14. Berlin is currently still investigating the extent and scope of the data loss, saying that it is possible that personal data or other confidential information had been accessed. 

The amount of data stolen in the cyber-attack on Berlin has not been disclosed officially; however, one entry on the dark web by the hackers’ group Rhysida, published on August 28, claims that 5,79 TB of data containing personal information of 12,076 people were stolen. The entry also stated that approximately 1,44 million files had been scanned. 

According to the post, the target of the attack was Berlin, Germany, without specifying any ransom value. Der Spiegel revealed that the ransom note was published by the hacker collective Rhysida, citing the group’s dark web blog and security sources. According to the report, a monitoring service confirmed on Friday that a post titled “Berlin, Germany” appeared on the leak site of Rhysida on August 28. Berlin has not officially attributed the attack to any hacker group. 

A joint security advisory released by the U.S. Cybersecurity and Infrastructure Security Agency, the FBI and the Multi-State Information Sharing and Analysis Center highlights that Rhysida has been abusing compromised legitimate usernames and passwords from remote access services and has been using phishing and the Zerologon vulnerability (CVE-2020-1472). The advisory recommends prioritizing the response to known exploited vulnerabilities, implementing multi-factor authentication and network segmentation. 

Berlin’s data protection commissioner and the Federal Office for Information Security have been informed of the attack. Interior Minister Iris Spranger stated that, according to preliminary information, no data from the election-relevant IT systems were removed from the network. Thus far, no election functions have been interrupted. Meanwhile, Manchester Airports Group (MAG) has announced that a cyber-security incident involving the unauthorized collection of customer data occurred at its UK airports. 

The personal data of passengers who booked car parking, lounges, or Fast Track services or who subscribed to in-airport WiFi were affected. The data compromised in the breach include customers’ email addresses, phone numbers, vehicle registration numbers, and postcode details. According to MAG, the data do not include customers’ payment or bank details, and no impact has been made on passengers’ safety or aviation safety or airport operations.

As of August 29, the online booking system, called Manage My Booking, has been temporarily offline for security reasons. It has been reported that affected customers have been contacted directly and have been warned to be vigilant of further communication attempts from unauthorized third parties.
Read more »
United States
Chinese Hackers Cyber Attacks Cyber espionage Botnet Attack Federal Agencies United States

US Says Chinese Hackers Hit Federal Agencies

 

The U.S. says a China-linked hacking operation broke into or targeted systems at NASA, the Federal Reserve, the Justice Department, the Senate, and other sensitive networks, then hid activity by routing traffic through a large botnet of compromised internet-connected devices. Authorities say they disrupted the operation by seizing domains tied to two hacking platforms, QScan and QTRouter. 

According to court filings cited by U.S. media, the campaign dates back to at least 2018 and extended across government agencies, hospitals, telecom firms, power companies, financial institutions, and defense contractors. The filings also list the Department of Energy, the Department of Health and Human Services, and the National Institutes of Health among the victims or targets.

Investigators say the group behind the activity was identified as QTFY, which was allegedly employed by the China-based Nanjing Xinjiuwei Network Technology Company. The DOJ says QTFY created and operated the two platforms to help customers infiltrate networks and cover their tracks. Reports say the services functioned as a paid hacking model, with QScan and QTRouter scanning for vulnerable devices, infecting them, and turning them into proxy nodes. 

The technical method was especially concerning because it relied on IoT devices that were easier to compromise than hardened corporate systems. By spreading traffic through those devices, the attackers could make malicious connections look ordinary and make attribution more difficult. U.S. officials said that tactic allowed the hackers to quietly reach into sensitive networks while reducing the chance of immediate detection. 

The case also shows how cyber operations can blend state interests, commercial tooling, and infrastructure abuse into one long-running campaign. Officials described the seizure as part of a wider push to disrupt Chinese-linked hacking against U.S. government systems and critical infrastructure. For security teams, the key lesson is that even well-defended institutions can be exposed when attackers use botnets, proxy layers, and broad scanning to find weak entry points.
Read more »
Subscribe to: Posts (Atom)