Visualização normal

Hoje — 9 de Setembro de 2026Stream principal
  • ✇Security Affairs
  • Hackers Drain $320 Million From Liquid Network, Then Return Most of It Pierluigi Paganini
    Crypto exchange network Liquid Network lost $320 million overnight, then got most of it back after the hackers demanded a bug fix instead of a ransom Bitcoin’s Liquid Network, a sidechain built by Blockstream and used by dozens of exchanges to move funds faster and more privately than the main Bitcoin blockchain allows, got drained of roughly 4,000 of the 4,200 Bitcoin sitting in its federation wallet on September 6. The attackers, who described themselves as white-hat hackers, have sinc
     

Hackers Drain $320 Million From Liquid Network, Then Return Most of It

8 de Setembro de 2026, 17:35

Crypto exchange network Liquid Network lost $320 million overnight, then got most of it back after the hackers demanded a bug fix instead of a ransom

Bitcoin’s Liquid Network, a sidechain built by Blockstream and used by dozens of exchanges to move funds faster and more privately than the main Bitcoin blockchain allows, got drained of roughly 4,000 of the 4,200 Bitcoin sitting in its federation wallet on September 6.

The attackers, who described themselves as white-hat hackers, have since returned 3,400 of those crypto coins, worth around $262.6 million, while keeping roughly 598 BTC, close to $47 million, for themselves.

Update: 3,400 BTC of the roughly 4,000 BTC withdrawn on September 6 has been returned to the @Liquid_BTC Federation wallet. The return followed confirmation from @Blockstream that the affected bridge nodes have been patched. Approximately 598 BTC remains outstanding, and…

— Samson Mow (@Excellion) September 7, 2026

The size of the initial theft makes this much more serious than another crypto hack. The attacker took nearly 95% of the wallet’s Bitcoin in a single transaction, leaving the fund behind Liquid’s L-BTC token with only about 197 BTC.

This wasn’t a partial breach. The attacker drained almost the entire collateral pool that should back every L-BTC token with an equal amount of real Bitcoin.

How the money actually left is the more technically interesting part. According to Bitrue’s breakdown of the exploit, the attackers didn’t steal a private key or compromise any authorization credentials at all. A software bug in Elements, the open-source code powering Liquid Network, apparently let more L-BTC exist than the system’s real Bitcoin reserves should have allowed, and that unbacked token was then redeemed for genuine BTC through SideSwap’s authorized peg-out mechanism. Liquid itself confirmed the specific access point directly, stating plainly that the funds moved through SideSwap’s authorization key, and that key itself was never compromised.

What happened next is where this stops looking like an ordinary crypto heist. Rather than demanding a ransom payment or threatening to dump the stolen coins, the attackers negotiated entirely in public, writing messages directly into Bitcoin transactions using the OP_RETURN field, a way to embed small amounts of arbitrary data on-chain.

The discussion between @Blockstream and the white-hat hacker (WHH) regarding the ~4000 BTC from @Liquid_BTC is happening in public. It seems to be their preference over email. As it's hard to follow the chain of messages in OP_RETURN, here's a summary with links.

11:30 AM PDT -… https://t.co/IEXyFpBITx

— Samson Mow (@Excellion) September 7, 2026

Their opening demand, relayed through Liquid’s own channels, was refreshingly blunt: fix the underlying vulnerability first, confirm every node is patched, and only then would they send the money back.

Blockstream appears to have met that condition. After the team confirmed that the affected bridge nodes had received the security patches, the attackers returned 3,400 BTC to the federation wallet. They first checked that they had the correct return address. They then kept the remaining 598 BTC, effectively rewarding themselves for the bug discovery. Former Blockstream executive Samson Mow provided updates during the incident but warned that the recovery is not over. The network remains paused while federation members complete more security work, resolve a chain split caused by the freeze, and restore confidence that L-BTC has full Bitcoin backing before they restart the network.

Whether “white hat” is the right label here is a genuinely contested question, and not just semantically. Security specialist Alena Vránová pushed back hard against the framing on social media, arguing that exploiting a vulnerability, draining $320 million, and demanding a fix before returning the money still meets the legal definition of extortion, potentially carrying felony charges and prison sentences up to 20 years in the US. Calling yourself ethical after the fact doesn’t retroactively make unauthorized access to someone else’s wallet legal, whatever bug you’re fixing on the way out.

If you attacked @Liquid_BTC fix it fast I'd reckon to avoid serious trouble.

If you exploit vuln, steal 4k BTC and demand a fix for ransom, that's EXTORTION.

This can mean felony charges and long prison time. In the U.S. up to 20 years, and computer-fraud charges can add more. https://t.co/aekesa5K0n

— Alena V. (@AlenaSatoshi) September 7, 2026

