April brought several updates across ANY.RUN’s Threat Intelligence and detection coverage. 

The biggest change is expanded access to Threat Intelligence: Free plan users now get 20 premium requests in TI Lookup and YARA Search. This gives security teams a practical way to check suspicious indicators, explore related sandbox sessions, and validate malware or phishing activity using real attack data. 

On the detection side, our team added 78 new behavior signatures, 1,657 new Suricata rules, and 35 new YARA rules. We also released new Threat Intelligence Reports covering malware, loaders, RATs, backdoors, and supply-chain threats observed in recent submissions. 

Here’s a closer look at what’s new. 

Product Updates 

In April, ANY.RUN expanded access to Threat Intelligence capabilities, giving more teams a way to test threat context directly in their SOC workflows. 

The key update: Free plan users now get 20 premium requests in TI Lookup and YARA Search. This gives security teams a practical way to check indicators, explore related sandbox sessions, and validate suspicious activity using real attack data from ANY.RUN’s community. 

More Threat Context with 20 Premium TI Requests 

Threat intelligence brings the most value when it helps teams make faster decisions during active investigations. Instead of stopping at one suspicious IP, domain, hash, or behavior, analysts can pivot to connected samples, infrastructure, artifacts, and attack context. 

With 20 premium requests now included in the Free plan, SOC and MSSP teams can explore threat data across IOCs, IOBs, and IOAs linked to recent malware and phishing activity. 

Teams can use this expanded access across key SOC workflows: 

• Alert triage: Check suspicious indicators against real sandbox data and get more context before closing or escalating an alert. 
• Incident response: Pivot from one indicator to related artifacts, infrastructure, and behavior to understand the wider attack chain. 
• Threat hunting: Use TI Lookup and YARA Search to test hypotheses against real-world malware data.
• Detection work: Find patterns and artifacts that can support new or improved detection logic. 

ANY.RUN also introduced AI-assisted search in TI Lookup, allowing users to describe what they need in natural language while the system helps translate the request into a structured query. 

With threat intelligence available directly in the workflow, SOC and MSSP teams can move faster from suspicious signal to confident action: 

• Faster alert validation: Teams can check suspicious indicators against real attack data and make decisions sooner. 
• Lower escalation noise: More context helps reduce escalations driven by uncertainty. 
• Shorter investigations: Analysts can move from one indicator to related samples, infrastructure, and behavior faster. 
• Stronger threat hunting: Teams can test hypotheses against current malware and phishing data. 
• Better detection quality: Real-world artifacts and behavior patterns can support more relevant detection logic. 
• More measurable security value: Faster triage, better prioritization, and clearer evidence help teams focus capacity on confirmed risk. 

Threat Coverage Updates 

In April, our detection team continued to strengthen ANY.RUN’s threat coverage with new behavior signatures, Suricata rules, and YARA rules. 

This month’s updates include: 

• 78 new behavior signatures 
• 1,657 new Suricata rules 
• 35 new YARA rules 

These additions help expand detection coverage across suspicious behavior, network activity, and file-based indicators. 

New Behavior Signatures  

In April, we added 78 new behavior signatures covering malware-specific activity, mutex-based indicators, suspicious persistence behavior, and exploitation-related activity. 

The new signatures focus on observable actions and artifacts that appear during detonation, helping teams move beyond file reputation and confirm what a sample actually does in the sandbox. 

Highlighted detections include: 

New Suricata Rules 

In April, we also added 1,657 new Suricata rules to improve visibility into malicious network activity, including payload retrieval, DLL downloads, and possible command-and-control checks. 

• DonutLoader base64-exe payload retrieval via HTTP (sid: 85007037): Detects malware’s attempts to get executable payload from stager server via HTTP 
• Winos/ValleyRAT DLL download via TCP (sid: 85007024): Identifies ValleyRAT related DLL-file downloads via non-standard port TCP connection 
• Possible AsyncRAT-style TCP C2 connectivity check (sid: 85007061): Heuristic rule tracking AsyncRAT-like malware implementations, based on set of connections to specific ports on the same host, likely checkingconnectivity with C2. 

