October brought another strong round of updates to ANY.RUN, from a new ThreatQ integration that connects our real-time Threat Intelligence Feeds directly into one of the industry’s leading TIPs, to hundreds of new signatures and rules that sharpen network and behavioral detection. 

With 125 new behavior signatures, 17 YARA rules, and 3,264 Suricata rules, analysts can now spot emerging threats faster and with greater precision. Together with the ThreatQ connector, these improvements make it easier for SOCs and MSSPs to enrich alerts, automate response, and gain deeper visibility into live attack activity. 

Product Updates 

Expanding Threat Intelligence Reach: ANY.RUN & ThreatQ 

October brought another major milestone to ANY.RUN’s growing ecosystem; a new integration that links ANY.RUN’s Threat Intelligence Feeds directly with ThreatQ, one of the industry’s leading Threat Intelligence Platforms (TIPs). 

This integration helps SOC teams and MSSPs gain real-time visibility into active global threats, cut investigation time, and strengthen detection accuracy across phishing, malware, and network attack surfaces. 

Now, analysts using ThreatQ can automatically ingest fresh, high-confidence IOCs gathered from live sandbox investigations of malware samples detonated by 15,000+ organizations and 500,000+ analysts worldwide. 

How this update helps security teams: 

• Early detection: Indicators are streamed into ThreatQ the moment they appear in ANY.RUN sandbox sessions, helping teams spot threats before they hit endpoints or networks. 

• Expanded coverage: Up to 99% unique IOCs from recent phishing and malware attacks provide visibility beyond traditional feeds. 

• Faster, smarter response: Each IOC includes a link to its sandbox analysis, giving full behavioral context for rapid validation and containment. 

• Lower analyst workload: Feeds are filtered to include only verified malicious indicators, cutting false positives and Tier-1 triage time. 

Simple Setup, Instant Impact 

The connector works through the STIX/TAXII protocol, ensuring full compatibility with existing ThreatQ environments. Security teams can configure feeds to update hourly, daily, or on a custom schedule; no custom development or infrastructure changes required. 

For detailed information, see ANY.RUN’s TAXII connection documentation. 

Threat Coverage Update 

In October, our team continued to strengthen detection capabilities so SOCs can stay ahead of new and evolving threats: 

• 125 new behavior signatures were added to improve coverage across ransomware, loaders, stealers, and RATs, helping analysts detect persistence and payload activity earlier in the attack chain. 

• 17 new YARA rules went live in production, expanding visibility into credential-dumping tools, network scanners, and new loader families. 

• 3,264 new Suricata rules were deployed, enhancing detection for phishing, APT infrastructure, and evasive network behaviors. 

These updates enable analysts to gain faster, more confident verdicts in the sandbox and enrich SIEM, SOAR, and IDS workflows with fresh, actionable IOCs. 

New Behavior Signatures 

This month’s updates focus on helping analysts catch stealthy activity earlier in the attack chain. The new behavior signatures detect payload downloads, privilege escalation attempts, and persistence mechanisms used by modern ransomware, stealers, and loaders. 

We also expanded coverage of mutex detections and legitimate administrative tools often abused by attackers. Together, these improvements provide clearer visibility into real-world execution flow and strengthen automated classification in the sandbox. 

Highlighted families and techniques include: 

• Jaff 

• Crypvault 

• Aptlock 

• XtBl 

• Ouroboros 

• Nefilim 

• DarkCloud 

• Xworm 

• Snake 

• Cryptowall 

• Phoenix 

• Lazarus 

• Supershell 

• Starfish 

• Valkyrie 

• Pranova 

• Spartacus 

• Velox 

• Lockify 

New YARA Rules 

In October, we added 17 new YARA rules focused on detecting emerging malware families, credential-dumping utilities, and reconnaissance tools increasingly used in modern attack chains. 

These additions strengthen both automated detection and manual hunting, helping analysts identify threats that blend malicious code with legitimate administrative software. 

Several new rules were built directly from live samples analyzed in the sandbox, capturing real payloads, shellcode fragments, and memory artifacts tied to loaders, stealers, and botnets. This ensures faster and more reliable classification when scanning new samples or correlating incidents across environments. 

Highlighted YARA rules include: 

• Maverick: Detection for a recently active loader family observed in targeted phishing campaigns. 

• ChaosBot: Identifies obfuscated botnet samples distributing info-stealers via Discord channels. 

• Hexa: Flags packed binaries linked to a new modular backdoor variant. 

• Pmdump: Detects credential-dumping activity using memory process extraction tools. 

• Task Manager DeLuxe: Identifies legitimate system tools often repurposed for lateral movement. 

• Network Scanner: Flags reconnaissance utilities used to map internal networks. 

• Yapm: Detects process-management tools frequently abused for privilege escalation. 

• TaskExplorer: Expands visibility into post-exploitation tool use. 

• Ophcrack: Detection of password-recovery tools commonly found in attacker toolkits. 

New Suricata Rules 

This month, the detection team delivered 3,264 new Suricata rules to improve coverage of phishing activity, APT operations, and evasive web-based malware behavior. 

These updates expand network visibility for SOCs and MSSPs, helping analysts detect malicious traffic even when it hides behind trusted services or multi-stage redirects. 

Highlighted additions include: 

• Tycoon 2FA Domain Chain (sid:85004273, 85004828, 85005024): New heuristic rules based on set of web-resources loaded in specific order by Tycoon client-side code 

• Patchwork APT Payload Retrieval via HTTP (sid:85004317): Detects HTTP requests for payload used by Patchwork APT 

• Microsoft 365 themed Phishing Attempt (sid:85004831): Identifies mismatch of MS365 authorization URL chain being used on fake websites 

About ANY.RUN 

ANY.RUN supports more than 15,000 organizations worldwide across industries such as banking, manufacturing, telecom, healthcare, and technology, helping them build faster, smarter, and more resilient cybersecurity operations. 

Our cloud-based interactive sandbox enables teams to safely analyze threats targeting Windows, Linux, and Android systems in real time. Analysts can observe every system and network action, interact with running samples, and extract IOCs in under 40 seconds; all without complex infrastructure setup. 

Combined with Threat Intelligence Lookup and Threat Intelligence Feeds, ANY.RUN helps SOCs accelerate investigations, reduce noise, and improve detection accuracy. Teams can easily integrate these capabilities into SIEM and SOAR systems to automate enrichment and streamline response. 

Ready to see it in action? 
Start your 14-day trial of ANY.RUN 

The post Release Notes: ANY.RUN & ThreatQ Integration, 3,000+ New Rules, and Expanded Detection Coverage  appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

Each cyberattack leaves behavioral evidence. A malware sandbox provides the secure environment analysts need to study that activity and uncover hidden tactics. 

Teams using sandbox analysis report measurable gains: 

• 90% faster detection of unknown malware 

• Up to 3× improvement in investigation speed 

• 60% fewer false positives in automated alerts 