The incident also creates a long-term trust problem that a security patch cannot fix. Galoy founder Nicolas Burtey argued that, even if the funds return in full, the attack has already damaged trust in Liquid. Who will trust Liquid with their money after this? The federated system promises one-to-one Bitcoin backing for every L-BTC token, but this attack showed that guarantee can fail. Recovering most of the funds does not erase that failure.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, Liquid Network)

  • ✇Security Affairs
  • IT Help Desk Impersonation Lets Hackers Bypass MFA Pierluigi Paganini
    Attackers bypass endpoint security by posing as IT staff, stealing Microsoft 365 sessions, draining SaaS data and demanding extortion. Forget installing malware because today’s extortionists just pick up the phone instead of writing code. A widespread threat cluster tracked as PREY-0058 bypasses endpoint security entirely by targeting Microsoft 365 and SaaS environments through pure social engineering. Attackers pose as internal IT help desk staff via phone calls and direct executives tow
     

IT Help Desk Impersonation Lets Hackers Bypass MFA

8 de Setembro de 2026, 04:41

Attackers bypass endpoint security by posing as IT staff, stealing Microsoft 365 sessions, draining SaaS data and demanding extortion.

Forget installing malware because today’s extortionists just pick up the phone instead of writing code. A widespread threat cluster tracked as PREY-0058 bypasses endpoint security entirely by targeting Microsoft 365 and SaaS environments through pure social engineering.

Attackers pose as internal IT help desk staff via phone calls and direct executives toward rogue authentication portals.

“The threat actors impersonate internal IT or helpdesk personnel by phone and direct them to an authentication-themed URL, often formatted as <victim organization>.<lure domain>.” reads the report published by Artic Wolf. “These attacks most frequently target Directors, Vice Presidents, and other executive staff.”

Once victims land on these pages, adversary-in-the-middle panels intercept credentials and multi-factor approvals in real time.

Stolen session tokens are then replayed using residential proxy networks that match the victim’s exact geographic location.

“Stolen sessions are replayed from residential proxy infrastructure, most notably NodeMaven, often from IP addresses that resolve to the same geo-location and network (ASN) as the victim.” states Artic Wolf. “Initial sign-in activity involves applications such as “My Signins”, “My Profile”, “My Apps”, which reveal account details and the applications available to the victim.”

This clever trick blinds standard impossible travel alerts and leaves defenders scratching their heads.

Intruders waste no time once they slip past the front door, immediately shifting focus to massive data harvesting.

“After initial access, the threat actors perform discovery techniques against SharePoint and Entra ID.” continues the report. “SharePoint discovery includes SearchQueryPerformed events with contentclass:STS_Sitecontentclass:STS_Web, and wildcard searches using indexdocid for pagination.”

They map out repositories and drain sensitive files from OneDrive, Exchange, and Box before dropping a heavy extortion demand.

To detect these attacks, monitor Microsoft 365 sign-ins coming from residential proxies or hosting networks such as NodeMaven. Suspicious activity is more likely when several common Microsoft account pages are accessed at the start of a session, especially OfficeHome, My Signins, My Profile, My Apps and Microsoft Account Controls.

Alerts should also consider changes from a user’s normal sign-in pattern, such as a different location, ISP, browser, operating system or user agent.

In SharePoint, look for unusual SearchQueryPerformed events that map or enumerate sites and files. In Exchange, watch for large numbers of MailItemsAccessed events in a short time, especially when they come from hosting or proxy IPs. Also monitor heavy SharePoint and OneDrive file access or downloads from one user, particularly when scripting tools such as Python requests or Microsoft Graph are used. Finally, watch for new phishing domains that imitate your organization and target passkey or MFA registration.

To reduce the risk, require managed devices for Microsoft 365 and block or challenge access from proxy and hosting networks. Use phishing-resistant MFA such as FIDO2 keys or device-bound passkeys, which can stop AiTM attacks. Limit users’ access to sensitive SharePoint data, enable Continuous Access Evaluation, and train employees and help-desk teams to verify unexpected IT calls through a trusted channel.

Artic Wolf also released Indicators of Compromise (IoCs) for these attacks.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, IT Help Desk)

  • ✇Security Affairs
  • Condé Nast Data of 32.8 Million Users Offered for Sale After WIRED Leak Pierluigi Paganini
    Condé Nast user data from 32.8 million accounts is reportedly for sale, raising risks of targeted phishing, fraud and scams. A database said to contain 32.8 million Condé Nast user records is being offered for $15,000 on a Russian-language cybercrime forum. Ransomnews reviewed a 5,000-record sample and concluded that it is consistent with genuine Condé Nast account data collected between September and late October 2025, including records that have not appeared publicly before. Ransomnews’ or
     

Condé Nast Data of 32.8 Million Users Offered for Sale After WIRED Leak

7 de Setembro de 2026, 16:40

Condé Nast user data from 32.8 million accounts is reportedly for sale, raising risks of targeted phishing, fraud and scams.

A database said to contain 32.8 million Condé Nast user records is being offered for $15,000 on a Russian-language cybercrime forum. Ransomnews reviewed a 5,000-record sample and concluded that it is consistent with genuine Condé Nast account data collected between September and late October 2025, including records that have not appeared publicly before. Ransomnews’ original report provides the underlying analysis.

