Latest cyber news, threats, security, and guidelines. Stack up.

Incidents

Thu 22 Oct

Updated Sun 25 Oct

Fisher & Paykel Healthcare says there was unauthorised and unlawful access to two employee email accounts and a subset of company files, some containing personally identifiable information; it says patient-data system not shown to be compromised and no ransomware or malware found

Fisher & Paykel Healthcare Corporation Limited, the respiratory care and sleep apnoea device maker, said in a statement issued from Auckland on 22 October 2026 that it had been made aware of unauthorised and unlawful access to two employee email accounts and a subset of company files, and that it immediately activated its response protocols to contain the incident and investigate. The company said some of the files accessed contained personally identifiable information, that it is in the process of notifying those affected and that it has notified relevant authorities. It said there has been no impact to its products, manufacturing operations or supply chain, that there is no evidence the activity compromised the system that maintains patient data, that it has identified no evidence of ransomware or malware, that it believes the incident has been contained, and that it does not expect any material impact on its financials or operations. The company has not said what kinds of personal information were in the files, how many people are affected or how the accounts were accessed. (sources: NZX announcement; CNA)

Fisher & Paykel Healthcare — F&P Healthcare statement regarding cyber incident (22 Oct 2026)

breaches identity

Incidents

Thu 22 Oct

Updated Sun 25 Oct

Hostwinds says it found unauthorised access to the system that runs its client area and billing, took the client area offline and has since reset every client area password; client area back online on a newly built system

Web hosting provider Hostwinds said on its status page on 22 October 2026 (posted 14:44 UTC, 10:44 pm Perth) that it had 'identified unauthorized access to the system that runs the Hostwinds client area and billing', proactively took the client area offline as a precaution, is working with an independent forensic and cybersecurity firm, and has notified the appropriate law enforcement agencies. Hostwinds said customer servers and websites remained online, but that as a precaution it had disabled access to potentially impacted services, so some customers might not be able to sign in to their server. In an update posted on 24 October (18:11 UTC, 2:11 am Perth 25 Oct), Hostwinds said the client area is back online at clients.hostwinds.com, having reopened on the evening of 23 October on a newly built system; that as part of its response it has reset every client area password, so old passwords no longer work; that it has emailed customers with full details and steps to take; and that its investigation with an independent forensic firm is continuing. In that update Hostwinds said PayPal payments were temporarily unavailable while it reconnected them and that the affiliate portal (affiliates.hostwinds.com) remained offline. Hostwinds has not said what data, if any, was accessed or how the attacker got in. Hostwinds warns that it will never ask for passwords, SSH keys or full card numbers by email, chat or phone, and that a password reset email only arrives after the customer selects 'Forgot password' themselves. (sources: Hostwinds status page; Hostwinds password-reset instructions) UPDATE (25 Oct 2026): In a status post at 19:51 UTC on 24 October (3:51 am Perth 25 Oct), Hostwinds said PayPal payments are working again, that customers whose PayPal payment failed should try again, and that access to the client area remains restored; it said its investigation with an independent forensic firm is continuing. (source: Hostwinds System Status)

Hostwinds System Status — Security incident: PayPal payments restored (24 Oct 2026), Security incident: client area back online, action needed (24 Oct 2026) and Security incident: Hostwinds client area offline (22 Oct 2026)

breaches cloud identity

Incidents

Thu 22 Oct

Capcom says a third party gained unauthorised access to customer information in its CAPCOM ID account service: 11,774,247 email-address records with login metadata worldwide, 43 also with birth date, gender, country and nickname, and passwords changed on 196 accounts; no credit card data