Behavior-based visibility gives SOCs the upper hand against stealthy attacks. Let’s see how sandbox security works, and why it has become essential for modern threat detection. 

What’s a Malware Sandbox? 

A malware sandbox is a controlled, isolated environment designed to safely run and observe suspicious files, links, or applications. It allows analysts to see exactly how a threat behaves without risking real systems or networks. 

Instead of relying on signatures or predefined rules, a sandbox focuses on dynamic malware analysis, monitoring how code acts in motion. This approach helps detect new, unknown, or obfuscated malware that traditional antivirus tools often miss. 

Watch the full video on how ANY.RUN’s malware sandbox works 

Inside the sandbox environment, analysts can observe file system changes, registry modifications, network requests, and command execution in real time. Every action is recorded, creating a detailed behavioral profile that reveals the malware’s purpose, persistence methods, and communication patterns. 

In short, a malware analysis sandbox turns hidden threats into visible data, giving cybersecurity teams the clarity they need to understand, detect, and stop complex attacks before they spread. 

How Does a Malware Sandbox Work? 

A malware sandbox operates by executing suspicious files, links, or processes in a virtual and fully isolated environment that imitates a real operating system. This lets analysts safely observe every action the sample performs, without exposing actual devices or networks to risk. 

Modern sandboxes can be built on virtual machines, containers, or emulation frameworks. Each architecture recreates realistic conditions, including file systems, system registries, network connections, and even user interactions, so malware behaves as it would in the wild. 

Here’s how sandbox analysis typically unfolds: 

1. Submission: A suspicious file or URL is uploaded to the sandbox environment for testing. 

2. Execution: The sample runs in isolation, often within multiple OS profiles or hardware simulations. 

3. Observation: The sandbox records every change; file creation, registry edits, system calls, and outbound connections. 

4. Reporting: Once execution completes, a detailed report summarizes the malware’s actions, persistence attempts, and communication patterns. 

This approach, known as dynamic malware analysis, focuses on behavior instead of static code. It allows analysts to detect zero-day threats, hidden payloads, and polymorphic variants that traditional antivirus tools often miss. 

Advanced malware detection sandboxes also counter evasion tactics by simulating real user activity, extending runtime to catch delayed triggers, and randomizing system identifiers to appear like genuine machines. 

By sandboxing malware, security teams gain deep behavioral visibility, understanding not just what the file is, but what it tries to do. 

Example: See Real Sandbox Analysis in Action 

To see how this process works in practice, let’s look at a real-world example. Inside the ANY.RUN sandbox, a phishing sample pretending to be a Google Careers page was analyzed.  

The sandbox reveals the entire attack chain in just 60 seconds, from the Salesforce redirect and Cloudflare CAPTCHA to the fake login page that stole credentials and sent them to its command server. 

See the live session now 

All stages were captured in real time: every request, redirection, and data theft attempt. The sandbox also generated a full picture of the attack: key indicators like file hashes and domains, the techniques the malware used, its network activity, and a clear process timeline. Everything an analyst would need to investigate or build detection rules was right there in one report. 

Benefits of a Malware Sandbox 

A malware sandbox gives analysts a clear view of what really happens when a threat runs. Instead of guessing based on static scans or file signatures, teams can watch the malware in action; safely, and in real time. 

Here’s why that matters: 

• Detect new threats early: Behavior-based detection helps catch zero-day malware before traditional tools even recognize it. 

• See the full attack chain: From file creation to network communication, sandboxes reveal every step the malware takes. 

• Cut down false alarms: Real behavior data separates real threats from harmless lookalikes, reducing alert fatigue. 

• Save investigation time: Automated sandbox analysis delivers full behavioral reports in minutes, not hours. 

• Strengthen threat intelligence: Indicators like domains, hashes, and payloads collected from sandbox runs can feed directly into your detection systems. 

• Scale with ease: Cloud sandbox setups let teams analyze thousands of samples at once, keeping pace with large-scale attacks. 

In short, a malware sandbox helps teams move from guessing to knowing, turning hidden behavior into clear, actionable insights that speed up detection and response. 

Types of Malware Sandboxes 

Not all sandboxes work the same way. Depending on how they’re deployed and what they’re used for, organizations can choose between several types, each offering a different balance of control, scalability, and performance. 

1. On-Premise Sandboxes 

These sandboxes run inside an organization’s own infrastructure. They’re ideal for teams that handle sensitive data and need full control over their analysis environment. On-premise setups can be customized to mimic internal systems closely, from OS configurations to network settings, but they often require more maintenance and hardware resources. 

2. Cloud Sandboxes 

A cloud sandbox runs remotely, making it easier to scale and share results across distributed teams. It’s especially useful for SOCs that need to analyze large volumes of samples daily or for companies that want access without complex local setup. Cloud solutions also stay up to date automatically, ensuring faster adaptation to new threats. 

3. Open-Source Sandboxes 

These types of sandboxes allow researchers and security teams to build their own sandbox environments from scratch. They’re highly customizable and great for experimentation or research, though they usually require more technical know-how to maintain. 

Each of these types of malware sandboxes serves a different need; from enterprise-grade automation to hands-on analysis. Choosing the right one depends on how much control, customization, and scale your security operations require. 

— Yes   — Partial / depends on setup   — No 

Who Needs a Malware Sandbox and How They Use It 

A malware sandbox is a daily necessity across different areas of cybersecurity. From SOC teams to threat intelligence analysts, everyone benefits from being able to see how malware behaves in a safe environment. 

Here’s how different professionals rely on sandbox analysis: 

• SOC teams: Use sandboxes to validate alerts and speed up triage. Instead of guessing whether a file is dangerous, they can watch its behavior in real time and prioritize responses accordingly. 

• Incident responders: Reconstruct full attack chains after an intrusion. Sandbox reports reveal what files were dropped, which connections were made, and how the infection spread; key data for containment. 

• Threat intelligence analysts: Extract indicators of compromise (IOCs), domains, and behavioral patterns to feed detection rules and threat databases. 

• Researchers and malware analysts: Study new malware families in depth without risking production systems, documenting how they evolve or communicate with C2 servers. 

• Managed security providers (MSSPs): Integrate sandbox results into client reports or monitoring workflows, adding measurable value to their detection and response services. 

Sandbox vs Antivirus: Why Sandboxing Wins Against Unknown Threats 

Antivirus software protects against threats that are already known. It scans files, compares them to a database of malware signatures, and blocks anything that matches. This method works well for common, well-documented attacks, but it struggles with new or changing ones. 

Modern malware often hides its code, changes its structure, or uses encryption to stay invisible to signature-based tools. That’s where a malware sandbox makes all the difference. 

Instead of checking what a file looks like, a sandbox watches what it does. It runs the file in a safe, isolated environment and tracks every move; the processes it starts, the files it creates, and the connections it tries to make. This approach, called behavior-based detection, exposes even the newest or most complex threats. 

