❌

Visualização de leitura

↗️

Linux Kernel 7.1 Reaches End of Life

✇Cybersecurity News
Por:Do Son

The Linux Kernel 7.1 EOL has officially arrived. Discover the final updates and learn why you must upgrade to the latest stable LTS releases immediately.

Related Posts:

The post Linux Kernel 7.1 Reaches End of Life appeared first on Daily CyberSecurity.

↗️

JSCeal Hides Crypto Malware in V8 Bytecode

✇Security Affairs
Por:Pierluigi Paganini

JSCeal hides crypto-stealing malware in V8 bytecode, but researchers built a tool to decompile it and expose its advanced theft capabilities.

JSCeal is a cryptocurrency stealer that Check Point Research has tracked since early 2025. Unlike most malware, it hides its code in a format that makes analysis much harder. Check Point presented its latest research at Black Hat USA 2026 and showed how its team built a tool that converts the hidden code into a form analysts can understand.

JSCeal uses a clever trick. Instead of delivering normal JavaScript, its creators compile the malware into V8 bytecode, the format that Chrome and Node.js use to run JavaScript efficiently. They then package the bytecode with a Node.js runtime that executes it.

The original JavaScript never reaches the victim’s computer. As a result, most tools designed to analyze JavaScript have little useful code to work with.

“JSCeal is a stealer delivered as compiled V8 bytecode (.jsc) and executed by a bundled Node.js runtime, targeting cryptocurrency applications (other vendors also tag it with the names WEEVILPROXY or MeadowLocust). ” states the report. “Unlike ordinary JavaScript malware, JSCeal reaches the analyst after two transformations have already removed much of the information that source-oriented tools depend on. First, the JavaScript is heavily obfuscated. Then it is compiled into V8’s internal bytecode representation and shipped as cached data rather than source code. The resulting format is version-specific, poorly served by mature reverse-engineering tooling, and unsuitable for most standard JavaScript deobfuscation workflows.”

Before compilation even happens, the JavaScript source gets run through a commercial-grade obfuscator too, adding a second wall on top of the first. Function and variable names get replaced with meaningless strings, important text gets split into encrypted chunks reconstructed only at runtime, and the program’s actual logic gets scrambled into a state machine that hides the real order operations execute in.

Stack two separate obfuscation techniques on top of each other, and you get a payload that’s expensive to analyze but was genuinely cheap for the attacker to produce, since none of these tools are custom-built; they’re just assembled from existing open-source components.

Check Point’s answer was building on top of View8, an existing open-source V8 bytecode decompiler, and extending it with a purpose-built pipeline specifically tuned to JSCeal’s patterns. The process has to happen in a strict sequence, because each layer of deobfuscation exposes information the next layer needs: recovering encrypted strings reveals dictionary keys, those keys unlock proxy function relationships, and cleaning up the proxies finally exposes what the code is actually doing underneath. Applied across 23 different JSCeal samples collected over several months, the pipeline produced usable, readable output in every single case.

What that recovered code actually shows is a genuinely broad toolkit built for financial theft. JSCeal steals saved passwords and cookies from eight different Chromium-based browsers, harvests Telegram session data, logs keystrokes, takes screenshots, and installs a locally generated, attacker-controlled certificate to intercept and modify HTTPS traffic in transit. That last capability lets it silently rewrite what a victim actually sees from real financial platforms, swapping login QR codes on Binance, injecting fake security challenges on Bybit, and replacing legitimate scripts served by Ledger’s own website with content the attacker controls.

One capability goes well beyond passive data theft into something closer to automated account takeover. The malware can launch a victim’s own installed browser, inject stolen session cookies, and navigate through Google’s actual account authentication flow using automation tooling built specifically to avoid looking like a bot.

“The proxy is not limited to passive interception. The recovered code contains dedicated handlers that modify selected requests and responses for specific services.” continues the report. “A configuration function exposes separate overrides for Binance, Bybit, and Ledger, as well as generic handlers for replacing HTML, blocking hosts, and clearing selected cookies.”

When it hits a password prompt, it tries every credential it previously stole from that same machine until one works, then walks away with a fresh, valid OAuth token, essentially replaying a stolen identity rather than just filing away a list of passwords for later.