Capcom Co., Ltd. said in a press release on 22 October 2026 that certain customer information tied to CAPCOM ID, the unified account used for its web services and needed to play some Capcom games online, was subject to unauthorised access by a third party. Capcom says the affected information (as of 22 October) is 11,774,247 records worldwide of email addresses plus system identifiers (account creation date and time, last login date and time, number of logins and the client IP address used at the last login); 43 of those records also included date of birth, gender, country/region and nickname, and login passwords on 196 accounts were changed without authorisation and have since been reset. Capcom says it has not confirmed any compromise of passwords originally set by customers and that credit card information was not included. According to Capcom's timeline, it detected suspicious activity on 19 October and confirmed unauthorised access the same day, set up an incident response headquarters on 20 October and confirmed customer information was affected, and reported the incident to the Osaka Prefectural Police and Japan's Personal Information Protection Commission on 21 October. Capcom says it has identified and addressed the attack method, without saying what it was; services that use CAPCOM ID, including games, remain available; it will notify affected customers and has set up dedicated support channels by region, including Asia (excluding Japan) and Oceania. Capcom warns that the information could be misused for fraudulent emails or messages impersonating Capcom. BleepingComputer reported the disclosure on 22 October. Source: Capcom press release (22 Oct 2026); report: BleepingComputer (22 Oct).

Capcom — Notice and Apology Regarding Customer Information Affected Through Unauthorized Access (press release, 22 Oct 2026)

breaches identity

Incidents

Thu 22 Oct

City of Columbia, South Carolina (state capital) says it is responding to a cyberattack that has shut down several city systems, including the MyColaSC resident services platform; the city says police, fire, 911, water and payment systems remain operational, according to The Record (22 Oct)

The city of Columbia, the capital of South Carolina (about 150,000 residents), said it is responding to a cyberattack that has shut down several government systems, according to The Record from Recorded Future News (22 Oct). A city spokesperson told The Record that the city's IT department recently identified suspicious activity and contacted the South Carolina Law Enforcement Division (SLED), which is now leading the investigation. According to The Record, the affected systems include the MyColaSC platform residents use to pay utility bills, report non-emergency issues and reach other city services, as well as Geographic Information Systems and systems supporting animal services; residents were asked to phone in concerns such as potholes, fallen trees and broken streetlights while MyColaSC is down. A city official told The Record that critical public safety and utility systems remain operational, including the Columbia Police Department, Columbia-Richland Fire Department, 911 communications, Columbia Water systems and the Payment Center, including online payment services. The city has not said what kind of attack it was, and The Record says no hacking group had taken credit for the incident as of Wednesday. No Australian impact. Source: The Record (22 Oct).

The Record (Recorded Future News) — South Carolina officials offer assistance after state capital hit with cyberattack (22 Oct 2026)

breaches

Incidents

Thu 22 Oct

INTERPOL Operation Serengeti III: police in 21 countries arrested 1,462 suspects, disrupted 10,909 malicious networks and recovered more than US$105 million in a 29 June–31 August crackdown on cybercrime across Africa

INTERPOL announced on 22 October 2026 the results of Operation Serengeti III, which it describes as one of Africa's largest cybercrime enforcement operations. INTERPOL says investigators from 21 countries, under its coordination, targeted cyber-enabled fraud, ransomware, business email compromise, online scams and digital extortion between 29 June and 31 August 2026, arresting 1,462 suspects, disrupting 10,909 malicious networks and recovering more than US$105 million in illicit funds. INTERPOL says authorities identified 65,929 victims and linked the criminal activity to losses exceeding US$385 million. INTERPOL's highlights: in Uganda, two transnational fraud rings were dismantled and 365 foreign nationals arrested over online investment and pension fraud targeting victims across Asia; in Angola, two illegal cryptocurrency mining centres were dismantled, nine suspects arrested and more than 2,000 mining devices seized; in Nigeria, a suspect was arrested over a large-scale phishing and business email compromise operation that harvested software credentials and amassed about 2.1 million email addresses. INTERPOL says partners including Group-IB, Kaspersky, Fortinet, Team Cymru, Uppsala Security, Cybercrime Atlas, Meta and the Global Anti-Scam Alliance supported the operation, and that several investigations remain active. The participating countries INTERPOL lists are 20 African nations and the United States; INTERPOL names no Australian victims.

INTERPOL — Cybercrime crackdown in Africa nets 1,462 arrests, recovers over USD 105 million (22 Oct 2026)

breaches

Incidents

Wed 21 Oct

Dutch police arrest two over new bank-helpdesk fraud that used AI-generated voice calls and an NFC relay app to empty accounts: about 170 victims and €380,000 in three weeks