Simply put, antivirus tools stop what’s already known. A malware sandbox uncovers what’s new and unknown. 

Used together, they give teams both quick protection and deeper visibility; a strong mix for modern cyber defense. 

How Attackers Try to Evade Sandboxes and Why They Still Get Caught 

As malware sandboxes become more advanced, attackers are learning to adapt. Some modern malware doesn’t simply run its code right away; it first checks where it’s running. If it senses it’s inside a sandbox, it may stay quiet, hoping to slip through undetected. 

These are some of the most common tricks attackers use: 

• Delaying execution: The malware waits several minutes or hours before acting, trying to outlast the sandbox’s observation time. 

• Looking for virtual clues: It searches for signs that it’s inside a virtual machine, like specific file names, processes, or limited memory, and stops running if it finds them. 

• Waiting for human activity: Some samples won’t execute until they detect mouse movement or clicks, assuming automated systems won’t simulate them. 

• Checking network connections: Malware might reach out to its command-and-control server and only activate if it receives a valid response. 

To keep up, modern malware analysis sandboxes have grown much smarter. They simulate human actions like typing and clicking, randomize virtual hardware details, and even extend analysis time to catch delayed behavior. Some advanced platforms also run the same sample across multiple environments to expose hidden logic or secondary payloads. 

So yes, attackers keep trying to fool sandboxes. But as sandbox technology evolves, those tricks are becoming less effective. Each new generation of sandbox security makes it harder for malware to hide, ensuring analysts still see the full picture before damage is done. 

How to Choose the Right Malware Sandbox 

With so many sandbox solutions available, choosing the right one can be tricky. Some focus on quick verdicts, others on deep behavioral insights. The best choice depends on your goals; whether you’re running a SOC, enriching threat intelligence, or conducting malware research. 

When evaluating options, start with what matters most: visibility. A good sandbox doesn’t just tell you that a file is malicious, it shows why. It should capture every action the sample performs: file system changes, registry edits, process trees, and network traffic. These behavioral details are what make sandbox analysis so powerful. 

Realism is equally important. The closer the sandbox mimics a real system, the more accurate the results. Platforms that support multiple operating systems and simulate user activity (like mouse clicks or typing) are better at exposing evasive malware that would otherwise stay hidden. 

Speed, scalability, and integration also matter. Cloud-based sandboxes process hundreds of samples in parallel, deliver reports within minutes, and connect easily to SIEM, SOAR, or threat intelligence systems. Structured exports in formats like JSON or STIX/TAXII make automation effortless. 

Finally, consider privacy. If you work with sensitive or client data, make sure your sandbox offers private or isolated analysis modes. 

When choosing your sandbox, think beyond detection. Look for visibility, speed, flexibility, and control; the qualities that help you understand how malware behaves and stop it before it spreads. 

Why ANY.RUN Meets These Criteria 

If you take those same criteria and apply them to ANY.RUN, you’ll see how closely the platform aligns with what modern security teams need. 

ANY.RUN combines what most teams need from a sandbox: visibility, control, and speed; all in a secure, interactive cloud environment. It helps analysts move faster, collaborate better, and uncover behaviors that traditional tools simply can’t see. 

Teams Using ANY.RUN’s Interactive Sandbox Report Measurable Results: 

• 95% of SOCs speed up investigations through real-time interaction and live analysis. 

• Up to 3× higher SOC efficiency, with faster decision-making and automated data sharing. 

• 21-minute reduction in mean time to respond (MTTR) per incident. 

• 36% higher detection rate on average, uncovering hidden and multi-stage threats earlier. 

• Up to 58% more threats detected overall, with behavioral visibility that static tools can’t match. 

• 20% lower workload for Tier 1 analysts, as sandbox automation removes repetitive triage steps. 

• 30% fewer Tier 1 → Tier 2 escalations, thanks to clearer, interactive analysis reports. 

• 90% of threats visible within 60 seconds, allowing faster containment and less dwell time. 

For businesses, that means lower risk exposure, more productive analysts, and faster containment of incidents, all without expanding headcount or infrastructure. 

Frequently Asked Questions About Malware Sandboxes 

About ANY.RUN 

ANY.RUN, a leading provider of interactive malware analysis and threat intelligence solutions, makes this kind of investigation fast and accessible. The service processes millions of analysis sessions and is trusted by 15,000+ organizations and over 500,000 professionals worldwide. 

Teams using ANY.RUN report measurable results; up to 3× higher SOC efficiency, 90% faster detection of unknown threats, and a 60% drop in false positives thanks to real-time interaction and behavior-based analysis. 

Explore ANY.RUN’s capabilities during 14-day trial→ 

Discover how ANY.RUN can help your team detect faster, analyze deeper, and respond smarter. 

Talk to ANY.RUN Experts 

The post What is a Malware Sandbox? Everything SOC Analysts and CISOs Need to Know  appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

• This blog introduces dynamic binary instrumentation (DBI) and guides you through building your own DBI tool with the open-source DynamoRIO framework on Windows 11.
• DBI enables powerful runtime analysis and modification of binaries critical for malware analysis, security auditing, reverse engineering, and performance profiling — all without access to source code.
• Learn DynamoRio’s strengths, its practical applications in evading anti-analysis techniques, and step-by-step instructions for developing and testing your own instrumentation clients.
• Explore hands-on examples with access to a GitHub repository with sample code to jumpstart your own research and tooling.

Binary instrumentation involves inserting code into compiled executables to monitor, analyze, or modify their behavior — either at runtime (dynamic) or before execution (static) — without altering the original source code. Tools like DynamoRIO, Intel PIN, Valgrind, Frida, and QDBI are commonly used in the field. Static binary instrumentation (SBI) injects code before a binary runs, typically by modifying the file on disk, whereas dynamic binary instrumentation (DBI) operates in memory while the program runs. These techniques are widely used for profiling, debugging, tracing, security analysis, and reverse engineering.

Introduction to DynamoRIO

DynamoRio (DR) is a matured, well-maintained, and frequently updated open-source DBI framework. HP and the Massachusetts Institute of Technology (MIT) developed the first version in collaboration around 2000. Derek Bruening, DynamoRio’s lead developer, described the main concept in his PhD Dissertation in 2004, and further information about the history of DR can be found here.

The main reasons why Talos uses DR for Windows- and Linux-based malware analysis is its low performance impact at execution time, the excellent transparency (the target application does not recognize it is instrumented), and the open source license. Table 1 provides a brief comparison of some of the common instrumentation frameworks used in the industry. Please consider this as a general reference only, as this comparison might be biased by our use cases and may not remain accurate over time due to the ongoing development of the different frameworks. There is also not a best overall toolkit, as it depends on the use case. 

It should also be noted that it always depends on the user code how well a certain instrumentation framework works. Even the best framework cannot fix bad user code.

