Posts on Security, Cloud, DevOps, Citrix, VMware and others.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.
In the agentic era, the stakes are higher: AI agents now act with real access to your identities, your data, and your cloud, so every adoption decision is a trust decision. That is why security is a through line at Microsoft Ignite 2026, from a Security Pre-Day before the event opens to a security segment in the keynote, and four security themes across all four days.
Join us in San Francisco from November 17 to 20, 2026, or online. See the Microsoft Security roadmap first, get hands-on with new agentic security solutions, and connect directly with the experts, partners, and peers who can help you make it real. This year we spotlight our AI-first, end-to-end security platform designed to protect identities, devices, data, applications, clouds, infrastructure, and the AI agents now working alongside your teams.
Understand where Microsoft is placing its bets. See what is being announced, what is shipping next, and what it means for your architecture, your security operations center (SOC), and your governance model.
Build skills you can use immediately. Technical breakouts run from level 200 to level 400, paired with instructor-led labs and onsite certifications, so you leave with implementation guidance rather than slideware.
Pressure-test your plans with the people who built it. Bring your real architecture, deployment, and roadmap questions to Microsoft engineers, MVPs, and the product teams behind these tools.
See the proof, not the promise. Customer stories, live demos, and partner solutions show what is already working in production today.
Connect with the people who make it real. Expert meetups, connection pods, table talks, and evening events put you alongside security practitioners, leaders, Microsoft partners, and peers working the same problems.
Make the most of your time at Microsoft Ignite
Whether you join us in San Francisco or online, you will have access to a full slate of experiences designed to help you connect, learn, and grow as a security professional. Here is what is in store.
Start a day early at the Security Pre-Day
On Monday, November 16, 2026, from 1:00 PM PT to 5:00 PM PT, the Security Pre-Day gives you four hours with Microsoft Security leaders and external industry voices before the main event begins. Expect presentations paired with interactive roundtables and ask-me-anythings (AMAs) with our security experts, built for security decision makers and practitioners alike.
Select the Security Pre-Day option during Microsoft Ignite registration.
Hear the news first in the keynote and Innovation Session
The opening keynote runs Tuesday, November 17, 2026, from 10:00 AM PT to 12:00 PM PT at Chase Center and sets the direction for the week with Satya Nadella, Microsoft CEO, and Judson Althoff.
Later in the week, the Security Innovation Session goes deeper on the security news with executive-led demos.
Where the security community comes together
Microsoft Ignite is where the security community gathers. Beyond the sessions, you will find expert meetups, connection pods, and evening experiences created for security professionals and leaders.
Secure the Night
You are invited to Secure the Night on Tuesday, November 17, 2026, an evening bringing the security community together to connect, celebrate, and have some fun. Join fellow customers and Microsoft Security leaders for a night designed to make meaningful connections.
Security and Agent 365 Neighborhood at Microsoft Hub
Bring your hardest questions to the people who build and defend with these products every day. Microsoft engineers, MVPs, and partners staff the Hub throughout the week. Experience hands-on demo, participate in community conversations and happy hours with industry experts. Also check out our Security Insider podcast recorded real time.
Partners and the Microsoft Intelligent Security Association
Microsoft Intelligent Security Association (MISA) members have a full week ahead at Microsoft Ignite. Beyond the partner-focused security sessions running throughout the event, the MISA Demo Station returns to the Expert Meetup Hub from November 17 to 19, 2026, where members will demo their solutions with customers on the show floor.
Thank you to our MISA partners Ascent Solutions, Avertium, BlueVoyant, Devicie, Huntress, Illumio, Mphasis, and RSM who are sponsoring the Microsoft Secure the Night party, each hosting an interactive activation on the party floor, and the week wraps with an exclusive MISA Happy Hour on November 19, 2026—a chance for MISA partners to network with fellow members and select Microsoft Security stakeholders. For information on registration for the MISA Happy Hour, please reach out to your dedicated MISA representative.
Explore the Security sessions at Microsoft Ignite 2026
Below are the four themes shaping this year’s Security track, along with a few sessions you will not want to miss. You can view the full catalog here and filter by topic, format, and role to plan your week.
Here is an overview of the Security tracks with some highlights of our top sessions.
Defend with AI
Security operations are being rebuilt around agents. This track covers what changes when AI can not only analyze but act, and how the SOC’s operating model, data foundation, and response playbooks have to evolve to keep pace.
Sessions to watch for
The Alert Is Dead. The Blueprint for the Agentic SOC, which maps what replaces alert-centric operations end to end.
The Agentic SOC Reality Check: Market Hype vs. AI Models vs. Automation, a real-time architectural breakdown with no slides and no canned speeches.
Winning the Race Against Time with Autonomous Protection, on how AI is changing the economics of cyberattacks and how to compress your response window.
Turn signal into real-time protections with Project Perception, a hands-on lab in agentic security.
Also in this track: threat intelligence at AI speed, AI-powered endpoint vulnerability discovery and remediation, attack disruption, finding and fixing code vulnerabilities with codename MDASH, and building the security data foundation the agentic SOC runs on.
Secure AI
Your organization is already shipping agents. This track is about seeing them, governing them, and protecting them from code to runtime, across the identities they use and the data they touch.
Sessions to watch for
When AI acts, security has to answer: Microsoft Security for AI, the platform view of securing agentic AI.
Inside look: Microsoft Security as customer zero for Agent 365, covering what we learned running it ourselves.
Local agents are here. Can you find and secure them?, paired with a companion lab on end-to-end threat protection for local agents.
AI Agents Are Scaling. Are Your Access Controls Ready?, a peer discussion on identity for non-human actors.
Also in this track: prioritizing and remediating your riskiest agents, a Zero Trust approach to securing AI runtime with Microsoft Defender, data protection and governance for agents with Microsoft Purview, securing Microsoft 365 Copilot and Cowork, and turning AI security research into deployable defenses.
Get Ready for AI
Before you scale AI, the fundamentals have to hold: identity, device and app trust, data hygiene, exposure management, and Zero Trust. This track is the practitioner’s path to an AI-ready security foundation.
Sessions to watch for
Build secure foundations to scale AI across your organization, the anchor session for this track.
Identity Knows What Your SOC Doesn’t: Stop Threats Faster Together, on closing the gap between identity and security operations.
Can’t Phish a Passkey. But Can You Prove Who’s Behind It? and SMS MFA Is Dead. What Comes Next?, a pair on the state of phishing-resistant authentication.
Zero Trust for AI workshop, a hands-on lab with a companion lightning talk, Apply Zero Trust for AI: the practitioner’s shortlist.
Insights from Microsoft’s journey to prepare its data for AI adoption, on what it actually took internally.
Also in this track: reducing exposure across your digital estate, a single policy model for humans and agents, protecting cloud and container applications from code to runtime, getting privileged access right, and getting more out of the E5 you already own.
Secure Data
Data is the substrate AI runs on, and the thing cyberattackers are after. This track is about discovering, classifying, and protecting sensitive data across clouds, devices, AI apps, and agents.
Sessions to watch for
Microsoft Purview: Build the Trusted Data Foundation for AI, the place to start.
Strengthen and Manage Data Security Posture with Microsoft Purview, on data security posture management in practice.
Deploy Copilot with confidence: Find and protect exposed sensitive data, a hands-on lab to run before you turn Copilot loose.
Microsoft Purview AMA: Preparing Your Data for Secure AI, where you can bring your questions to the product team.
Also in this track: closing exfiltration gaps with data loss prevention, and turning global regulatory requirements into operating controls.
Choose the session format that fits how you learn
Breakout sessions run 45 minutes at level 200 to 400, led by experts with live demos and real architecture. They are the technical core of the Security track.
Theater sessions are 25 minutes of fast, demo-driven content in the Hub, designed to show rather than tell.
Lightning talks are 15 minutes in intimate mini-theaters, built for curiosity, questions, and quick insight.
Table talks are 45-minute, small-group technical discussions on real-world challenges and trade-offs, moderated by Microsoft subject matter experts.
Hands-on labs are 75 minutes, instructor-led and proctor-supported, in a live environment. RSVP is required and labs fill fast.
Build your schedule
Do not miss your chance to be part of Microsoft Ignite. Explore the full session catalog, filter by topic, format, and role to plan your week, and register today to connect with the global security community and get hands-on with the latest innovations.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
Microsoft has warned of phishing campaigns distributing an installer for the MSP360 Remote Monitoring and Management (RMM) software under the guise of meeting invitations, PDF-themed lures, software update prompts, and other social-engineering content.
"Once executed, the legitimate MSP360 installer, distributed under a deceptive file name established remote management access on affected devices and enabled threat actors to gain an initial foothold using trusted administrative software," the Microsoft Security Research team said.
The initial foothold is then used to download and install a ConnectWise ScreenConnect client, offering threat actors a redundant remote-access channel to compromised endpoints. The access is then abused to deliver additional tools and carry out information collection and credential-access operations. The activity has not been attributed to any known threat actor or group.
The multi-stage intrusion chain, which the Windows maker detected in July 2026, begins with phishing emails distributing a digitally signed MSP360 RMM v2.5.0.67 installer under deceptive names such as below -
The installer packages are staged on attacker-controlled infrastructure and legitimate cloud services including Amazon S3, Cloudflare R2, Dropbox, GitLab, and Supabase.
Once launched, the installer drops multiple DLLs, while relaunching itself by invoking the Windows User Account Control (UAC) elevation workflow to run in a privileged context, establish persistent access by deploying MSP360, and leverage the RMM tool to execute PowerShell for stealthily installing ScreenConnect.
The installer also enumerates installed .NET runtimes and registers two Windows services (RMM.Agent.exe and RMM.Agent.Launcher.exe) and creates Registry-based autorun entries to ensure that MSP360 is automatically launched when users sign-in to the machine.
Furthermore, it modifies the Windows Firewall configuration to allow inbound UDP traffic to MSP360 (i.e., RMM.Agent.exe) on port 48678.
The dual-RMM remote access attack enables the attacker to transfer additional executables and facilitate post-compromise activity, while camouflaging malicious activity within regular remote administration workflows. The payloads are run through ScreenConnect's native RunFile functionality.
Microsoft said it also observed a separate set of attacks in July 2026 that switched MSP360 for Faronics Deploy Agent to find a way in, and then used it to download and install ScreenConnect. This suggests that the threat actors are putting multiple RMM tools for remote access.
"This activity highlights how threat actors continue to abuse legitimate remote administration software to blend into normal IT operations while maintaining persistent access and reducing detection opportunities," Microsoft said.
"The combination of MSP360 and ScreenConnect provided the threat actor with redundant remote administration channels and enabled the transfer, execution, and management of additional tooling during subsequent stages of the intrusion."
from The Hacker News https://ift.tt/NwThzIL
via IFTTT
Cybersecurity researchers have disclosed technical details of a recently patched critical security flaw in Citrix NetScaler ADC and Gateway that has come under active exploitation in the wild.
The vulnerability, tracked as CVE-2026-88772 (CVSS score: 9.5), has been described as a memory overflow bug in the Datagram Transport Layer Security (DTLS) protocol handling that's rooted in the NetScaler Packet Processing Engine (NSPPE).
"Citrix NetScaler ADC and NetScaler Gateway contain an improper restriction of operations within the bounds of a memory buffer vulnerability that could allow for remote code execution or denial-of-service," the U.S. Cybersecurity and Infrastructure Security Agency (CISA) said.
The issue, per watchTowr, is that NetScaler implicitly trusts the declared fragment size in the DTLS handshake header's fragment_length field (i.e., 1 byte), while the header simultaneously claims that the complete message, as denoted by the length field, is 120 bytes long.
This parsing inconsistency can be exploited by an attacker to craft a malicious record that makes the record look small, while the actual data being copied to the buffer is much larger in size, resulting in an overflow.
"For example, a 120-byte handshake message can arrive as 120 fragments. Every fragment has length=120, but each one can have fragment_length=1," security researcher Sina Kheirkhah explained. "Their offsets would be 0, 1, 2, and so on up to 119. Once every position has arrived, the server considers the 120-byte message complete. Joining those pieces is called reassembly."
Each received packet of 1,459 bytes is stored in NetScaler Buffers (NSBs), which is then stitched into a single scratch buffer of only 35,840 bytes. Given that the vulnerable version does not check whether the next packet can fit into the scratch buffer, data gets written past the end of the buffer and leads to a buffer overflow.
"The malicious records tell the reassembly code that each record supplies only one byte of a 120-byte handshake message," Kheirkhah said. "However, NSPPE keeps almost the whole record in an NSB. After 120 records, the handshake message is considered complete, but its NSB chain contains about 174 KB of data."
watchTowr's analysis further found that this overflow can be weaponized to divert control flow to arbitrary shellcode with root-level privileges by using the mprotect() system call to defeat NX (no-execute) protections.
The disclosure comes a day after the preemptive exposure management company released a proof-of-concept (PoC) for CVE-2026-88771, which has been abused alongside CVE-2026-88772 in real-world attacks.
from The Hacker News https://ift.tt/BEqTdnC
via IFTTT
We review the potential Anthropic IPO, in the context of revenue trajectory, expense trajectory and planned commitments, past and future funding rounds, future expanse commitments to large datacenter projects, and the strengths and weaknesses of the business in the current and potentially future political climates in the US and around the world.
Russian state hackers known as Star Blizzard have been using fake event invitations to trick people into installing a backdoor on their Windows computers, according to Microsoft.
The campaigns, aimed at people and organizations tied to Ukraine, have affected more than 100 organizations since January, mostly in the U.S. and U.K. At least one computer was infected, but the number of breached organizations has not been disclosed.
Security agencies in the U.S., U.K., Australia, Canada and New Zealand said in December 2023 that Star Blizzard almost certainly works under Center 18 of Russia's Federal Security Service (FSB). The group has long stolen email passwords by posing as people its targets know.
By 2023, it had already used fake conference and event invitations as bait, often exchanging messages with a target before sending a malicious link.
Microsoft counted at least 13 larger campaigns this year, each with tens to hundreds of emails, on top of the group's usual targeted phishing.
Since March, those campaigns have used email accounts on WordPress and cPanel websites, which Microsoft is highly confident the group hacked for that purpose. Before, the group mostly used free email services such as Proton and Microsoft consumer accounts.
In 2025, the group delivered its malware through fake CAPTCHA pages that tricked targets into running commands themselves, a method known as ClickFix. This year it switched to a method Microsoft calls RedFlick. RedFlick uses scheduled tasks, jobs that Windows runs automatically, to install a backdoor named CosmicPulse.
The invitations name well-known think tanks or NGOs as hosts, such as Chatham House and the Atlantic Council. Many emails are written to appear to come from within the target's organization.
The first email usually carries no attachment. If the target replies, the group sends a password-protected RAR or ZIP archive, with the password shown in an image.
The first campaigns, in January and February, posed as Ukrainian authorities and sent fake tax audit and fine notices to users of the Ukrainian email service Ukr.net. Later lures included a water shutdown notice for hotels in Kyiv and a payment notice for staff at an international financial organization.
One March campaign worked differently. People who replied to an Atlantic Council-themed invitation got a link to DarkSword, an iPhone exploit kit, instead of the Windows backdoor, according to Microsoft.
Proofpoint reported Atlantic Council-themed emails from the group in March, along with a sharp rise in its email volume.
Trellix found 4 such emails sent on March 26. Its confidence that the emails led to DarkSword is medium, because the exploit pages were offline and no exploit code was recovered.
How the Backdoor Gets In
Microsoft traced several versions of the infection chain. In all of them, a shortcut (LNK) file disguised as a PDF initiates the attack, and a Windows Installer (MSI) package sets up scheduled tasks.
Opening the shortcut quietly runs commands that fetch the installer from a remote server. In January, a hidden script used the SSH program to download it. In July, the shortcut downloaded a PDF with a hidden command that tries to fetch the installer.
In the version seen in April, the installer created 3 scheduled tasks named to look like normal network components:
Internet Quality Test Connection
Network Configuration Manager
System Health Monitor
The first task sends the computer name and user name to the group's command-and-control (C2) server and can run more code from a remote location. The second sets up WebDAV, a Windows feature that opens a web address as if it were a folder. The third uses control.exe, the Windows Control Panel program, to run the next stage from the C2 server.
The next stage is a downloader disguised as a Control Panel item. It installs CosmicPulse, a Python-based backdoor. The downloader is the one earlier reports called NOROBOT or BAITSWITCH.
Microsoft says these techniques overlap with a June campaign, reported by Digital Security Lab Ukraine, that targeted Ukrainian civil society organizations. That campaign used fake invitations to the Ukraine Recovery Conference. The lab did not name the attackers and could not recover the final payload.
Two indicators appear in both Microsoft's list and the June report, a comparison by The Hacker News found: the IP address 103.160.59[.]97 and the domain secure-dns-hub[.]com. Sharing them does not by itself show that the same group ran both campaigns.
What Defenders Can Check
Microsoft published hunting queries and indicators for the campaigns, with advice for government bodies, NGOs, and think tanks that work on or support Ukraine policy. It also notifies customers it sees as targeted or compromised.
One domain, secure-dns-hub[.]com, was still in use when Microsoft published the report on September 29, according to the company.
Organizations likely to be targeted can take these steps:
Check sender addresses. In these campaigns, the real organization's name appears before the @ sign rather than in the domain. When in doubt, contact the sender through a phone number or email address you already know.
Search for the 3 scheduled task names above and for the Microsoft Defender detections Trojan:Script/RedFlick and Backdoor:Python/CosmicPulse.
Widen the time range of Microsoft's 3 Defender XDR hunting queries, which look back only 7 days as published. Defender's advanced hunting keeps up to 30 days of raw data, so checking back to January needs logs kept longer, for example in Microsoft Sentinel.
Block or limit outbound SSH connections the business does not need. The January version used SSH to fetch its installer.
If you use Microsoft Defender, turn on the attack surface reduction rules that block rare, new, or untrusted executable files and obfuscated scripts.
Use phishing-resistant sign-in methods. The group still runs password phishing with Evilginx, a tool that can also steal session cookies to get around two-factor authentication.
Update iPhones to iOS 26.3 or later, which fixes all 6 flaws DarkSword uses, and turn on Lockdown Mode where that is not yet possible, Trellix advises.
Microsoft's public report does not list specific cleanup steps for a computer where the tasks are found. Defender XDR customers can check the company's threat analytics reports, which include recommended response actions.
from The Hacker News https://ift.tt/JHkbghX
via IFTTT
In July 2026, Microsoft Defender Experts observed phishing campaigns targeting organizations across multiple industries that distributed a masqueraded MSP360 Remote Monitoring and Management (RMM) installer through meeting invitations, PDF-themed lures, software update prompts, and other social-engineering content. Once executed, the legitimate MSP360 installer, distributed under a deceptive file name established remote management access on affected devices and enabled threat actors to gain an initial foothold using trusted administrative software.
Microsoft observed the MSP360 deployment being used to download and install a ConnectWise ScreenConnect client, creating a secondary remote-access channel that provided redundant access to compromised systems. Microsoft did not observe exploitation of ScreenConnect software itself; rather, threat actors abused legitimately obtained remote administration software to establish and maintain access. After access was established, threat actors used these remote administration channels to deploy additional tools and conduct post-compromise activity, including information collection and credential-access operations.
This activity highlights how threat actors continue to abuse legitimate remote administration software to blend into normal IT operations while maintaining persistent access and reducing detection opportunities. Microsoft Defender for Endpoint detects suspicious and uncommon remote-management activity, while the hunting queries and mitigations in this post can help organizations identify and restrict unapproved RMM use.
Attack chain overview
The observed multi-stage intrusion chain began when phishing lures delivered a legitimate, digitally signed MSP360 RMM v2.5.0.67 installer under deceptive filenames. Following successful User Account Control (UAC) elevation, the installer established MSP360 services for persistent access and leveraged the RMM agent to invoke PowerShell, download, and silently install ConnectWise ScreenConnect.
This effectively introduced a second remote administration channel on the compromised device, which the threat actor subsequently used to transfer and execute additional tooling supporting credential access, local data collection, and other post-compromise activity.
Figure 1. Attack chain showing phishing delivering a masqueraded MSP360 RMM installer that deploys ScreenConnect for persistent remote access and follow-on activity.
Microsoft observed multiple phishing campaigns that used a multi-stage delivery chain to distribute legitimate, digitally signed MSP360 RMM software (v2.5.0.67). Phishing emails directed users to actor-controlled landing pages that impersonated document-sharing portals, invitation workflows, Adobe Reader download pages, Zoom installation pages, and business collaboration platforms.
Upon user interaction, victims were redirected to download locations hosted on both attacker-controlled infrastructure and legitimate cloud services including Amazon S3, Cloudflare R2, Dropbox, GitLab, and Supabase. The downloaded executables used filenames crafted to resemble legitimate business content, meeting invitations, PDF documents, and software installers. Analysis of downloaded samples showed that many ultimately contained the same MSP360 RMM installer package despite appearing as different files to the victim.
Figure 2. Actor-controlled tax-document lure prompting download of a masqueraded MSP360 installer.Figure 3. Image displaying the execution of downloaded MSP360 RMM.
The campaign relied on a diverse set of payload-hosting mechanisms. Microsoft observed the actor distributing the payload through attacker-controlled domains, websites assessed to be compromised, and legitimate cloud-hosted services. Cloud-hosted services used for payload distribution included Amazon S3, Cloudflare R2, Dropbox, GitLab, and Supabase.
This approach enabled the actor to rapidly rotate delivery infrastructure while continuing to distribute the same MSP360 installer using different lure themes and filenames.
RMM platforms are attractive to threat actors because they are designed to provide administrators with broad remote management capabilities across managed endpoints, including remote command execution, software deployment, file transfer, and persistent service-based access. When abused, these same capabilities can give threat actors a flexible post-compromise channel for maintaining access, deploying additional tooling, and conducting follow-on activity while blending in with legitimate remote administration workflows.
MSP360 RMM installation and foothold establishment
After victims downloaded and executed the masqueraded MSP360 installer, the binary launched from the user’s Downloads directory under a filename designed to resemble a legitimate business document.
The installer subsequently dropped multiple installation components, including System.dll, nsExec.dll, and UAC.dll, to the following folder paths before relaunching itself through an elevation workflow generated by the installer framework. Next, the installer invoked a Windows User Account Control (UAC) elevation workflow. In observed successful installations, the process continued with elevated privileges, allowing deployment of MSP360 components and services. In unsuccessful installations, the elevation did not complete, and deployment terminated before the software was fully installed.
Following elevation, the installer initiated the MSP360 installation workflow and recorded installation status messages using Windows eventcreate.exe. The installer generated “Begin installation” and “End installation. MSP360 de Success.” events under the event source: MSP360 RMM Agent installer. The installer dropped multiple MSP360 plugins and binaries within the installation directory: C:\Program Files\RMM Agent\.
The installer also performed prerequisite discovery by enumerating installed .NET runtimes using: dotnet –list-runtimes. To establish long-term access on the affected device, the installer registered two Windows services: RMM.Agent.exe & RMM.Agent.Launcher.exe. Microsoft observed events indicating stopping any existing MSP360 services and installing new MSP360 services.
In addition to service-based persistence, the installer created registry-based autorun entries for MSP360 user interface components, ensuring the tray applications would automatically launch when users signed in.
The installation routine also modified the Windows Firewall configuration by creating an inbound allow rule for the MSP360 agent. The rule allowed inbound UDP traffic to C:\Program Files\RMM Agent\RMM.Agent.exe on port 48678. This configuration enabled network communications required by the remote management platform.
Figure 4. Process execution flow of the MSP360 RMM installation.
Not every execution of the installer resulted in a successful deployment. In some instances, the installer was launched by the user and began its installation routine but subsequently attempted to obtain elevated privileges through User Account Control (UAC). When elevation was denied or aborted, the installation terminated before completing deployment of the MSP360 RMM components. The process execution flow showed installation initialization activity followed by events indicating that administrative privileges were required, with no subsequent evidence of the persistence mechanisms, services, or remote management functionality observed during successful installations.
Figure 5. Unsuccessful installation of MSP360 RMM.
Remote command execution from MSP360 Agent and ScreenConnect deployment
Following successful installation of MSP360 RMM, the newly installed RMM.Agent.exe service launched PowerShell. The PowerShell process modified the execution policy for the current session and executed Invoke-WebRequest commands to download an MSI package named ClientSetup.msi from actor-controlled infrastructure. The downloaded package was then installed silently through msiexec.exe using the /qn switch, eliminating visible user interaction. This installation activity resulted in the deployment of a ConnectWise ScreenConnect client on the compromised endpoint, including ScreenConnect.ClientService.exe, ScreenConnect.WindowsClient.exe, and supporting components.
The installer additionally created Windows service registrations, application uninstall entries, and authentication-related registry modifications associated with the newly deployed ScreenConnect client.
Figure 6. The process execution flow of the remote command execution and ScreenConnect deployment.
Following deployment, the ScreenConnect client service launched with configuration parameters referencing actor-controlled infrastructure and subsequently established successful outbound communications. The service then spawned ScreenConnect.WindowsClient.exe, providing an additional remote access channel independent of MSP360. Following establishment of the ScreenConnect session, the threat actor used ScreenConnect to transfer and stage additional executables in the following directories:
These files were among the most frequently observed utilities delivered by the threat actor following establishment of a ScreenConnect session. Several filenames were intentionally chosen to resemble legitimate Windows, Microsoft Defender, Phone Link, and security-related components, likely to reduce user suspicion and blend into normal operating system activity. These utilities were observed during post-compromise activity and were used to support subsequent operations on affected systems. Several of the observed tools are commonly associated with credential access, information collection, execution of additional payloads, and efforts to reduce defender visibility.
The execution of these files occurred through ScreenConnect’s built-in RunFile functionality, which allows files to be transferred to and executed on managed endpoints. This activity demonstrates how the threat actor leveraged a legitimate MSP360 RMM deployment to establish an initial foothold before deploying ConnectWise ScreenConnect as a secondary remote access platform. The combination of MSP360 and ScreenConnect provided the threat actor with redundant remote administration channels and enabled the transfer, execution, and management of additional tooling during subsequent stages of the intrusion.
The threat actor subsequently used these remote access platforms to facilitate follow-on activities including information collection, credential access, and the deployment of additional utilities on compromised systems.
Microsoft also observed separate activity during July in which FaronicsDeployAgent.exe, a legitimate deployment and remote access application, was used in a similar manner to MSP360 RMM. In this activity, the threat actor leveraged FaronicsDeployAgent.exe as the initial remote management platform and subsequently used it to download and install ScreenConnect. This observation demonstrates that the deployment of ScreenConnect was not limited to MSP360-based intrusions, with additional legitimate remote administration software also being leveraged to establish remote access and facilitate ScreenConnect installation.
Attribution
Microsoft has not attributed this activity to a named threat actor. The campaigns are tracked as unattributed activity.
Mitigation and protection guidance
Microsoft recommends the following actions to help organizations reduce their exposure to this activity. Check the recommendations card for the deployment status of monitored mitigations.
Govern approved RMM tools: For approved RMM systems used in your environment, enforce security settings where possible to implement multi-factor authentication (MFA).
Restrict unauthorized software: Use Application Control for Windows to create policies to block unapproved IT management tools. Both solutions include functionality to block specific software publisher certificates:
Application Control for Windows file rule levels allow administrators to specify the level at which they want to trust their applications, including listing certificates as untrusted.
AppLocker’s publisher rule condition is available for files that are digitally signed, which can enable organizations to block non-approved RMM instances that include publisher information.
Block specific signed applications: Microsoft Defender for Endpoint also provides functionality to block specific signed applications using the block certificate action.
Consider searching for unapproved RMM software installations (see the Advanced hunting section). If an unapproved installation is discovered, reset passwords for accounts used to install the RMM services. If a system-level account was used to install the software, further investigation may be warranted.
Strengthen endpoint protection: Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections provide near-instant, automated protection against new and emerging threats.
Investigate unauthorized installations: Turn on the following attack surface reduction rule to block or audit activity associated with this threat:
Block process creations originating from PsExec and WMI commands. Some organizations may experience compatibility issues with this rule on certain server systems but should deploy it to other systems to prevent lateral movement originating from PsExec and WMI
Microsoft Defender XDR detections
Microsoft Defender XDR customers can refer to the list of applicable detections below. Microsoft Defender XDR coordinates detection, prevention, investigation, and response across endpoints, identities, email, and apps to provide integrated protection against attacks like the threat discussed in this blog.
Tactic
Observed activity
Microsoft Defender coverage
Initial access
Delivery of masqueraded MSP360 application v2.5.0.67
Microsoft Defender Antivirus – SupportScam:Win32/RogueMSP.MU!MTB
Execution
Execution of the RMM software
Microsoft Defender for Endpoint – Suspicious usage of remote management software – Uncommon remote access software
Persistence
Persistence established by RMM software
Microsoft Defender for Endpoint – Anomaly detected in ASEP registry – Suspicious file registered as a service
Credential Access
Potential credential-access activity following RMM deployment
Microsoft Defender for Endpoint – Possible theft of passwords and other sensitive web browser information
Threat intelligence reports
Microsoft customers can use Microsoft Defender XDR Threat Analytics and related Microsoft threat intelligence reporting to stay current on the malicious activity, indicators, detection coverage, and recommended response actions associated with this campaign. These reports provide investigation context, protection guidance, and updated intelligence that security teams can use to prevent, mitigate, or respond to related activity in their environments.
Advanced hunting
// Run this query to identify the presence of MSP360 RMM agent
let MSP360RMM = "108ef7e628d7a20bd6241a5b57149e27a6061f467123eb64061975559f8f73dc";
DeviceFileEvents
| where Timestamp >= ago(30d)
| where SHA256 =~ MSP360RMM
// Run this query to identify the remote command execution from MSP360 RMM Agent
DeviceProcessEvents
| where Timestamp >= ago(30d)
| where (InitiatingProcessVersionInfoCompanyName == "MSP360" and ProcessCommandLine == "\"powershell.exe\"") or ( InitiatingProcessCommandLine == "\"powershell.exe\"" and ProcessCommandLine has_all ("msiexec.exe","\\Temp\\",".msi") and InitiatingProcessParentFileName == "RMM.Agent.exe")
// Run this query to identify the suspicious network connections from the threat actor’s use of ScreenConnect
let MaliciousURLs = DeviceNetworkEvents
| where Timestamp >= ago(30d)
| where InitiatingProcessCommandLine == "\"powershell.exe\""
| where InitiatingProcessParentFileName == "RMM.Agent.exe"
| where isnotempty(RemoteUrl)
| distinct RemoteUrl;
DeviceNetworkEvents
| where Timestamp >= ago(30d)
| where InitiatingProcessFileName has_any ( "ScreenConnect.ClientService.exe","ScreenConnect.WindowsClient.exe","ScreenConnect.Client.exe")
| where isnotempty(RemoteUrl)
| where RemoteUrl in (MaliciousURLs)
// Run this query to identify the suspicious payloads dropped and launched by the threat actor’s use of ScreenConnect
DeviceProcessEvents
| where Timestamp >= ago(30d)
| where InitiatingProcessCommandLine has_all ("ScreenConnect.WindowsClient.exe", "RunFile","\\Documents\\","\\Temp\\")
MITRE ATT&CK Techniques observed
This campaign has exhibited use of the following attack techniques. For standard industry documentation about these techniques, refer to the MITRE ATT&CK framework.
Resource Development
T1583.001 Acquire Infrastructure: Domains | Domains were used to host phishing landing pages, payload delivery infrastructure, and ScreenConnect services associated with the campaign.
T1583.006 Acquire Infrastructure: Web Services | The threat actor leveraged legitimate cloud-hosting providers including Amazon S3, Cloudflare R2, Dropbox, GitLab, and Supabase for payload distribution.
Initial Access
T1566.002 Phishing: Spearphishing Link | Victims received workplace meeting, Zoom, Google Meet, invitation, RSVP, PDF, and Adobe-themed phishing emails containing links that redirected to malicious payload download locations.
T1204 User Execution | Victims downloaded and executed a masqueraded MSP360 installer distributed under deceptive filenames designed to resemble legitimate business documents and software.
T1036 Masquerading | The actor distributed legitimate MSP360 software under filenames designed to resemble meeting applications, invitations, PDFs, and business documents.
T1036.005 Match Legitimate Name or Location | Follow-on tooling used filenames that closely resembled legitimate Windows, Microsoft Defender, security, and Phone Link applications.
T1112 Modify Registry | MSP360 and ScreenConnect modified registry locations associated with services, persistence, credential provider components, protocol handlers, and uninstall entries.
Command and Control
T1219 Remote Access Software | The threat actor abused legitimate remote administration software including MSP360 RMM and ConnectWise ScreenConnect to maintain access to victim systems.
T1105 Ingress Tool Transfer | MSP360 downloaded ScreenConnect, while the threat actor’s use of ScreenConnect was subsequently used to transfer and execute additional tooling on compromised endpoints.
T1573 Encrypted Channel | Payload retrieval and remote access communications occurred over encrypted network channels.
T1102 Web Service | Multiple cloud-hosted web services were used throughout the delivery and command-and-control infrastructure.
Discovery
T1082 System Information Discovery | The installer enumerated installed .NET runtimes using dotnet –list-runtimes during the installation workflow.
Collection
T1005 Data from Local System | Additional tooling delivered through ScreenConnect was observed in post-compromise activity and used to collect information from victim devices.
Indicators of compromise (IOCs)
Observed indicators associated with this campaign are listed below.
Legitimate MSP360 RMM v2.5.0.67 installer observed being distributed under deceptive filenames during the campaign. The observed sample was signed using a certificate that has since been revoked.
Utilities transferred or executed through ScreenConnect sessions and observed during post-compromise activity. Several of the identified tools are commonly associated with credential access, information collection, and efforts to reduce defender visibility.
To hear stories and insights from the Microsoft Threat Intelligence community about the ever-evolving threat landscape, listen to the Microsoft Threat Intelligence podcast.
Review our documentation to learn more about our real-time protection capabilities and see how to enable them within your organization.
An attacker used stolen passwords of staff at France's tax administration to take tax data on hundreds of thousands of taxpayers and businesses in June and July.
Neither the tax administration nor France's national cybersecurity agency saw the data leave. The attack was not sophisticated, the agency, ANSSI, says in a report (in French) published on Tuesday: it worked because of weak login protection, poorly separated networks and gaps in monitoring.
The tax administration, known as the DGFIP, runs France's tax website, impots.gouv.fr. The data came from E-Contact, the tool taxpayers use to message the tax administration.
For individuals, the data that may have been viewed or copied includes their tax ID, contact details, family situation, reference taxable income and tax withholding rate, plus a list of the messages they exchanged with the DGFIP. For fewer than 250 people, the messages themselves may also have been taken.
For businesses, it covers the company name, SIREN registration number, address and basic details of their messages. For fewer than 2,076 businesses, the content of those messages may have been seen.
The theft became known on August 12, when the attacker claimed it on an online forum, seven weeks after the first batch of data was taken. Prime Minister Sébastien Lecornu then asked ANSSI for an in-depth audit. In August, the ministry overseeing the DGFIP offered a different explanation.
It said at the time that the DGFIP's access checks had not revealed the theft "because of the sophistication of the attack" (translated from French).
How the Attacker Got In
The attacker used two separate routes, according to the report. The first began with suspicious logins in early May and led to E-Contact.
The first route relied on several dozen passwords belonging to DGFIP staff, stolen over three months. They were probably taken by infostealers, malware that quietly copies saved logins, from computers the DGFIP did not manage, most likely staff's own devices.
Two portals the attacker used, PIGP and ADER, asked only for a password, so a stolen one worked at once. PIGP is a web portal that DGFIP staff used for email and HR services. ADER provides access to certain DGFIP applications via the RIE, the network that connects French government ministries.
The attacker reached the RIE through compromised Education ministry systems connected to it. Sensitive DGFIP applications were not separated from the rest of the RIE, allowing them to be accessed from parts of the network with no apparent need. Investigators also found traces of many attempts to move into other government bodies on the network.
The accounts the attacker used had no special privileges, yet they could reach a large amount of data. ANSSI did not look at how user rights were managed for this report.
The second route led to land-registry data. It went through APEX, a portal for partners such as notaries and land surveyors, which asked for a password and a one-time code sent by email.
The DGFIP's investigation found that a land surveyor's computer at a private firm had possibly been compromised, allowing the attacker to bypass that code. The data was taken between July 27 and August 8. It concerns nearly 435,000 households, according to a note from the Senate finance committee, dated September 4 and reported by Public Sénat.
Why No One Saw the Theft
The DGFIP already had a routine for stolen staff logins, ANSSI says. Its security operations center (SOC) is the team that watches for attacks. When the SOC detected a compromised account or a threat intelligence provider flagged one, it reset the password.
That routine caught some of the attacker's activity but not the theft. On June 7, searches using a stolen account set off an alert and a same-day password reset, but the SOC missed that the attacker had moved from PIGP to ADER.
On June 23, the provider flagged another account the attacker was using, and searches made with it opened a SOC ticket at 8:50 p.m. Paris time. At 4:26 a.m. the next day, the attacker began pulling data from E-Contact via ADER using automated scraping tools that copy data page by page.
The SOC handled the ticket at 10:40 a.m. by resetting the account's password. The reset addressed the alert on PIGP but did not terminate the attacker's open session on ADER. Data kept flowing for almost 16 more hours, until 2:31 a.m. on June 25.
In July, the SOC again caught the attacker's searches but not the theft. The attacker restarted the automated extraction on July 22 with another stolen account. The SOC spotted suspicious searches with that account the next day and reset it on July 24.
The DGFIP's SOC was not monitoring ADER at all. No system linked the warning signs, such as logins at night and connections from VPNs, from addresses in India or from addresses known to be malicious. Data volumes raised no alert either, including the 11 GB exchanged between June 22 and 25.
The number of requests each user made was not checked either, although scraping needs one request per page. On their own, such signals usually cause many false alarms, but together they could have raised an alert, ANSSI says.
ANSSI's own monitoring missed the theft too. Its detection sensors sit only at the entry and exit points of the RIE and the internet, and the agency has no access to application logs.
Because the attacker used real staff accounts, ANSSI's network monitoring did not see the activity. Even so, the total number of requests should have raised alerts, the agency says.
On June 9, the Education ministry's security team told the security teams of all ministries about an incident on its network, shared 17 indicators of compromise and asked them to watch connections from the ministry's addresses. The attacker had already used one of those addresses and did so again in late June. ANSSI says the time taken to analyze and share such indicators should have been kept to a minimum.
On August 6, ANSSI passed the DGFIP two suspicious addresses it had found by searching its past sensor data. The DGFIP blocked them and reset five accounts, but neither agency identified the theft until the attacker claimed it on August 12.
What Has Changed and What ANSSI Recommends
When the report was written, DGFIP staff accounts had been shut out of ADER since August 13 and out of PIGP since August 18. The DGFIP does not expect to reopen either portal to them.
APEX was locked and the surveyor's account disabled on August 14, and the firm's other accounts were disabled four days later. These cuts significantly disrupted some DGFIP services and partner organizations.
An action plan has been drawn up to extend monitoring to all DGFIP business applications, implement strong authentication, and set limits on the amount of data that can be accessed. ANSSI says only a fuller audit, already planned, will identify all the weaknesses that could be exploited.
E-Contact, which had no second login step, will have one, and tools to detect unusual volumes of data viewed or copied will be deployed, according to the Senate note. By the time of the note, staff could no longer reach DGFIP tools from their personal devices.
ANSSI's recommendations for the DGFIP include:
Revoke every active session, on all applications and portals, whenever a password is reset.
When an account is reported as compromised, check what it did from the likely date of compromise.
Use multi-factor authentication (MFA) on every application, with a second factor that still protects the account if the password is stolen. A one-time code sent by email is not enough if the same password opens the mailbox. Hardware tokens or authenticator apps, ideally on a separate device, are preferred.
Monitor every business application in a SIEM, a system that collects security logs. Set quotas on the records accessed, requests made and data exchanged over a given period.
Do not allow personal devices to access work resources.
Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/U80r3PR
via IFTTT
A group of academics from VUSec and Scuola Superiore Sant'Anna have disclosed details of a new Spectre CPU vulnerability variant that affects Just-In-Time (JIT) engines present in web browsers, language runtimes, and the operating system kernel, across multiple CPU vendors.
"The key insight is that, while modern CPUs restore architectural code coherence after self-modification, they do not necessarily invalidate stale indirect branch prediction entries (i.e., branch targets)," researchers Sander Wiebing, Yuhui Zhu, Alessandro Biondi, and Cristiano Giuffrida said in an accompanying paper.
"In JIT engines, these stale targets can outlive the original code and later be reused when the code cache is repopulated, yielding a transient execute-after-free primitive. This allows attackers to hijack transient control flow to newly generated code at obsolete offsets, bypassing software hardening or reaching misaligned gadgets."
BTR was evaluated against SpiderMonkey (the JIT engine of Mozilla Firefox), GraalVM, and the Linux kernel's cBPF JIT, all of which have been found to be affected, although with "markedly different exploitability characteristics and leakage rates."
As a proof-of-concept, two end-to-end exploits have been devised against the Linux kernel that can be used to leak and recover the root password hash within minutes from a fully patched Intel system with default protections enabled.
Spectre refers to a class of CPU security vulnerabilities first discovered in 2017 that exploit speculative execution, a performance optimization technique that modern processors use to predict and execute instructions beforehand.
An attacker can exploit this loophole to trick a CPU into performing speculative operations that access sensitive data, and then infer that data through a cache timing side channel.
Spectre v2 is one specific type of the Spectre attack that abuses indirect branch prediction in modern processors to achieve the same goals. Specifically, it poisons the CPU's branch prediction mechanism to cause a victim program to execute an indirect branch, which, in turn, causes the CPU to mispredict the branch and speculatively execute attacker-controlled code or a gadget.
Although the results of the misprediction are discarded, an attacker can infer what the victim's speculative execution accessed by taking advantage of the cache state changes and measuring the cache changes.
"BTR targets JIT engines and arises from the interplay between Self-Modifying Code (SMC) and indirect branch prediction," the researchers said, adding, "JIT engines do expose exploitable transient-execution opportunities induced by SMC for the first time."
The attack presumes an attacker who is able to run unprivileged code in a JIT engine and is seeking to disclose sensitive data from the host environment. The entire sequence of actions is as follows -
The attacker lures the JIT engine into allocating a training chunk and forces the victim branch to jump to it, thereby inserting a BTB entry referencing the current entry point.
The attacker forces a deallocation of the training chunk and an allocation of the target chunk that partially reuses the same address.
The attacker triggers the indirect branch again, the CPU uses the now-stale branch target buffer (BTB) entry and speculatively jumps to the old training-chunk entry point.
The end result is control-flow hijacking and secret data disclosure.
"By redirecting control flow to an architecturally invalid entry point, the attacker can bypass Spectre hardening mitigations or execute misaligned instructions, ultimately disclosing secret data," the researchers explained.
However, a key aspect BTR hinges on is that the stale BTB entry must not be invalidated or replaced after the JIT engine frees the training chunk, and the branch predictor must select the stale BTB entry for prediction.
Following responsible disclosure, mitigations for BTR have been released and merged into the Linux kernel (CVE-2026-64507 and CVE-2026-64508).
"GraalVM instead hinders region reuse by randomizing JIT code-cache locations," the researchers said. "Mozilla considered IBPB [Indirect Branch Predictor Barrier]-based mitigations, but is currently prioritizing the completion and deployment of site isolation."
The disclosure comes nearly two months after MIT CSAIL researchers Daniël Trujillo and Mengjia Yan disclosed a speculative execution attack technique called Interrupt Injection that can bypass Spectre v2 defenses and leak arbitrary kernel memory from Intel- and AMD-based Linux systems.
from The Hacker News https://ift.tt/AyX8UzV
via IFTTT