Dutch police (politie.nl, 21 October 2026) said Rotterdam's Team Cybercrime arrested two men, aged 23 from Vaassen and 25 from Ede, on 6 October in an investigation led by the Public Prosecution Service into a new form of bank-helpdesk fraud. According to the police, victims received calls playing AI-generated voice clips about suspicious activity on their account; those who pressed 1 were put through to a fake bank employee who pressured them to download an app and hold their bank card to their phone to 'block' it. The app relayed the card's NFC chip data to an accomplice standing at an ATM, who withdrew thousands of euros. In the three weeks the team had sight of the group's servers, police saw about 170 victims and about €380,000 in losses, with victims of all ages from across the Netherlands. Police had the servers taken offline. The 23-year-old is suspected of being the technical lead, the other of a coordinating role; on 20 October a Rotterdam court ordered them held for at least 90 more days. Security Affairs reported the case on 26 Oct.

Politie (Dutch police) — Twee verdachten aangehouden in onderzoek naar nieuwe vorm van bankhelpdeskfraude (21 Oct 2026)

breaches ai

Incidents

Wed 21 Oct

Updated Sat 24 Oct

Toronto Crime Stoppers pauses all tip intake, saying 176,859 Toronto tips from January 2022 to November 2025 were in data stolen in March from P3, the tip software it has used since 2018