Feature	DynamoRIO	Intel PIN	Frida
Type	DBI	DBI	Dynamic Runtime Instrumentation via API Hooking
Instrumentation granularity	Basic blocks and instructions	Instruction-level (very fine-grained)	Function-level and instruction-level (via memory hooks)
Language (API)	C/C++	C/C++	JavaScript, Python, C
Target platforms	Windows, Linux (limited macOS, Android forks)	Windows, Linux (x86/x64 only)	Windows, Linux, macOS, Android, iOS
Architecture support	x86, x64, ARM (partial), AArch64 (forks)	x86, x64	x86, x64, ARM, ARM64
License	Open source (BSD-like)	Proprietary (free for non-commercial)	Open-source core and commercial license (Frida Pro)
Performance overhead	Medium (2–10× depending on tool complexity)	High (10–20× or more with deep instrumentation)	High (especially with many hooks or on mobile)
Transparency (anti-debug evasion)	Medium (code caching may leak)	Medium to low (can be fingerprinted)	Low (easily detectable by injected libraries or syscalls)
Best use cases	Runtime analysis, instrumentation, sandboxing	Deep instruction analysis, academic research	API hooking, mobile analysis, debugging, live patching
Shellcode detection feasibility	Excellent (module-level execution monitoring)	Good, but more effort needed	Limited (good for allocation and hook, not raw exec detection)
Community and documentation	Active community, used in research and industry	Older, still maintained by Intel	Very active, large community, modern docs

Table 1. DBI framework comparison.

Why use DBI to analyze malware?

Ultimately, the possibilities are only limited by your creativity and malware technology knowledge. However, here are some examples:

Anti-anti-VM detection

Malware samples can be executed on real hardware and still be monitored and analyzed. Alternatively, VM detection functions can be patched at runtime to make sure the malware does not recognize it is running in a VM.

Anti-anti-analyzing techniques

Malware uses many simple but common anti-X techniques (such as anti-debugging, anti-emulation, anti-tamper, anti-disassembler, self modification, etc.) that do not recognize DBI or do not have any impact on the DBI analysis. Many code runtime manipulation techniques which the frameworks are using are either transparent or hidden to the malware or the malware is just not trying to find them. The latter probably applies to the majority of malware today. 

De-obfuscation

For example, code traces and memory dumps based on certain conditions can give the analyst a better idea of what the malware is actually doing.

Finding interesting functions within the malware

It is relatively simple to build a shellcode execution detection tool with DBI to find a second stage in a packer by looking for functions which are allocating RWX memory, copying data into it and jumping into these memory areas later. You can also look for cryptographic constants which might be hidden in Mixed-Boolean-Arithmetic functions and are rebuilt at runtime to find unpacking routines or string obfuscation functions. Another example would be to count how often functions are called to find interesting functions which might be used to decode strings.

Dumping memory and gather runtime information

With DBI you can monitor the execution and get runtime values of registers or memory locations. You can also trigger on certain values of registers or other conditions to do dynamic memory dumps at runtime.  

Automation

Build an unpacker or config extractor for frequently seen malware families

Inside DynamoRio

Before starting to write your own client, it is important to understand some basics about how DR works under the hood. DR is a process virtual machine (PVM). In the context of DR, this refers to a virtual execution environment that allows DR to dynamically instrument, monitor, and modify the behavior of a running application at the level of individual processes. DR operates entirely in user space (ignoring some experimental features). When DR starts a target application, it injects itself into the process and hooks or intercepts system calls. It takes control before the target application begins execution and starts copying the first basic block(s) of the target application into a code cache, which is a memory region DR has full control over. Then it redirects the execution flow to this code cache. This enables DR to monitor and modify the original instructions of the target application. It relocates addresses and modifies the target application code in a way that it is working semantically exactly like it would if it is executed natively (Figure 2).

For performance optimization, the basic block code cache is extended with a trace cache (Figure 3). DR monitors and measures the execution of basic blocks in the basic block cache and builds groups of basic blocks which are frequently executed in the same order. At a certain threshold it combines these basic blocks and copies them into the trace cache including the instrumentation code and some inline checks. In reality, it is not a simple counter, it depends on multiple factors. This technique speeds up the execution time due to the fact that less context changes are necessary. In this context a context change means a switch between the target application code and DRs core and dispatching routines.

All these operations should be transparent/hidden to the target application. It should appear to the program as if it were running natively on hardware — unaware of and unaffected by any instrumentation. DR takes care about the following side effects:

• Register states: DR saves and restores all registers it modifies so that the application sees the original values.
• Stack and memory: Internal data used by DR (e.g., for managing its own state) is hidden from the application.
• Instruction semantics: A transformed or instrumented instruction behaves identically to the original — no change in meaning or side effects.
• Control flow: Even if DR adds trampolines or modifies jumps, the logical flow of execution remains the same from the program’s point of view.
• Signals and exceptions: Any exceptions (e.g., SIGSEGV) or signals are handled in a way that preserves original behavior and context.

More details can be found here.

Writing a simple client

The development environment used:

• Windows 11 Version 24H2 (Default Settings)
• Visual Studio 2019, CMAKE (incl. in VS)
  • The DR homepage recommends VS 2019 for building its source code, for building clients with the latest DR version, but VS 2022 might work in most cases too. If you want to be on the safe side, use VS 2019.
• DR 11.3.0
  • Download it here, then unzip it to a folder of your choice. These examples use “C:toolsDynamoRIO-Windows-11.3.0”. Later 11 versions should work, too. 

The DR release package includes several tools for memory debugging, profiling, instrumentation, legacy CPU simulation, cache simulation and more. See the DR homepage for more details. In this blog post, we will not use these tools, but instead build our own.  

When writing your own instrumentation client, you usually run it via “drrun.exe”, which is the DR loader application. The syntax is the following for a 64-bit client and 64-bit target application; for 32-bit, you just use the drrun.exe 32-bit version from the “bin32” directory, rather than the “bin64”.

<DYNAMORIO_INSTALL_DIR >bin64drrun.exe -c "

<DIR_TO_YOUR_CLIENT>client.dll" [client arg1, client arg2, …] –

“<TARGET_APP_DIR>target_app.exe”

The DR client (“client.dll”) is the instrumentation code you are writing to do something with the target application (“target_app.exe”). The “target_app.exe” is the malware which we want to instrument.

While you can also write standalone tools which are not loaded via “drrun.exe”, it is quite complex and out of scope of this tutorial. There are several options to configure the instrumentation process (details here). For this blog we will choose the simplest way via “drrun.exe” and default configurations.

To test the tool chain we will first write a DR “hello world” client (simple_client1). You can find the code on our GitHub repository. All examples in the repository are organized as seen in Figure 4.

They all include the client source code (e.g., client.c), a corresponding CMake file (CMakeLists.txt), and build32/64.bat scripts, which include the CMake build commands and MSYS_build32/64.sh scripts for starting the build process on MSYS2. All of the source code is heavily commented and prints out debugging messages and information of the important steps happening during the instrumentation phases. The code is written in a way that makes it easier to understand how things are working, not for performance or security goals. For example, it lacks some exception or input checks, which you might want to add if your client runs in a productive environment.   

