IT teams get clear action this week: patch SharePoint servers against an active ransomware chain, apply Fortra’s BoKS fixes for three critical bugs, and audit Microsoft 365 sign-in logs for adversary-in-the-middle phishing aimed at AI policy staff. A breach at the Technical University of Denmark exposed data on up to 200,000 people, and law enforcement detained a suspected ShinyHunters member who is cooperating with investigators.
What is happening with the SharePoint flaws being used to deploy ransomware?
Attackers are chaining flaws in Microsoft SharePoint to disable security tools and drop ransomware on enterprise servers. The activity, tracked as Warlock, is one of the most pressing concerns for any organization running self-hosted SharePoint, because it turns a collaboration server into a ransomware foothold.
The chain targets on-premises SharePoint servers, kills endpoint protection so other defenses cannot flag the payload, and then deploys file-encrypting ransomware across the host. Disabling security tooling before encryption is what makes the incident different from a typical web exploit; the defenders’ usual alarms are turned off in the same step that lets the encryption run.
What to do now:
- Apply the latest SharePoint cumulative updates from Microsoft on every on-premises farm, starting with internet-facing servers.
- Confirm endpoint protection is running, healthy, and reporting after the patches, then re-enable tamper protection if it was turned off during prior troubleshooting.
- Hunt SharePoint IIS logs and Windows event logs for signs of web shell creation, unexpected process spawns from SharePoint, and PowerShell running under the SharePoint service account.
- Restrict SharePoint management ports from the internet and place the farm behind a VPN or reverse proxy where possible.
- Test and confirm offline backups of SharePoint content databases and config databases so recovery does not depend on the same network the attacker reached.
What did the Fortra BoKS patches fix?
Fortra shipped patches for eight vulnerabilities in Core Privileged Access Manager (BoKS), the product used to centrally manage Unix and Linux fleets, with three rated critical. BoKS sits in front of privileged access for thousands of Linux and Unix systems at a time, so a flaw here can hand an attacker the keys to a large estate.
The most severe is CVE-2026-79901 at CVSS 9.9, an authentication bypass in BoKS Manager deployments that rely on the BoKS keytab for Active Directory service account management. AD service account passwords are generated from a predictable pseudo-random sequence seeded with the current Unix timestamp, so an attacker who knows the service principal and can estimate the password-change time can reproduce a limited set of candidates and verify them offline. A standard authenticated AD account can request a service ticket for the affected SPN, and no administrative access to BoKS is normally required.
CVE-2026-79898 at CVSS 9.1 is a command injection in crlserver. An authenticated user can substitute shell commands that run as root on the BoKS Master. It is reachable through BCC and the WSI REST or SOAP API, both of which can be reached over the network without a local sudo or suexec rule.
CVE-2026-12627 at CVSS 9.8 is a stack buffer overflow in BoKS autoregistration that can lead to memory corruption.
What to do now:
- Apply Fortra’s October updates to BoKS Manager and BoKS Master immediately, and confirm the version reported by the console matches the patched release.
- For any deployment still on BoKS keytab-based AD service account management, rotate the AD service account password and force reissuance of Kerberos tickets, then watch for unexpected ticket requests against the affected SPN.
- Restrict network access to BCC and the WSI REST and SOAP APIs to management subnets only, and require a jump host or VPN.
- Audit BoKS logs for unexpected crlserver activity, new autoregistration entries, and any service ticket request from an account that should not be talking to BoKS.
What was exposed in the Technical University of Denmark breach?
The Technical University of Denmark (DTU) disclosed that information belonging to up to 200,000 users may have been exposed after attackers used compromised credentials to log into DTUBasen, the university’s identity and access management (IAM) system. The exposed dataset spans more than two decades of user records, which is why the number is so high for a single institution.
DTUBasen holds records for nearly 40,000 active users and around 160,000 former users. For current users, the potentially exposed data includes Danish civil registration numbers (CPR), full names, home addresses, profile pictures, work email addresses, job titles, office locations, and other employment-related details. The dataset also included the names, relationships, and telephone numbers of next of kin when active users had provided that information. For former users, home addresses, profile pictures, and next-of-kin details are automatically deleted after six months, which limits some of that exposure.
DTU warned that exposed CPR numbers and other personal data could be used for identity fraud and to make phishing attempts more convincing. Notifications are being sent through e-Boks, Denmark’s official digital mailbox system, and the university said it will notify all current and former employees, though not all current and former students will be reached directly.
What to do now for any organization running an IAM platform:
- Force a password reset for every account that can reach the IAM admin console, and require phishing-resistant MFA such as FIDO2 keys rather than SMS or push.
- Review IAM audit logs for impossible-travel sign-ins, logins from new ASNs, and any session that pulled bulk user exports.
- Rate-limit and alert on bulk read calls against the user directory, especially exports of personal data fields like national ID, address, and phone.
- Prepare a notification template in advance so affected users can be told what was exposed, what to watch for, and what steps reduce fraud risk.
What is the latest on the ShinyHunters arrest?
Jordanian authorities detained a suspected ShinyHunters member this week, and the individual is cooperating with the FBI and international partners to help locate others in the extortion group. The arrest matters because ShinyHunters has been linked to large-scale data theft and extortion, and the cooperation is meant to map the rest of the network.
The detained individual was taken into custody on Tuesday, according to two sources familiar with the arrest. The suspect is walking investigators through electronic devices and digital communications to identify and locate alleged co-conspirators. The reported detention follows a September claim by ShinyHunters that it had breached FBI systems via an alleged Oracle PeopleSoft zero-day and moved laterally into FBI-managed AWS GovCloud, claiming to have stolen between 2TB and 3TB of data, including current and former FBI employee information, job applicant data, medical and psychiatric information, and internal service records. The FBI has confirmed it is investigating claims of unauthorized activity but has not confirmed that data was stolen. On September 15, Dutch police arrested a 24-year-old Amsterdam man as part of the same investigation. After that arrest, the FBI publicly warned other ShinyHunters members to turn themselves in.
What to do now for organizations that may have data in past ShinyHunters leaks:
- Re-check exposed credential lists against your domain and SaaS tenants, and force password resets for any matched accounts.
- Watch for extortion emails referencing your organization by name, including sample data fields, and treat any inbound contact from self-described breach actors as a reportable incident.
- Review internet-facing Oracle PeopleSoft and similar enterprise apps for indicators of compromise, unusual admin logins, and unexpected outbound data transfers.
Who is TA419 targeting with Microsoft-themed phishing?
A China-aligned threat activity cluster tracked as TA419 is running adversary-in-the-middle phishing campaigns against U.S. AI policy experts, using Microsoft-themed infrastructure to steal credentials and session cookies. The targeting is narrow but high-value: a successful phish on a policy expert can open doors to sensitive policy discussions and to other figures in the same network.
The campaign uses AitM phishing kits that sit between the victim and the real Microsoft login page, capturing both the password and the active session token. That matters because a stolen session cookie can let an attacker skip MFA prompts on a freshly logged-in account. The lure is built around Microsoft branding and sign-in flows that look identical to the real thing.
What to do now:
- Enforce phishing-resistant MFA (FIDO2 hardware keys or platform-bound passkeys) for all Microsoft 365 accounts, especially for staff handling policy, external affairs, or sensitive research.
- Roll out Microsoft Entra ID Conditional Access to block sign-ins from atypical locations and to require compliant devices.
- Continuously revoke and reissue session tokens for high-risk accounts, and shorten session lifetimes where the policy allows.
- Train staff handling AI policy or external communications to verify any unexpected Microsoft sign-in prompt out-of-band before approving it.
What did the Reserve Bank of India governor say about cyberattacks and financial risk?
The governor of the Reserve Bank of India warned that the next global financial crisis may be triggered by a cyberattack, a war, or a technology failure rather than by a traditional banking failure. The point is that operational risk, not credit risk, is now the most plausible spark for a systemic event.
Speaking at the Kautilya Economic Conclave in New Delhi, the governor said the next crisis may begin with a geopolitical event, a cyberattack, or a technological failure, and singled out AI as making cyber risks worse. He cited faulty models, dependence on outside suppliers, and weaker human oversight as new failure modes, and warned that a slowdown in AI spending or weaker AI-related earnings could set off a sharp fall in asset prices. India’s Finance Minister made a similar point last month, noting that AI helps catch fraud faster but also enables larger attacks. In August, the Financial Stability Board said AI-driven cyberattacks are now the top risk to the global financial system.
What to do now for financial and technology risk leaders:
- Treat third-party AI and SaaS providers as critical infrastructure, with documented exit plans, contract-level security obligations, and continuous monitoring rather than annual review.
- Map which business processes depend on a single model provider or a single cloud region, and design fallbacks.
- Add AI-related scenarios to tabletop exercises, including model failure, supplier compromise, and large-scale fraud enabled by generative AI.
What to do this week
- Patch on-premises SharePoint farms and verify endpoint protection is healthy and tamper-protected.
- Apply Fortra BoKS updates, rotate AD service account passwords tied to BoKS keytab, and restrict access to BoKS WSI REST and SOAP APIs.
- Force IAM password resets, require phishing-resistant MFA, and alert on bulk reads from the user directory.
- Re-check credentials against leaked ShinyHunters data and audit Oracle PeopleSoft and similar enterprise apps for compromise.
- Enforce phishing-resistant MFA and Conditional Access for Microsoft 365 users in policy, research, and external affairs roles.
- Add third-party AI failure and large-scale AI-enabled fraud to your incident response and tabletop plans.
FAQ
What is the active SharePoint ransomware threat?
Attackers are chaining SharePoint flaws to disable endpoint security and drop ransomware on on-premises SharePoint servers, tracked as Warlock. Apply the latest Microsoft cumulative updates, confirm endpoint protection is healthy, and restrict SharePoint management ports from the internet.
How bad are the Fortra BoKS vulnerabilities?
Fortra patched eight BoKS flaws, three rated critical: CVE-2026-79901 (CVSS 9.9) authentication bypass via predictable AD service account passwords, CVE-2026-79898 (CVSS 9.1) command injection in crlserver reachable over the network, and CVE-2026-12627 (CVSS 9.8) stack buffer overflow in autoregistration. Apply the October updates, rotate affected AD service account passwords, and restrict BCC and WSI API access.
How many people were affected by the DTU breach?
Up to 200,000 people, drawn from nearly 40,000 active DTU users and around 160,000 former users, after compromised credentials were used to access the DTUBasen IAM system. Potentially exposed data for active users includes Danish CPR numbers, names, home addresses, profile pictures, work email, job titles, office locations, and next-of-kin contact details.
This article summarizes reporting from thehackernews.com, thehackernews.com, twitter.com, localhost, thehackern.