The alleged dataset covers users across Condé Nast’s publishing portfolio, which includes Vogue, The New Yorker, GQ, Glamour, WIRED, Vanity Fair and other titles. Condé Nast has not publicly confirmed the breach or commented on the new sale listing.

The seller claims the database contains 32,815,767 unique email addresses. It also allegedly includes names, postal addresses, gender, dates of birth and phone numbers for portions of the population, but no passwords, password hashes, usernames or payment-card data.

“A database of 32,815,767 Condé Nast user records went on sale on a Russian-language hacker forum on 7 September 2026 for $15,000, offered as the full set behind December’s WIRED leak.” Ransomnews states. “Ransomnews tested the 5,000-row sample: it is genuine Condé Nast account data, captured in September and October 2025, and the 30.5 million non-WIRED records have not surfaced publicly before. Condé Nast has never commented on the breach.”

Ransomnews found that 31.6% of records allegedly include both first and last names, 22.3% include a postal address, 17.5% include gender, 12.6% include a date of birth and 2.9% include a phone number. The data is valuable because it can be filtered and combined with other information, not because every record contains every field.

The listing claims to include the full dataset behind the December 2025 leak involving WIRED, one of Condé Nast’s best-known publications. The seller says that a separate version excluding WIRED contains 30,455,594 records, which implies a WIRED subset of roughly 2.36 million records.

That figure closely matches the 2,366,576 WIRED records made public in December 2025. SecurityWeek previously reported that the actor behind that leak, using the name “Lovely,” claimed to have stolen more than 40 million Condé Nast records and threatened to release data linked to other publications.

Here’s a simpler and more natural version:

The numbers connect the new listing to the earlier WIRED breach, but they don’t prove that the seller is the original attacker. The seller could be the same person, a partner, or someone who got the data later.

The sample does not look like a recycled copy of the public WIRED leak. It contains names and street addresses at higher rates than the earlier WIRED dataset, has a different field structure and shows a demographic distribution that fits a broader collection of Condé Nast consumer titles, including publications with predominantly female readerships.

Ransomnews did not test the records against live Condé Nast accounts, which would have created further privacy risks. Instead, it used internal consistency checks to determine whether the sample behaved like a real long-running consumer database.

The 5,000-record sample closely matched the seller’s claims, with field-completion rates differing by only 1.2 percentage points. Among records with full names, 61.9% had an email address that matched the name or its initials. When names were randomly mixed between records, that figure fell to just 0.3%.

The data also passed basic time and location checks. None of the 227 records using Apple Relay, iCloud, Outlook, Me.com or Proton addresses appeared to predate those services. Also, 96.4% of U.S. ZIP codes matched the listed state, while 93.5% matched the listed city.

Messy data can be useful evidence. Fields such as “Select your state,” numeric dropdown values, inconsistent country labels, lower-case names and dates of birth set to 1 January are the kind of ordinary web-form errors that accumulate in a database built over decades. Fabricated data is usually cleaner. Real data is often embarrassingly human.

Account-creation dates in the sample run from February 1999 to 23 October 2025. Ransomnews notes that new-account entries thin sharply from September 2025 onward, which suggests the extraction took place over several weeks between September and late October.

That timing fits the earlier incident. The public WIRED leak contained records dated through September 2025, while the person calling themselves Lovely contacted DataBreaches.net in November and the WIRED material appeared online in December.

SecurityWeek’s earlier analysis said the attacker’s technical claims were consistent with insecure direct object reference, or IDOR, and broken access-control issues. In that kind of failure, an application lets one user view or alter another user’s data because it checks identifiers but fails to verify authorisation properly.

The seller’s account is new, has little visible reputation and offers escrow, according to Ransomnews. That profile fits a seller seeking a single buyer rather than public attention, especially when the dataset is priced at less than one-twentieth of a cent per record.

A public dump produces headlines. A private sale can produce a more focused problem: a buyer can use the data for phishing, lead generation, fraud, credential-stuffing preparation or correlation with other leaked datasets without ever publishing the full file.

The absence of passwords does not make the data harmless. A person who subscribed to Vogue, booked a gift subscription for GQ or registered for The New Yorker may receive a message that accurately uses their name, address and publication relationship. That is enough to make a fake renewal, refund or billing request look far more credible than ordinary spam.

Readers should treat unexpected messages about subscription renewals, billing problems, delivery issues, gifts or account verification with caution. Instead of using an email link, open the publisher’s website directly through a known address and check the account there.

A password reset is not the first priority based on this dataset alone, because no passwords or password hashes were found in the sample. However, anyone who reused the same email address across many services should be alert to follow-on phishing and should use a password manager and multi-factor authentication on important accounts.

Postal addresses were present in more than one-fifth of the claimed records. That means fraud may also arrive as physical mail, not only by email or SMS. A letter that references a real magazine title or subscription is not proof that it is genuine.