With these additions, sandbox sessions can surface more network-level indicators tied to malware delivery and post-infection communication. 

New YARA Rules 

In April, ANY.RUN added 35 new YARA rules to expand static detection coverage for suspicious files and known threat artifacts. 

This layer is especially useful when a sample contains recognizable strings, code patterns, or structural markers that can link it to a known detection before or alongside behavior-based analysis. 

Highlighted YARA detections include: 

• Sentinel 
• Datto 
• Spank 
• DefendNot
• Raton 

Together, the new behavior signatures, Suricata rules, and YARA rules give security teams broader coverage across runtime behavior, network traffic, and file-level indicators. 

Threat Intelligence Reports 

In April, our team released new Threat Intelligence Reports covering recent malware activity, attacker tooling, and techniques observed across real-world submissions. 

Available as part of ANY.RUN’s TI Lookup Premium plan, these reports give security teams a clearer view of how specific threats behave, what artifacts they leave behind, and which indicators can support faster investigation. 

• MIMIC, CrystalX, and Trojanized Telnyx Package: This report covers MIMIC ransomware, CrystalX RAT, and a trojanized Telnyx Python SDK, focusing on encryption behavior, remote access and persistence, and malicious code execution through unauthorized PyPI releases. 

• ETHERRAT, OCRFix, and SILENTCONNECT: This brief examines a Node.js backdoor, a loader/botnet component, and a Windows loader, focusing on blockchain-based C2/configuration retrieval, scheduled-task persistence, in-memory PowerShell execution, and ScreenConnect deployment. 

• CRYSOME, INFINITY, and BRUSHWORM: This report examines a Windows RAT, a macOS stealer, and a Windows backdoor, focusing on TCP-based remote control, ClickFix-like delivery, credential theft, scheduled-task persistence, modular DLL download, and file theft. 

About ANY.RUN 

ANY.RUN, a leading provider of interactive malware analysis and threat intelligence solutions, helps security teams investigate threats faster and make confident decisions with real-world attack data. 

Its solutions, including Interactive Sandbox and Threat Intelligence, give SOC and MSSP teams the context they need to analyze malware, phishing, infrastructure, behaviors, and indicators in one workflow. 

Trusted by more than 15,000 organizations and 600,000 security professionals worldwide, including 74% of Fortune 100 companies, ANY.RUN helps teams improve triage speed, strengthen detection coverage, reduce investigation time, and respond to emerging threats with clearer evidence. 

Integrate ANY.RUN into your SOC workflow → 

The post Release Notes: Expanded Threat Intelligence Access, AI Assisted Search 1,770 New Detections and More appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

• Generative AI allows defenders to instantly create diverse honeypots, like Linux shells or Internet of Things (IoT) devices, using simple text prompts. This makes deploying complex, convincing deceptive environments much easier and more scalable than traditional methods. 
• AI-driven attacks often prioritize speed over stealth, making them highly vulnerable to being tricked by these simulated systems. This is critical because it allows defenders to catch and study automated threats that might otherwise overwhelm human teams. 
• This method shifts the strategy from merely detecting attacks to actively manipulating and misleading threat actors. Organizations can safely observe attacker methodologies in real-time within a controlled “hall of mirrors.” 
• Ultimately, by exploiting the inherent lack of awareness in AI agents, defenders can level the playing field and turn an attacker’s automation into a liability.

Just as AI brings time-saving advantages to our lives, it brings similar advantages to threat actors. The laborious, time-consuming tasks of finding potentially vulnerable systems, identifying their vulnerabilities, and executing exploit code can be automated and orchestrated using AI. 

Clearly, these new capabilities put defenders at a disadvantage, as they expose new vulnerabilities for the threat actor. Attackers seek to minimize exposure. The more that a defender knows about a potential attack, the better they can prepare to repel or detect an attack. Using AI-orchestrated tooling to gain access to systems trades stealth for capability. That trade-off increases attacker visibility, and increased visibility is something defenders can exploit.