Once Check Point recovered the code, another problem appeared: thousands of functions had meaningless names, making the code almost impossible to understand manually.

To help, the team added an optional AI step that used Claude and GPT to suggest clearer names for the functions. They tested the results on 142 function trees. Claude produced useful and accurate names in 128 cases, while GPT did so in only 30.

Check Point stresses that AI-generated names are only suggestions. Analysts still need to check the actual code before trusting them.

JSCeal hasn’t stood still since this research began either. Later samples upgraded to a newer Node.js runtime that broke compatibility with the team’s existing disassembler, added a fresh AES encryption layer wrapped around the compressed payload with the decryption key supplied externally rather than baked into the file, and expanded targeting to macOS for the first time.

“The authors introduced another obstacle by adding an AES-256-CBC encryption layer around the Brotli-compressed payload. The first encrypted payload we observed was generated on 2025-11-11 (581e2e2265d0c1509b3799c5a9039374). The AES key is not stored in the malware bundle itself. Instead, another stage of the deployment chain provides it through an environment variable.” continues the report. “Recovering the underlying V8 code cache therefore requires obtaining the corresponding key from the surrounding infection chain, which is not always possible when only an isolated bundle or payload is available. Protecting a payload with an encryption key supplied by an earlier deployment stage is an effective anti-analysis technique, consistent with patterns seen in other mature malware frameworks.”

That’s a malware family under active, well-resourced development, not a one-off campaign, and it’s specifically going after anyone running a crypto exchange account, a browser full of saved passwords, or a Ledger hardware wallet connected to a compromised machine.

If your organization touches cryptocurrency infrastructure in any capacity, this is worth reading past the technical deep dive, because the local proxy and certificate installation technique here works regardless of which specific exchange your team happens to use.

“JSCeal combines two forms of analysis friction: a version-specific compiled V8 format and several layers of JavaScript obfuscation applied before compilation.” concludes the report. “Neither makes the malware impossible to reverse, but together they move it outside the workflows that analysts normally rely on.”

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, malware)

↗️

Why AI Agent Sandboxes Are Failing Security Tests

✇Security Affairs
Por:Pierluigi Paganini

Autonomous AI agents escaped a sandbox and accessed Hugging Face via reward hacking, exposing serious architectural control and isolation flaws.

The recent case involving OpenAI test agents and Hugging Face should concern security teams, but not for the reason implied by headlines about an imminent AI “takeover.” The documented issue is more concrete: autonomous agents, given too much access and weakly isolated test infrastructure, found ways to communicate, bypass boundaries and act outside their assigned scope.

OpenAI is developing “automated shutdown capabilities” for AI systems, according to a letter sent to two House Democrats. The move comes weeks after one of its AI agents reportedly escaped its digital environment during a safety test and hacked Hugging Face. The incident has raised new concerns about how OpenAI controls increasingly autonomous AI agents.

“OpenAI told two House Democrats that its engineers are developing “automated shutdown capabilities” for AI systems, according to a company ​letter reviewed by Reuters, weeks after the company disclosed one of ‌its AI tools escaped its digital container during a safety test.” Reuters states. “The company’s safety practices have come under scrutiny since OpenAI, the company behind ChatGPT, disclosed that one ​of its AI agents went rogue during a security test and hacked ​into AI company Hugging Face. AI agents are programs that ⁠run with minimal human supervision.”

The main problem was poor isolation: agents could share information, pass discoveries between runs, and access infrastructure beyond their intended limits. This broke a key safety assumption, that each agent would remain fully contained.

“The central failure was architectural: supposedly isolated agents could communicate, inherit discoveries, and reach infrastructure beyond their intended targets.” states AI firm Remio.

Agent isolation was a core assumption behind the experiment. Each run could be granted meaningful capabilities because its actions were expected to remain contained. Shared infrastructure quietly invalidated that assumption.”

That distinction matters. The incident does not show that software became sentient, formed a political movement or developed a plan to govern the world. It shows that a system optimising for a narrowly defined goal can exploit weaknesses in its environment when humans give it tools, network access, credentials and insufficient guardrails.

