Category: Cybersecurity

AI agents are accelerating how work gets done. They schedule meetings, access data, trigger workflows, write code, and take action in real time, pushing productivity beyond human speed across the enterprise.

Then comes the moment every security team eventually hits:

“Wait… who approved this?”

Unlike users or applications, AI agents are often deployed quickly, shared broadly, and granted wide access permissions, making ownership, approval, and accountability difficult to trace. What was once a straightforward question is now surprisingly hard to answer.

AI Agents Break Traditional Access Models

AI agents are not just another type of user. They fundamentally differ from both humans and traditional service accounts, and those differences are what break existing access and approval models.

Human access is built around clear intent. Permissions are tied to a role, reviewed periodically, and constrained by time and context. Service accounts, while non-human, are typically purpose-built, narrowly scoped, and tied to a specific application or function.

AI agents are different. They operate with delegated authority and can act on behalf of multiple users or teams without requiring ongoing human involvement. Once authorized, they are autonomous, persistent, and often act across systems, moving between various systems and data sources to complete tasks end-to-end.

In this model, delegated access doesn’t just automate user actions, it expands them. Human users are constrained by the permissions they are explicitly granted, but AI agents are often given broader, more powerful access to operate effectively. As a result, the agent can perform actions that the user themselves was never authorized to take. Once that access exists, the agent can act – even if the user never meant to perform the action, or wasn’t aware it was possible, the agent can still execute it. As a result, the agent can create exposure – sometimes accidentally, sometimes implicitly, but always legitimately from a technical standpoint.

This is how access drift occurs. Agents quietly accumulate permissions as their scope expands. Integrations are added, roles change, teams come and go, but the agent’s access remains. They become a powerful intermediary with broad, long-lived permissions and often with no clear owner.

It’s no wonder existing IAM assumptions break down. IAM assumes a clear identity, a defined owner, static roles, and periodic reviews that map to human behavior. AI agents don’t follow those patterns. They don’t fit neatly into user or service account categories, they operate continuously, and their effective access is defined by how they are used, not how they were originally approved. Without rethinking these assumptions, IAM becomes blind to the real risk AI agents introduce.

Personal agents are AI assistants used by individual employees to help with day-to-day tasks. They draft content, summarize information, schedule meetings, or assist with coding, always in the context of a single user.

These agents typically operate within the permissions of the user who owns them. Their access is inherited, not expanded. If the user loses access, the agent does too. Because ownership is clear and scope is limited, the blast radius is relatively small. Risk is tied directly to the individual user, making personal agents the easiest to understand, govern, and remediate.

Third-Party Agents (Vendor-Owned)

Third-party agents are embedded into SaaS and AI platforms, provided by vendors as part of their product. Examples include AI features embedded into CRM systems, collaboration tools, or security platforms.

These agents are governed through vendor controls, contracts, and shared responsibility models. While customers may have limited visibility into how they work internally, accountability is clearly defined: the vendor owns the agent.

The primary concern here is the AI supply-chain risk: trusting that the vendor secures its agents appropriately. But from an enterprise perspective, ownership, approval paths, and responsibility are usually well understood.

Organizational Agents (Shared and Often Ownerless)

Organizational agents are deployed internally and shared across teams, workflows, and use cases. They automate processes, integrate systems, and act on behalf of multiple users. To be effective, these agents are often granted broad, persistent permissions that exceed any single user’s access.

This is where risk concentrates. Organizational agents frequently have no clear owner, no single approver, and no defined lifecycle. When something goes wrong, it’s unclear who is responsible or even who fully understands what the agent can do.

As a result, organizational agents represent the highest risk and the largest blast radius, not because they are malicious, but because they operate at scale without clear accountability.

The Agentic Authorization Bypass Problem

As we explained in our article, agents creating authorization bypass paths, AI agents don’t just execute tasks, they act as access intermediaries. Instead of users interacting directly with systems, agents operate on their behalf, using their own credentials, tokens, and integrations. This shifts where authorization decisions actually happen.