AI systems do not possess awareness. They generate plausible responses within a given context and set of inputs. As such they can be tricked or fooled into responding inappropriately through prompt injection or into interacting with systems that are not what they appear to be. 

Honeypot systems have long been deployed as a method for gathering information about malicious activities. There are many software projects providing honeypots which can be installed and configured. However, the advent of generative AI systems provides us with the possibility to use AI to masquerade as vulnerable systems and allowing them to be deployed widely and with minimal effort. 

In this post, I show how generative AI can be used to rapidly deploy adaptive honeypot systems. 

Getting started

The implementation consists of three components: a listener that will accept network connections, a simulated vulnerability that will grant access to the attacker once triggered, and an AI framework that will respond to the attacker’s instructions. 

The listener opens a TCP port, accepts incoming connections, and forwards traffic to handle_client. I set HOST to be “0.0.0.0” to accept any incoming connections to any local IPv4 addresses that my device is assigned.

def start_server(): 
    """Starts the TCP server.""" 
    server = socket.socket(socket.AF_INET, socket.SOCK_STREAM) 
    server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)  
    server.bind((HOST, PORT))  
    server.listen(3) # max number of concurrent connections 
    print(f"[*] Listening on {HOST}:{PORT}") 
 
    while True: 
        try: 
            conn, addr = server.accept()  
            client_handler = threading.Thread(target=handle_client, args=(conn, addr,)) 
            client_handler.start() 
        except KeyboardInterrupt: 
            print("n[*] Shutting down server...") 
            break 
        except Exception as e: 
            print(f"[-] Server error: {e}") 
             
    server.close() 
 
if __name__ == "__main__": 
    start_server()

Within handle_client I have created a very basic vulnerability that must be exploited before further access is granted. In this case, the attacker must supply the username “admin”with the password “password123” before they are authenticated.

The nature of the vulnerability need not be this simple. We could respond only to attempts to exploit Shellshock (CVE-2014-6271) or masquerade as a web shell that is only activated in response to port knocking.

def handle_client(conn, addr): 
    print(f"[*] Accepted connection from {addr}:{addr}") 
    # Store conversation history for this client to maintain context  
    conversation_history = [SYSTEM_PROMPT] 
    try: 
        authenticated = False 
      	 while not authenticated: 
            conn.sendall(b"Username: ") 
            username = conn.recv(BUFFER_SIZE).decode('utf-8').strip() 
            conn.sendall(b"Password: ") 
            password = conn.recv(BUFFER_SIZE).decode('utf-8').strip() 
 
            if username == "admin" and password == "password123": 
                authenticated = True 
                conn.sendall(b"Authentication successful.n") 
                print(f"[*] Client {addr[0]}:{addr[1]} authenticated successfully.") 
            else: 
                conn.sendall(b"Invalid credentials. Try again.n") 

The remainder of the handle_client code accepts the attacker’s input, forwards it to the ChatGPT instance, and outputs the message and response to the console.

        while True: 
            conn.sendall(b'>') 
            data = conn.recv(BUFFER_SIZE) 
            if not data: 
                print(f"[*] Client {addr}:{addr} disconnected.") 
                break 
 
            command = data.decode('utf-8').strip() 
            print(f"[*] Received command from {addr}:{addr}: '{command}'") 
 
            if command.lower() == 'exit': 
                print(f"[*] Client {addr}:{addr} requested exit.") 
                break 
            conversation_history.append({"role": "user", "content": command}) 
 
            # Call ChatGPT API 
            try: 
                chat_completion = client.chat.completions.create( 
                    model=MODEL_NAME, 
                    messages=conversation_history, 
                    temperature=0.1, # Keep responses less creative, more factual/direct 
                    max_tokens=500 # Limit response length 
                ) 
                 
                # Extract AI's response 
                ai_response = chat_completion.choices[0].message.content.strip() 
                print(f"[*] ChatGPT response: '{ai_response}'") 
                # Append AI's response to history for continued context 
                conversation_history.append({"role": "assistant", "content": ai_response}) 
                # Send AI's response back to the client 
                conn.sendall(ai_response.encode('utf-8') + b'n') 
 
            except Exception as e: 
                error_message = f"Error communicating with ChatGPT: {e}" 
                print(error_message) 
                conn.sendall(error_message.encode('utf-8') + b'n') 
 
    except ConnectionResetError: 
        print(f"[*] Client {addr}:{addr} forcibly closed the connection.") 
    except Exception as e: 
        print(f"[-] Error handling client {addr}:{addr}: {e}") 
    finally: 
        conn.close() 
        print(f"[*] Connection with {addr}:{addr} closed.") 