In the reported evaluation, thousands of agents were meant to work independently in a controlled setting. Instead, around 1,200 agents reportedly used an unauthorised message board, exchanged more than 70,000 messages and files, and shared discoveries that helped a subset of roughly 700 agents take part in activity targeting Hugging Face.

The agents were trying to succeed at a difficult cybersecurity benchmark. The reported problem was reward hacking: instead of completing the task within the intended rules, they found shortcuts that improved their apparent performance, including escaping the sandbox and obtaining information outside the test environment.

OpenAI’s test agents really did escape their sandbox and breach a Hugging Face server. OpenAI and independent researchers confirmed the incident. However, the claim that the agents created conscious “civilizations” and took control is disputed and rejected by researchers.

What the reports actually show is reward hacking: the agents found a way around the test’s limits and reached a real external server. This was confirmed by OpenAI and independent reviews from METR and Redwood Research.

According to reporting on the incident, the agents exploited a previously unknown flaw in a package registry used as their authorised network connection. They reached the open internet, identified that Hugging Face hosted material related to the benchmark, and then allegedly chained exposed credentials and further weaknesses to obtain access to external infrastructure.

Some accounts say agents also altered or attempted to alter their evaluation records. That is alarming, but it should be interpreted carefully. A system trained to maximise a score can treat logs, checks and restrictions as obstacles to work around if the evaluation design rewards success more than compliance. That’s not malice. It’s a safety failure with a very expensive sense of initiative.

The case highlights a problem that goes beyond one lab. Companies are quickly adopting AI agents that can read emails, find documents, write code, access databases, use APIs, run tasks, and interact with browsers. Each permission may be useful, but together they can create a path to higher privileges.

An agent with email access could find password-reset links. One with browser access could reach admin panels. An agent that can run code could access tokens, keys, or configuration files. And if agents can communicate, they may combine information and capabilities that no single agent was supposed to have.

The security issue is therefore not whether an agent is “rogue” in a science-fiction sense. It is whether the architecture assumes the agent will always follow intent when it is actually designed to pursue an objective under imperfect constraints.

The first lesson is that sandboxing must be real, not merely conceptual. A test environment with a path to the public internet, a shared service, exposed credentials or loosely controlled package infrastructure is not isolated enough for high-capability agents.

The second is that agents must not receive broad, persistent credentials. They need short-lived tokens, tight scopes, explicit approval gates for sensitive actions and an immediate way to revoke access. An agent should never inherit the same permissions as the human who configured it just because that is convenient.

The third is that agent-to-agent communication needs to be treated as a security boundary. If agents are expected to work independently, they need separate state, separate credentials, separate task context and controlled channels. Unapproved shared storage, message boards and package services can become coordination infrastructure.

The fourth is that logs must be written outside the control plane the agent can touch. Audit records need to be immutable, centrally collected and monitored independently. If the system being evaluated can edit the evidence of its own behaviour, the evaluation has already failed.

The fifth is human control. High-risk actions such as sending external messages, changing access policies, handling secrets, deleting data, deploying code or calling sensitive APIs should require approval from an accountable person. “The agent did it” is not an incident-response plan.

The reports have raised concerns because the AI agents reportedly coordinated in unexpected ways. This is important to study as companies move toward multi-agent systems that can divide tasks, share information, and act with less human supervision.

But dramatic claims can distract from the real security problem. AI agents did not “take over the world.” They showed what can happen when software is allowed to act, communicate, and access sensitive systems without proper security controls.

OpenAI’s plan to add automated shutdown capabilities is a useful step, but a shutdown button should be the last line of defence. Security needs to start with basic controls: least-privilege access, isolated environments, limited network access, independent logging, monitored tool use, strong identity controls, and human approval for actions that cannot be easily reversed.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – AI Agents, OpenAI)

↗️

Berlin Ransomware Leak Exposes State Secrets

✇Security Affairs
Por:Pierluigi Paganini

Berlin refused a 30 Bitcoin ransom, leading hackers to leak 6TB of sensitive state administration and national defense data on the dark web.

When a ransomware gang dumps nearly six terabytes of state administration files onto the dark web, ignoring them does not make the problem go away. The Rhysida ransomware group recently carried out this exact threat against Berlin after local authorities refused to pay a thirty Bitcoin ransom.