IMPORTANT: Make sure you change the CMakeLists.txt file content depending on your installation. In other words, mainly verify/change the directories. Also verify the other scripts to ensure the directories and filenames match your environment.

The build process is usually very easy. Install Visual Studio 2019 incl. CMAKE, verify/edit the directories inside the scripts, and run the MSYS_build32/64.sh script in a MSYS2 shell. The script mainly does the following:

1. Start the “Developer Command Prompt for VS 2019”. 
2. Execute the build32/64.bat batch file, which includes the build commands. 

Note: Most scripts build “Release” versions. You can change the CMAKE_BUILD_TYPE parameter of the build commands in the build32/64.bat to “RelWithDebInfo” for a release with debug information or to “Debug” for a full debug release, but in most cases this is not necessary for normal troubleshooting.

Again, the client library needs to have the same bit width like the target application; in other words, if the target application is 32-bit, you need a 32-bit DR client. If the target application is 64-bit, the client needs to be 64-bit, too. If there is a mismatch, you will get the error message below (Figure 5). This tutorial will only focus on 64-bit apps and clients, but the GitHub repository also contains 32-bit versions of most demos.

Run the client via drrun.exe against a test program. For example:

"C:toolsDynamoRIO-Windows-11.3.0bin64drrun.exe" -c ".buildReleasesimple_client.dll" – ../testsamples/threads/x64/Release/threads.exe

If you can see the “Hello from DynamoRIO client” message after instrumentation of the test application, your development environment works and you can proceed to the next example of a client which will be a bit more useful. If something goes wrong, you can also run the target application with drrun.exe only (e.g., drrun.exe – <target application>).This will tell you if there is an issue with your client or you run into a DR bug. Another useful drrun.exe switch is “-debug”; beside other things, it finds memory leaks in your client. We are aware that one of the demo clients in the repository has a memory leak, but that is on purpose. See the source code for details.

First real instrumentation client

Let’s start to write a simple client that prints out all DLLs loaded by a process at run time. Look at the simple_client2 example from GitHub for the implementation details. Running the client looks like this:

Every client starts execution with the “dr_client_main” function. This is the start function of your client. Here we will do some initialization and you can find the callback register functions. See Figure 8 below for an example. 

The callback functions are controlling the custom instrumentation process. In other words, DR is using callback functions for executing the code you want to use during instrumentation. The function names give you a good idea about what they do. For example, in Figure 8, the “drmgr_register_module_load_event” function is registering a callback function “event_module_load_trace_instr” which is then getting called every time a module (e.g., a DLL) is loaded by the target application at runtime. In our simple example code, the “event_module_load_trace_instr” function will just print out the name of the loaded module. 

Most of the functions you need are part of DR extensions. These extensions are part of the DR project and they are already included in the DR distribution package (the ZIP file you have downloaded). You do NOT need to install or configure them. They offer higher-level abstractions for commonly needed features, so you don’t have to implement them from scratch. These functions usually start with the name of the extensions (e.g., “drmgr_register_module_load_event” for drmgr functions). Here are some extensions with brief descriptions:

• drreg: register stealing and allocating
• drsyms: symbol table and debug information lookup
• drcontainers: hash table, vector, and table
• drmgr: basic instrumentation functions and tools
• drwrap: function wrapping and replacing
• drutil: memory tracing, string loop expansion
• drx: multi-process management, misc. utilities
• drsyscall: system call monitoring
• drdecode: CPU decoding/encoding library
• umbra: shadow memory framework

In this tutorial we will look at “drmgr” and “drwrap”. Let’s have a closer look at these extensions.

DynamoRIO Multi-Instrumentation Manager (drmgr)

It is a helper library designed to make writing DR clients easier, cleaner, and safer. 

Drmgr offers the following functions:

• Event registration: Simplifies registering for events like bb_event or thread_init
• Thread-local storage (TLS): Safely manages TLS slots
• Per-thread cleanup: Automatically frees thread-specific memory on exit
• Safe initialization: Ensures extensions are initialized in the right order
• Avoids conflicts: Handles shared slot allocation so multiple extensions don’t collide

The picture below shows some examples for event registration callback functions included in drmgr. They are called when the corresponding event occurs. The names are more or less self-explanatory.

Drmgr wraps several of the low level functions from dr_events.h. For example, “drmgr_register_bb_instrumentation_event()” wraps “dr_register_bb_event()”. In common, it is simpler and/or more secure to use the functions in drmgr. 

The GitHub simple_client3 example is a simple code tracer. For the code trace, we register a callback function which is called for every instruction. To do this, use the insertion_func parameter of drmgr_register_bb_instrumentation_event(). The registered callback function and subfunction then disassembles the instructions and prints it out. The implementation details can be found in the mentioned simple_client3 project. The simple_client3 example also patches a function at runtime. The patching process is described in the next chapter. 

Another function you probably always want to register in your client is the exit event callback function.

It is registered via the dr_register_exit_event() function and is used to clean up things when the target application process has exited. For example, it is used to call extension exit functions or free allocated memory (Figure 9). 

DynamoRIO drwrap

Drwrap offers helper functions to simplify the runtime patching of the target application functions. For example, it can help wrap a function before (pre) and/or after (post) execution of the function. This means you can either use a pre-wrap function, which could manipulate arguments handed over to the function, or a post-function, which could manipulate the return value of a function in the target application. A good use case would be patching an VM detection routine or an anti-analyzing function in a malware which detects the instrumentation process. That being said, many of the typical anti-analysis tricks malware uses do not work under DR — or DR is actively putting counter measures in place. For most of the common anti-analyzing tricks in malware, you do not need to patch anything. We will talk about the details later on in this blog. 

A full example for an instrumentation with drwrap can be found in simple_client3. From a high level overview, it is as simple as this: You first register a drwrap pre- or post-function (e.g., when the module which includes the function you want to patch is loaded). Then the registered function (wrap_post_function()), manipulates the function at runtime. In this example it sets the return value to zero (Figure 10).

This should be enough for a quick intro and overview on how to write DR clients. You can find many more examples and details in the GitHub repository. 

If you wrote a useful client and want to share it with the community, we are happy to add it to the ”3rdparty” directory. We are not responsible for the code in this directory, so use it at your own risk.

Vibe coding

Vibe coding for DR clients works alright. If you use it for simple functions, it often works. From Talos’ experience, vibe coding full and complex clients usually doesn’t work. In most cases, it will just crash and you will spend more time cleaning the bugs than saving time with it. The best case scenario is it runs with sub-optimal side effects. However, AI can be an excellent tool to brainstorm which DR function to use for certain tasks or how to get started for a certain use case.

DynamoRio and anti-analyzing techniques