The more uncomfortable lesson is about breach economics. An attacker can release a small, recognisable subset to demonstrate that the data is real, then hold the larger collection back until a buyer appears. The public sees a leak. The criminal market sees inventory.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, data breach)

  • ✇Security Affairs
  • StyleSmuggler: The Magento Zero-Day Behind New Store Attacks Pierluigi Paganini
    StyleSmuggler Magento zero-day is under active attack, letting unauthenticated attackers execute code and install backdoors on stores that may already be patched. A new zero-day flaw, dubbed StyleSmuggler, in Magento and Adobe Commerce is under active attack, giving unauthenticated attackers a path to run code on vulnerable online stores. Sansec researchers say it affects current Magento Open Source releases, including 2.4.7, 2.4.8 and 2.4.9. According to the experts, exploitation began on S
     

StyleSmuggler: The Magento Zero-Day Behind New Store Attacks

7 de Setembro de 2026, 14:49

StyleSmuggler Magento zero-day is under active attack, letting unauthenticated attackers execute code and install backdoors on stores that may already be patched.

A new zero-day flaw, dubbed StyleSmuggler, in Magento and Adobe Commerce is under active attack, giving unauthenticated attackers a path to run code on vulnerable online stores. Sansec researchers say it affects current Magento Open Source releases, including 2.4.7, 2.4.8 and 2.4.9. According to the experts, exploitation began on September 4.

“Sansec discovered StyleSmuggler, an unpatched Magento and Adobe Commerce zero-day that gives unauthenticated attackers remote code execution. All current versions are affected, including 2.4.9.” reads the report published by Sansec. “Attacks started September 4th. Sansec is rolling out emergency mitigation.”

This is not a routine patch-cycle problem. Sansec reproduced the full attack chain on clean installations and observed a first victim running Magento 2.4.6-p15 with July and August 2026 patches already applied and a clean patch-status result. In plain terms, a store could be fully updated according to its normal process and still be exposed.

“StyleSmuggler injects malicious code into Magento’s template system.” states Sansec. “By using the styles properties, it can evade existing safeguards. It works in two stages:

  1. Inject (poison) PHP code, for example by generating a failure report.
  2. Let Magento execute the poisoned code via a failed payment email

The attack is especially dangerous because it does not require a victim to open an attachment, click a link or even receive a successful email. Magento can execute the injected code while it renders its standard “Payment Transaction Failed Reminder” notification, and the chain can still work if email delivery itself fails.

That makes unusual spikes in failed-payment reminders a useful detection clue, although not conclusive proof of compromise. Legitimate payment failures happen. A sudden burst of them combined with strange system activity is a different conversation.

StyleSmuggler works by placing PHP code into Magento’s templating path and later causing the platform to evaluate it. The first stage creates or poisons a record, while the second stage turns a routine email-rendering process into remote code execution.

The attack reportedly uses GraphQL-related handling and the styles property to evade safeguards that would normally reject dangerous input. Sansec says moving sessions to Redis or a database does not stop the attack, because operators have already adapted their methods when one delivery route fails.

“Moving sessions to Redis or the database does not stop the attack. One merchant reported an attempt that failed against session storage and, eight seconds later, a second attempt that succeeded by using a file uploaded through Magento’s custom options instead.” continues the report. “Both came from the same operator.”

That detail matters because it shows an active operator, not a static proof-of-concept circulating online. Defenders should assume attackers are testing several paths, watching failures and changing tactics quickly.

Once the exploit succeeds, Sansec observed a lightweight Rust backdoor that connects to attacker-controlled infrastructure and waits for commands. At the time of the report, Sansec had not seen evidence that operators had yet used the implant for follow-on actions, but a backdoor that is installed and waiting is not an idle technical curiosity.

The malware initially hid behind a process name resembling [kworker/u:8:0], then appeared as fc-cache on September 6 and as chronyd on September 7.

These names are designed to blend into Linux environments, where administrators may expect to see kernel workers, font-cache utilities and Network Time Protocol daemons.

The fc-cache variant copies itself into a font-cache directory, writes a PID lock file and uses cron to restart twice an hour. The chronyd version can persist through cron as well, but Sansec also observed a build that relaunched itself without relying on a visible cron entry. An empty crontab is not proof that a host is clean.

The command channel is disguised as time synchronisation traffic. The implant sends 48-byte UDP packets to port 123, the standard NTP port, and uses domains that resemble time servers.

“Command and control is disguised as time sync. Every 60 seconds it resolves ntp.timesync.to and sends 48-byte UDP packets to port 123 that look like NTP server replies.” continues the report.

Only the first four bytes look like a normal NTP message; the remaining data can carry the agent ID, hostname, username, operating-system version, memory and disk use, uptime, root status and implant version.