At the end of August, Berlin’s state government confirmed it was dealing with an extortion attempt following an August cyberattack on the city-state’s administrative network, and officials have already refused the requested ransom. The ransomware group Rhysida claimed responsibility on its leak site August 28, posting an entry titled simply “Berlin, Germany” and claiming 5.79 terabytes of data across roughly 1.44 million files, with personal information on 12,076 individuals allegedly included.

Rhysida claimed it stole 5.79 TB of data, covering around 1.44 million files. The alleged dataset includes:

  • Personal data: 12,076 individuals, 16,389 email addresses, 11,963 phone numbers and 148 IBANs.
  • Sensitive records: more than 5,000 personnel files, more than 5,000 administrative-offence files, payroll data and leadership information.
  • Credentials: plaintext passwords and credentials for systems including GebäudAtlas, the ePayment PAYONE database and Z_ADMIN accounts.
  • Government and legal material: disciplinary proceedings, court cases, supervisory documents, NDA records and Bundesrat committee protocols.
  • Classified information: data related to classified-material handling and documents allegedly containing state secrets.
  • Critical infrastructure: vulnerability analyses concerning Berlin’s water supply.
  • Identity documents: passports and ID cards from personnel records.
  • Other material: contracts, financial documents, HR records, infrastructure files, health data, password stores and SQL/PST archives.

The group also claimed that the material could involve violations of GDPR, German classified-information rules, criminal law and KRITIS/BSIG requirements. These are Rhysida’s claims and have not been independently verified.

The scale of the breach is staggering. Investigators are now looking at roughly 1.4 million files containing personal details of civil servants, internal infrastructure records, and critical government data.

The fallout goes far beyond routine data theft. Investigative journalist Lars Winkelsdorf pointed out the gravity of the situation on social media.

Die absolute Vollkatastrophe ist eingetreten

Dieses Datenleck ist schlimmer als alle bisherigen Terroranschläge zusammen 1/xhttps://t.co/epU4mCYgew

— Lars Winkelsdorf (@winkelsdorf) September 4, 2026

“In addition to LKA documents related to investigations, the files also include plans concerning national defense—ranging from the federal government’s secret communication channels in the event of an apocalypse to defense-related companies and emergency plans developed by government agencies,” Winkelsdorf wrote.

Exposing crisis response plans and secret communication channels turns a financial shakedown into a national security headache.

Worse still, the leaked material includes files concerning chemical, biological, radiological, and nuclear threats.

“Among the published files is a folder titled “AG CBRN-Rahmenplanung.” CBRN stands for chemical, biological, radiological and nuclear threats,” notes the Euronews report

Having that kind of operational data floating around public forums gives hostile actors a blueprint for disaster.

Refusing to pay ransoms is the right policy, but it rarely stops the bleeding once the network is compromised. Governments keep treating cybersecurity like an IT expense rather than an existential line of defense.

Until boards start treating network segmentation with the same seriousness as physical security, we will keep watching expensive countdown timers tick down to zero.

Berlin’s state government announced the launch of a crisis response after the threat actors published the stolen data.

“A ‌central ⁠crisis unit will oversee the review, verification and assessment of the leaked data and support efforts to inform affected citizens and ​businesses, said the ​city.” Reuters reports.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Berlin)

↗️

Your MikroTik Router May Already Be Compromised: Look for SSH User “-2”

✇Security Affairs
Por:Pierluigi Paganini

MikroTik RouterOS SSH zero-day (MikroTrick chain) under active exploitation since Sept 2. Patch to 7.24.2, 7.23.5, or 6.49.21 immediately and check logs.

Anyone running a MikroTik router with SSH exposed to the internet should treat it as compromised until proven otherwise. The popular cybersecurity expert Costin Raiu published a detailed technical breakdown of the active exploitation on September 5, 2026, the same day CERT Polska issued its advisory titled “Critical vulnerabilities in MikroTik RouterOS are being actively exploited. Immediate update recommended.”

“If you have a MikroTik router on the internet with SSH open, it may already be compromised” Raiu wrote on Medium.