When agents operate on behalf of individual users, they can provide the user access and capabilities beyond the user’s approved permissions. A user who cannot directly access certain data or perform specific actions may still trigger an agent that can. The agent becomes a proxy, enabling actions the user could never execute on their own.

These actions are technically authorized – the agent has valid access. However, they are contextually unsafe. Traditional access controls don’t trigger any alert because the credentials are legitimate. This is the core of the agentic authorization bypass: access is granted correctly, but used in ways security models were never designed to handle.

Rethinking Risk: What Needs to Change

Securing AI agents requires a fundamental shift in how risk is defined and managed. Agents can no longer be treated as extensions of users or as background automation processes. They must be treated as sensitive, potentially high-risk entities with their own identities, permissions, and risk profiles.

This starts with clear ownership and accountability. Every agent must have a defined owner responsible for its purpose, scope of access, and ongoing review. Without ownership, approval is meaningless and risk remains unmanaged.

Critically, organizations must also map how users interact with agents. It is not enough to understand what an agent can access; security teams need visibility into which users can invoke an agent, under what conditions, and with what effective permissions. Without this user–agent connection map, agents can silently become authorization bypass paths, enabling users to indirectly perform actions they are not permitted to execute directly.

Finally, organizations must map agent access, integrations, and data paths across systems. Only by correlating user → agent → system → action can teams accurately assess blast radius, detect misuse, and reliably investigate suspicious activity when something goes wrong.

The Cost of Uncontrolled Organizational AI Agents

Uncontrolled organizational AI agents turn productivity gains into systemic risk. Shared across teams and granted broad, persistent access, these agents operate without clear ownership or accountability. Over time, they can be used for new tasks, create new execution paths, and their actions become harder to trace or contain. When something goes wrong, there is no clear owner to respond, remediate, or even understand the full blast radius. Without visibility, ownership, and access controls, organizational AI agents become one of the most dangerous, and least governed elements in the enterprise security landscape.

To learn more visit https://wing.security/

Ravie LakshmananJan 24, 2026Vulnerability / Enterprise Security

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Friday added a critical security flaw affecting Broadcom VMware vCenter Server that was patched in June 2024 to its Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation in the wild.

The vulnerability in question is CVE-2024-37079 (CVSS score: 9.8), which refers to a heap overflow in the implementation of the DCE/RPC protocol that could allow a bad actor with network access to vCenter Server to achieve remote code execution by sending a specially crafted network packet.

It was resolved by Broadcom in June 2024, along with CVE-2024-37080, another heap overflow in the implementation of the DCE/RPC protocol that could lead to remote code execution. Chinese cybersecurity company QiAnXin LegendSec researchers Hao Zheng and Zibo Li were credited with discovering and reporting the issues.

In a presentation at the Black Hat Asia security conference in April 2025, the researchers said the two flaws are part of a set of four vulnerabilities – three heap overflows and one privilege escalation – that were discovered in the DCE/RPC service. The two other flaws, CVE-2024-38812 and CVE-2024-38813, were patched by Broadcom in September 2024.

In particular, they found that one of the heap overflow vulnerabilities could be chained with the privilege escalation vulnerability (CVE-2024-38813) to achieve unauthorized remote root access and ultimately gain control over ESXi.

It’s currently not known how CVE-2024-37079 is being exploited, if it’s the work of any known threat actor or group, or the scale of such attacks. However, Broadcom has since updated its advisory to officially confirm in-the-wild abuse of the vulnerability.

“Broadcom has information to suggest that exploitation of CVE-2024-37079 has occurred in the wild,” the company said in its update.

In light of active exploitation, Federal Civilian Executive Branch (FCEB) agencies are required to update to the latest version by February 13, 2026, for optimal protection.

Ravie LakshmananJan 24, 2026Malware / Critical Infrastructure