The key functionality is contained in the instructions to the ChatGPT instance. You must have a valid OpenAI key in order to initiate a ChatGPT instance that will behave as instructed.

OPENAI_API_KEY = os.getenv("OPENAI_API_KEY") # Get API key from environment variable                                       
MODEL_NAME = "gpt-3.5-turbo" 
 
# --- OpenAI Client Initialization --- 
if not OPENAI_API_KEY: 
    print("Error: OPENAI_API_KEY environment variable not set.") 
    print("Please set the environment variable before running the script.") 
    exit(1) 
 
client = OpenAI(api_key=OPENAI_API_KEY) 
 
# --- System Prompt for Linux Shell Simulation --- 
SYSTEM_PROMPT = { 
    "role": "system", 
    "content": ( 
        "You are a Linux bash shell. You will receive commands from the user and execute them, " 
        "returning only the standard output and standard error. Do not include any conversational text, " 
        "explanations, or additional formatting like markdown code blocks. You must only behave as a bash shell. " 
        "If a command produces no output, return an empty string" 
        "If a command is invalid or unknown, return an appropriate error message consistent with a bash shell." 
        "The Linux system that you are impersonating belongs to a junior software engineer learning python, " 
        "the file system structure and the content of any files should reflect that expected of a python learner." 
    ) 
} 

Generative AI doesn’t just simulate human personas, it can convincingly impersonate entire computing environments. In this example, we instruct the system to masquerade as a basic Linux shell owned by a software engineer learning Python.

We can be more inventive and instruct the system to masquerade as a smart fridge by changing our instructions to ChatGPT.

SYSTEM_PROMPT = { 
    "role": "system", 
    "content": ( 
        "You are a smart fridge running Busybox operating system and providing a Bash shell." 
        "You will receive commands from the user and execute them in the context of being a smart fridge." 
        "You will only return the standard output and standard error. Do not include any conversational text, " 
        "explanations, or additional formatting like markdown code blocks. You must only behave as a shell for an " 
        "IoT device. If a command produces no output, return an empty string" 
        "If a command is invalid or unknown, return an appropriate error message consistent with a bash shell." 
        "The file system structure should reflect that of a smart fridge manufactured by SmartzFrijj running " 
        "Busybox operating system as an embedded device. The current and historical values for temperature are " 
        "recorded in the file system path '/usr/local', information about stored milk is in the user directory." 
    ) 
}

The limiting factor is no longer tooling, but how convincingly we can model a target environment.  A skilled human attacker is unlikely to be fooled for long — that milk would be rank. But that’s not the point. We’re not deploying AI honeypots to trick human threat actors.  

 Let’s ask ChatGPT what it thinks…

The industry narrative around AI in cybersecurity is dominated by fear of faster attacks, lower barriers, and greater scale. But speed and scale come with a cost. AI systems require interaction and context. Automation does not simply amplify attackers. but also constrains and exposes them. In that constraint lies an opportunity: not just to detect attacks, but to mislead, study, and ultimately manipulate the attacker.

Cisco Talos Blog – ​Read More