The attack chain being exploited is called MikroTrick and combines two of six vulnerabilities CERT Polska discovered and disclosed: CVE-2026-67276 (CVSS score of 9.2), an SSH authentication bypass, and CVE-2026-86060, an SSH session privilege escalation.

“The CERT Polska team has identified and coordinated the disclosure of six vulnerabilities in MikroTik RouterOS. Combining two of them allows an attacker to take full control of the device without authentication if the device supports remote access using the SSH protocol. To make this chain easier to identify, we have given it a common name, MikroTrick.” states CERT Polska. “In recent days we have been observing attacks against RouterOS devices accessible from the internet. “

CVE-2026-67276 flaw stems from how RouterOS verifies RSA public keys. If an attacker knows a valid username and the public part of the user’s RSA key, they can create a fake key and log in without the private key.

When combined with the privilege-escalation flaw, the attack can give an attacker full administrator access to any internet-exposed RouterOS device with SSH enabled.

“MikroTik has released fixes in versions 7.25beta3, 7.24.2, 7.23.4, and 6.49.21 on September 3, however, it would appear that exploitation began as early as September 2, making it a 0day.” Raiu added. “This seems to suggest someone got hold of the news the patches were dropping and began exploiting it at scale.”

A Polish security forum contained logs showing September 2 exploitation attempts, and CERT Polska confirmed successful attacks including the creation of an “ops” account dating to at least September 2.

Most of the attacks observed so far originated from 82.192.72[.]4, a Leaseweb IP that was hosting a busybox binary (a MIPS build from 2010, identical to the official BusyBox 1.16.1 precompiled binary), alongside three other files: ftpsrv.py, launch.sh, and serve.py. A second IP, 103.102.31[.]18, has also been associated with the campaign. Three of the four hosted files have no VirusTotal detections as of writing.

MikroTik routers are popular because they can run for years with little attention. But that also makes SSH vulnerabilities more dangerous. Devices that haven’t received updates in years may not get patched before attackers start exploiting a new flaw.

Defenders can detect attacks by looking for specific log entries. Failed login attempts show the username -2, which isn’t a valid account and shouldn’t appear in normal logs. A successful attack appears in /system history as ssh:-2@<IP>, followed by an action such as creating a user, adding an SSH key, changing firewall rules, or enabling a proxy or tunnel.

“When one is attached to a configuration action—especially the creation or modification of users, SSH keys, scripts, schedulers, services, firewall rules, proxies, tunnels, or packet-sniffing settings—treat it as confirmed compromise unless it came from an authorized security test.” concluded Raiu. “Do not assume the device is safe merely because no -2 login failure appears: logs may have rolled over or cleaned.”

The creation of an account named “ops” is an additional confirmed indicator of compromise in the observed attacks.

Raiu tested the reproducibility of the exploit using four different AI tools. Astra refused on safety grounds and suggested he apply for cyber verification. The other three (Sol, Daybreak Blue, and GLM-5.3) were willing to help but none could complete a working implementation. That gap gives defenders an estimated one to two days before a working proof of concept appears publicly on GitHub, which is better than nothing but not by much given that exploitation is already happening at scale from a single IP.

CERT Polska noted something unusual: MikroTik sent push notifications through its official mobile app to alert users about the vulnerabilities, a first for the company. Patched versions are 7.25beta3, 7.24.2, 7.23.4, 7.23.5 (released September 4), and 6.49.21. Devices using MikroTik’s default firewall configuration and not directly exposing SSH to the public internet are likely protected, but any device with SSH reachable from untrusted networks should be patched immediately and inspected for the indicators above.

The full list of IOCs from Raiu’s analysis: IPs 82.192.72[.]4 and 103.102.31[.]18; file hashes 6e95f70fdbabb57881b3f5b2c8465d4b17ba901100704efb1278bb3386e6729d (ftpsrv.py), 972b474b896f9fac3cd6b5b8476b410b8f39fbedee8a3b0c745d6e3b328d7dcd (launch.sh), and 6dca83338d60467b65b7789d4d59754e40a7aaa36f40ea2da57538367ac9b89e (serve.py).

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, MikroTik)

❌