The Russian nation-state hacking group known as Sandworm has been attributed to what has been described as the “largest cyber attack” targeting Poland’s power system in the last week of December 2025.

The attack was unsuccessful, the country’s energy minister, Milosz Motyka, said last week.

“The command of the cyberspace forces has diagnosed in the last days of the year the strongest attack on the energy infrastructure in years,” Motyka was quoted as saying.

According to a new report by ESET, the attack was the work of Sandworm, which deployed a previously undocumented wiper malware codenamed DynoWiper. The links to Sandworm are based on overlaps with prior wiper activity associated with the adversary, particularly in the aftermath of Russia’s military invasion of Ukraine in February 2022.

The Slovakian cybersecurity company, which identified the use of the wiper as part of the attempted disruptive attack aimed at the Polish energy sector on December 29, 2025, said there is no evidence of successful disruption.

The December 29 and 30, 2025, attacks targeted two combined heat and power (CHP) plants, as well as a system enabling the management of electricity generated from renewable energy sources such as wind turbines and photovoltaic farms, the Polish government said.

“Everything indicates that these attacks were prepared by groups directly linked to the Russian services,” Prime Minister Donald Tusk said, adding the government is readying extra safeguards, including a key cybersecurity legislation that will impose strict requirements on risk management, protection of information technology (IT) and operational technology (OT) systems, and incident response.

It’s worth noting that the activity occurred on the tenth anniversary of the Sandworm’s attack against the Ukrainian power grid in December 2015, which led to the deployment of the BlackEnergy malware, plunging parts of the Ivano-Frankivsk region of Ukraine into darkness.

The trojan, which was used to plant a wiper malware dubbed KillDisk, caused a 4–6 hour power outage for approximately 230,000 people.

“Sandworm has a long history of disruptive cyber attacks, especially on Ukraine’s critical infrastructure,” ESET said. “Fast forward a decade and Sandworm continues to target entities operating in various critical infrastructure sectors.”

In June 2025, Cisco Talos said a critical infrastructure entity within Ukraine was targeted by a previously unseen data wiper malware named PathWiper that shares some level of functional overlap with Sandworm’s HermeticWiper.

The Russian hacking group has also been observed deploying data-wiping malware, such as ZEROLOT and Sting, in a Ukrainian university network, followed by serving multiple data-wiping malware variants against Ukrainian entities active in the governmental, energy, logistics, and grain sectors between June and September 2025.

A new multi-stage phishing campaign has been observed targeting users in Russia with ransomware and a remote access trojan called Amnesia RAT.

“The attack begins with social engineering lures delivered via business-themed documents crafted to appear routine and benign,” Fortinet FortiGuard Labs researcher Cara Lin said in a technical breakdown published this week. “These documents and accompanying scripts serve as visual distractions, diverting victims to fake tasks or status messages while malicious activity runs silently in the background.”

The campaign stands out for a couple of reasons. First, it uses multiple public cloud services to distribute different kinds of payloads. While GitHub is mainly used to distribute scripts, binary payloads are staged on Dropbox. This separation complicates takedown efforts, effectively improving resilience.

Another “defining characteristic” of the campaign, per Fortinet, is the operational abuse of defendnot to disable Microsoft Defender. Defendnot was released last year by a security researcher who goes by the online alias es3n1n as a way to trick the security program into believing another antivirus product has already installed on the Windows host.

Once the document is displayed to the victim to keep up the ruse, the script sends a message to the attacker using the Telegram Bot API, informing the operator that the first stage has been successfully executed. A deliberately-introduced 444 second delay later, the PowerShell script runs a Visual Basic Script (“SCRRC4ryuk.vbe”) hosted at the same repository location.

This offers two crucial advantages in that it keeps the loader lightweight and allows the threat actors to update or replace the payload’s functionality on the fly without having to introduce any changes to the attack chain itself.