Toronto Crime Stoppers said in a statement dated 21 October 2026, on behalf of chair Sean Sportun, that it is pausing its program effective immediately: it has removed the Tip Submit feature from its website, advised its vendor Navigate360/P3 to suspend intake for Toronto Crime Stoppers, and directed Canada's National Anonymous Call Centre to stop accepting or processing new information meant for it. Toronto Crime Stoppers says hackers stole data in March from P3, the tip software it has used since 2018, which is owned by Navigate360. It says Navigate360 told it that 176,859 Toronto tips, dating from January 2022 to November 2025, were in the stolen data and that Navigate360 has found 14,973 names in those tips, without saying whether the names belong to tipsters, people named in tips, or both; its timeline says Navigate360 told it on 6 July that 12,392 of those tips 'potentially' contained personal information. Toronto Crime Stoppers says some original tips containing potentially identifying information were stolen, that Navigate360 has not given it the text of the stolen tips despite numerous requests through its legal counsel, and that Navigate360 told it in April that Toronto's data had not been taken before saying on 9 June that it was affected. It asks people not to send tips by phone, online or through the app until it has a safer way to protect them, and to call 911 if someone is in danger. Source: Toronto Crime Stoppers statement (21 Oct 2026). Updated 22 Oct 2026: The Record reported Toronto's pause, saying it came hours after Canada's CBC reported that more than 1.5 million tips from Crime Stoppers chapters across the country were exposed in the breach; according to The Record, about half of the 1.5 million leaked tips CBC studied, some dating back 25 years, contained personal information, and CBC reporters reviewed hacked data made available to them in March by Distributed Denial of Secrets (DDoSecrets). The Record says a hacktivist collective known as Internet Yiff Machine claimed responsibility for the March breach. (source: The Record, including its account of CBC's reporting)

Toronto Crime Stoppers — Statement from Toronto Crime Stoppers on the P3 data breach (21 Oct 2026; PDF with timeline)

breaches

Incidents

Wed 21 Oct

Updated Sat 24 Oct

Railway (cloud app deployment platform) says an attacker seeking AI provider API keys reached a subset of its internal systems between 20 and 22 October (UTC) and decrypted a subset of customers' environment variables, with at most 1.85% of workspaces (about 100,000) potentially affected; it urges users to roll secrets stored before 21 October, has invalidated all Railway API tokens and has restored builds for all tiers

Railway's security disclosure, posted by Jacob Cooper on 21 October 2026, says Railway detected anomalous activity that morning involving systems that store customer environment variables, and that its investigation to date indicates an unauthorised third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents. Railway notes environment variables may contain secrets such as API keys or database and registry credentials. Railway says it believes this is part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers, and that it has notified those upstream providers to revoke all keys proactively. Railway says its initial analysis suggests the impact may be limited to a subset of users, but it recommends that all users immediately roll every environment variable stored in Railway, including API keys, and any private registry credentials, and review logs for those services for unusual activity; it says it will email affected customers directly as it confirms which accounts were affected. Railway's status page carries the incident as 'Railway Platform Outage', first posted at 07:24 UTC on 21 October (3:24 pm Perth); at 09:28 UTC (5:28 pm Perth) Railway said its dashboard, API and CLI were unavailable and new builds paused in all regions, and at 21:59 UTC (5:59 am Perth 22 Oct) it linked the security notice. At 22:10 UTC (6:10 am Perth 22 Oct) Railway said it was rotating all Railway bucket credentials, with new credentials appearing in dashboards automatically but services unable to be redeployed to pick them up until builds are restored; at 22:45 UTC (6:45 am Perth 22 Oct) it said builds remained paused and that the credential revocations shown in customers' audit logs, carried out by a Railway employee, are expected. Railway has not said how the attacker gained access or how many accounts are affected. UPDATE 22 October (Railway status page): at 01:22 UTC (9:22 am Perth) Railway published guides on recommended next steps, covering checks for unexpected usage at OpenRouter, Anthropic, OpenAI, Grok and Stripe, checks for anomalous GitHub, AWS and GCP access, rotation of PostgreSQL, MySQL, MongoDB and Redis database credentials, and redeploying buckets and reconnecting GitHub after the credential reset; Railway says some steps require a redeploy and will have to wait until builds are available, but others can begin now. In its 03:00 UTC update (11:00 am Perth) Railway said builds remained paused and it expected to have an update for Enterprise users soon. UPDATE 22 October, later (Railway status page): at 03:32 UTC (11:32 am Perth) Railway said builds for Enterprise workspaces are now available, so Enterprise customers can complete the guide steps that require a redeploy, including applying new credentials, with Pro, Hobby, then Free and Trial plans to follow in stages. At 04:17 UTC (12:17 pm Perth) Railway said that, in accordance with its security disclosure, it has invalidated all Railway API tokens, so integrations using the Railway Public API need new tokens. From 04:39 UTC Railway reported deployments stalling at stages such as 'Running pre-deploy command'; at 06:01 UTC it said it was still working on enabling builds for Pro, Hobby, then Free and Trial, and at 06:12 UTC (2:12 pm Perth) it said Enterprise deployments were moving through each stage at normal speed. UPDATE 22 October, evening (Railway status page): at 06:29 UTC (2:29 pm Perth) Railway said builds are now available for Pro and Enterprise workspaces, so Pro customers can complete the guide steps that require a redeploy. At 10:15 UTC Railway said some builds were still failing more often than usual and many deployments remained queued; in its 11:47 UTC update (7:47 pm Perth) it said deployment wait times were coming down, though some deployments may still take longer than usual to start, and that it was still working on enabling builds for Hobby, then Free and Trial. UPDATE 23 October (Railway status page): at 21:08 UTC on 22 October (5:08 am Perth 23 Oct) Railway said builds are now available for Hobby workspaces and that new signups remain temporarily paused; at 21:59 UTC (5:59 am Perth) it said builds are enabled for Hobby, Pro and Enterprise workspaces, are generally completing successfully but may take longer than usual, and that it will update when it enables builds for Free and Trial workspaces. Correction (23 Oct 2026): an earlier version put Railway's 'dashboard, API and CLI unavailable' post at 11:33 UTC on 21 October, the security-notice link at 22:10 UTC and the bucket-credential rotation notice at 22:37 UTC; Railway's status page shows those posts at 09:28 UTC, 21:59 UTC and 22:10 UTC. (source: Railway status page) UPDATE (24 Oct 2026): Railway's preliminary report, published at 23:31 UTC on 22 October (7:31 am Perth 23 Oct), says the incident led to unauthorised access to a subset of internal Railway systems and that early investigation indicates the attacker was trying to obtain AI provider API keys to perform distillation attacks. Railway puts the attack between 13:58 UTC on 20 October and 03:32 UTC on 22 October, when it confirmed the attacker no longer had access to any internal systems. Railway says the attacker pulled secrets in encrypted form, later accessed credentials for its CI environment and decrypted artifacts holding additional API access, and ran an unauthorised query of encrypted environment variables, a subset of which were decrypted using the compromised credentials. Railway says at most 1.85% of all workspaces, about 100,000, had some environment variables potentially compromised; because it cannot tell which variables were decrypted, it is also contacting other users it considers high risk. Railway says the attacker did not access Railway user accounts, that it is not ruling out access to user source code until its final forensic report, and that it gave vendors such as GitHub and SpaceXSI all API keys on the platform, so a revocation notice from a vendor does not by itself mean a user's credentials were affected. Railway says existing deployments stayed online, builds for all tiers are restored, and it has engaged external incident response experts and the authorities. (source: Railway preliminary report)

Railway — Security Disclosure: Wednesday October 21st (21 Oct 2026)

breaches cloud identity

Incidents

Wed 21 Oct

Updated Wed 28 Oct

Onamae.com Desktop Cloud (Japan): GMO Internet says the service had security vulnerabilities, customer information was taken and some customers report trading-account transactions they did not make; it refuses an attacker's money demand, will compensate losses and says up to 26,739 servers may be affected

In a notice on Onamae.com dated 21 October 2026 (status as of 4:00 Japan time, 3:00 am Perth), the operator of Onamae.com Desktop Cloud apologised and said a third party had gained unauthorised access to the service, and that on 20 October it confirmed malicious programs had been installed in some customers' server environments. The notice says information stored on the servers may have been viewed and puts the number of servers that may be affected at 26,739; it says that so far it has not confirmed any leak of customers' personal information it holds or any misuse of viewed information, and that it does not hold payment information, including credit card details. To prevent further damage, the operator says it began shutting down customers' servers in stages from 4:00 on 21 October, covering all Desktop Cloud plans, and will announce a restart date once it is decided; its investigation of customer servers continues. It asks customers who stored or used credentials such as IDs and passwords on their servers to change them promptly, including anywhere the same password is reused, and warns of phishing emails and suspicious contacts exploiting the incident, saying it never asks for passwords or card details by email or phone. According to BleepingComputer, Onamae.com is operated by GMO Internet, part of GMO Internet Group, and the Desktop Cloud service is marketed for running MetaTrader 4 automated FX trading. UPDATE (27 Oct 2026; GMO Internet): In its second and third reports (22 October, as of 16:59 JST, and 23 October, as of 15:30 JST), GMO Internet said customers had reported unauthorised operations on their trading accounts, that login details for trading tools such as MT4/MT5 saved on the servers may have been obtained and used illegally by a third party, that it is investigating with an external cybersecurity firm, and that it consulted the police on 22 October; it says 26,739 is the number of servers that may be affected, not the number of confirmed cases. In its fourth report (24 October, as of 11:50 JST, 10:50 am Perth), GMO said its investigation had confirmed that the service's systems had security vulnerabilities, that its environment was accessed without authorisation and that customer information was taken outside the company, and that some customers had reported transactions in their trading accounts that they did not recognise. GMO says it will pay every current customer a flat JPY 5,000 condolence payment, will compensate realised losses from transactions its investigation confirms were unauthorised, and will announce how to apply by 6 November; it says it has asked major exchanges and securities companies to block access via the service, forcibly terminate all active sessions and monitor for unauthorised transactions, and has asked government agencies to apply active cyber defence measures. GMO says it received a demand for money from a person believed to be the attacker, with threats that included further manipulation of customers' trading accounts at more than 70 securities and FX companies and publication of information about the company and its customers, and that it will not comply because paying would not guarantee the information is deleted or its misuse prevented. In its seventh report (26 October, as of 23:10 JST, 10:10 pm Perth), GMO said the threatening email arrived on 21 October and demanded approximately 8 billion yen, and that persons believed to be the attackers had told it they would publish customer information and carry out a ransomware attack at 12:00 on 27 October; it said it was collecting and analysing customers' devices. In its ninth report (Japanese, dated 27 October, as of 11:59, no time zone stated), GMO says no malware, including ransomware, has been found on the devices it has finished analysing, but that analysis continues and it has not confirmed that every customer's device is safe; it asked customers to back up their data and then disconnect and power off their PCs before 12:00, and says it will provide a new PC of equivalent performance to customers whose PCs are hit by ransomware. (source: GMO Internet) UPDATE (27 Oct 2026; GMO Internet): In its tenth report (Japanese, dated 27 October, as of 13:55, no time zone stated), GMO says it confirmed at 12:30 on 27 October that a person believed to be the attacker had published what it claims is information about GMO and its customers; GMO says it is still checking the content, which may include things that are not true, and that it will contact customers individually if it confirms their information is included. GMO warns people not to visit or spread the published material, saying the information of anyone who accesses that site is obtained by the attacker, and says it is preparing legal action, including criminal complaints, against people who spread it maliciously. GMO says no ransomware attack had been confirmed as of 13:55 on 27 October, that it has begun considering a further payment, separate from the JPY 5,000, for customers whose information it confirms was published, and that security companies including Trend Micro and AI companies have offered to help. In its eleventh report (as of 14:55 on 27 October, no time zone stated), GMO repeats that it will not meet the attacker's demands or pay, and says it has consulted the police and other authorities. (source: GMO Internet) UPDATE (28 Oct 2026, Perth; GMO Internet): In its twelfth report (Japanese, dated 27 October, as of 19:10, no time zone stated), GMO says it will never meet the attackers' demands and sets out a special payment for customers whose information it confirms was published by the attacker: JPY 10,000 for basic details such as name and contact information, JPY 15,000 for financial or authentication details such as trading-account IDs and passwords, and JPY 25,000 for sensitive or special-care personal information, added together per category up to JPY 3 million per publication, and separate from the flat JPY 5,000 payment and loss compensation announced earlier. GMO Internet Group is also creating a "GMO Cybercrime Bounty" of up to US$1 million in total (about JPY 150 million at JPY 150 to the dollar, GMO says) for specific, verifiable information that helps identify or arrest those involved; GMO says submissions open at 12:00 Japan time on 28 October (11:00 Perth) at cybercrimebounty.gmo, that the reward is not a ransom or a payment for the stolen data, and that people must not hack, contact or pay the attackers themselves. GMO again warns that anyone who accesses the site carrying the published data has their own information captured by the attacker, and asks anyone who has visited it to run a full antivirus scan. (source: GMO Internet)

Onamae.com — Desktop Cloud unauthorised access notice (Japanese, 21 Oct 2026, as of 4:00 JST)

breaches cloud

Incidents

Wed 21 Oct

Updated Mon 2 Nov

State Bank of India discloses data loss: 3,897 customer records with personal details found in a set of about 375,000 records on the dark web, flagged by CERT-In and the Defence Cyber Agency on 16 October

State Bank of India (SBI), India's largest bank, told the BSE and NSE stock exchanges on 21 October 2026 that it 'has experienced an incident involving the loss of certain data'. On 16 October it received alerts from its threat intelligence provider, India's Defence Cyber Agency and CERT-In about suspected exposure of SBI customer data on the dark web. In a preliminary analysis of about 375,000 records available there, the bank identified 3,897 customer records containing personal information. The filing says the exposed information reportedly included registered mobile numbers, dates of birth, names, gender, email addresses, residential addresses, branch and customer information file (CIF) identifiers, lead IDs, and metadata from loan and lead records and related files. Account numbers, passwords, card details and government ID numbers are not among the categories listed. SBI says it activated its incident response and containment procedures, engaged an independent CERT-In-empanelled firm to investigate the authenticity, source and extent of the exposure, and that there is no material impact on its core operations. The filing does not say whether SBI's own systems, a subsidiary or a third party were the source, or whether affected customers will be notified. (source: State Bank of India filing) Correction (02 Nov 2026): removed The Hacker News as a source; removed details no other source gives. (source: State Bank of India)

State Bank of India — Regulation 30 disclosure: Incident involving Data Loss (NSE/BSE filing, 21 Oct 2026)

breaches

Incidents

Tue 20 Oct

Updated Mon 2 Nov

More than 300 Tor exit relays were hijacked in early October to intercept SSH logins made over Tor and harvest passwords; one operator found the Ebury 1.8.3 OpenSSH backdoor on his servers, and the Tor Project had removed all affected relays by 5 October

Attackers took over more than 300 Tor exit relays between 1 and 5 October 2026 and rewrote their exit policies to carry SSH (port 22) and plaintext mail, so that SSH connections made through Tor were redirected to 12 interception servers that could capture passwords. A researcher publishing as kaba noticed a changed host-key warning on 2 October, scanned all of Tor's roughly 3,000 exits that day and found 333 redirecting SSH to the same interception servers; he reported it to the Tor Project's network health team, which also spotted the policy change. Directory authorities flagged affected relays BadExit and MiddleOnly from 18:00 UTC on 4 October, and by 17:00 UTC on 5 October no relay with the attacker's policy remained in the consensus. A directory-data analysis on the tor-relays list counts 377 relays from 59 operators that switched to the attacker's policy between 1 and 4 October (about 7.46% of exit capacity at the peak), many hosted at FranTech/BuyVM. Only password logins could be stolen: a user had to connect to an SSH server over Tor in that window, hit one of the hijacked exits, accept the interceptor's host key and type a password; key-based logins cannot be relayed this way. The interceptor passed the session through to the real server, watched commands and could log in separately with the stolen password to check sudo and run an installer. Relay operator Zimmer (Quetzalcoatl family) wrote in a post-mortem on 7 October that two of his servers had been running the Ebury 1.8.3 OpenSSH backdoor since 28 August, after an attacker logged in with a reused password over SSH password authentication; this Ebury version is newer than ESET's published indicators. No victim count exists and who is behind the campaign is unknown. (sources: Tor Project notice to relay operators; kaba's write-up; Tor Project tor-relays list posts by Zimmer and 1AEO) Correction (02 Nov 2026): removed The Hacker News as a source. (source: Tor Project tor-relays list; kaba)

kaba — How I got over 300 Tor exit nodes removed (researcher write-up, 20 Oct 2026)

breaches network

Incidents

Tue 20 Oct

Updated Tue 27 Oct

Symantec: Russia's APT28 (Swallowtail, Fancy Bear) used the Hookedge backdoor against a naval shipbuilder, a military aircraft engine maker and a law enforcement agency in two NATO countries; two-month shipbuilder intrusion with an SSH tunnel and a new in-memory loader

Symantec's Threat Hunter Team (Broadcom) reported on 20 October 2026, also reported by The Record on 20 October, that the GRU-linked group it calls Swallowtail (APT28, Fancy Bear, Forest Blizzard) targeted a naval shipbuilder, a manufacturer of military aircraft engines and a law enforcement agency in two unnamed European NATO member states. At the shipbuilder an employee opened a macro-enabled Word attachment on 24 July 2026, which dropped Hookedge, a backdoor first documented by Recorded Future's Insikt Group in August that fetches tasks through a hidden off-screen Microsoft Edge window and the webhook.site service. A second stage later moved to an attacker IP address, and over about a week of hands-on activity the operators planted an SSH private key to open a persistent reverse SSH tunnel from their server into the internal network, captured NTLM handshakes with a short PowerShell loopback listener, and deployed ld.exe, a previously undocumented reflective loader that decrypts a payload in memory only with a key passed at run time (the payload was not recovered). Activity ran from 24 July to at least 24 September. Symantec could not say whether data was stolen but says defence information was the likely aim and the campaign appears ongoing. No Australian targets were reported. (sources: Symantec Threat Hunter Team; The Record) Correction (27 Oct 2026): the card date has moved from 19 to 20 October 2026, the date both Symantec's post and The Record's report visibly show; an earlier '19 October US time' for The Record rested on a guessed time zone. (source: The Record)

Symantec Threat Hunter Team — Swallowtail: Russian espionage group targets defense firms in two NATO countries (20 Oct 2026)

breaches network identity