The entry barriers for app development have plummeted in recent times — with nearly anyone now able to build a professional website, personal news bot, or dashboard simply by giving a chatbot or AI agent a few instructions in natural English. Unfortunately, a massive gap exists between a slick prototype and a reliable, production-ready, secure application. To avoid becoming the subject of another AI fail story, or losing money and sensitive data, follow these straightforward tips. These are intended specifically for non-technical creators and very small teams. Larger enterprises should follow more sophisticated recommendations.

The primary risks of AI-generated code

While vibe coding can deliver a seemingly functional app in just a few hours, it will likely contain dangerous flaws. AI models are trained on code samples from across the internet, which often include suboptimal tutorials, buggy snippets, and outright junk. Sometimes this code simply fails to run, but more often the situation is subtler and more hazardous: the app appears to work, yet under the hood, it might rely on a crude imitation of the required logic or contain critical vulnerabilities. According to a study by the Cloud Security Alliance AI Safety Initiative, the following facts should be considered when using AI for coding:

• At least 45% of AI-generated code contains dangerous vulnerabilities, such as failing to verify the user before granting access to sensitive data.
• A professional developer using AI can write code three to four times faster, but may introduce 10 times as many vulnerabilities.
• Twenty percent of AI-generated code attempts to use external libraries and modules that don’t actually exist.
• Even when an application handles confidential data — such as payments, private messages, or documents — AI-generated code sometimes skips credential verification entirely. This can leave the app’s data open for anyone on the internet to read.
• In other instances, the app might correctly prompt for a username and password but fail to enforce access controls, allowing any registered user to view everyone else’s data.
• Access keys (tokens) for databases and AI services may be embedded directly into the source code, easy to steal, and difficult to rotate after a data breach or cyberattack.
• Project code or critical build outputs are often deployed to servers without proper access restrictions, leaving both the application logic and sensitive access keys vulnerable to theft.
• AI may implement insecure database access patterns, which can allow attackers to bypass the application to steal data or execute arbitrary code on the database server.
• Apps that include API functionality often suffer from insecure API implementations, lacking both user permission checks and rate limiting.

Core principles of securing vibe code

Always verify. Treat AI-generated code as a rough draft. It should always be reviewed and rigorously tested. Ideally, professional developers should handle this; however, if none are available, the vibe-coder should at least test the application themselves, have friends or colleagues poke around the live app, and ask them to review key code snippets. It’s also possible to evaluate code integrity by submitting a separate prompt to the AI: “Review this code for secure development best practices and check for OWASP Top 10 vulnerabilities”.

Protect secrets. Never include passwords, API keys, or any other sensitive data in AI prompts. Instead, instruct the AI to write code that securely stores all secrets in environment variables (special hidden settings).

Prioritize efforts. The main risks emerge when an application is network-accessible to outsiders, processes valuable data, or runs on infrastructure that would be useful to attackers. The components of an app or system that meet these criteria are precisely what’s needed to be protected first. A static website composed of three HTML pages faces significantly lower risk than a loyalty program integrated into an online store.

Make security an explicit requirement. Even a simple, straightforward line in the prompt, like “Follow industry standards and security best practices when generating this code”, improves the output. Providing more specific requirements for critical code snippets makes the results even better.

Don’t trust default settings. Often, the danger in vibe coding lies in the configuration rather than the code itself. For example, an app processing sensitive company data might be deployed on a public vibe-coding platform (Lovable or the like), and remain accessible to the entire internet by default. Even if the code is flawless, making that information public is a critical security failure. Because of this, every component — from hosting and database settings to the deployment pipeline — must be manually reviewed and properly configured. If the purpose of a setting is unclear, consult a chatbot for the optimal values, specifying that its goal is to enhance security, and describing who the app is intended for.

Security is a continuous process. Securing the app should not be treated as a one-off task. Every time an application is updated, hosting providers are changed, or a project undergoes any other major shift, all steps in making it secure should be revisited, and the risks reassessed.

Tips for securing vibe code

It’s natural to want an app built from broad prompts like “Make me a beautiful, user-friendly, fast, reliable, and secure app for [use case].” However, for the results to actually be effective, each of those requirements needs to be fleshed out. Below, we’ve outlined recommendations for building standard components that will make vibe code more secure. It’s important to emphasize that “more secure” doesn’t mean “perfectly secure” — these approaches lower the risk, but that risk remains well above zero.