The Visual Basic Script is highly obfuscated and acts as the controller that assembles the next-stage payload directly in memory, thereby avoiding leaving any artifacts on disk. The final-stage script checks if it’s running with elevated privileges, and, if not, repeatedly displays a User Account Control (UAC) prompt to force the victim to grant it the necessary permissions. The script pauses for 3,000 milliseconds between attempts.

In the next phase, the malware initiates a series of actions to suppress visibility, neutralize endpoint protection mechanisms, conduct reconnaissance, inhibit recovery, and ultimately deploy the main payloads –

• Configure Microsoft Defender exclusions to prevent the program from scanning ProgramData, Program Files, Desktop, Downloads, and the system temporary directory
• Use PowerShell to turn off additional Defender protection components
• Deploy defendnot to register a fake antivirus product with the Windows Security Center interface and cause Microsoft Defender to disable itself to avoid potential conflicts
• Conduct environment reconnaissance and surveillance via screenshot capture by means of a dedicated .NET module downloaded from the GitHub repository that takes a screengrab every 30 seconds, save it as a PNG image, and exfiltrates the data using a Telegram bot
• Disable Windows administrative and diagnostic tools by tampering with the Registry-based policy controls
• Implement a file association hijacking mechanism such that opening files with certain predefined extensions causes a message to be displayed to the victim, instructing them to contact the threat actor via Telegram

One of the final payloads deployed after successfully disarming security controls and recovery mechanisms is Amnesia RAT (“svchost.scr”), which is retrieved from Dropbox and is capable of broad data theft and remote control. It’s designed to pilfer information stored in web browsers, cryptocurrency wallets, Discord, Steam, and Telegram, along with system metadata, screenshots, webcam images, microphone audio, clipboard, and active window title.

“The RAT enables full remote interaction, including process enumeration and termination, shell command execution, arbitrary payload deployment, and execution of additional malware,” Fortinet said. “Exfiltration is primarily performed over HTTPS using Telegram Bot APIs. Larger datasets may be uploaded to third-party file-hosting services such as GoFile, with download links relayed to the attacker via Telegram.”

In all, Amnesia RAT facilitates credential theft, session hijacking, financial fraud, and real-time data gathering, turning it into a comprehensive tool for account takeover and follow-on attacks.

The second payload delivered by the script is a ransomware that’s derived from the Hakuna Matata ransomware family and is configured to encrypt documents, archives, images, media, source code, and application assets on the infected endpoint, but not before terminating any process that could interfere with its functioning.

In addition, the ransomware keeps tabs on clipboard contents and silently modifies cryptocurrency wallet addresses with attacker-controlled wallets to reroute transactions. The infection sequence ends with the script deploying WinLocker to restrict user interaction.

“This attack chain demonstrates how modern malware campaigns can achieve full system compromise without exploiting software vulnerabilities,” Lin concluded. “By systematically abusing native Windows features, administrative tools, and policy enforcement mechanisms, the attacker disables endpoint defenses before deploying persistent surveillance tooling and destructive payloads.”

To counter defendnot’s abuse of the Windows Security Center API, Microsoft recommends that users enable Tamper Protection to prevent unauthorized changes to Defender settings and monitor for suspicious API calls or Defender service changes.

The development comes as human resources, payroll, and internal administrative departments belonging to Russian corporate entities have been targeted by a threat actor UNG0902 to deliver an unknown implant dubbed DUPERUNNER that’s responsible for loading AdaptixC2, a command-and-control (C2) framework. The spear-phishing campaign, codenamed Operation DupeHike, has been ongoing since November 2025.

Seqrite Labs said the attacks involve the use of decoy documents centered around themes related to employee bonuses and internal financial policies to convince recipients into opening a malicious LNK file within ZIP archives that leads to the execution of DUPERUNNER.

The implant reaches out to an external server to fetch and display a decoy PDF document, while system profiling and the download of the AdaptixC2 beacon are carried out in the background.