That is a smart concealment choice. Many networks allow NTP traffic without close inspection because reliable time synchronisation is a normal operational requirement. Calling your malware chronyd and making it speak something that resembles NTP is not subtle genius. It is just clever enough to pass a lazy allowlist.

Sansec also found signs of a second, apparently unrelated attacker operating against stores compromised through StyleSmuggler. This actor deployed a compact PHP dropper that placed a web shell inside the product-image cache, using hash-like directory names to make the extra PHP file less obvious.

The web shell returns a normal-looking 404 response unless a request contains the correct X-Cache-Token header. With the header present, it can execute PHP supplied through a POST parameter. That design helps the attacker keep the shell invisible during casual checks and automated scans.

“Before writing that file, the dropper calls out to 457cfa2fb7p5.daf892t5qau4og8pi4cghbc6fhm1dim3u.oast.site, a subdomain of a public service that developers and testers use to confirm that injected code ran.” states the report. “This actor came in through StyleSmuggler. We recovered the dropper from a Store: request header, and its PHP tags are still JSON-escaped from the record Magento logged it into.”

The lesson is not merely to remove the obvious background process. Stores need a full compromise assessment, including a review of PHP files under pub/media, cron spool files, unexpected processes, altered templates, report records, web-server logs and outbound connections.

Adobe was working on a patch as of September 7, according to Sansec, but no release date had been confirmed. A scheduled Adobe security release was due on September 8, although it was not known whether it would address StyleSmuggler.

Until an official fix is available and applied, merchants should consider temporarily disabling GraphQL if they do not have a compensating control capable of blocking this exploit. This can affect storefront and integration functions, so it should be treated as a risk decision rather than a casual configuration change.

Operators should also hunt for processes named [kworker/u:8:0], fc-cache and chronyd that run from unusual paths such as temporary directories, user cache directories or hidden folders. A legitimate chronyd process does not normally emit nine NTP server-mode packets in rapid succession every minute.

Security teams should inspect outbound traffic to suspicious NTP-like domains and UDP port 123 destinations, particularly 185.157.160.251, which Sansec linked to the observed domains on September 7. They should also search authentication and system logs for repeated crontab command not allowed messages generated by the web-service user, such as www-data.

If compromise indicators appear, treat the system as compromised, not merely vulnerable. Isolate the host, preserve logs and forensic evidence, rotate Magento administrator credentials, API tokens, database credentials, payment-provider secrets and cloud keys, then search for secondary backdoors before restoring normal operations.

The Sansec StyleSmuggler report includes current indicators of compromise, malware hashes, C2 infrastructure, suspicious process names and file paths. Its guidance will likely change as the campaign develops, because the attackers have already changed payload names and persistence methods within days.

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, StyleSmuggler)

Ontem — 8 de Setembro de 2026Stream principal
  • ✇Cybersecurity News
  • Outsider Phishing Kit Survives Operation Ghost Hook Takedown Do Son
    The Outsider Phishing Kit persists despite the Operation Ghost Hook takedown. Discover how the ChenLun Outsider PhaaS kit bypasses MFA via AiTM attacks. Related Posts: Phantom Deal Scam Targets Executives With Fake NDAs Microsoft Teams IT Support Impersonation Leads to Domain Takeover Chinese Actor Gambling Goblin Hijacks Brazilian Gov Sites The post Outsider Phishing Kit Survives Operation Ghost Hook Takedown appeared first on Daily CyberSecurity.
     
  • ✇Cybersecurity News
  • Phantom Deal Scam Targets Executives With Fake NDAs Do Son
    The Phantom Deal campaign uses fake acquisition documents to target executives. Gen exposed the Phantom Deal fraud after tracking bogus payment demands. Related Posts: Outsider Phishing Kit Survives Operation Ghost Hook Takedown Microsoft Teams IT Support Impersonation Leads to Domain Takeover Chinese Actor Gambling Goblin Hijacks Brazilian Gov Sites The post Phantom Deal Scam Targets Executives With Fake NDAs appeared first on Daily CyberSecurity.
     
  • ✇Cybersecurity News
  • Chinese Actor Gambling Goblin Hijacks Brazilian Gov Sites Do Son
    The Gambling Goblin campaign turns Brazilian government websites into an SEO weapon. Suspected Gambling Goblin operators push illicit gambling pages. Related Posts: Outsider Phishing Kit Survives Operation Ghost Hook Takedown Phantom Deal Scam Targets Executives With Fake NDAs Microsoft Teams IT Support Impersonation Leads to Domain Takeover The post Chinese Actor Gambling Goblin Hijacks Brazilian Gov Sites appeared first on Daily CyberSecurity.
     
  • ✇Security | CIO
  • The EU AI Act just gave you a breach notification clock you didn’t know about
    Most security teams already have a breach clock memorized. GDPR gives you 72 hours. SEC rules give public companies four business days after determining an incident is material. Those numbers get built into incident response runbooks, tabletop exercises and escalation paths, because the clock starts the moment the team confirms something happened. Article 73 of the EU AI Act adds a third clock, and in my work advising enterprise clients on AI governance, I have yet to s
     