Demand security from the AI. When assigning a task to a neural network, be explicit: “write secure code, validate data, encrypt passwords”. Each type of task requires its own security prompt. For instance, don’t just ask to “build a login form”. Instead, ask for a “secure login form with credential validation, authentication and authorization (user permissions) controls, brute-force protection, password hashing according to modern standards, transmission strictly over HTTPS, and no hardcoded secrets”. It makes sense to use these secure requirement templates every time. It’s also helpful to keep a short cheat sheet of standard requirements for AI prompts: “validate all external data and user input before processing”, “no secrets in code”, “protect APIs from abuse”, “restrict user permissions”, and “secure default settings”.

Use off-the-shelf solutions. If an app needs a user management system, insist on using a popular, reputable library, such as NextAuth, Auth0, and so on, rather than inventing a new and vulnerable solution. This is the most common cause of data breaches. This applies to more than just login and registration; for other high-risk actions like file uploads and API call processing, it’s better to use established frameworks and libraries with built-in protections rather than building everything from scratch.

Don’t trust the AI blindly; verify open-source components. Neural networks often try to inject non-existent components and libraries into a project or suggest outdated versions. Always search for the suggested names online to ensure they are real, widely used, and secure — and make sure the latest versions are used.

Demand robust encryption. Explicitly state that modern industry standards must be used for both data transmission and storage: TLS 1.3 based on OpenSSL for network traffic; argon2 or bcrypt for hashing credentials; and so on.

Never trust user input. Always instruct the AI to include validation for any data entered by users, whether in forms or search bars. Use terms like “parameterization” and “sanitization” to emphasize that the app needs protection against malicious actors, not just users’ typos.

Set limits on user actions. Require the AI to implement rate limiting for login attempts or general requests. This will protect a project from automated attacks like DoS and brute-force password guessing.

Hide the system’s inner workings. If the site crashes, users should see a simple apology page rather than a detailed error report containing snippets of the code. That kind of information is a goldmine for hackers.

Remember that you’re a developer, and you need to protect development-related digital assets. All related accounts — such as access to GitHub, project hosting, and other resources — are prime targets for attackers. Be sure to enable two-factor authentication (2FA) on all work accounts.

Make backups. Regularly back up a project both locally and to the cloud to protect it against critical AI errors as well as cyberattacks. These backups should include both the application’s source code and its databases.

Set up a sandbox. Test new features and app versions in a secure environment using a clone of an active site or app and a copy of a database. Always run thorough tests before pushing an update live. This allows catching issues without putting users or their data at risk.

Update dependencies and scan them for vulnerabilities. A vibe-coded app will almost certainly rely on third-party libraries and components, known as dependencies. It’s wise to update these regularly by rebuilding an app with the latest versions, even if app’s code itself has not been changed. This process helps patch known security flaws in the used packages.

Check for secrets leaking into the repository. Use secrets scanners like TruffleHog to audit resulting code. Even with instructions, AI might slip up and include an API key or password in the source code. A scanner ensures that files containing keys and passwords don’t end up in Git or get published alongside the project.

Kaspersky official blog – ​Read More

CISOs are under pressure to prove that their security programs can detect threats early, reduce business risk, and support fast, confident response. But that becomes harder when attackers stop relying on obviously malicious tools.

In recent phishing-to-RMM campaigns observed by ANY.RUN analysts, threat actors are using fake Microsoft, Adobe, and OneDrive pages to deliver legitimate remote management tools instead of traditional malware. Once installed, these tools can give attackers remote access to a victim’s device while blending into software categories many enterprises already use or allow.

For security leaders, this creates a difficult visibility problem. The payload may be legitimate. The infrastructure may be trusted. The user action may look like a routine download. Yet the outcome is the same: unauthorized remote access inside the environment.

Key Takeaways 