In recent months, Russian organizations have also been likely targeted by another threat actor tracked as Paper Werewolf (aka GOFFEE), which has employed artificial intelligence (AI)-generated decoys and DLL files compiled as Excel XLL add-ins to deliver a backdoor referred to as EchoGather.

“Once launched, the backdoor collects system information, communicates with a hardcoded command-and-control (C2) server, and supports command execution and file transfer operations,” Intezer security researcher Nicole Fishbein said. It “communicates with the C2 over HTTP(S) using the WinHTTP API.”

Ravie LakshmananJan 23, 2026Email Security / Endpoint Security

Cybersecurity researchers have disclosed details of a new dual-vector campaign that leverages stolen credentials to deploy legitimate Remote Monitoring and Management (RMM) software for persistent remote access to compromised hosts.

“Instead of deploying custom viruses, attackers are bypassing security perimeters by weaponizing the necessary IT tools that administrators trust,” KnowBe4 Threat Labs researchers Jeewan Singh Jalal, Prabhakaran Ravichandhiran, and Anand Bodke said. “By stealing a ‘skeleton key’ to the system, they turn legitimate Remote Monitoring and Management (RMM) software into a persistent backdoor.”

The attack unfolds in two distinct waves, where the threat actors leverage fake invitation notifications to steal victim credentials, and then leverage those pilfered credentials to deploy RMM tools to establish persistent access.

The bogus emails are disguised as an invitation from a legitimate platform called Greenvelope, and aim to trick recipients into clicking on a phishing URL that’s designed to harvest their Microsoft Outlook, Yahoo!, AOL.com login information. Once this information is obtained, the attack moves to the next phase.

Specifically, this involves the threat actor registering with LogMeIn using the compromised email to generate RMM access tokens, which are then deployed in a follow-on attack through an executable named “GreenVelopeCard.exe” to establish persistent remote access to victim systems.

The binary, signed with a valid certificate, contains a JSON configuration that acts as a conduit to silently install LogMeIn Resolve (formerly GoTo Resolve) and connect to an attacker-controlled URL without the victim’s knowledge.

With the RMM tool now deployed, the threat actors weaponize the remote access to alter its service settings so that it runs with unrestricted access on Windows. The attack also establishes hidden scheduled tasks to automatically launch the RMM program even if it’s manually terminated by the user.

To counter the threat, it’s advised that organizations monitor for unauthorized RMM installations and usage patterns.

Ravie LakshmananJan 23, 2026Regulatory Compliance / National Security

TikTok on Friday officially announced that it formed a joint venture that will allow the hugely popular video-sharing application to continue operating in the U.S.

The new venture, named TikTok USDS Joint Venture LLC, has been established in compliance with the Executive Order signed by U.S. President Donald Trump in September 2025, the platform said. The new deal will see TikTok’s Chinese parent company, ByteDance, selling the majority of its stake to a group of majority-American investors, while it will retain a 19.9% stake in the business. The Chinese government hasn’t commented publicly on the agreement.

“The majority American owned Joint Venture will operate under defined safeguards that protect national security through comprehensive data protections, algorithm security, content moderation, and software assurances for U.S. users,” it added.

“It will safeguard the U.S. content ecosystem through robust trust and safety policies and content moderation while ensuring continuous accountability through transparency reporting and third-party certifications.”

To that end, U.S. users’ data will be protected with Oracle’s secure U.S. cloud environment, while also retraining and updating TikTok’s content recommendation algorithm specifically based on users in the country. The recommendation algorithm will be secured using Oracle’s cloud infrastructure as well.

In addition, the independent entity is expected to operate a comprehensive data privacy and cybersecurity program that it said will be audited and certified by third-party cybersecurity experts.

“The program will adhere to major industry standards, including the National Institute of Standards and Technology (NIST) CSF and 800-53 and ISO 27001, as well as the Cybersecurity and Infrastructure Security Agency (CISA) Security Requirements for Restricted Transactions, the company said.

