Do not expose your MGMT interfaces to internet" is a recurring advice.
What about limiting mgmt access to trusted IP hosts via a local-in-policy?
PLEASE NOTE: we are NOT talking about "Administrators" object settings here, as it's well known that using that so-called mitigation will cause the login page to be actually presented to the potential attacker - and, ANY exposed HTTP(S) protocol will sooner or later be breached by the CVE of the week.
We are talking about: I set ONE main trusted public IP address the mgmt interface should reply to by actually presenting a web page (and maybe a 2nd one acting as a backup)... that's two addresses out of 4 billions.
All other HTTP(S) request to GUI are just be silently dropped, with no reply whatsoever.
Is that safe enough?
Added: one could even expand this concept by blocking via local-in-policy, WAN-side, any other critical protocol, as an added safety measure - even if that protocol has never been activated in first place: SSH/TELNET, FTP, SNMP, etc.
"Many of the binaries included debug symbols and other development artifacts, suggesting we were looking at in-progress builds rather than a finished, widely deployed tool. The speed and variety of changes across the samples indicate a framework that is being iterated upon quickly to achieve broader, real-world use".VoidLink can steal credentials for cloud, Git, and other source code version control systems, and Check Point believes it is likely targeted at software engineers, either for espionage or supply-chain attacks.3
"It includes rootkit-style capabilities (LD_PRELOAD, LKM, and eBPF), an in-memory plugin system for extending functionality, and adaptive stealth that adjusts runtime evasion based on the security products it detects, favoring operational security over performance in monitored environments"VoidLink is deployed using a two-stage loader. Upon initialization, it enumerates the system's security tools and hardening measures to calculate a risk score and an evasion strategy that its modules then use for increased stealth. The framework supports multiple command-and-control (C&C) communication channels, such as HTTP/HTTPS, ICMP, and DNS tunneling, as well as P2P/mesh-style communication between infected systems. The framework creates a profile of host behavior to adapt C&C communication intervals, has a stealth module containing rootkits targeting various kernel versions that are deployed based on the infected environment, and contains several anti-analysis mechanisms.
Tracked as CVE-2025-62215
According to an advisory from Microsoft's Threat Intelligence Center and Security Response Center, successful exploitation requires an attacker to win a race condition (Concurrent Execution using Shared Resource with Improper Synchronization) in Windows kernel[2], which would result in privilige escalation (SYSTEM) on the targeted system. [3]
The fix was released among other updates for Nov. 2025 patch Tuesday. Helpnet Security describes it as a memory corruption issue. Trend micro's Dustin Childs notes that "Bugs like these are often paired with a code execution bug by malware to completely take over a system"[4]

Threat actors used vishing tactics against staff across various orgs to gain access to Salesforce instances within those orgs.
UNC6040 threat actors commonly call victims’ call centers posing as IT support employees addressing enterprise-wide connectivity issues. Under the guise of closing an auto-generated ticket, UNC6040 actors trick customer support employees into taking actions that grant the attackers access or lead to the sharing of employee credentials, allowing them access to targeted companies’ Salesforce instances to exfiltrate customer data.
UNC6040 threat actors have utilized phishing panels, directing victims to visit from their mobile phones or work computers during the social engineering calls. After obtaining access, UNC6040 threat actors have then used API queries to exfiltrate large volumes of data in bulk.
UNC6040 threat actors have also directly requested user credentials and multifactor authentication codes to authenticate and add the Salesforce Data Loader application, facilitating data exfiltration.
Salesforce allows organizations to integrate with third-party applications, often called connected apps, using OAuth tokens for authentication after approved by an administrator or sufficiently privileged user. UNC6040 threat actors have deceived victims into authorizing malicious connected apps to their organization's Salesforce portal. This application is often a modified version of Salesforce’s Data Loader. During a vishing call, the actor guides the victim to visit Salesforce's connected app setup page, i.e.,
https://login.salesforce[.]com/setup/connect, to approve the UNC6040 malicious app. This grants UNC6040 threat actors significant capabilities to access, query, and exfiltrate sensitive information directly from the compromised Salesforce customer environments. Authorizing a malicious connected app bypasses many traditional defenses such as MFA, password resets and login monitoring, and because OAuth tokens are issued by Salesforce itself, activity coming from the malicious app can look like it’s from a trusted integration.
UNC6040 threat actors have created malicious applications within Salesforce trial accounts, allowing the threat actors the ability to register the connected apps without using a legitimate corporate account, making detection difficult.
Some UNC6040 victims have subsequently received extortion emails allegedly from the ShinyHunters group, demanding payment in cryptocurrency to avoid publication of exfiltrated data. These extortion demands have varied in time following UNC6040 threat actors’ access and data exfiltration, ranging from a period of days to months
.....you just need a user to accept oauth consent for an illegitimate app. By default, Salesforce allows this as long as the user has API access. The individual app can be blocked and oauth revoked by an admin later, but the first "install" is allowed by default
Lapsus$ has been inactive since 2022, when Scattered Spider emerged. ShinyHunters first appeared in 2020 and joined forces with Scattered Spider earlier this year. They jointly announced their retirement last month.

Specific data fields vary from customer to customer. Our analysis has found that the majority of customer records that were compromised are limited to:The airline said the platform stored names, email addresses, phone numbers, birth dates and frequent flyer numbers for six million customers. Qantas did not use the system to store credit card details, personal financial information, or passport details. Qantas has not identified the exact platform attacked in this incident. The airline is a known user of Salesforce and Genesys, vendors whose wares are often deployed in call centres
Name, and/or
Email address, and/or
Qantas Frequent Flyer number (and in some cases, tier, status credits and points balance).
---end data------