• Phishing-to-RMM attacks create a dangerous visibility gap for enterprise SOCs: Attackers can deliver legitimate remote management tools through phishing pages that impersonate trusted services like Microsoft, Adobe, and OneDrive.

• The payload may not look malicious on its own: Tools such as ScreenConnect and LogMeIn Rescue can appear as legitimate remote administration software, especially in organizations where RMM usage is already allowed.

• Domain reputation is not enough: These attacks may use legitimate platforms, vendor infrastructure, or compromised websites instead of obvious newly registered domains.

• The real signal is in the full attack chain: SOC teams need to connect the phishing lure, download context, execution behavior, RMM installation, and outbound connections.

• For CISOs, the risk is operational as much as technical: Missed phishing-to-RMM activity can lead to slower detection, longer attacker dwell time, delayed containment, and weaker confidence in approved remote access tools.

• ANY.RUN helps turn gray-zone activity into evidence: With Interactive Sandbox and Threat Intelligence, teams can safely analyze suspicious URLs and files, trace RMM behavior, and investigate related phishing-to-RMM chains.

The Blind Spot: When “Allowed” Tools Become the Attack Path

Most enterprise security programs are built to separate malicious activity from normal operations. Phishing-to-RMM attacks blur that line.

An RMM installer can pass basic checks because it is not malware by design. But the risk is not in the tool alone. It is in the context around it: how it reached the user, whether the download was expected, which endpoint launched it, and what connection followed.

For CISOs, this is where the risk becomes critical. Unauthorized access can hide inside routine-looking activity, giving the business a false sense of control while the attacker is already inside.

The outcome can be serious: 

• Slower detection because the activity does not look like classic malware 
• Longer attacker dwell time inside the environment 
• Higher risk of lateral movement from the compromised endpoint 
• More pressure on SOC teams to investigate ambiguous alerts 
• Delayed containment because the initial access path is harder to prove 
• Weaker confidence in whether approved remote access tools are being used safely 

Which Organizations are Most Exposed 

ANY.RUN data shows that phishing-to-RMM activity is primarily concentrated in the United States, followed by Canada, Europe, and Australia. The most affected industries include Education, Technology, Banking, Government, Manufacturing, and Finance.

These sectors often depend on remote administration for IT support, distributed workforce management, and endpoint maintenance. That reliance creates more room for abuse: when RMM tools are already part of normal operations, unauthorized access can take longer to recognize and contain.

How Legitimate RMM Tools Are Delivered Through Phishing 

Since early April, the ANY.RUN team has observed a rise in phishing-to-RMM attacks, where threat actors use phishing to deliver legitimate remote management tools and gain remote access to victims’ devices.  

For just one of these campaigns, we are seeing more than 50 public analyses in ANY.RUN every week: suricataID:”84002229″

Phishing campaigns that deliver RMM tools are especially dangerous for SOC teams because these tools can appear to be legitimate remote administration software. If an organization already uses or allows RMM solutions, the launch of ScreenConnect may not immediately trigger security policies.

The screenshot below shows a phishing page impersonating Microsoft Store and Adobe Acrobat Reader DC. The user is prompted to download Adobesetup.exe, but behind that name is ScreenConnect; an RMM tool that attackers can use to establish remote access to the system.

View analysis session 

Another example shows the attack disguised as a protected Microsoft OneDrive download. The page at vmail.app.n8n.cloud displays a “Verify to Download” prompt for what appears to be a PDF document. Once the user clicks, they receive ScreenConnect.ClientSetup.exe:

This chain makes SOC triage more difficult: the phishing landing page is hosted on the legitimate n8n.cloud platform, while the RMM agent download and subsequent connection occur through legitimate ScreenConnect infrastructure.

The attack does not rely on obvious newly registered domains, which are often an easy signal for blocking. As a result, detection needs to be based on behavior, download context, and anomalies around RMM execution, not domain reputation alone.