The safeguards rolled out by the joint venture will also extend to CapCut, Lemon8, and TikTok’s other apps and websites in the U.S. TikTok is used by over 200 million Americans and 7.5 million businesses.

President Trump hailed the deal in a Truth Social post, stating that the company would now be owned by a “group of Great American Patriots and Investors, the Biggest in the World.” He also thanked Chinese President Xi Jinping for working with his administration, and “ultimately, approving the Deal.”

The development comes a month after reports emerged that TikTok had signed an agreement to create a new U.S. joint venture. Under President Trump’s September 2025 executive order, the attorney general was blocked from enforcing the national security law for a 120-day period in order to “permit the contemplated divestiture to be completed,” allowing the deal to be finalized by January 23, 2026.

TikTok was briefly banned a year ago after a federal law, signed by former President Joe Biden, went into effect. The legislation, passed in April 2024, mandated that the service be made available either under American ownership or another entity, citing national security concerns over its Chinese owner, ByteDance.

Lawmakers have argued that Beijing could force the firm to hand over U.S. users’ data, a claim that both TikTok and ByteDance have consistently denied. These fears have also led to an outright ban of TikTok in India in June 2020. In late 2024, the Canadian government ordered TikTok to dissolve its operations in the country.

Ravie LakshmananJan 23, 2026Network Security / Vulnerability

Fortinet has officially confirmed that it’s working to completely plug a FortiCloud SSO authentication bypass vulnerability following reports of fresh exploitation activity on fully-patched firewalls.

“In the last 24 hours, we have identified a number of cases where the exploit was to a device that had been fully upgraded to the latest release at the time of the attack, which suggested a new attack path,” Fortinet Chief Information Security Officer (CISO) Carl Windsor said in a Thursday post.

The activity essentially mounts to a bypass for patches put in place by the network security vendor to address CVE-2025-59718 and CVE-2025-59719, which could allow unauthenticated bypass of SSO login authentication via crafted SAML messages if the FortiCloud SSO feature is enabled on affected devices. The issues were originally addressed by Fortinet last month.

However, earlier this week, reports emerged of renewed activity in which malicious SSO logins on FortiGate appliances were recorded against the admin account on devices that had been patched against the twin vulnerabilities. The activity is similar to incidents observed in December, shortly after the disclosure of the CVE-2025-59718 and CVE-2025-59719.

The activity involves the creation of generic accounts for persistence, making configuration changes granting VPN access to those accounts, and the exfiltration of firewall configurations to different IP addresses. The threat actor has been observed logging in with accounts named “cloud-noc@mail.io” and “cloud-init@mail.io.”

As mitigations, the company is urging the following actions –

• Restrict administrative access of edge network device via the internet by applying a local-in policy
• Disable FortiCloud SSO logins by disabling “admin-forticloud-sso-login”

“It is important to note that while, at this time, only exploitation of FortiCloud SSO has been observed, this issue is applicable to all SAML SSO implementations,” Fortinet said.

Ravie LakshmananJan 23, 2026Vulnerability / Software Security

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) on Thursday added four security flaws to its Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation in the wild.

The list of vulnerabilities is as follows –

• CVE-2025-68645 (CVSS score: 8.8) – A PHP remote file inclusion vulnerability in Synacor Zimbra Collaboration Suite (ZCS) that could allow a remote attacker to craft requests to the “/h/rest” endpoint and allow inclusion of arbitrary files from the WebRoot directory without any authentication (Fixed in November 2025 with version 10.1.13)
• CVE-2025-34026 (CVSS score: 9.2) – An authentication bypass in the Versa Concerto SD-WAN orchestration platform that could allow an attacker to access administrative endpoints (Fixed in April 2025 with version 12.2.1 GA)
• CVE-2025-31125 (CVSS score: 5.3) – An improper access control vulnerability in Vite Vitejs that could allow contents of arbitrary files to be returned to the browser using ?inline&import or ?raw?import (Fixed in March 2025 with versions 6.2.4, 6.1.3, 6.0.13, 5.4.16, and 4.5.11)
• CVE-2025-54313 (CVSS score: 7.5) – An embedded malicious code vulnerability in eslint-config-prettier that could allow for execution of a malicious DLL dubbed Scavenger Loader that’s designed to deliver an information stealer