The EU AI Act just gave you a breach notification clock you didn’t know about

8 de Setembro de 2026, 07:00

Most security teams already have a breach clock memorized. GDPR gives you 72 hours. SEC rules give public companies four business days after determining an incident is material. Those numbers get built into incident response runbooks, tabletop exercises and escalation paths, because the clock starts the moment the team confirms something happened.

Article 73 of the EU AI Act adds a third clock, and in my work advising enterprise clients on AI governance, I have yet to see one with a runbook for it.

The obligation took effect on August 2, and it did so alone. The EU’s Digital Omnibus on AI, in force since late July, pushed the rest of the Act’s high-risk enforcement wave — classification, conformity assessment, technical documentation — back to December 2027. Article 73 was not part of that reprieve, though the extra time elsewhere is worth using to get ready. It requires providers of high-risk AI systems to report serious incidents to national market surveillance authorities within 15 days by default, 10 days if a death is involved and just 2 days for incidents the Act classifies as widespread or as a serious disruption to critical infrastructure. Coverage of Article 73 so far has treated it as a legal filing requirement, handled through the same channel as a data protection filing. That framing misses what the obligation is. It is an incident response deadline, and it runs on a different trigger than the breach clocks most security teams already know.

A client once asked me, almost as an aside, whether their customer-facing AI tool would trigger a reporting duty if it simply gave someone bad information rather than getting hacked. At the time, the honest answer was probably not, under any framework they were tracking. Article 73 changes that, and most organizations building or buying AI for the EU market have not caught up yet.

What counts as a trigger here is broader than most teams expect

GDPR’s 72-hour clock starts when you become aware of a personal data breach. That is a bounded question. Did data leave the environment? Was it accessed without authorization? Article 73 asks something harder. The European Commission’s draft guidance takes the position that an indirect causal link between an AI system and a downstream harm is enough to trigger the reporting duty. Their example is a loan denial that traces back to a flawed AI credit assessment. The AI system does not cause harm the moment it produces the assessment, only once a human acts on it and denies the loan. The fundamental rights category requires the infringement to interfere with Charter-protected rights at scale, which is why the Commission illustrates that threshold with patterns, a recruitment tool that discriminates systematically or a credit system that categorically rejects an entire neighborhood. Under the Commission’s reading, once a pattern like that exists, the clock starts when the provider becomes aware of it, not when the system generated the output.

Here’s a plainer version of that pattern. A public benefits agency uses an AI system to match applicants against its records. A flaw in the matching logic occasionally conflates applicants, and over several weeks it happens to a run of different people, each flagged as already receiving the same benefit elsewhere and suspended. Nobody catches the pattern at the time, because each flag looks unremarkable on its own. Applicants don’t find out until their payments stop arriving, weeks after the first mismatch. The system never malfunctioned in any way security tooling would catch. It just produced bad matches until people started missing payments.

That is a different kind of determination than “Did we get breached?” It requires tracing a causal chain from a model output through a downstream decision to an actual harm, then judging how confident you are in that link before you are required to report it. Most incident response teams have a well-practiced instinct for confirming unauthorized access, but few have one for confirming that an AI system caused a harm that surfaced elsewhere in the business, days or weeks later. I have watched security leaders confidently answer, “Were we breached?” in minutes, then go quiet when asked, “Did our AI system cause this?” because nobody owns that second question yet.

Why this does not fit into an existing IR playbook

Most incident response programs are built around a single moment: detection. Something trips an alert, a SOC analyst confirms it and the clock starts. Article 73 incidents will not look like that at all. The AI system that produced the flawed output may show no signs of compromise. Nothing gets flagged by a SIEM. The first sign might come from a customer complaint, an internal audit finding or a pattern a compliance analyst notices months after the AI system made the decision.

That means the “becoming aware” clause in Article 73 is doing real work, and most organizations have not decided who is responsible for noticing. Is it the team monitoring the AI system’s technical performance, the business unit acting on its outputs, or whoever eventually hears the complaint? Under Article 73, the clock starts when any of them establishes, or suspects, the causal link, and 15 days is not a long runway if the first internal conversation about “is this our incident” does not happen until day six or seven. I have seen governance structures where a business unit head, a model risk team and security each assumed someone else owned this judgment call. In practice nobody did, and that gap is where a 15-day clock burns down to five.

Some security teams are already mapping agent governance to a maturity model, arguing that oversight must scale with autonomy, moving from agent identities that are barely inventoried toward ones that are bounded, monitored and revocable in real time. Article 73 raises the stakes on that model considerably. The less a human reviews an AI system’s output before it reaches a customer, the more likely a downstream harm surfaces without anyone watching for it in real time, which is exactly the blind spot Article 73 is designed to close.

What needs to change

A few additions belong in an existing incident response program before this becomes a live problem instead of a paper requirement.