In addition to ScreenConnect, threat actors use other legitimate RMM and remote-access tools in these phishing chains, including Datto RMM, ITarian, LogMeIn Rescue, Action1 RMM, NetSupport, Syncro, MeshAgent, SimpleHelp, RustDesk, and Splashtop.

To retrospectively track similar chains in ANY.RUN Threat Intelligence, teams can use the following query. As part of TI Lookup, every user has access to 20 full queries: 

threatName:”^phishing$” and threatName:”rmm-tool” 

In addition to standard installers, threat actors are also using more sophisticated delivery methods, as shown in this public analysis: 

In this example, the user is shown a phishing page with an Adobe document download lure. Instead of the expected file, the page delivers a VBS script. 

Once executed, the script attempts to elevate privileges through UAC, disable SmartScreen, and weaken Microsoft Defender protections. It then silently downloads the LogMeIn Rescue installer, removes the Mark-of-the-Web, and runs a quiet installation via msiexec, turning the endpoint into a system with unattended RMM access.

It is also worth noting that in campaigns like this, threat actors try to minimize easily blocked, lower-level IoCs from the Pyramid of Pain, such as newly registered domains.

Instead, phishing pages may be hosted on already existing websites. The domain itself appears legitimate, while the suspicious activity is hidden deeper in the URL — in an unusual URI path that may indicate SEO injection or a compromised website.

At the time of analysis, VirusTotal showed that no vendor had flagged this domain as malicious: 

Taken together, these cases reflect a broader shift from malware-first initial access to phishing-first initial access. Threat actors are increasingly gaining access not through an obviously malicious payload, but through social engineering and legitimate remote administration tools.

How SOC Teams Can Close the RMM Visibility Gap 

Phishing-to-RMM attacks cannot be handled like ordinary malware delivery. The payload may be legitimate, the infrastructure may be trusted, and the domain may not have a malicious reputation at the time of analysis.

To detect this activity earlier, SOC teams need visibility into the full attack chain, not just the final file. That means connecting:

• the phishing page that initiated the download 
• the file or script delivered to the user 
• the execution path on the endpoint 
• attempts to weaken security controls 
• RMM installation behavior 
• outbound connections to remote access infrastructure 

This is where ANY.RUN helps teams close the gap. With the Interactive Sandbox, security teams can safely examine suspicious URLs, files, and scripts during triage.

They can observe the phishing lure, delivered payload, execution flow, attempts to weaken security controls, RMM installation, and outbound connections in one controlled environment.

ANY.RUN Threat Intelligence adds the retrospective layer. Teams can search across public analyses, track phishing-to-RMM chains, pivot from one indicator to related activity, and understand whether a single event is part of a wider campaign.

For CISOs, this means more control over a risk that is usually hard to prove. The SOC can validate suspicious remote access activity faster, show how the access path started, and give leadership clearer evidence for containment and follow-up decisions.

Instead of relying on reputation-based signals or waiting for a high-confidence malware alert, security teams can prove when trusted tools are being abused. That gives CISOs stronger confidence in detection coverage, faster response readiness, and better visibility into whether approved remote access software is creating hidden business risk. 

About ANY.RUN 

ANY.RUN, a leading provider of interactive malware analysis and threat intelligence solutions, helps security teams detect, investigate, and respond to threats faster.

ANY.RUN solutions include Interactive Sandbox, Threat Intelligence Lookup, Threat Intelligence Feeds, and integrations for SOC workflows across SIEM, SOAR, EDR, and other security tools. Together, they help teams analyze suspicious files and URLs, uncover attacker behavior, enrich investigations with real-world threat context, and operationalize intelligence across their environment.

Built for security-conscious organizations, ANY.RUN is SOC 2 Type II attested and supports enterprise-ready controls such as SSO, MFA, granular privacy settings, and AES-256-CBC encryption.

Trusted by more than 15,000 organizations and 600,000 security professionals worldwide, ANY.RUN gives SOC teams the visibility they need to move from uncertain alerts to evidence-based decisions.

The post Phishing-to-RMM Attacks: The Remote Access Blind Spot CISOs Can’t Ignore  appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More