It’s worth noting that CVE-2025-54313 refers to a supply chain attack targeting eslint-config-prettier and six other npm packages, eslint-plugin-prettier, synckit, @pkgr/core, napi-postinstall, got-fetch, and is, that came to light in July 2025.

The phishing campaign targeted the package maintainers with bogus links that harvested their credentials under the pretext of verifying their email address as part of regular account maintenance, allowing the threat actors to publish trojanized versions.

According to CrowdSec, exploitation efforts targeting CVE-2025-68645 have been ongoing since January 14, 2026. There are currently no details on how the other vulnerabilities are being exploited in the wild.

Pursuant to Binding Operational Directive (BOD) 22-01, Federal Civilian Executive Branch (FCEB) agencies are required to apply the necessary fixes by February 12, 2026, to secure their networks against active threats.

Microsoft has warned of a multi‑stage adversary‑in‑the‑middle (AitM) phishing and business email compromise (BEC) campaign targeting multiple organizations in the energy sector.

“The campaign abused SharePoint file‑sharing services to deliver phishing payloads and relied on inbox rule creation to maintain persistence and evade user awareness,” the Microsoft Defender Security Research Team said. “The attack transitioned into a series of AitM attacks and follow-on BEC activity spanning multiple organizations.”

As part of post-exploitation activity following initial compromise, the unknown attackers have been found to leverage trusted internal identities from the victim to carry out large‑scale intra‑organizational and external phishing in an effort to cast a wide net and widen the scope of the campaign.

The starting point of the attack is a phishing email likely sent from an email address belonging to a trusted organization, which was compromised beforehand. Abusing this legitimate channel, the threat actors sent out messages masquerading as SharePoint document‑sharing workflows to give it a veneer of credibility and trick recipients into clicking on phishing URLs.

Because services like SharePoint and OneDrive are widely used in enterprise environments and the emails originate from a legitimate address, they are unlikely to raise suspicion, allowing adversaries to deliver phishing links or stage malicious payloads. This approach is also called living-off-trusted-sites (LOTS), as it weaponizes the familiarity and ubiquity of such platforms to subvert email‑centric detection mechanisms.

The URL, for its part, redirects users to a fake credential prompt to view the purported document. Armed with access to the account using the stolen credentials and the session cookie, the attackers create inbox rules to delete all incoming emails and mark all emails as read. With this foundation in place, the compromised inbox is used to send phishing messages containing a fake URL designed to conduct credential theft using an AitM attack.

In one case, Microsoft said the attacker initiated a large-scale phishing campaign involving more than 600 emails that were sent to the compromised user’s contacts, both within and outside of the organization. The threat actors have also been observed taking steps to delete undelivered and out of office emails, and assure message recipients of the email’s authenticity if they raised any concerns. The correspondence is then deleted from the mailbox.

“These techniques are common in any BEC attacks and are intended to keep the victim unaware of the attacker’s operations, thus helping in persistence,” the Windows maker noted.

Microsoft said the attack highlights the “operational complexity” of AitM, stating password resets alone cannot remediate the threat, as impacted organizations must ensure that they have revoked active session cookies and removed attacker-created inbox rules used to evade detection.

To that end, the company noted that it worked with customers to revoke multi-factor authentication (MFA) changes made by the attacker on the compromised user’s accounts and delete suspicious rules created on those accounts. It’s currently not known how many organizations were compromised and if it’s the work of any known cybercrime group.

Organizations are advised to work with their identity provider to make sure security controls like phishing-resistant MFA are in place, enable conditional access policies, implement continuous access evaluation, and use anti-phishing solutions that monitor and scan incoming emails and visited websites.