We have built a simple Anti-X pseudo malware without any malicious functions to test DR’s transparency and robustness against common anti-analyzing techniques frequently seen in malware. You can find it in the Anti-X GitHub repository. It includes different anti-debugging techniques, self modifying code, large loops, exceptions, and simple code verification techniques to detect hooks or breakpoints. The self-modifying aspect also changes the control flow graph at runtime to verify that DR can handle this. We provide the source code so you can verify that it does not do any harm to your machine.

Test case: shellcode

This test case decodes a shellcode at runtime and executes it. 

Result: No problem for DR. The code is executed as expected. No difference to the native execution without instrumentation. 

Test case – SSL/TLS traffic

In this test case we downloaded an info page about our external IP address from “https[://]ifconfig[.]me” to test whether or not we could intercept the TLS traffic. 

Result: This works well on most machines we tested it on. Only on very recent Intel Mobile CPUs the download failed with ERROR 12175 (ERROR_WINHTTP_SECURE_FAILURE) if the anti-x application was instrumented. This error usually occurs if the verification of certain security parameters of the TLS connection failed (e.g. the certificate is not valid yet or timed out). Whether this is a new Windows anti-tamper feature or a DR bug is currently unknown. We are investigating this and we will update the blog once we find the root cause. If you have an idea about the root cause or if this occurs on your machine, as well, we would be happy to hear from you.

Test case: Code validation

In this test case, we are verifying the CRC32 of the bytes of a certain function in memory. If any byte of the function gets changed (e.g., a debugger sets a breakpoint [0xCC]), the CRC32 would be different than calculated over the native function.

Result: The CRC32 value does not change if the target application is instrumented.

Test case: Simple anti-debugger tests

The first test (IsDebuggerPresent) should be self-explanatory, and the second uses the threat context object to check if one of the debug registers (DR0-3) is set, which would indicate a hardware breakpoint. 

Result: None of the tests detect that the application is instrumented. 

Test case: Exceptions

In this test case, we trigger an exception which is handled by the application to investigate if it has any side effects to the target application.

Result: No problem. The application is executed the same way without instrumentation. 

Test case: Runtime measurement

This test checks if the execution time between two code sections is too long. This detects debuggers or anything that significantly delays the code execution.

Result: As long as you do not do foolish things, such as insert too much code at runtime or instrument a large loop inside the target application, DR is usually fast enough to avoid detection. Of course, this depends on the kind of instrumentation you do and on how aggressive the timer is set. DR usually adds a delay of between 2 – 10 times that of the original execution time. 

Test case: Large loops

Result: Similar to the above, you don’t want to instrument something inside this loop, but anything outside is no problem.

Test case: Self-modifying code

In our self-modifying code, we are doing multiple things:

• Pre-patching code: This means we patch the code soon before it is executed.
• Post-patching code: This means we patch the code after it is executed, and the next time this function is called the patch will be executed instead of the original code.
• Interleave jumps: We jump in between the bytes of an instruction, which converts the bytes of the instruction into another instruction. In our case a “mov” instruction becomes a “jmp” instruction. This not only changes the instruction, but also the control flow graph (CFG) at runtime. We want to verify if this has an impact on the Basic Block and Trace Cache mentioned above.

First, let’s have a closer look at the self-modifying code which we are using. Here you can see the pre-patch code. It converts the original “jmp end_label” instruction to a “mov rax,3” instruction. Once again, it is not only the instruction that is being changed; the control flow graph (CFG) is also being modified.

The next one is the post-patch, which is similar to the pre-patch and overwrites a “mov rax,1234” with a “mov rax,1”, but this modification is done after the code was executed. This means when the function is called the next time, the values in rax and rbx are not equal anymore, the comparison later fails, and the jump is not taken. 

Last but not least, in the middle of the function, we do the interleave trick. The “test rax,rax” will set ZF=0 (RAX = 3) which means the “jz” will not be taken and the “jnz” will be taken. Some static disassemblers get confused by this and disassemble the byte starting with “048h, 0C7h, …” to a “mov rax, 0FFFFFFFF90900CEB”, because they do not realize that these bytes are never executed.

Only after manually converting it, the disassembler shows the jmp (= EB 0C), in other words the byte we jnz’ed to. Again, we want to see if DR’s code cache generator or dispatcher gets confused by this. 

Result: The self-modifications are working as expected. DR executes everything like it would on a real CPU. These self modifications were no problem for DR. 

The screenshot below is from the simple_client3 DR client run against the anti-x target application mentioned above, which is doing a code trace over the self modifying function. We deleted all messages from the client output, except the instruction related output.

The left side is the instruction trace showing when the self modifying function was called the first time. The right side is the second call of the self modifying function. 

Summary

DR offers a wide range of built-in capabilities to counter common malware anti-analysis techniques. However, some methods can still detect or circumvent DR; these were intentionally excluded from this blog to avoid aiding malware authors. In this post, we introduced how to use DR for malware analysis and demonstrated how it can help bypass typical anti-analysis measures with minimal effort. We hope this helps readers get started with DR and encourages you to contribute to our GitHub project. Have fun exploring DBI and DynamoRIO!

Cisco Talos Blog – ​Read More

Phishing campaigns and ransomware families evolved rapidly this October, from fake Google Careers pages and ClickUp redirect chains to Figma-hosted credential theft and LockBit’s move into ESXi and Linux systems. ANY.RUN analysts also uncovered TyKit, a reusable phishing kit hiding JavaScript inside SVG files to steal Microsoft 365 credentials across multiple sectors. 

Each of these threats shows how attackers are increasingly abusing legitimate cloud platforms, layering CAPTCHA checks and redirects to bypass detection. All cases were analyzed inside ANY.RUN’s Interactive Sandbox, revealing execution flows and behavioral indicators missed by static tools; insights SOC teams can turn into actionable detection logic. 

Let’s break down how these attacks unfolded, who they targeted, and what security teams can learn to strengthen their defenses before the next wave hits. 

1. Google Careers Phishing Campaign: Legitimate Platforms Used to Steal Corporate Credentials 

Post on X 

ANY.RUN analysts uncovered a phishing campaign posing as Google Careers, where attackers combined a Salesforce redirect, Cloudflare Turnstile CAPTCHA, and a fake job application page to steal corporate credentials. The campaign primarily targets employees in technology, consulting, and enterprise service sectors, exploiting the trust people place in well-known brands and cloud services. 

Unlike typical phishing kits, this campaign weaves together multiple legitimate platforms to make the flow appear authentic, slipping through filters and reputation-based security tools. Once credentials are entered on the fake Google Careers portal, they’re exfiltrated to the command-and-control (C2) server, such as satoshicommands[.]com, enabling further compromise of work accounts, client data, and internal collaboration tools. 

For organizations, this attack creates a chain reaction: compromised mailboxes, lateral movement across SaaS ecosystems, and potential exposure of customer or partner data; all while evading detection from traditional tools that trust the Salesforce and Cloudflare domains in the redirect path. 

See full execution chain exposed in 60 seconds 

Adversaries in this campaign misuse legitimate platforms to host phishing flows that evade automated detection. The combination of trusted domains and multi-step redirection makes these attacks particularly hard to catch without behavioral visibility. 

Below are ready-to-use Threat Intelligence Lookup queries to expand visibility, uncover infrastructure overlaps, and convert findings into detection rules, not just IOCs: 

Google-like application domains: domainName:”apply.g*.com” OR domainName:”hire.g*.com” 

Vercel deployment patterns: domainName:”puma-*.vercel.app” OR domainName:”hiring*.vercel.app” 

YouTube TLD impersonation: domainName:”hire.yt” 

C2 domain: domainName:”satoshicommands.com” 

Gathered IOCs: 

• 188[.]114[.]97[.]3  

• 104[.]21[.]62[.]195  

• hire[.]gworkmatch[.]com  

• satoshicommands[.]com 

2. Figma Abuse Leads to Microsoft-Themed Phishing Campaigns 

Post on X 

ANY.RUN analysts identified a growing wave of phishing attacks abusing Figma, where public design prototypes are used to host and deliver Microsoft-themed credential theft campaigns. This trend highlights a serious blind spot in corporate defenses; the exploitation of trusted cloud platforms that security systems often whitelist by default. 

Attackers are turning to Figma because it offers everything they need for a convincing delivery: it’s a widely trusted domain, allows anyone to publish and share prototypes publicly without authentication, and renders interactive content directly in the browser. That makes it perfect for embedding phishing elements, buttons, links, and visuals that look completely legitimate, while bypassing traditional email filters and URL reputation checks. 

Across multiple samples analyzed last month, 49% of these attacks were linked to Storm-1747, followed by Mamba (25%), Gabagool (2%), and several smaller operators. Each uses Figma as the initial hosting vector, sending victims “document” invitations that appear genuine and trigger the phishing flow upon interaction. 

Check real case: Figma abuse leading to fake Microsoft login page 

1. Phishing email invites the victim to view a “shared document.” 

2. Figma prototype hosts a fake collaboration page within the figma.com domain. 

3. Embedded link triggers a fake CAPTCHA or Cloudflare Turnstile widget. 

4. Redirection leads to a Microsoft-themed login page that collects credentials. 

Inside ANY.RUN’s Interactive Sandbox, analysts can safely detonate these links, visualize the full redirection flow, and expose the hidden credential capture mechanism; something static filters miss entirely. This interactive approach gives SOC teams real behavioral context for tuning detections and reduces investigation time when facing similar cloud-hosted phishing chains. 

To uncover additional campaigns abusing Figma and connected infrastructure, use the following TI Lookup query: 

domainName:”figma.com” AND threatName:”phishing” 

This search surfaces recent submissions that share behavioral traits, letting SOC teams expand visibility and transform isolated IOCs into behavioral detection rules. 

Gathered IOCs: 

• 9a4c7dcf25e9590654694063bc4958d58bcbe57e5e95d9469189db6873c4bb2c 
• Dataartnepal[.]com 

3. LockBit 5.0: New Variant Targets ESXi and Linux, Putting Critical Infrastructure at Risk 

Post on X 

Researchers spotted a major update from the LockBit group on its sixth anniversary: LockBit 5.0. Unlike earlier releases, this version targets not only Windows but also Linux and VMware ESXi, meaning attackers are now going after core infrastructure. A single successful intrusion can take down many virtual machines at once and knock whole systems offline. 

LockBit 5.0 introduces stronger obfuscation, flexible configuration files, and enhanced anti-analysis techniques, making it significantly harder to detect and dissect. The campaign primarily targets enterprise networks, managed service providers, and government systems across Europe, North America, and Asia, where virtualized environments form the backbone of daily operations. 

A single LockBit 5.0 intrusion can shut down dozens of servers simultaneously, halting production systems, paralyzing data centers, and causing prolonged outages with severe financial and reputational consequences. 

Technical Overview of LockBit 5.0 Variants 

1. VMware ESXi 

View real-world analysis of VMware ESXi variant 

The most critical of the three builds. A dedicated encryptor for hypervisors capable of disabling multiple virtual machines at once. Its CLI closely mirrors the Windows version but adds datastore and VM config targeting, enabling it to halt operations across entire host environments in seconds. 

2. Windows 

View real-world analysis of Windows variant 

The mainline variant runs with DLL reflection, supports both GUI and console modes, encrypts local and network drives, and performs cleanup actions like deleting shadow copies, stopping critical services, and clearing event logs. It drops a ransom note linking to LockBit’s live negotiation portal. 

3. Linux 

View real-world analysis of Linux variant 

A lightweight console-based encryptor that replicates Windows behavior with added mount point filters, disk wiping, anti-analysis routines, and region-based execution restrictions to evade detection and avoid unwanted publicity in certain locales. 

Inside ANY.RUN’s Interactive Sandbox, analysts can trace how the new encryptors behave across each operating system, from memory injection and service termination to encryption logic and ransom note delivery, helping SOC teams identify new TTPs early and enrich detection logic with behavioral indicators, not just static IOCs. 

Use the following Threat Intelligence Lookup queries to identify LockBit 5.0 activity and enrich your SOC’s detection coverage with live sandbox data: 

ESXi Lockbit 5.0: commandLine:”vmware -v” 

Linux Lockbit 5.0: filePath:”^/home/user/.local/share/evolution/tasks/ReadMeForDecrypt.txt$” 

Windows Lockbit 5.0: filePath:”^C:\ReadMeForDecrypt.txt$” 

These queries help analysts pivot from OS-specific artifacts to global attack patterns, connecting infrastructure and payload updates across submissions. 

What Security Teams Should Do Now: 

• Boost visibility: Combine endpoint and network telemetry with behavior-based monitoring. Use ANY.RUN’s sandbox and TI Lookup to detect evolving LockBit builds earlier, enrich IOC sets, and reduce MTTR by up to 21 minutes. 

• Harden access: Enforce MFA for vCenter and admin accounts, restrict direct Internet access to ESXi hosts, and route all management connections through a secure VPN. 

• Ensure resilience: Maintain offline backups, test recovery workflows regularly, and rehearse ransomware playbooks to minimize downtime in case of a breach. 

4. ClickUp Hosts Used as Phishing Redirectors 

Post on X 

ANY.RUN analysts found attackers abusing ClickUp to host redirect pages and hide phishing flows. In many cases ClickUp is the visible domain the victim clicks, then the chain moves through other trusted services (like Microsoft’s microdomains and Azure Blob Storage) before landing on a credential-harvesting page. 

Attackers use ClickUp because public docs and prototypes are quick to create, look legitimate in inboxes, and come from a domain most organizations don’t block. Besides ClickUp, they also exploit microdot-style Microsoft endpoints and Azure Blob Storage to host the final phishing page, making the whole flow look like normal collaboration traffic. 

Check a real-world case that exposes the full attack chain in ~1 minute 

1. Phishing email: Invites victim to view a shared ClickUp “document.” 

2. ClickUp redirect page: Host or shortener on doc[.]clickup[.]com forwards the user. 

3. Microsoft microdomain hop: A forms or doc endpoint (e.g., forms.office.com or other msft microdomains) is used to add legitimacy. 

4. Azure Blob Storage: Final hosting for the fake Microsoft login page. 

5. Credential exfiltration: Captured credentials POST to attacker-controlled collector. 

Because every domain in the chain belongs to a legitimate provider, these campaigns are hard to detect. Filters and whitelists that trust SaaS vendors often let the traffic pass, and users are less likely to be suspicious when the URL looks familiar. 

Inside ANY.RUN’s Interactive Sandbox, analysts can observe how each redirect unfolds across real Microsoft and ClickUp domains, see the credential-harvesting page render inside Azure Blob Storage, and extract live indicators for immediate defense updates. This visibility helps SOC teams shorten investigation time and enrich detection logic with behavioral context, not just URLs. 

Ready-to-Use Threat Intelligence Lookup Queries 

Use the following TI Lookup queries to uncover related infrastructure and track recurring phishing activity across trusted cloud providers: 

Azure Blob Storage: domainName:”*.blob.core.windows.net$” AND threatName:”phishing 

Microsoft Forms: domainName:”forms.office.com$” AND threatName:”phishing 

ClickUp: domainName:”clickup.com$” AND threatName:”phishing” 

Gathered IOCs: 

• https[:]//forms[.]office[.]com/e/YtRCbHDk14 

• microlambda[.]blob[.]core[.]windows[.]net 

5. TyKit: New Phishkit Stealing Hundreds of Microsoft Accounts in Orgs 

Detailed breakdown of TyKit attack 

ANY.RUN analysts identified Tykit, a reusable phishing kit that hides JavaScript inside SVG files to push victims through a multi-stage flow and steal Microsoft 365 logins.  

First seen in May 2025 with activity peaking in September–October 2025, it hits organizations across the US, Canada, LATAM, EMEA, SE Asia, and the Middle East, with notable impact on finance, government, telecom, IT, real estate, construction, professional services, education, and more. 

Tykit blends redirects, basic anti-debugging, and staged C2 checks to outlast simple filters. A successful phish can lead to account takeover, data theft from mailboxes and cloud drives, lateral movement, and MFA bypass via AitM logic. 

View analysis session with TyKit 

How the attack unfolds: 

1. SVG delivery → Obfuscated JS rebuilds payload and triggers redirect (eval, atob, charCodeAt patterns). 

2. Trampoline + CAPTCHA → Cloudflare Turnstile; blocks DevTools/context menu. 

3. Fake M365 sign-in → Background POST /api/validate to C2; server returns next HTML stage. 

4. Exfiltration → POST /api/login sends {key, redierct [sic], token, server, email, password}. 

5. Optional log hook → POST /x.php when server replies with status:”info”. 

To collect all IOCs and perform a detailed case analysis, see the following TI Lookup  query: 

SVG/C2 pattern: domainName:”^segy.*” 

Combined query: sha256:”a7184bef39523bef32683ef7af440a5b2235e83e7fb83c6b7ee5f08286731892″ OR domainName:”^loginmicr*.cc$” OR domainName:”^segy*” 

How to Prevent Tykit Attacks 

• Inspect SVGs: Treat SVGs as potential attack vectors; detonate them in a sandbox to reveal hidden scripts and redirects. 

• Enable phishing-resistant MFA: Use FIDO2 or certificate-based methods and disable legacy authentication. 

• Monitor key indicators: Watch for domains like segy*, loginmicr(o|0)s.*.cc, and POSTs to /api/validate or /api/login. 

• Automate detection: Alert on Base64 /?s= parameters and integrate Threat Intelligence Feeds for fresh IOCs. 

• Train and respond fast. Teach users that even image files can trigger phishing. If compromised, revoke sessions and reset credentials. 

Using ANY.RUN’s Interactive Sandbox during incident response accelerates this process: analysts can safely replay the infection chain, confirm what data was exfiltrated, and extract accurate IOCs within minutes. This shortens MTTR and helps strengthen detections for the next wave of similar campaigns. 

Gathered IOCs: 

SHA256 (SVGs): 

• ECD3C834148D12AF878FD1DECD27BBBE2B532B5B48787BAD1BDE7497F98C2CC8 

• A7184BEF39523BEF32683EF7AF440A5B2235E83E7FB83C6B7EE5F08286731892 

Domains & patterns: 

• segy[.]zip, segy[.]xyz, segy[.]cc, segy[.]shop, segy2[.]cc 

• ^loginmicr(o|0)s.*?.([a-z]+)?d+.cc$ 

URLs & requests: 

• GET /?s=<b64_victim_email> 

• POST /api/validate 

• POST /api/login 

• POST /x.php 

View august’s top threats analysis to spot recurring tactics and compare how attacker trends evolved month to month 

Empower Your SOC with Live Visibility and Actionable Intelligence 

From phishing kits and stealers to ransomware and zero-day exploits, today’s attacks evolve faster than static defenses can keep up. Investigating them manually can take hours, while attackers move in minutes. ANY.RUN helps SOC teams close that gap with real-time, interactive analysis. 

Here’s how teams stay ahead: 

• Expose the full attack chain instantly: Detonate suspicious files, links, or scripts in real time and see every process, redirect, and payload as it happens. 

• Accelerate investigations: Live network mapping, script deobfuscation, and automatic IOC extraction cut analysis time from hours to minutes. 

• Reduce MTTR by over 21 minutes per case: Clear visibility into system behavior and exfiltration flows enables faster triage and confident containment. 

• Enrich detection logic automatically: Pivot from a single domain or hash in Threat Intelligence Lookup to hundreds of related submissions, revealing shared infrastructure and TTP patterns. 

• Feed fresh intelligence into your stack: Integrate ANY.RUN’s Threat Intelligence Feeds with your SIEM, SOAR, or XDR for continuous updates and context-rich alerts. 

For SOCs, MSSPs, and threat researchers, ANY.RUN delivers the speed, depth, and live visibility needed to turn reactive defense into proactive threat hunting and stay ahead of every new campaign. 

Explore ANY.RUN’s capabilities during 14-day trial→ 

About ANY.RUN 

ANY.RUN supports more than 15,000 organizations worldwide, including leaders in finance, healthcare, telecom, retail, and tech, helping them strengthen security operations and respond to threats with greater confidence. 

Designed for speed and visibility, the solution blends interactive malware analysis with live threat intelligence, giving SOC teams instant insight into attack behavior and the context needed to act faster. 

By integrating ANY.RUN’s Threat Intelligence suite into your existing workflows, you can accelerate investigations, minimize breach impact, and build lasting resilience against evolving threats. 

The post Major Cyber Attacks in October 2025: Phishing via Google Careers & ClickUp, Figma Abuse, LockBit 5.0, and TyKit  appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More