First, a defined owner for the causal link determination. Data breach response usually has a clear owner: security confirms the technical facts, legal makes the materiality call. Article 73 needs an equivalent split: Someone technical enough to trace an AI system’s output to a downstream decision and someone with authority to make the reporting call once that link looks plausible rather than certain. In practice, I recommend naming this owner in the incident response plan, not leaving it to be sorted out during the first real incident, when the clock is already running.

Second, a lower bar for opening an investigation. If GDPR taught teams to investigate the moment unauthorized access is suspected, Article 73 requires investigating the moment a downstream harm is suspected to trace back to an AI system, when the system looks normal to security monitoring. That means feeding business unit complaints and customer escalations into the same triage process that currently only starts from technical alerts.

Third, a documented decision log for the indirect link judgment call. Given how broadly the Commission has defined what counts as reportable, organizations will make defensible calls not to report many ambiguous situations. Those decisions need to be documented with the reasoning behind them, the way a security team documents a false positive call, because a regulator revisiting that judgment months later will expect to see how it was made rather than take the outcome on faith.

Fourth, controls built into the AI system, not bolted on after the fact. A defined owner and a lower investigation bar help catch a problem once it surfaces, but neither reduces how often a flawed output reaches a customer first. Scoped credentials, tool allowlists and pre-action approval hooks cut down on how many incidents exist to report.

The AI Act’s high-risk obligations have absorbed most of the attention this year, because conformity assessments and technical documentation are heavy lifts with long lead times. Article 73 looks lighter by comparison, a reporting duty rather than a certification process. It is not lighter. It asks security and compliance teams to build a new kind of judgment into their incident response programs, on a clock as tight as anything GDPR or the SEC have required. Treat the deferral on the rest of the high-risk package as what it actually is, extra runway to build that judgment and name its owner, because the conformity paperwork still gives you months and Article 73 still gives you days.

  • ✇Malwarebytes
  • Loyalty points fraud is funding hacker holidays (Lock and Code S07E18)
    This week on the Lock and Code podcast… Crooks are taking a holiday. They’re counting on you to fund it. For decades, cybercriminals have stolen roughly the same types of data. Biographical and personal details—like Social Security numbers, birthdates, addresses, and phone numbers—can be stolen to commit identity fraud. Credit card numbers, expiration dates, and CVC codes can be stolen to make fraudulent purchases. Usernames and passwords can, in the wrong hands, let a cybercriminal impers
     

Loyalty points fraud is funding hacker holidays (Lock and Code S07E18)

7 de Setembro de 2026, 15:23

This week on the Lock and Code podcast…

Crooks are taking a holiday. They’re counting on you to fund it.

For decades, cybercriminals have stolen roughly the same types of data. Biographical and personal details—like Social Security numbers, birthdates, addresses, and phone numbers—can be stolen to commit identity fraud. Credit card numbers, expiration dates, and CVC codes can be stolen to make fraudulent purchases. Usernames and passwords can, in the wrong hands, let a cybercriminal impersonate someone, steal sensitive photographs to later use for extortion, or abuse a reputation.

All of these attack models seek to turn sensitive or important data into currency. But an emerging form of digital fraud is targeting data that, when used strategically, practically is currency: Loyalty points.

Loyalty points programs are run by nearly every type of consumer-facing business today, from hotels to airlines to grocery stores to donut shops. As repeat customers accrue these points, they can exchange them for discounted prices on future purchases, cutting the costs of hotel stays, flights, rental cars, and even entire vacations.

But the value stored within these loyalty points makes them a high target for cybercrime, said Kim Sutherland, Global Head of Fraud and Identity at LexisNexis® Risk Solutions.

“Most loyalty currency is worth about one cent per point, and then there are premium programs that can be worth more than that,” Sutherland said, explaining that 100,000 airlines points, for example, can be worth $1,000 in the US. “Why criminals care so much about this is because most of us are not paying attention to our loyalty programs the same way we would our bank account.”

But diligence is much needed here, Sutherland said, noting that one Chicago teacher only learned that 240,000 of his airlines points had been stolen because he received a basic confirmation email about their use. In another example, a man’s airline miles were stolen and fraudulently used to book rental cars in New York and Memphis.

Today, on the Lock and Code podcast with host David Ruiz, we speak with Sutherland about loyalty points theft— how it happens, what companies are doing to protect customers, and what people can do to stay safe.

“Some of us don’t even know how to access those points, right? Or we don’t even know we’re accumulating them, but the fraudsters do.”

Tune in today to listen to the full conversation.

Show notes and credits:

Intro Music: “Spellbound” by Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 4.0 License
http://creativecommons.org/licenses/by/4.0/
Outro Music: “Good God” by Wowa (unminus.com)


Listen up—Malwarebytes doesn’t just talk cybersecurity, we provide it.