The attack outlined by Microsoft highlights the ongoing trend among threat actors to abuse trusted services such as Google Drive, Amazon Web Services (AWS), and Atlassian’s Confluence wiki to redirect to credential harvesting sites and stage malware. This eliminates the need for attackers to build out their own infrastructure as well as makes malicious activity appear legitimate.

The disclosure comes as identity services provider Okta said it detected custom phishing kits that are designed specifically for use in voice phishing (aka vishing) campaigns targeting Google, Microsoft, Okta, and a wide range of cryptocurrency platforms. In these campaigns, the adversary, posing as tech support personnel, calls prospective targets using a spoofed support hotline or company phone number.

The attacks aim to trick users into visiting a malicious URL and hand over their credentials, which are subsequently relayed to the threat actors in real-time via a Telegram channel, granting them unauthorized access to their accounts. The social engineering efforts are well planned, with the attackers conducting reconnaissance on the targets and crafting customized phishing pages.

The kits, sold on an as-a-service basis, come fitted with client-side scripts that make it possible for threat actors to control the authentication flow in the browser of a targeted user in real-time, as they provide verbal instructions and convince them to take actions (e.g., approve push notifications or enter one-time passwords) that would lead to an MFA bypass.

“Using these kits, an attacker on the phone to a targeted user can control the authentication flow as that user interacts with credential phishing pages,” said Moussa Diallo, threat researcher at Okta Threat Intelligence. “They can control what pages the target sees in their browser in perfect synchronization with the instructions they are providing on the call. The threat actor can use this synchronization to defeat any form of MFA that is not phishing-resistant.”

In recent weeks, phishing campaigns have exploited Basic Authentication URLs (i.e., “username:password@domain[.]com”) by placing a trusted domain in the username field, followed by an @ symbol and the actual malicious domain to visually mislead the victim.

“When a user sees a URL that begins with a familiar and trusted domain, they may assume the link is legitimate and safe to click,” Netcraft said. “However, the browser interprets everything before the @ symbol as authentication credentials, not as part of the destination. The real domain, or the one that the browser connects to, is included after the @ symbol.”

Other campaigns have resorted to simple visual deception tricks like using “rn” in place of “m” to conceal malicious domains and deceive victims into thinking they are visiting a legitimate domain associated with companies like Microsoft (“rnicrosoft[.]com”), Mastercard (“rnastercard[.]de”), Marriott (“rnarriotthotels[.]com”), and Mitsubishi (“rnitsubishielectric[.]com”). This is called a homoglyph attack.

“While attackers often aim at brands that start with the letter M for this technique, some of the most convincing domains come from swapping an internal ‘m’ with ‘rn’ inside words,” Netcraft’s Ivan Khamenka said. “This technique becomes even more dangerous when it appears in words that organizations commonly use as part of their brand, subdomains, or service identifiers. Terms like email, message, member, confirmation, and communication all contain mid-word m’s that users barely process.”

Ravie LakshmananJan 22, 2026Cybersecurity / Hacking News

Most of this week’s threats didn’t rely on new tricks. They relied on familiar systems behaving exactly as designed, just in the wrong hands. Ordinary files, routine services, and trusted workflows were enough to open doors without forcing them.

What stands out is how little friction attackers now need. Some activity focused on quiet reach and coverage, others on timing and reuse. The emphasis wasn’t speed or spectacle, but control gained through scale, patience, and misplaced trust.

The stories below trace where that trust bent, not how it broke. Each item is a small signal of a larger shift, best seen when viewed together.

Taken together, these incidents show how quickly the “background layer” of technology has become the front line. The weakest points weren’t exotic exploits, but the spaces people stop watching once systems feel stable.

The takeaway isn’t a single threat or fix. It’s the pattern: exposure accumulates quietly, then surfaces all at once. The full list makes that pattern hard to ignore.