The September 2026 SAP Security Patch Day resolves 20 flaws. Apply these SAP Security Patch Day updates to fix CVE-2026-44756 and secure your environment.
Discover the details of the Liquid Network hack. A white hat attacker stole 4,000 Bitcoins but returned most of the funds to force a bug bounty payment.
Patch the critical FreeIPA CVE-2026-76578 immediately. This FreeIPA vulnerability allows complete, unauthenticated administrative access to your servers.
Claude Mythos is the first model reported to complete a cyber kill chain without step-by-step human direction. The finding does not describe malware or a confirmed victim breach. It is a controlled test, but shows how quickly autonomous attack capability is advancing.
The concern is speed. The model found weaknesses, entered a defended enterprise network, collected credentials, raised privileges, moved between systems and reached domain administrator control.
Those are stages defenders try to interrupt during an intrusion. GitHub hosts projects and discussions using the Claude Mythos name, but did not identify a malware campaign.
The finding comes from Booz Allen’s assessment of autonomous models. It is a benchmark result, not evidence of a named program independently attacking organizations.
Booz Allen said in a report shared with Cyber Security News (CSN) that it tested 18 U.S. and Chinese models as autonomous attackers against a production-grade enterprise network. Researchers used network and host telemetry to measure actions, rather than accept model claims.
Claude Mythos AI Autonomously Executes Full Cyber Kill Chain
The Cyber Weapon Index gave Claude Mythos an 80 score, combining 74 for vulnerability research and 86 for kill-chain attainment.
It was the only model assessed as reaching the final objective. Researchers said it moved from a stolen employee credential to administrator-level control in every credentialed attempt.
The harder scenario began with no credentials. The report says Claude Mythos penetrated from outside and worked out how to raise its access, instead of following a fixed plan.
Attack lifecycle (Source – GitHub)
The reported autonomous AI agent breach illustrates why this development has drawn attention. The test examined whether models could spot weaknesses in compiled software without source code.
Only frontier Anthropic models identified the previously unseen flaw used in testing, and only Claude Mythos reportedly exploited it. The result is from a defined setting, not proof of universal performance.
Other models showed progress without matching the full outcome. Four reached domain access and control, four achieved lateral movement, and two reached credential access.
All but one penetrated the network autonomously. An attacker need not finish every stage alone to cause disruption or give a human operator a head start.
Defenders face a speed problem
The report argues that risk lies in the entire AI system, not only its model. An attack harness can link a model with tools, memory, feedback and an execution environment.
A model that stops short alone can become more effective with automation, tailored prompts and operational tools. The report found that a harness paired with Claude Sonnet could rival Claude Mythos. A public model score, therefore, can leave serious blind spots.
The likely entry routes are familiar: exposed services, unpatched flaws, stolen credentials and weak access controls.
AI reduces the time and expertise needed to test options, analyze results and adapt. AI agents rebuilding attack tools illustrate how persistence after failure can amplify this advantage. The recommended response is to assume an initial foothold and restrict what happens next.
Organizations should connect vulnerability management, detection, containment and response; enforce least privilege, strong identity checks, segmentation and isolation of high-value systems; and test containment while keeping services running.
Teams should test safeguards in deployed configurations, including tool permissions and autonomy levels. The report recommends continuous measurement of models and surrounding systems, plus controlled access for vetted defenders to reproduce threatening behavior.
This exceeds paper compliance when attack methods change quickly. The headline is not that an AI model has become a criminal actor. A controlled assessment found one system capable of completing a realistic sequence of offensive tasks.
The gap between early access and full compromise may be narrowing, making patching, identity protection and segmentation urgent. Related AI-driven government system breaches show why coordinated automation needs preparation.
A new intrusion campaign shows how quickly a Windows domain can be turned into a launchpad for deeper compromise. The operators used a Sliver command-and-control beacon, account creation, credential theft and remote administration to establish control after gaining an initial foothold.
The activity was staged from an exposed server and aimed at one unnamed US organisation. Its scripts were built for a real Active Directory environment, including a planned rollout across 18 hosts, while the recovered material contained no proof that ransomware was deployed in this specific incident.
Analysts at The Hunter’s Ledger identified the operation as a high-risk post-exploitation toolkit and tracked it as UTA-2026-024.
The research ties the infrastructure to a confirmed ransomware incident, but does not name the people behind this intrusion or conclude that they deployed an encryptor.
The Hunter’s Ledger said in a report shared with Cyber Security News (CSN) that the operators combined ordinary public tools with unusually detailed knowledge of the victim’s network.
The result was a durable access package designed to disable safeguards, steal credentials and keep its control channels available.
Hackers Disable Endpoint Protection
After entering the domain, the operators scripted the creation of an Active Directory account with a non-expiring password and added it directly to Domain Admins.
They also created a local administrator, enabled Remote Desktop Protocol access, and turned off Network Level Authentication, expanding the paths available for later movement.
The scripts stopped and disabled eight services associated with the victim’s endpoint protection product, then checked each service state.
They also collected the SAM, SYSTEM and SECURITY registry hives for offline password cracking, while a separate LSASS memory dump and Mimikatz supplied additional routes to credentials.
A central concern is the campaign’s persistence. Scheduled tasks ran as SYSTEM, used forged author details and included backdated registration dates.
Kill Chain (Source – THE HUNTER’S LEDGER)
One weekly task downloaded the latest attack chain without saving a fixed payload, a tactic similar to remote scheduled task delivery in EtherRAT attacks.
The team also manipulated the victim’s DNS content filter through its administrative interface. It added the attackers’ domain to an allowlist and placed a matching record in internal DNS, making the domain resolve internally and pass the same security control intended to block it.
This approach mirrors a broader pattern in Windows intrusions, where trusted administrative features become the delivery system after access is obtained.
Recent reporting on fake installer campaigns disabling Defender also showed attackers using installer workflows and scheduled tasks to weaken controls before maintaining access. In both cases, the danger is not a single tool but the sequence of actions surrounding it.
Blockchain C2 Complicates Response
Alongside Sliver, the toolkit used a Node.js implant that obtained its command server from an Ethereum smart contract.
The first domain recorded in that contract was the same one inserted into the victim’s DNS configuration, directly connecting the two seemingly different parts of the operation.
The contract changed domains five times over five months, making simple domain blocks short-lived. Yet the contract itself stayed unchanged and publicly readable, giving defenders a better tracking point.
The related beacon also contacted its main server every 60 seconds with no measured timing variation, a useful signal for network hunting.
The recommended response is to reset credentials across the affected domain, not solely for known accounts; review privileged-group additions and SYSTEM tasks; restore the DNS allowlist; rotate the filter administrator password; and remove planted internal DNS entries.
Teams should also look for RDP enabled with Network Level Authentication disabled and monitor the contract for later C2 changes. Security teams should favor behavior over broad signatures for public tools.
Baseline scheduled tasks, alert on fileless download commands running as SYSTEM and review sudden endpoint-protection service changes.
Historical operator-used address from April 2026, designated monitor-only
Domain
publisherresolution.com
First C2 domain written to the Ethereum resolver contract
Domain
resumeacceptable.com
Historical Ethereum resolver C2 domain
Domain
simultaneouslypower.com
Historical Ethereum resolver C2 domain
Domain
wiselystarting.com
Historical Ethereum resolver C2 domain
Domain
itemrange.com
Most recently recorded Ethereum resolver C2 domain
URL
https://publisherresolution.com
Ethereum resolver contract value
URL
https://resumeacceptable.com
Ethereum resolver contract value
URL
https://simultaneouslypower.com
Ethereum resolver contract value
URL
https://wiselystarting.com
Ethereum resolver contract value
URL
https://itemrange.com
Ethereum resolver contract value
URL
http://193.233.202.17:42718/task_39.ps1
Fileless PowerShell download location used by the persistence task
File name
svcload.exe
Modified PrintSpoofer derivative
File name
ws35.exe
Reverse-shell sample containing the fallback address
File name
ws36.exe
Reverse-shell sample containing the fallback address
File name
ws37.exe
Reverse-shell sample containing the fallback address
File name
ws_3srv.exe
Reverse-shell sample containing the fallback address
File name
task_39.ps1
PowerShell payload retrieved by the scheduled task
File name
slv_beacon_sc.bin
Sliver beacon shellcode payload
Smart contract
0xb3f2897f2bc797e5b9033faef8c81e92b01cb831
Ethereum contract used to resolve the Node.js implant’s C2 location
MSI UpgradeCode
{B3D67F25-0E3A-4B6B-965C-2C7610958983}
Stable installer identifier observed in the MSI package
User-Agent
Chrome/108.0.6602.492
Hardcoded malformed User-Agent associated with the campaign’s request profile
Note:IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
A proof-of-concept zero-click worm dubbed “WeWorm” that it says can spread through WeChat voice calls on both iOS and Android, compromising a target’s WeChat account in seconds without the victim answering the call.
Calif says the bug was reported to Tencent in July and that Tencent has since mitigated the exploit for users, but the research still serves as a stark warning about how mobile messaging apps can become wormable attack surfaces at planetary scale.
WeChat is not a niche target. Tencent says Weixin and WeChat together exceeded 1.4 billion monthly active users as of the end of Q1 2026, while WeChat’s own site describes the platform as serving over 1 billion users with chats and calls across major mobile and desktop platforms.
That sheer reach is what makes Calif’s demonstration so alarming: a memory-corruption flaw in the app’s VoIP stack is not just another messaging bug, but a potential entry point into one of the world’s most deeply embedded communications ecosystems.
According to Calif’s public research listing, WeWorm is described as “the first zero-click worm to spread through WeChat calls across iOS and Android,” and it was published on September 8, 2026, as part of the company’s Android-tagged research work.
Calif frames the finding not as a theoretical edge case but as a live demonstration of how a trusted messaging relationship can be weaponized, with one compromised contact becoming the launch point for attacks against everyone in that person’s social graph.
The company’s demo chain reportedly used three phones to prove cross-platform propagation. A Pixel 10a was used as the initial attacker device, which then called an iPhone 17e and exploited the flaw while the call was still ringing; the compromised iPhone was then used to call another Pixel 10a, which was reportedly taken over in the same way.
In practical terms, that is the textbook definition of a wormable condition in a communications app: the attacker calls the victim, the victim becomes the attacker, and the infection path continues with almost no friction.
What makes the scenario especially dangerous is the “zero-click” aspect. Calif says the victim does not need to answer the call or interact with the phone at all for exploitation to succeed, and even if the person does answer, they hear nothing while the compromise still goes through.
That claim places WeWorm in the most feared class of mobile exploits, where normal user caution offers little protection because there is no malicious link to avoid and no attachment to reject.
Calif also says exploitation yields full control of the victim’s WeChat account, including the ability to read and send messages, place calls, and act on the user’s behalf inside the app.
On its own, account takeover at that level would already be severe for identity abuse, surveillance, fraud, and lateral targeting; chained with additional device-level bugs, Calif says the same access could be extended to full control of the underlying Android or iOS device.
The company specifically links that possibility to its broader AI-assisted exploit research, including Android work such as OEMpocalypse, which it has presented as a path from app-level access to root on several vendor ecosystems.
One condition slightly narrows the attack surface: the attacker must already be on the victim’s friend list. But Calif argues that this is a weak barrier in real-world conditions because once a single trusted contact is compromised, that person’s account can be used to reach additional friends, turning the victim’s social trust network into the worm’s propagation layer.
That is a familiar and troubling pattern in modern communications security, where safety features and trust assumptions designed for convenience can become force multipliers once an adversary gets an initial foothold.
The technical root cause, Calif says, is a memory-corruption bug in WeChat’s VoIP stack, though the company is withholding full exploit details until a later conference presentation.
That restraint matters because memory-corruption flaws in real-time communications code are among the most sensitive bug classes in mobile security, especially when they sit inside call-handling paths that process network data before a user takes any action.
Calif further suggests that this bug is only one example of a broader class of “unconventional attack surfaces” spread across messaging apps, hinting that similar issues may exist in other platforms with rich calling and media features.
WeWorm may be a demo, but its significance is real. Calif has effectively shown that mobile messaging worms are no longer a distant nightmare or a plot device for conference talks; they are a practical research outcome in 2026, built against one of the world’s largest communications platforms and developed at AI speed.
SAP has released its September 2026 Security Patch Day updates, delivering 19 new security notes and one update to a previously issued note.
The patches address vulnerabilities across SAP NetWeaver, SAP Extended Passport Processing, SAP Cloud Application Programming Model, SAP S/4HANA, SAP Integration Suite, SAP Commerce Cloud, and other enterprise products.
The most severe issue is CVE-2026-44756, a critical memory corruption vulnerability in SAP Extended Passport Processing, tracked under SAP Note 3747649. It carries a CVSS score of 10.0, the highest possible severity rating.
The flaw affects multiple SAP kernel and Web Dispatcher versions, including KERNEL 7.22, 7.53, 7.54, 7.77, 7.89, 7.93, 8.04, and 9.16 through 9.20.
An unauthenticated remote attacker could potentially exploit the memory corruption flaw to compromise confidentiality, integrity, and availability. Organizations using affected SAP kernel components should treat this update as an emergency patching priority.
Another critical vulnerability, CVE-2026-58240, affects SAP NetWeaver Message Server. SAP Note 3759472 addresses a missing authentication check with a CVSS score of 9.8. The issue affects KERNEL versions 9.16, 9.18, 9.19, and 9.20.
Successful exploitation could allow an attacker without valid credentials to access or interact with exposed services, creating a serious risk to SAP environments.
SAP Security Updates September 2026
SAP also fixed CVE-2026-76969, a critical credential disclosure vulnerability in multitenant applications using the SAP Cloud Application Programming Model library sap/cds-mtxs.
The flaw has a CVSS score of 9.4 and affects versions up to 1.18.3, 2.7.6, 3.9.6, and 4.0.2. Developers and cloud administrators should update affected dependencies quickly, especially where they handle tenant data and application credentials.
A fourth critical issue, CVE-2026-66768, impacts SAP GUI for Java in SAP NetWeaver. The improper access control vulnerability, fixed by SAP Note 3781729, has a CVSS score of 9.0. It affects BC-FES-JAV 8.10 and could allow a low-privileged attacker to gain unauthorized access after user interaction.
The September release also includes high-severity fixes, including CVE-2026-76958, an 8.5-rated XXE flaw in SAP Integration Suite Trading Partner Management that could expose sensitive files, enable server-side requests, or disrupt XML processing.
SAP patched insecure deserialization in SAP NetWeaver Business Client, memory corruption in SAP NetWeaver Application Server for ABAP and ABAP Platform, and CRLF injection in SAP Commerce Cloud Search and Navigation.
The company also released an update for CVE-2026-58243, a high-severity privilege escalation flaw in SAP ABAP Developer Tools originally addressed during the August 2026 Patch Day.
SAP S/4HANA Finance for Advanced Payment Management S4CORE: 105, 106, 107
Medium
3371336
CVE-2026-76961
Cross-Site Request Forgery (CSRF)
SAP S/4HANA Finance for Advanced Payment Management S4CORE: 108
Medium
3365311
CVE-2026-76959
Cross-Site Request Forgery (CSRF)
SAP S/4HANA Finance for Advanced Payment Management UIAPFI70: 800, 900, 901, 902
Medium
3657599
CVE-2026-76962
Missing authorization check
SAP S/4HANA Manage Bank Chains app S4CORE: 107, 108, 109
Medium
3772838
CVE-2026-76963
Missing authorization check
SAP NetWeaver and ABAP Platform SAP_BASIS: 700, 701, 702, 731, 740, 750, 751, 752, 753, 754, 755, 756, 757, 758
Medium
3736494
CVE-2026-58234
Denial of service
SAP Process Integration SOAP Adapter MESSAGING: 7.50; SAP_XIAF: 7.50
Low
Medium-severity fixes cover SQL injection, server-side request forgery, clickjacking, cross-site request forgery, information disclosure, authorization bypass, and Apache Log4j-related security misconfiguration issues. SAP also patched a low-severity denial-of-service flaw in the SAP Process Integration SOAP Adapter.
SAP administrators should review all relevant security notes in the SAP Support Portal, map them to deployed product versions, test patches under change-control procedures, and apply the fixes as soon as possible.
Internet-facing SAP services, NetWeaver Message Server instances, cloud application dependencies, and systems processing sensitive business data should receive priority attention.
The U.S. Department of State’s Rewards for Justice program has announced a reward of up to $10 million for information leading to the identification or whereabouts of Amir Yaryab, a senior figure in Iran’s Islamic Revolutionary Guard Corps Cyber-Electronic Command (IRGC-CEC).
U.S. officials allege that Yaryab oversees the command’s Cyber Operations Command, managing cyber units responsible for attacks on critical infrastructure across the U.S., Europe, and the Middle East.
This reward is part of broader efforts to combat malicious cyber activities targeting U.S. critical infrastructure, as outlined under the Computer Fraud and Abuse Act.
U.S. Offers $10 Million Reward
Yaryab is said to lead various components within the IRGC-CEC known as Shahid Hemmat and Shahid Shushtari, both involved in cyber and cyber-enabled information campaigns against multiple sectors, including defense, telecommunications, energy, and finance.
U.S. authorities have linked Yaryab to several IRGC-affiliated groups, including CyberAv3ngers and Dadeh Afzar Arman (DAA), which have been implicated in malware incidents and assaults on civilian infrastructure worldwide.
This recent announcement has intensified scrutiny on the Iranian cyber command, especially as operational technology systems remain vulnerable to internet-based threats. The alert correlates with past warnings about CyberAv3ngers targeting industrial control systems.
A joint advisory issued by CISA, the FBI, NSA, EPA, and international collaborators revealed that IRGC-connected actors began compromising Israeli-made Unitronics Vision Series programmable logic controllers (PLCs) in late 2023. These devices are essential in various sectors, including water treatment, energy, transportation, and healthcare.
Reports indicate that between November 2023 and January 2024, CyberAv3ngers initiated multiple waves of attacks against U.S. based Unitronics PLCs, compromising at least 75 devices, 34 of which were in the U.S. water and wastewater sector.
The attackers primarily targeted internet-exposed devices that used default passwords or lacked password protection. The cyber offensive was not merely a matter of defacement; it involved altering the ladder logic within PLCs, which directly manage the operations of physical devices such as pumps and valves.
Unauthorized changes could disrupt essential functions, and attackers also tampered with device names, software versions, and remote access credentials, complicating recovery efforts.
Moreover, in some incidents, individuals responsible for these attacks replaced human-machine interface (HMI) displays with messages asserting responsibility and threatening Israeli-made equipment. This interference can obstruct plant operators from accessing crucial operational data.
CyberAv3ngers’ activities highlight the significant risks to critical infrastructure posed by weak operational technology security. When attackers compromise PLCs, they can take control of critical industrial processes, leading to potentially disastrous consequences.
In response, organizations operating PLCs and HMIs are urged to mitigate risks by identifying and eliminating devices directly exposed to the public internet. Strong password policies, multifactor authentication, and other security measures should be enforced.
For those using Unitronics Vision Series PLCs, CISA recommends updating engineering workstations and firmware to the latest versions and securing remote access through VPNs and firewalls.
Additionally, maintaining updated asset inventories and monitoring for unusual activities can help prevent such cyber threats. The ongoing activities of CyberAv3ngers underscore the urgent need for robust cybersecurity measures in industrial systems to defend against state-aligned adversaries seeking to disrupt critical services.
Panzer ransomware has entered Italy amid a sharp rise in attacks. The ransomware-as-a-service, or RaaS, operation surfaced on August 5 and listed a kitchen manufacturer in Treviso and a telecommunications engineering firm in Catanzaro among its alleged victims.
The group advertises tools for Windows, Linux, FreeBSD, and VMware ESXi systems. An attack on a virtualization host can disrupt many business applications at once, turning one compromised server into a wider outage.
Panzer posted victims across 11 countries and the campaign arrived as claimed ransomware incidents in Italy reached 212 by September 6, above the 169 recorded during all of 2025.
Doimo Cucine and NTE Italia had not publicly confirmed the incidents when the report was published, but their listing may be a credibility-building tactic.
Panzer Ransomware Targets Italian Manufacturers
Panzer stands out less for a publicly examined encryptor than for the business system surrounding it. Prospective affiliates reportedly apply through Tox, face screening, and receive access to a dashboard for builds, negotiations, payment invoices, leak posts, and team accounts.
The stated split gives affiliates 80 percent of each payment and the platform 20 percent. Operators also claim to monitor new affiliates for signs of researcher or law-enforcement access, showing a controlled recruitment process.
Its ESXi option is particularly serious for manufacturers and telecom providers that run core workloads as virtual machines.
An intruder who reaches a hypervisor could encrypt multiple virtual disks and halt dependent services, rather than affecting a single employee device.
Reporting on VMware vCenter attack techniques illustrates how control of virtualization infrastructure can become a direct path to ransomware deployment.
Panzer also appears to pair encryption with data theft. The group claimed 30 GB of stolen data from Doimo Cucine and 16 GB of sensitive documents from NTE Italia.
Backups may restore systems, but they do not remove the pressure created by a threatened data leak or potential reporting duties. Researchers have not independently confirmed Panzer’s first access method or publicly analysed payload.
Available assessments instead associate the operation, with limited confidence, with password attacks, credential theft, remote-service movement, local data collection, security-tool tampering, and data transfers over alternative protocols.
Possible entry routes include vulnerable internet-facing VPN or gateway devices, exposed Remote Desktop Protocol services, phishing messages with malicious documents, and abused remote-management software.
The focus on exposed access points echoes reporting on RDP and VPN attack routes, where stolen credentials and unpatched perimeter systems open a route into internal networks.
Defending virtualized operations
Italian organizations should begin with remote access. Require phishing-resistant multi-factor authentication for VPN, remote administration, and privileged accounts; remove unnecessary privileges; and rotate credentials immediately when compromise is suspected.
Internet-facing appliances and remote-management tools also need prompt patching and regular exposure reviews.
Segmentation is equally important. Keep domain controllers, backup repositories, vCenter, and ESXi management interfaces away from everyday user networks.
Restrict administrative protocols to monitored management segments, so a compromised workstation cannot easily reach the systems that control an entire virtual estate.
Teams should watch for warning signs before encryption begins: unusual VPN logins, new administrator accounts, unexpected PsExec or WMI activity, unapproved remote-management tools, large archives in user or ProgramData folders, and unfamiliar cloud-transfer utilities.
A new ESXi ransomware campaign underscores why telemetry from hypervisors deserves the same attention as endpoint alerts.
Two commands deserve urgent attention when they appear unexpectedly on a server: vssadmin delete shadows and bcdedit recoveryenabled no.
They can remove recovery options, and responders should isolate the affected host, preserve evidence, and begin incident-response procedures rather than waiting for encryption.
Finally, maintain offline or immutable backups for every platform, including virtual machines, and test restorations routinely.
Monitor large outbound transfers, prepare legal and communications plans for double extortion, and ensure that recovery testing covers the applications and dependencies that keep production and telecom services operating.
Note:IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
AI-powered customer service bots are being given more responsibility inside businesses, including access to customer profiles, billing data, support inboxes, account changes, and refund tools. The research showed that attackers may not need traditional vulnerability scanners or direct application exploitation.
Instead, they can manipulate the data and messages an AI agent receives, causing it to reveal sensitive information or perform actions as a legitimate customer.
One major risk involves chatbot transcript features. Many support bots let users email a copy of a conversation. An attacker could inject malicious text into a chat session and use the transcript function to create a phishing email that appears to come from a trusted support address.
If a customer receives a message from support@company.com, they may be more likely to trust it than a normal phishing attempt.
Email spoofing flaws can worsen the issue. Some AI agents identify users by reading the visible From header in an incoming email. However, email delivery and authentication systems may validate a different sender field.
An attacker could send an email that passes authentication using an attacker-controlled address, prompting the AI system to associate the message with a victim’s account.
AI Bots Tricked Into Stealing Security Codes
In one attack scenario, an AI customer service agent could receive a request that appears to come from a victim. The bot may then retrieve billing data, profile information, or account details.
Prompt injection in LLMs (Source: Intigriti)
If the attacker adds their own address to the CC or reply field, the bot could unintentionally send the confidential response to the attacker.
Security researcher Inti De Ceukelaire warned at Bug Bounty Village during DEF CON 34 that these capabilities can be abused through email tricks, prompt injection, identity confusion, and weak authentication checks.
The research also highlighted risks around multi-factor authentication. Some bots require a one-time passcode before making sensitive changes, such as updating a phone number.
But weak email normalization can sometimes allow attackers to reset rate limits by changing the format of an email address while still pointing to the same mailbox.
For example, different systems may treat comments, aliases, or unusual formatting in an email address differently. One component may recognize the address as belonging to the attacker.
Invoking tool calls in LLM chatbots (Source: Intigriti )
At the same time, another backend service could parse embedded data differently and retrieve a victim’s account. This type of flaw is especially dangerous when raw user input is inserted directly into API requests.
AI agents connected to support inboxes can also expose third-party account codes. An attacker may first send an instruction designed to influence the bot’s behavior.
They could then trigger a legitimate password reset email from another service, such as a social media platform, to the company support inbox.
If the AI agent reads the incoming code and follows the earlier malicious instruction, it could forward or leak the code to attacker-controlled infrastructure.
Human approval does not always stop these attacks. A human operator and an AI agent may process different versions of the same email.
Attackers can use multipart messages, hidden HTML, CSS styling, quoted replies, or specially formatted attachments to present a harmless message to a human while exposing a malicious instruction to the AI system.
Leaking OTP’s using Google Chrome’s AI (Source: Intigriti)
Knowledge-base poisoning is another growing concern. Customer service agents often use retrieval-augmented generation to answer questions from company documentation.
If a crawler indexes community comments, user profiles, or untrusted pages on the company domain, attackers may plant false instructions or fake discount codes that the AI treats as trusted internal information.
Organizations deploying AI support agents should strictly separate untrusted customer content from system instructions. They should authenticate users with verified session-bound identity controls, normalize email addresses consistently, validate all tool requests server-side, and prevent bots from sending secrets to unverified recipients.
AI agents should also have limited permissions. A chatbot that can read emails, modify accounts, issue refunds, and access third-party verification codes creates a high-value target. Businesses must treat AI agents as privileged automation systems, not just conversational interfaces.
BigBear 2.0 is a phishing operation designed to steal proof that a user has already passed multi-factor authentication.
It targets Microsoft 365 accounts through convincing sign-in links, then takes over the logged-in browser session rather than attempting to break the authentication factor.
The operation is a rebranded Evilginx2 phishing framework that targets Microsoft 365 accounts. Victims are drawn in through email links that open a proxy page resembling a Microsoft sign-in page.
It relays their traffic to the genuine service while quietly collecting credentials and the session data returned after sign-in.
CloudSEK analysts identified BigBear 2.0 in June 2026 after gaining access to its administrative panel. The researchers linked the activity to an operator using the alias General Boss and found a network of 42 virtual private server nodes.
CloudSEK said in a report shared with Cyber Security News (CSN) that the panel held 5,137 stolen records tied to 461 organizations and 3,331 unique victim IP addresses across more than 40 countries.
Of those records, 474 represented complete authenticated sessions, alongside 1,032 passwords and 4,148 session cookies. The records illustrate an operation that collects both immediate account access and material that may support persistent access later.
BigBear 2.0 Evilginx2 Phishing Campaign Bypasses Microsoft 365 MFA
BigBear 2.0 uses an adversary-in-the-middle setup, meaning it sits between the victim and the real Microsoft login service.
It captures the email address and password, lets Microsoft validate the request, and waits for the victim to complete their normal approval or code challenge.
Campaign Timeline (Source – CloudSEK)
When sign-in succeeds, Microsoft sends an authenticated session cookie to the browser. Because the proxy handled the exchange, it can copy that cookie before forwarding the response.
The attacker can replay it in another browser and enter email, Teams, SharePoint, OneDrive, and connected single sign-on applications as the victim. Microsoft 365 session hijacking campaigns have reported the same account-takeover risk.
This is not a weakness in a one-time password, SMS code, or push notification by itself. These methods confirm the user during the live session, but the proxy steals the resulting proof. BigBear used country-matched residential proxies and scripts that pushed users away from security-key authentication.
The campaign particularly affected IT services and managed service providers, a concern because one compromised provider can offer attackers a route into customer environments.
Organizations should treat a suspected stolen cookie as an identity incident, not merely a password problem. Reset affected passwords, revoke active sessions and refresh tokens, and force a new sign-in for impacted accounts.
Teams should examine mailbox forwarding rules, OAuth consent grants, unfamiliar application access, and sign-in activity for evidence that a hijacked session was used after authentication. This review should begin as soon as suspicious activity is reported.
The most useful long-term control is phishing-resistant authentication, especially FIDO2 or WebAuthn security keys and passkeys where properly deployed.
These methods bind a login cryptographically to the genuine site, making a lookalike proxy far less useful. Passkey attack techniques nevertheless deserve ongoing attention.
Phishlet sample (Source – CloudSEK)
Administrators should require compliant devices through Conditional Access, shorten session lifetimes where appropriate, and watch for unusual residential IP ranges or new browser sessions.
Email filtering should inspect links that imitate sign-in pages even when they use valid certificates. Teams can monitor for the distinctive headers and cookies listed below, because infrastructure can be reassigned.
For users, a familiar Microsoft page and successful MFA prompt do not always prove that a browser is connected directly to Microsoft.
Verify unexpected sign-in requests through a trusted bookmark or known application, not an email link. This concern is reinforced by Evilginx session-cookie attacks, which also depend on real-time relaying rather than stolen passwords alone.
The campaign combined cookie theft, geographic proxy matching, and affiliate access. MFA must be paired with phishing-resistant methods, session controls, and rapid token revocation.
Indicators of compromise (IoCs):-
Type
Indicator
Description
IP address
38[.]60[.]250[.]157
BigBear 2.0 VPS node
IP address
95[.]179[.]233[.]79
BigBear 2.0 VPS node
IP address
80[.]240[.]27[.]55
BigBear 2.0 VPS node
IP address
65[.]20[.]103[.]58
BigBear 2.0 VPS node
IP address
38[.]54[.]124[.]88
BigBear 2.0 VPS node
IP address
208[.]85[.]20[.]79
BigBear 2.0 VPS node
IP address
95[.]179[.]169[.]154
BigBear 2.0 VPS node
IP address
107[.]191[.]46[.]14
BigBear 2.0 VPS node
IP address
130[.]94[.]82[.]180
BigBear 2.0 VPS node
IP address
38[.]54[.]124[.]58
BigBear 2.0 VPS node
IP address
208[.]85[.]18[.]18
BigBear 2.0 VPS node
IP address
45[.]32[.]147[.]239
BigBear 2.0 VPS node
IP address
208[.]76[.]222[.]214
BigBear 2.0 VPS node
IP address
130[.]94[.]82[.]230
BigBear 2.0 VPS node
IP address
65[.]20[.]102[.]80
BigBear 2.0 VPS node
IP address
70[.]34[.]208[.]46
Historical BigBear 2.0 VPS node
IP address
130[.]94[.]113[.]184
Historical BigBear 2.0 VPS node
IP address
78[.]141[.]193[.]59
Historical BigBear 2.0 VPS node
IP address
64[.]176[.]72[.]180
Historical BigBear 2.0 VPS node
IP address
136[.]244[.]114[.]85
Historical BigBear 2.0 VPS node
IP address
70[.]34[.]244[.]122
Historical BigBear 2.0 VPS node
IP address
199[.]247[.]10[.]14
Historical BigBear 2.0 VPS node
IP address
152[.]39[.]137[.]60
Historical BigBear 2.0 VPS node
IP address
91[.]245[.]235[.]208
Historical BigBear 2.0 VPS node
IP address
45[.]32[.]64[.]165
Historical BigBear 2.0 VPS node
Domain
konceptenterprises[.]com
Phishing domain
Domain
ccpipharma[.]com
Phishing domain
Domain
annastudios-paros[.]com
Phishing domain
Domain
dnsforward[.]com
Phishing domain
Domain
hotelmidtownsurat[.]com
Phishing domain
Domain
dataclust[.]com
Phishing domain
Domain
cifutura[.]com
Phishing domain
Domain
hoaivt[.]com
Phishing domain
Domain
dronalms[.]com
Phishing domain
Domain
virextec[.]com
Phishing domain
Domain
offtic[.]com
Phishing domain
Domain
rootreseller[.]com
Phishing domain
Domain
management[.]michaelmarcotte[.]com
Phishing domain
Domain
kgsscans[.]com
Phishing domain
Domain
soil-management[.]com
Phishing domain
Domain
daengrentacar[.]com
Historical phishing domain
Domain
arrmmy[.]com
Historical phishing domain
Domain
captelind[.]com
Historical phishing domain
Domain
planisteradmin[.]com
Historical phishing domain
Domain
hnospascualfadon[.]com
Historical phishing domain
Domain
haliotisbar[.]com
Historical phishing domain
Domain
knowncontractor[.]com
Historical phishing domain
Domain
valtteri[.]net
Historical phishing domain
URL
management[.]daengrentacar[.]com/meetings
Observed live Microsoft 365 phishing page
Filename
cookie.js
File attachment used in the credential-processing workflow
Defanged token for revoked primary administrator bot
Telegram bot
@botterxyz_bot
Affiliate credential-exfiltration bot
Telegram bot token
8625043408[:]AAH6G8X0aW0QhoLEB1uJiYQ5-2aLSJzg8VE
Defanged affiliate bot token
Telegram bot
@PackingitonG_bot
Affiliate credential-exfiltration bot
Telegram bot token
8783369414[:]AAGENRhb7By-0-cQFgrnOw1AW4NbOeUutVE
Defanged affiliate bot token
Telegram bot
@donplayer_bot
Affiliate credential-exfiltration bot
Telegram bot token
8807072847[:]AAEYbUaFcbeAgxTZ2Zl8pFbpjRPM9jXvvzE
Defanged affiliate bot token
Telegram bot
@bolywan_bot
Affiliate credential-exfiltration bot
Telegram bot token
8462028468[:]AAEQt7oq0c3nTHzApQtHk3RdZ7ifnkYd1XM
Defanged affiliate bot token
Telegram bot
@rdsxtdytguyg75d_bot
Affiliate credential-exfiltration bot
Telegram bot token
8794520788[:]AAERSVBlWMpzHc21CCP_-9tL_pjqH9-WuFI
Defanged affiliate bot token
HTTP header
x-evg-token
Evilginx-related application header
HTTP header
x-evg-server
Evilginx-related application header
HTTP header
x-evg-session
Evilginx-related application header
Cookie
evginx_session
Evilginx-related session cookie
Cookie
evginx_token
Evilginx-related token cookie
Cookie
evginx_admin
Evilginx-related administrator cookie
Cookie
bigbear_session
BigBear 2.0 session cookie
Cookie
bigbear_token
BigBear 2.0 token cookie
Note:IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
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.
Images of real children—including a member of a European royal family—were used to create some of the 350 ads containing child sexual abuse. Lawmakers say they plan to investigate.
Jellyfin has released version 12.0, a significant update to its open-source media server. This version includes a wide range of platform improvements and essential security updates affecting both the server and the web client. The project strongly advises administrators to plan their upgrade carefully because it includes database migrations and compatibility-breaking changes for existing deployments. […]
Dell has released security updates for the Secure Connect Gateway (SCG) Application and Appliance after discovering three critical vulnerabilities. These flaws can expose enterprise deployments to unauthenticated administrative access, remote command execution, and potential host-level compromise. Detailed in Dell Security Advisory DSA-2026-382, these issues affect SCG 5.0 appliance versions earlier than 5.36.00.16 and application versions […]
Anthropic’s Claude Mythos Preview has demonstrated the ability to complete an end-to-end enterprise intrusion simulation, progressing from initial access through chained exploitation and network traversal to the defined compromise objective. The result marks a material shift in frontier-model cyber capability: the model did not merely solve isolated CTF-style tasks, but autonomously connected weaknesses commonly found […]
WhatsApp is developing a guest-call feature that would let people without a WhatsApp account join encrypted calls through a web link. This capability would extend WhatsApp’s existing Call Links feature to include guests, letting invited participants join calls directly from a browser without installing the mobile app or creating an account. Currently, the feature is […]
Entrar
.webp)
.webp)
.webp)
.webp)