Protect yourself from online attacks that threaten your identity, your files, your system, and your financial well-being with our exclusive offer for Malwarebytes Premium for Lock and Code listeners.

  • ✇The CyberWire
  • Hackers gonna hack back.
    Welcome in! You’ve entered, Only Malware in the Building. Join us each month to sip tea and solve mysteries about today’s most interesting threats. Your host is ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Selena Larson⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠, ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Proofpoint⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ intelligence analyst and host of their podcast ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠DISCARDED⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠. Inspired by the residents of a building in New York’s exclusive upper west side, Selena is joined by her co-hosts ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠N2K Networks⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Da
     

Hackers gonna hack back.

8 de Setembro de 2026, 02:00
Welcome in! You’ve entered, Only Malware in the Building. Join us each month to sip tea and solve mysteries about today’s most interesting threats. Your host is ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Selena Larson⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠, ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Proofpoint⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ intelligence analyst and host of their podcast ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠DISCARDED⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠. Inspired by the residents of a building in New York’s exclusive upper west side, Selena is joined by her co-hosts ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠N2K Networks⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Dave Bittner⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ and ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Keith Mularski⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠, former FBI cybercrime investigator and now Chief Global Ambassador at ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Qintel⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠. Being a security researcher is a bit like being a detective: you gather clues, analyze the evidence, and consult the experts to solve the cyber puzzle. This week, Dave, Selena, and Keith explore the pros and cons of allowing select U.S. companies to conduct offensive cyber operations under strict government guardrails. They discuss what the proposed framework could mean for private-sector security researchers, how researchers have already been operating in this space for years, and where the line between defense and offense gets blurry. They also look at how adversaries such as China and Russia use proxy companies and other private-sector entities to conduct cyber operations—and consider whether giving trusted U.S. companies similar capabilities could strengthen cyber defenses or create new risks.

Antes de ontemStream principal
  • ✇Security Affairs
  • JSCeal Hides Crypto Malware in V8 Bytecode 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 u
     

JSCeal Hides Crypto Malware in V8 Bytecode

7 de Setembro de 2026, 07:19

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)

  • ✇Security Affairs
  • Berlin Ransomware Leak Exposes State Secrets 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
     

Berlin Ransomware Leak Exposes State Secrets

7 de Setembro de 2026, 04:19

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)

  • ✇Security Affairs
  • Your MikroTik Router May Already Be Compromised: Look for SSH User “-2” 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 Mikro
     

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

6 de Setembro de 2026, 10:46

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)

  • ✇Security Affairs
  • SECURITY AFFAIRS MALWARE NEWSLETTER ROUND 113 Pierluigi Paganini
    Security Affairs Malware newsletter includes a collection of the best articles and research on malware in the international landscape Malware Newsletter Hackers Steal Claude Login Sessions With Infostealer Malware to Hijack Accounts Fire Ant Evolves: From Hypervisors to Trusted Infrastructure       Gryxa: The AI-Built Toolkit That Watches How You Remove It ValleyRAT masquerading as adware   13 Malicious Packagist Themes Deliver iOS Spyware That Steals Crypto Wallet Seeds  
     

SECURITY AFFAIRS MALWARE NEWSLETTER ROUND 113

6 de Setembro de 2026, 05:27

Security Affairs Malware newsletter includes a collection of the best articles and research on malware in the international landscape

Malware Newsletter

Hackers Steal Claude Login Sessions With Infostealer Malware to Hijack Accounts

Fire Ant Evolves: From Hypervisors to Trusted Infrastructure      

Gryxa: The AI-Built Toolkit That Watches How You Remove It

ValleyRAT masquerading as adware  

13 Malicious Packagist Themes Deliver iOS Spyware That Steals Crypto Wallet Seeds  

Mirage Kitten targeting aviation and FinTech sectors across the Middle East and Africa with a new malware set

Uncovering StreamRat: From Meta Ads to Full Device Takeover  

Counterfeit installers to system compromise: Tracking a deceptive software download campaign

Gaming the system: how a Chinese-speaking actor turned Brazilian government sites into an SEO weapon September 2, 2026

Mini Shai-Hulud’s Latest Wave: 280 New Places It Hunts for Your Secrets  

Pegasus Spyware Infection of Serbian Pro-Democracy Student Activist 

Chinese-Speaking Operator Uses AI Agents to Target Government and Education Systems Across Asia

DPRK APTs: Ted backdoor and curlRAT target South Korean media and automotive sectors

Anatomy of BraZetsu: How Cybercriminals Fuel the Underground Ecosystem

Peer Pressure: Inside the Sality Botnet Disruption Operation

Graph-Based Learning for Android Authorship Attribution: A Comparative Analysis of GNN Models

Stability and Hopf Criteria in a Malware Dissemination Model for Wireless Sensor Networks with Distributed Recovery Delays

PhantomCall: Evading ML Malware Detectors via Function Call Graph Perturbation

REPLICANT: Learning Policies for Evading and Hardening Malware Detectors

Follow me on Twitter: @securityaffairs and Facebook and Mastodon

Pierluigi Paganini

(SecurityAffairs – hacking, newsletter)

❌
❌