This month in security with Tony Anscombe – June 2025 edition
From Australia’s new ransomware payment disclosure rules to another record-breaking DDoS attack, June 2025 saw no shortage of interesting cybersecurity news
WeLiveSecurity – Read More
From Australia’s new ransomware payment disclosure rules to another record-breaking DDoS attack, June 2025 saw no shortage of interesting cybersecurity news
WeLiveSecurity – Read More
So far in our comprehensive guide to passkeys, we’ve covered how to ditch passwords on popular combinations of Android, iOS, macOS, and Windows smartphones and computers. This post focuses on important specific cases:
What if you need to sign in to your passkey-protected account from a library, an airport computer, or a relative’s home? Don’t rush to remember your backup password.
Start the sign-in process on the computer: enter your username and, if prompted, click Sign in with passkey. A QR code will appear on the screen for you to scan with the smartphone that stores your passkey. If the scan is successful, the QR code will disappear, and you’ll be signed in to your account.
Several factors must align for this seemingly simple process to proceed smoothly:
You might find using passkeys via QR codes inconvenient if you frequently access your accounts from different devices. If that’s the case, you can store your passkeys not on your computer or smartphone, but on a USB hardware security key — such as a YubiKey, Google Titan Security Key, or a similar device — for secure website sign-in. When you create a passkey, just choose to save it to your hardware key. Then you can sign in to your account from any computer or smartphone by plugging in that security token.
Just make sure it has the right combination of ports (USB-A, USB-C, Lightning) or NFC support to work with all your devices. Some token models even include a fingerprint scanner, which provides an extra layer of protection against account hijacking if your device is stolen or lost.
Unfortunately, there’s a catch: many older and popular token models can store a maximum of only 25 passkeys. Only a few advanced models — like the YubiKey with firmware version 5.7 — have raised this limit to 100.
Additionally, operating system developers view passkeys as a great opportunity to tie users more closely to their ecosystems. By default, depending on your smartphone, you’ll likely be prompted to save your passkey to either iCloud Keychain or Google Password Manager. As a result, the option to use a hardware security key might be hidden deep within the interface.
To create a passkey on a hardware token, you’ll often need to click the not-so-obvious Other options link on macOS/iOS, or Different device on Android, to select the hardware key option.
The biggest headache right now is if you store all your passkeys in your smartphone’s default storage and you want to switch ecosystems — moving from Android to iOS or vice versa. Currently, none of the three major OS developers — Google, Apple, or Microsoft — let you directly transfer passkeys. That’s because no one can guarantee the process will be secure. Both Apple and Google are working on implementing this feature in the future, but if you decide to swap devices today — say, from an iPhone to a Google Pixel — transferring your passkeys won’t be straightforward.
To avoid this hassle, it’s best to use a third-party password and passkey manager right from the get-go. With Kaspersky Password Manager, passkey support is already available on Windows, with Android support planned for July, and iOS and macOS support — for August 2025.
Most online services that offer to switch to passkeys don’t disable other sign-in methods. If your account was protected by a weak or compromised password before you switched to a passkey, cybercriminals can still bypass your shiny new passkey by simply signing in with that old password.
Creating a passkey for an account that still has a weak password is like installing a bulletproof front door while leaving the flimsy back door unlocked with the key hidden under the mat.
That’s why, before you enable passkeys for any online service, we strongly recommend changing your password as well. Since you won’t be typing this password every day — it’s just a backup for your passkey-protected account — you can really go wild with its complexity. We’re talking strong passwords that are 16 characters or longer, and mixing up letters, numbers, and special characters. These are practically uncrackable. Ideally, generate and save that robust password in the same password manager where you’re planning to store your passkeys. Don’t rely on AI models to generate complex passwords. Our recent research revealed that while these passwords might look complex, LLMs tend to favor certain characters for no obvious reason when creating passwords, which makes their output surprisingly predictable.
The underlying WebAuthn standard that powers passkeys can be implemented quite differently across browsers and operating systems. Websites often adopt these capabilities in their own unique ways. This can lead to frustrating challenges — even for tech-savvy users. Here are a few examples of this:
Any one of these situations is made worse by the fact that errors when creating or signing in with passkeys are either not mentioned at all in help documentation, or described very vaguely. It’s often completely unclear how to fix the problem. However, when passkey issues arise, websites almost always offer a backup option, such as sending a one-time access code to your email.
Despite these challenges, a passwordless future with passkeys is on the horizon. We recommend getting ready now by creating passkeys wherever possible, saving them in your password manager, and remembering to check and update your passwords and contact information on websites to make sure you can recover access if your passkeys ever give you trouble.
Want to read more about passwords and passkeys?
Kaspersky official blog – Read More

Welcome to this week’s edition of the Threat Source newsletter.
Happy summer, friends! I hope everyone is staying cool and/or warm.
I am fresh back from an exhaustive but great time in San Diego at Cisco Live U.S. It was so good to see colleagues, meet new friends and pet many therapy dogs in the Splunk booth. As often happens to me, I was approached by someone who was looking for mentorship and guidance in how to get into a cybersecurity career. It’s not unusual for me to be approached by folks looking to get into cybersecurity. I’m the large, bearded guy with the Talos shirt, so I stick out.
So, I’m often asked how I got the career I have in cybersecurity and how others can do the same. For a guy who often has a quip or answer for most things, I always pause here. I can’t help but think of my entire career and the dumb luck and hard work that landed me where I’m at. Giving that summation to others wouldn’t be fair, because… well, my journey wasn’t a linear one. I think for many of my peers, the same applies. We found cybersecurity as a career through a series of events that organically landed us in this field. In my case, moreso than others, the path isn’t easy to follow because there was no clearly staked path for me to follow, either.
I’ll explain as best I can: One today might go to school and graduate with a degree in information security and/or some security certificates, then begin the job hunt for an entry level gig. These types of degrees, certificates and even jobs simply didn’t exist in any meaningful way or numbers when I started my career. If you wanted to learn cybersecurity, there weren’t classes to take — you got a computer science degree and figured it out. I, like many in the GenX world, started as an IT professional. As the industry and cyber threats evolved, the career space over the years shifted and we found ourselves helping fight the good fight and keeping folks secure.
Today is truly different, and I’m so happy about it and the opportunities it can give others. I’m envious of the school degrees, industry certifications and mentorship programs that exist today that did not exist for me. There is also an incredibly helpful information security community that provides hacking tutorials, or Capture the Flag competitions (CTFs) or hackathons that I would have loved to have been a part of in my formative years.
By now, I know you’re thinking, “Cool story, grandpa, but answer the question: how do I get a job in cybersecurity?” In my estimation, the answers are as follows:
Notice that none of those things mention anything specifically technical. No malware reverse engineering, red teaming, threat intelligence or security analyzing. I can tell you that to work at Talos, you must exhibit strong traits of all six of those things I listed. One through five makes sense. Good hackers are tenacious, smart, work well with others and seek out fellow friends to network and hack with.
Number six though – what’s up with that? Simply put, life deals us all a hand of cards that we must play, and those cards may not be great. For example, you want to get a job in cybersecurity, but you’re a primary care giver of a family member and you don’t have a lot of freedom. You might be financially constrained. You may have health issues or a disability that limits some options. Or you simply just have a job that you don’t like, and a career in security calls out to you, but the bills don’t pay themselves. This is all common, and you’re a bit “stuck.”
So while you’re stuck, find ways to grow where you’re planted. Study. Network locally or online. Try a CTF or a hacking competition. Whatever you do, just keep growing yourself, your skillset and your network. You can do it. And before you know it, you’ll have that career helping to fight the good fight with the rest of us.
I believe in you! You got this!
Cybercriminals are increasingly exploiting Large Language Models (LLMs) by using uncensored versions, developing their own malicious LLMs or “jailbreaking” legitimate ones to bypass safety protocols. These compromised or malicious LLMs are then used to generate highly convincing phishing campaigns, create harmful code and automate various cybercrime operations, making attacks more sophisticated and scalable.
Cybercriminals’ widespread abuse of LLMs lowers the barrier to entry for sophisticated attacks, making it easier for even less skilled actors to launch effective campaigns. This means you’re more likely to run into highly convincing phishing attempts, scams and malware that are difficult to distinguish from legitimate communications, putting your personal info and company security at higher risk.
Given this evolving threat landscape, it’s important to be extra vigilant and skeptical online. Treat all online communications with caution, even if they look perfectly authentic. For individuals, that means double-checking emails and messages for anything fishy, no matter how well-written they seem. For businesses, it’s time to beef up your cybersecurity defenses, invest in smart threat detection and keep your employees sharp on how to spot and report these increasingly clever social engineering tricks.
New AI Jailbreak Bypasses Guardrails With Ease
On topic with our latest blog, the new “Echo Chamber” attack bypasses advanced LLM safeguards by subtly manipulating conversational context, proving highly effective across leading AI models. (SecurityWeek)
US insurance giant Aflac says customers’ personal data stolen during cyberattack
Aflac says hackers stole an unknown quantity of its customers’ personal information from its network during a cyberattack earlier this month. (TechCrunch)
APT28 Uses Signal Chat to Deploy New Malware in Ukraine
A new cyber attack campaign by the Russia-linked APT28 (aka UAC-0001) threat actors using Signal chat messages to deliver two new malware families dubbed BEARDSHELL and COVENANT. (The Hacker News)
UK watchdog fines 23andMe over 2023 data breach
The U.K. data protection watchdog has fined 23andMe £2.31 million ($3.1 million) for failing to protect U.K. residents’ personal and genetic data prior to its 2023 data breach. (TechCrunch)
Decrement by one to rule them all: AsIO3.sys driver exploitation
Learn how our researcher, Marcin Noga, found two critical vulnerabilities in ASUS’ Armory Crate and AI Suite drivers.
Talos Takes: Teaching LLMs to spot malicious PowerShell scripts
Hazel chats with Ryan Fetterman from the SURGe team to explore his new research on how LLMs can assist security operations centers in identifying malicious PowerShell scripts.
Leveraging Detections from the Splunk Threat Research Team & Cisco Talos
Wednesday, July 23
11:00 a.m. to 12:00 p.m. PDT
Join us for a discussion around the latest security detections developed for the SOC and how to find and remediate threats, faster.
SHA 256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507
MD5: 2915b3f8b703eb744fc54c81f4a9c67f
VirusTotal: https://www.virustotal.com/gui/file/9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507
Typical Filename: VID001.exe
Claimed Product: N/A
Detection Name: Win.Worm.Coinminer::1201
SHA 256: 05883fccb64dd4357c229ccca669afdacbfa0bc9a1c8d857f5205aed0a81e00a
MD5: 71b973dbdfc7b52ae10afa4d0ad2b78f
VirusTotal: https://www.virustotal.com/gui/file/05883fccb64dd4357c229ccca669afdacbfa0bc9a1c8d857f5205aed0a81e00a/details
Typical Filename: PCAppStore.exe
Claimed Product: PC App Store
Detection Name: Riskware/VeryFast
SHA 256: a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91
MD5: 7bdbd180c081fa63ca94f9c22c457376
VirusTotal: https://www.virustotal.com/gui/file/a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91/details
Typical Filename: IMG001.exe
Claimed Product: N/A
Detection Name: Simple_Custom_Detection
SHA 256: c67b03c0a91eaefffd2f2c79b5c26a2648b8d3c19a22cadf35453455ff08ead0
MD5: 8c69830a50fb85d8a794fa46643493b2
VirusTotal: https://www.virustotal.com/gui/file/c67b03c0a91eaefffd2f2c79b5c26a2648b8d3c19a22cadf35453455ff08ead0/details
Typical Filename: AAct.exe
Claimed Product: N/A
Detection Name: PUA.Win.Dropper.Generic::1201
SHA 256: 2a753cdc8c5401dcb67f3be58751a32ce23c875f8720a70459533b30e5ba4f1f
MD5: 7d5a9a41157fb0002f5234b4512e0ac2
VirusTotal: https://www.virustotal.com/gui/file/2a753cdc8c5401dcb67f3be58751a32ce23c875f8720a70459533b30e5ba4f1f/details
Typical Filename: pros.exe
Claimed Product: N/A
Detection Name: Trojan.GenericKD.76128711
Cisco Talos Blog – Read More
Digitalization of business – especially in the small and medium-sized segment – allows for quick upscaling, better customer service, and entry into new markets. On the downside, digitalization amplifies the damage caused by a cyberattack, and complicates the recovery process. Given that company resources are always limited, which attacks should be deflected first?
To answer this question, we studied the INTERPOL Africa Cyberthreat Assessment Report 2025. The document is useful because it collates police cybercrime statistics and data from information security companies – including Kaspersky – allowing us to compare the number and types of attacks with the actual damage they caused. This data can be used to build a company’s information security strategy.
Average ranking of cybercrime types by reported financial impact across African subregions, based on INTERPOL member country data. Source
Fraudulent operations were the clear leader in terms of damage caused across the continent. They’re gaining momentum in line with the rising popularity of mobile banking, digital commerce, and social media. In addition to mass phishing aimed at personal and payment data theft, targeted attacks are growing at a rapid rate. Scammers are grooming potential victims in messenger apps for months, building trust and guiding them into a money extortion scheme – for example, a fake cryptocurrency investment. Such schemes often exploit romantic relationships and are therefore called romance scams, but there are other variations. In Nigeria and Ivory Coast, for example, scammers were arrested for attacking small media platforms and advertising agencies. Posing as advertisers, they stole almost 1.5 million U.S. dollars from victims.
The fact that 93% of Africans use plain old WhatsApp rather than corporate communication tools for work significantly boosts the success rate of attacks on employees and company owners.
Press headlines may give the impression that ransomware operators mainly target large organizations, but the statistics in the report debunk this theory – showing that both the number of attacks and the actual financial damage caused are significant across all business segments. What’s more, there’s a direct link between the level of digitalization and the number of attacks. So, if a company observes an overall increase in “digitized” business activity in its market segment, the threat level is sure to rise accordingly. In Africa, “affiliates” of the largest and most dangerous ransomware-as-a-service platforms – such as LockBit and Hunters International – are responsible for major incidents on a national scale.
Among the main ransomware incidents in Africa – hardly known about outside the continent – we highlight the following: the theft of $7 million from Nigerian fintech company Flutterwave; attacks on Cameroonian electricity supplier ENEO; a large-scale ransomware attack to exfiltrate data from Telecom Namibia; and the targeting of South Africa’s National Health Laboratory Service (NHLS), which led to canceled operations and the loss of millions of lab test results.
Although the direct losses from banking Trojans and infostealers fell outside the top-three in terms of damage, it’s the “successes” of this criminal industry that have a direct impact on the number and severity of other attacks – primarily ransomware and business email compromise (BEC). After stealing what credentials they can from thousands of users with infostealers, attackers filter and group them by various criteria, then sell curated sets of accounts on the illicit market. This allows other criminals to buy passwords to infiltrate organizations of interest to them.
For small and medium businesses mainly using public services like Gmail or Office 365, infection with an infostealer gives attackers full access to corporate correspondence and business operations. The attackers can then exploit this to trick customers and counterparties into paying for goods and services to a fraudulent account. BEC attacks have a firm hold at the top of the damage charts, and small businesses can fall victim to them in two ways. First, cybercriminals can extract money from larger clients or partners by impersonating the compromised small business. Second, it’s easier with a small business to persuade the owner or accountant to transfer money than it is with a large organization.
There are several large criminal syndicates based in Africa that are responsible for international BEC operations causing multi-billion-dollar damage. Their targets also include African organizations — primarily those in the financial and international trade sectors.
To effectively counter digital threats, law enforcement agencies need to share data with commercial information security companies that harness telemetry to identify threat distribution hotspots. Recent successes of such partnerships include operations Serengeti (1000 arrests, 134 000 malicious online resources disabled), Red Card (300 arrests), and Secure (32 arrests, 20 000 malicious resources disabled). These operations, conducted under the auspices of INTERPOL, used cyberthreat intelligence received from partners – including Kaspersky.
But businesses can’t leave cybersecurity solely to the police; they need to implement simple but effective security measures of their own:
Kaspersky official blog – Read More

Armory Crate and AI Suite are applications used to manage and monitor ASUS motherboards and related components such as the processor, RAM or the increasingly popular RGB lighting. These types of applications often install drivers in the system, which are necessary for direct communication with hardware to configure settings or retrieve critical parameters such as CPU temperature, fan speeds and firmware updates.
Therefore, it is critical to ensure that drivers are well-written with security in mind and designed such that access to the driver interfaces are limited only to certain services and administrators.

During the audit of the code and components related to the aforementioned applications, Cisco Talos discovered two critical vulnerabilities in the AsIO3.sys driver. Both vulnerabilities were discovered in the IRP_MJ_CREATE handler:
The first vulnerability is a stack-based buffer overflow that occurs during the process’s ImagePath conversion from “Win32 Path” to “NT Namespace Path”.
The second vulnerability allowed bypassing the authorization mechanism implemented in the driver, granting access to its functionality not just to the intended service but to any user. With access to a security-critical function within this driver, I successfully developed a fully working exploit that escalates local user privileges to “NT SYSTEM”, which we describe in detail below.
Please keep in mind that I discovered this exploit before the Windows 11 24H2 update arrived. This update prevents regular users from leaking information such as loaded kernel modules and their addresses via “NtQuerySystemInformation.” This is discussed in further detail below.
While looking for drivers installed alongside the Armory Crate software, I noticed two related to ASUS in the DriverView list.

Focusing on AsIO3.sys, I investigated whether this driver creates any devices and, most importantly, whether a regular user can communicate with such a device.
Using DeviceTree, we can see the following encouraging picture:

The AsIO3.sys driver creates the Asusgio3 device, which nearly everyone in the system has full access to. After a quick check with a simple code that attempts to open a handle to the device, I got the error code:
“5 == ERROR_ACCESS_DENIED”.

This was unexpected based on the DeviceTree interface, so I re-checked the privileges to that device using Sysinternals “accesschk” and got completely opposite results.

Which is the truth? To find out, I reversed fragments in the AsIO3 driver responsible for handling the “IRP_MJ_CREATE” request.
By loading the driver and beginning the reversing process, we see a single function handles IRP requests for three different request types.

Diving into “callback_irp_dispatch”, I found a fragment responsible for handling the “IRP CREATE” request:

Checking the “ImageHashCheck” function, we can see the following:

Using the API “ZwQueryInformationProcess” with the flag “ProcessImageFileNameWin32” (lines 8 and 19), ASUS developers attempt to obtain the image path (the path to the executable file) of the current process — specifically, the process that is trying to obtain a handle to the device.
Next, in line 26, we see the translation of the path from the “Win32 File Namespace” to the “NT Namespace”. Hold tight — we will return to this line in a moment.
In lines 35-46, there is a typical SHA256 hash calculation for the current process’s executable file. In line 47, the calculated hash is compared with a hardcoded hash in the driver, and if they match, the function returns “true”, allowing the process to obtain a handle to the device.
When we dump the hash from the global variable “g_sha256Hash” (visible on line 47), it appears as follows:
python Python>binascii.b2a_hex(idc.get_bytes(0x0000000140009150,32)) B'c5c176fc0cbf4cc4e37c84b6237392b8bea58dbccf5fbbc902819dfc72ca9efa'
I calculated the SHA256 hash for “AsusCertService.exe” and saw that it was the same hash:
powershell PS C:Usersicewall> Get-FileHash -Path "C:Program Files (x86)ASUSAsusCertServiceAsusCertService.exe" -Algorithm SHA256 Algorithm Hash Path --------- ---- ---- SHA256 C5C176FC0CBF4CC4E37C84B6237392B8BEA58DBCCF5FBBC902819DFC72CA9EFA C:Program Files (x86)ASUSAsusCertServiceAsusCertService.exe
With this new understanding, only the “AsusCertService.exe” service and processes whose PIDs are added by it to the allowed list can obtain a handle to the Asusgio3 device. Otherwise, the operation returns the status “Access is denied.”
This article will not spend much time on the vulnerability discovered in the “Win32PathToNtPath” function, as it will not be used in the later stages of exploitation. However, it is interesting enough to mention.
The developers assumed that a Windows path could have a maximum length of approximately “MAX_PATH” (260) characters. Based on this assumption, they copied the received Image Path into a fixed-size 255-character buffer located on the stack, without first checking the actual length of the path. However, this assumption is incorrect, as a path can exceed ~260 characters. As Microsoft documents here, “The maximum path of 32,767 characters is approximate, because the “\?” prefix may be expanded to a longer string by the system at run time, and this expansion applies to the total length.”
For more information about this vulnerability, read this advisory: CVE-2025-1533/TALOS-2025-2144 – Asus Armoury Crate AsIO3.sys stack-based buffer overflow vulnerability
Knowing that the authorization mechanism is based on the “ImagePath” returned by the “ZwQueryInformationProcess” API and the SHA256 hash calculated for the executable file at this path, we can start considering potential bypasses.
By examining the implementation of “(Nt/Zw)QueryInformationProcess” in the “Windows Research Kernel (WRK)”, I learned that the information about the current process’s “ImagePath” is retrieved from the “EPROCESS” structure. Therefore, there is no chance to manipulate its value from User-Mode, but there are still options for potential bypass.
Using a hardlink, we can bypass the “ImageHashCheck” routine. First, we create a hardlink to the PoC.exe file.

The “PoC.exe” won’t do much for now — it will simply wait for user input before attempting to open a handle to the Asusgio3 device.

Instead of running our “PoC.exe” directly, we then execute “run.exe” hardlink. As a result, in the EPROCESS structure, ImagePath will point to a hardlink.
While the run.exe (PoC.exe) is executed and waiting for user input, we then delete the hardlink and create a new one with the same name, but pointing to AsusCertService.exe. However, trying to create a direct hard link to the original AsusCertService.exe location returns the following:

Because of mitigations Microsoft introduced years ago, a user can only create a hard link to a file that they have permission to overwrite. This is not a problem in this case, as I can simply copy the file to a temporary location and then create a hard link.

Now I can further run the previously executed PoC.exe process. In this scenario, at the moment when PoC.exe attempts to open a handle to the Asusgio3 device, the run.exe hard link points to the AsusCertService.exe file, and the SHA256 hash matches. When this occurs, we can bypass this authorization mechanism.
Browsing through the code of the AsIO3.sys driver’s IOCTL handlers, I came across the following functionality, which serves as a good primitive for exploit development. As a regular user, I performed the following actions (among others) using proper IOCTL:
However, the exploitation turned out to be more challenging than this originally indicated.
There are at least two crucial MSR registers from a security perspective:
These MSR registers define the addresses in the kernel where execution is redirected when the SYSCALL or SYSENTER instructions are triggered. By modifying these registers, we can potentially hijack control flow and execute arbitrary code with privileged access, making them an important vector in kernel exploitation. I found a promising-looking handler for IOCTL 0xA040A45C, which allows overwriting the MSR register with arbitrary data.

In line 16, the “_writemsr” instruction, where the data we control, coming from “SystemBuffer” (line 8), is used as the MSR register index (“msrReg”) and value (“msrRegVal”).
At first glance, this looks promising; however, there is a call in line 11 that checks the “msrReg” value (index). Take a closer look:

The MSR index is checked against the list of allowed MSR indexes located in the “MSR_allowedList” array. Unfortunately, this list does not show the crucial registers mentioned earlier: “IA32_LSTAR (0xC0000082)” or “IA32_SYSENTER_EIP (0x00000176)”. Instead, after decoding the indexes to register names and their purposes, we can only manipulate registers without security implications.

With these discoveries, we must look for alternative exploitation methods.
Looking for other code that could be useful during the exploitation process, I found a few IOCTL handlers giving the possibility to map physical memory into the virtual address space of our process. One of them is “0xA040200C”.

We fully control the values of arguments passed to this function: “phyAddress”, “memSize”. At first glance, it seems as though we can map arbitrary physical memory into our user space. We can leverage this primitive in a few different ways, some of which are below:
Russell Sanford’s “Exploiting LOLDrivers” presentation provides more information about these methods, but I had to choose one adequate for the situation.
Unfortunately, I can’t directly translate virtual addresses to physical ones via MmGetPhysicalAddress because there is no way to call this API directly in this driver. Searching through physical memory is very time-consuming and might be problematic (see other examples of implementations and the issues people encountered when choosing this path).
In the end, I chose to implement the “Low Stub” method to manually translate virtual addresses to physical ones. Before doing this, I looked at the function called in line 18, which I named “checkPhyMemoryRange”.

Developers defined certain physical memory address ranges located under the “g_goodRanges” variable. If the specified range does not fit pre-defined ranges, the function returns true, continues execution and results in an error code.
When checking the location of the “Low Stub” “PPROCESSOR_START_BLOCK structure”, we’re able to read it. In the same way, we could read the value of the CR3 register pointing to the PML4 base address.
The next entry from the memory mapping structures pointed to a location outside the allowed address ranges. As a result, I abandoned this approach.
Looking for new useful piece of code, I spotted the following “IOCTL 0xa0402450” handler:

Users can fully control all three arguments. At first glance, this code might look quite harmless, but when I dove into internals of “ObfDereferenceObject”, I saw the following:

Being able to pass arbitrary addresses to “ObfDereferenceObject”, I can decrement any memory value by 1. To be precise, using “ObfDereferenceObject” I decrement by 1 memory located at “Object – 0x30”. I kept this in mind when writing the exploit.
But how can we turn these primitives into something useful? Do we need an additional memory leak? When I decided to create a fully working exploit, I assumed a scenario where the code would be executed by a local user (process integrity level: medium). Those familiar with the exploitation process on Windows know that NtQuerySystemInformation can provide very useful information about kernel structures.
However, it’s 2025 and Windows 11 is in use. I remembered news about an upcoming mitigation that would prevent regular users from leaking information such as loaded kernel modules and their addresses via “NtQuerySystemInformation”.
At the beginning of February, when I wrote a fully working exploit, my Windows 11 still did not get the 24H2 update. It was still “ntoskrnl.exe – 10.0.22621.4890 (WinBuild.160101.0800)”.
After I finished writing this article in March 2025, I could see that my 24H2 update finally arrived (“ntoskrnl.exe -10.0.26100.3476 (WinBuild.160101.0800)”). Leaking kernel addresses with “NtQuerySystemInformation” is no longer possible.

Armed with all the knowledge mentioned above, I began writing the exploit.
As mentioned in the previous paragraph, users can utilize the “NtQuerySystemInformation” API to leak, among others, the address of the “KTHREAD” structure for its own thread. This is where such a simple primitive as “decrement by one” becomes useful.
The “KTHREAD” structure at offset “0x232” has a field called “PreviousMode”, which for User-Mode threads is set to 1. That field is very important and is checked by multiple kernel-level APIs, eventually limiting their functionality if a user calls a particular syscall from User-Mode.
For example, examine what happens when the API calls “ReadProcessMemory,” which calls syscall “NtReadVirtualMemory (MiReadWriteVirtualMemory)”.

As we can see at the beginning, the syscall obtains the current thread structure at line 11. Next, in line 13, there is a special condition for the case when PreviousMode is set to 1 (User-Mode). In line 23, there is a check verifying whether the address pointed to by the user (“BaseAddress”), when increased by the requested memory size, exceeds the maximum address where user-mode components are mapped. This ensures that a user making a call from User-Mode cannot read any memory from the Kernel-Mode address space.
Based on this fact, I changed PreviousMode for my own thread by decrementing its value from “1” to “0”, effectively changing its status from User-Mode to Kernel-Mode. This allows me, among other things, to read and write across the entire address space.
To find the address of “KTHREAD” for my own thread, I followed these steps:

To identify my own thread, I opened a handle to it in line 8. (I later used the handle value to spot related to its structure.) Calling “NtQuerySystemInformation” with “SystemHandleInformation” class, I obtained information about all handles in the system. To spot my own thread handle, I filtered the results looking for a handle value, process ID and object type (thread).

Now that I had the “KTHREAD” address and primitive to change the “PreviousMode” field, I combined it together:

I obtained a pointer to the EPROCESS structure simply by using information about its location from KTHREAD. EPROCESS will be discussed in more detail shortly. Remember that “ObfDereferenceObject” subtracts 0x30 from the address passed as an argument, which is why in line 900, 0x30 is added to the PreviousMode address.
Next, thanks to line 903, we have time to swap the symlink destination and bypass the authorization mechanism before opening a handle to the Asusgio3 device. Inside the “DecrementPreviousMode” function, I simply opened a handle to “Asusgio3” and sent a properly formatted buffer to trigger the primitive.

The “PreviousMode” field of the thread has now been changed to “Kernel-Mode”, allowing me to read the entire virtual address space. With this capability, the first step is to read and store the address location of the EPROCESS structure.

Having the address of my own EPROCESS structure, I started to search the linked list of processes for the SYSTEM process (PID == 4). To achieve this, I used a specific field within the EPROCESS structure called “ActiveProcessLinks”, which is a double-linked list of all processes in the system.

Finding the EPROCESS structure belonging to the SYSTEM process allows me to read its security token and replace the token with the one just read. Remember to increment the reference count of the SYSTEM token!

Now I can run the escalated console:

This reveals the following:

Success! This exploit results in a console with escalated privileges to SYSTEM level. Watch the video here.
During the reversal process, I noticed that the developers had patched some previously discovered vulnerabilities and exploitation primitives by restricting certain driver functionalities. However, relying on a disallowed list approach is never a good security practice, as an attacker only needs to find one function that isn’t explicitly blocked to exploit it. Instead, a more effective approach is to implement an allowed list, limiting functionality to only what is necessary.
More importantly, access to a driver with such critical and potentially dangerous functionality should be strictly controlled through multiple layers of security and made available only to a limited number of privileged system users.
Lastly, this research has demonstrated that attackers can leverage even seemingly simple primitives — such as “decrement by one” — to develop a fully functional privilege escalation exploit. This highlights the importance of careful security design in kernel-mode components.
Cisco Talos Blog – Read More
Imagine ditching passwords and SMS verification codes, and instead signing in to apps and websites with a simple fingerprint scan or even a smile at your camera. That’s the promise of passkeys. What’s more, unlike passwords, passkeys are resistant to theft. This means you could read news about data breaches — like the recent one affecting 16 billion accounts — without your heart sinking.
Under various names, this sign-in method is strongly recommended by WhatsApp, Xbox, Microsoft 365, YouTube, and dozens of other popular online services. But what does using passkeys look like in practice? We’ve covered this in detail for Google accounts, and today, we’ll explore how other online services and platforms support passkeys. In this first post, we’ll cover the basics of using passkeys on one or multiple devices. In our next post, we’ll dive into more complex scenarios, such as signing in to your account on a public computer, using Linux, or storing your passkeys on a dongle.
A passkey is a unique digital login key created for a specific website or app. It’s securely stored on your device: your smartphone, computer, or a dedicated USB dongle such as a YubiKey or Google Titan Security Key. When you sign in, your device uses biometrics or a PIN to verify it’s really you. After verification, your device sends a secure response, generated from that unique passkey, to the website. This mechanism offers strong protection against account theft, which is possible with traditional passwords — be that through phishing attacks or website breaches. Passkeys are supported across Apple, Google, and Microsoft devices, and theoretically, with cloud synchronization, they should be accessible across all your devices. For a deeper dive into the internal workings of passkeys, check out our previous article on the subject.
Before you fully commit to using passkeys, it’s worth considering how convenient they’d be for your specific setup. While the technology is becoming widely adoption, each website and platform implements it differently, using varying terminology for the same features. Additionally, transferring or syncing passkeys can present challenges.
If your smartphone is your only gadget, you are all-in on Apple devices, or you have a couple of recent Android or ChromeOS devices, passkeys will likely save you time when signing in to websites and apps, with minimal hassle.
However, if you use multiple platforms and own many devices, we strongly recommend a third-party password and passkey manager, such as Kaspersky Password Manager, for a smoother experience. Even then, you might still encounter occasional incompatibilities or quirky interfaces on some sites and apps.
For those using less common browsers, Linux-based operating systems, or older computers and smartphones, switching to passkeys might be entirely impracticable, or come with significant limitations.
Keep in mind that very few, if any, services deactivate password-based sign-in when you enable a passkey. This means that, in reality, the enhanced protection against account compromise isn’t as strong as advertised — unless you proactively disable password sign-in yourself. On the flip side, having a password as a backup sign-in method minimizes instances where you might lose access to your account due to passkey issues — but we’ll get into more detail about that later.
Passkeys can be used across major operating systems and browsers, and you don’t necessarily need the absolute latest versions.
For you to use a passkey, the website or application you’re signing in to must also support the technology. Hundreds already do, so we’ll just mention some of the major players.
Popular services that don’t currently support passkeys notably include ChatGPT, Claude, DeepSeek, Reddit, Spotify, Instagram, AliExpress, Temu, and Shein.
When considering the switch to passkeys and deciding how to store them, there are a few important drawbacks to keep in mind. The first two are unlikely to ever be fully resolved, while others may become less significant over time.
If you’re rocking just one device that fully supports passkeys (like Apple, Google, or Samsung smartphones released in the last couple of years), making the switch to passkeys is a breeze.
Simply head to the settings of each service you use, find the “Security” section, and look for a “Create a passkey” option.
Here are detailed instructions for Google, Microsoft, Facebook, WhatsApp, TikTok, Discord, Amazon, PayPal, Adobe, Linkedin, and Yahoo.
You won’t find instructions for creating a passkey for your iCloud account here because it happens automatically. Whenever you connect any device running iOS 16 or later, or macOS Ventura or later, to your account, a passkey is created. While you won’t see this in your settings, when you sign in to the iCloud website from an unfamiliar device, you’ll be able to use your passkey instead of a password.
Once created, passkeys are saved locally on your device: on iOS/macOS, they’re in Keychain, and on Android, they can be found in Google Password Manager. Windows is a bit more complex, as passkeys can use either the computer’s built-in storage (accessible via Windows Hello) or other storage options.
Going forward, to sign in to a website or app, just select “Sign in with passkey”, and complete the standard device verification — whether that’s a fingerprint, face scan, or PIN.
The latest versions of Safari on iOS and macOS, as well as Chrome on Windows and macOS (version 136 and later, with Android support “coming soon”), now offer an automatic upgrade option. If your browser has a saved password for a website that now supports passkeys, after you sign in, the browser might automatically create and save a passkey, then prompt you to use it for future passwordless sign-in.
If you’ve got more than one device, you’ll need to figure out how to sync your passkeys across all of them.
If you use only Macs and iPhones, or exclusively Android and ChromeOS devices, you won’t need to go through the hassle of manually setting up passkeys on each gadget. Simply create all your passkeys on one device and ensure that the sync option is enabled in the settings.
For iOS, you can enable this in the iPhone settings under Settings → [your name] → iCloud → Saved to iCloud → Passwords & Keychain → Sync this iPhone (complete guide). On Android, data saved in Google Password Manager automatically syncs with your Google account. Windows and Linux, however, currently lack a built-in passkey sync tool, although Microsoft has said it will develop one soon.
Things get a bit trickier for those who mix and match — especially with popular combinations like Windows + Android or macOS + Android. While you can use passkeys saved on an Android smartphone on your computer, it’s generally limited to Chrome, and only as long as you’re signed in to your Google account in the browser. Given Chrome’s significant drawbacks regarding privacy and user tracking, this solution won’t appeal to everyone. Besides, on a computer, this only allows you to sign in to websites with passkeys; app logins remain exclusive to your Android smartphone.
If you’re an iPhone user with a Windows computer, your iPhone passwords are accessible through the iCloud for Windows app, but it doesn’t support passkeys just yet.
Fortunately, an effective alternative has been available since late 2024. Third-party password managers have gradually added passkey management features across all major platforms. Therefore, the most reliable and universal way to store passkeys, regardless of how many devices you own or what type they are, is to use a robust password manager that supports passkeys and is NOT developed by Apple, Google, or Microsoft. For example, Kaspersky Password Manager already supports passkeys on Windows, with Android support planned for July, and iOS/macOS support for August 2025.
A password manager also solves the backup and recovery problem described above. If your only device with passkeys stored in a third-party password manager is lost or damaged, you can restore your passkeys to a new device from the password manager secure cloud storage.
To use a password manager for passkeys, you’ll need to install it on all your devices and add its browser extension to all browsers on your computer.
Managing your saved passkeys is done centrally. If you’re not using a third-party password manager, you can check, delete, or replace outdated passkeys as follows:
If you’re using a third-party password manager , all passkey management is handled within that application.
In our next post, we’ll dive into more complex situations when using passkeys, including:
Meanwhile, be sure to subscribe to our Telegram channel to catch the announcement for the next part!…
Kaspersky official blog – Read More
June 2025 saw several sophisticated and stealthy cyber attacks that relied heavily on obfuscated scripts, abuse of legitimate services, and multi-stage delivery techniques. Among the key threats observed by ANY.RUN’s analysts were malware campaigns using GitHub for payload hosting, JavaScript employing control-flow flattening to drop Remcos, and obfuscated BAT scripts delivering NetSupport RAT. Let’s see how ANY.RUN’s Interactive Sandbox and Threat Intelligence Lookup can help security teams detect, investigate, and understand these threats.
Original post on X and LinkedIn
A new campaign distributing Braodo stealer leverages public GitHub repository, including raw file content, to host payloads. The primary goal of this stealer is data exfiltration, and at the time of analysis, its detection rate was low. The BAT files used in the campaign include misleading comments to complicate analysis.
ANY.RUN’s Script Tracer simplifies the analysis by logging the multi-stage execution flow step by step, without the need for manual deobfuscation. Let’s take a closer look at this threat’s behavior using ANY.RUN Interactive Sandbox, which provides full visibility into process activity and persistence mechanisms.
View analysis

The first BAT file executes a CMD command that launches PowerShell in hidden mode to avoid displaying a visible window. It then downloads a second BAT file from github[.]com, disguised as a .PNG file, saves it to the %temp% folder, and executes it.

The second BAT file launches a new PowerShell script file, that removes components from the earlier stages, enforces TLS 1.2, retrieves an additional payload from raw.githubusercontent[.]com, saving it in the Startup folder, and downloads main payload in a ZIP file. This behavior is captured in ANY.RUN’s Script Tracer.

The final payload, Braodo Stealer, is extracted from a ZIP file, stored in the Public directory, and executed using python.exe. After execution, it deletes the initial archive to reduce artifacts. The Python file is obfuscated with pyobfuscate and contains non-encrypted, custom Base64-encoded payload strings appended to the script.

ANY.RUN’s Threat Intelligence Lookup allows analysts to discover recent Braodo attacks and fresh samples of this stealer dissected by the users of the Interactive Sandbox. Search by the malware’s name and view analyses:
threatName:”Braodo”

The search results contain a selection of Brado samples recently analyzed by the Sandbox users. Each analysis session can be explored in depth for harvesting IOCs and observing the malware’s behavior.
Original post on X and LinkedIn
Another tricky piece of malicious Java script has been observed using a technique called control-flow flattening obfuscation to secretly deliver Remcos malware. The JS contains multiple self-invoking functions that loop arrays of strings and numbers in a while(!![]) loop until a calculated checksum matches a predefined value. This obfuscation technique forces static analyzers to parse through the array’s content instead of returning the required string directly.
ANY.RUN’s Script Tracer enables easy analysis of heavily obfuscated scripts by logging their execution in real time, with no need for manual deobfuscation.

The script:

PowerShell-abusing script attacks are becoming more widespread and sophisticated. It is extremely important for threat hunters to be able to investigate and analyze such attacks, see what malware and malefactors are using them, and how.
A guest article by Clandestine, threat hunter and researcher, has recently been published in our blog highlighting a number of advanced tips for leveraging Threat Intelligence Lookup for malware data gathering and analysis (a guide to main TI Lookup features and their use is included, so we recommend to read and take note).
Clandestine demonstrates how one can find malware samples that use scripting languages to hide malicious code or execute obfuscated commands:
commandLine:”powershell” and fileExtension:”js”

This query identifies scripts that run system commands, the pattern commonly observed in multi-stage attacks where script files act as initial droppers that subsequently execute obfuscated PowerShell commands.
The combination of file extension parameters (you can search for other script types like Visual Basic Script (.vbs) files) with command-line indicators helps security analysts identify and analyze this obfuscation technique.
Original post on X and LinkedIn
Cybercriminals continue to rely on BAT files (batch scripts) to sneak malware into systems and evade detection. ANY.RUN team has studied one such case where an obfuscated BAT file was used to deliver the NetSupport Remote Access Trojan (RAT) – a tool originally designed for remote IT support but now abused by attackers to gain full control over victims’ machines.

The key execution chain stages are:


As attackers develop new ways to penetrate networks and evade detection, threat hunting becomes more challenging and demands to follow trends to keep ahead of possible disasters.
Threat Intelligence Lookup allows you to search for small, seemingly benign artifacts in the network that can be traces of malicious activities, like a folder creation in the system directory AppDataRoaming by a command line-run script:
commandLine:”AppData\Roaming\Options”

With the CommandLine search parameter, you can find malware samples based on any script artifacts found in system logs, for example, registry key changes.
ANY.RUN’s Threat Intelligence Lookup is a critical ally for security teams facing an ever-growing variety of evasive malware. With attackers increasingly relying on multi-stage scripts, living-off-the-land binaries (LOLBins), and public infrastructure like GitHub, traditional indicators often go unnoticed.
With Threat Intelligence Lookup your team can:
The cyber incidents in June 2025 underscore a clear trend: adversaries are refining their methods with obfuscation, open-source abuse, and layered execution chains. To combat these threats effectively, security teams need both visibility and context. Our Interactive Sandbox and TI Lookup empower analysts to deconstruct complex attacks and proactively hunt emerging threats before they become breaches.
ANY.RUN supports over 15,000 organizations across industries such as banking, manufacturing, telecommunications, healthcare, retail, and technology, helping them build stronger and more resilient cybersecurity operations.
With our cloud-based Interactive Sandbox, security teams can safely analyze and understand threats targeting Windows, Linux, and Android environments in less than 40 seconds and without the need for complex on-premise systems. Combined with TI Lookup, YARA Search, and TI Feeds, we equip businesses to speed up investigations, reduce security risks, and improve team’s efficiency.
Integrate ANY.RUN’s Threat Intelligence suite in your organization
The post Top 3 Cyber Attacks in June 2025: GitHub Abuse, Control Flow Flattening, and More appeared first on ANY.RUN’s Cybersecurity Blog.
ANY.RUN’s Cybersecurity Blog – Read More

Generative AI and LLMs have taken the world by storm. With the ability to generate convincing text, solve problems, write computer code and more, LLMs are being integrated into almost every facet of society. According to Hugging Face (a platform that hosts models), there are currently over 1.8 million different models to choose from.
LLMs are usually built with key safety features, including alignment and guardrails. Alignment is a training process that LLMs undergo to minimize bias and ensure that the LLM generates outputs that are consistent with human values and ethics. Guardrails are additional real-time safety mechanisms that try to restrain the LLM from engaging in harmful or undesirable actions in response to user input. Many of the most advanced (or “frontier”) LLMs are protected in this manner. For example, asking ChatGPT to produce a phishing email will result in a denial, such as, “Sorry, I can’t assist with that.”
For cybercriminals who wish to utilize LLMs for conducting or improving their attacks, these safety mechanisms can present a significant obstacle. To achieve their goals, cybercriminals are increasingly gravitating towards uncensored LLMs, cybercriminal-designed LLMs and jailbreaking legitimate LLMs.
Uncensored LLMs are unaligned models that operate without the constraints of guardrails. These systems happily generate sensitive, controversial, or potentially harmful output in response to user prompts. As a result, uncensored LLMs are perfectly suited for cybercriminal usage.

Uncensored LLMs are quite easy to find. For example, using the cross-platform Omni-Layer Learning Language Acquisition (Ollama) framework, a user can download and run an uncensored LLM on their local machine. Ollama comes with several uncensored models such as Llama 2 Uncensored which is based on Meta’s Llama 2 model. Once it is running, users can submit prompts that would otherwise be rejected by more safety-conscious LLM implementations. The downside is that these models are running on users’ local machines and running larger models, which generally produce better results but requires more system resources.

Another uncensored LLM popular among cybercriminals is a tool called WhiteRabbitNeo. WhiteRabbitNeo bills itself as a “Uncensored AI model for (Dev) SecOps teams” which can support “use cases for offensive and defensive cybersecurity”. This LLM will happily write offensive security tools, phishing emails and more.

Researchers have also published methods to demonstrate how to strip alignment that is embedded into the training data of existing open-source models. Once removed, a user can uncensor their LLM by using the modified training set to fine tune a base model.
Since most popular LLMs come with significant guardrails, some enterprising cybercriminals have developed their own LLMs without restrictions that they market to other cybercriminals. This includes apps like GhostGPT, WormGPT, DarkGPT, DarkestGPT and FraudGPT.

For example, the developer behind FraudGPT, CanadianKingpin12, advertises FraudGPT on the dark web, and also has an account on Telegram. The dark web site for FraudGPT advertises some interesting features:
Talos attempted to obtain access to FraudGPT by reaching out to CanadianKingpin12 on Telegram. After considerable negotiation, we were finally offered a username and password at the FraudGPT dark web site. However, the username and password provided by CanadianKingpin12 did not work. CanadianKingpin12 then asked us to send them cryptocurrency to purchase a software “crack” for the FraudGPT login page. At this point it was clear that CanadianKingpin12 had no working product, and they were scamming potential FraudGPT customers out of their cryptocurrency. This was confirmed by several other victims who had also been scammed by CanadianKingpin12 when they attempted to purchase access to the FraudGPT LLM. Scams such as these are an ever-present risk when dealing with unscrupulous actors, and it continues a long tradition of scams in the cybercrime space.
Similar cybercriminal-designed LLM projects can be found elsewhere on the dark web. A cybercriminal LLM called DarkestGPT, which starts at .0015BTC for a one-month subscription, advertises the following features:

Given the limited viability of uncensored LLMs due to resource constraints and the high level of fraud and scams present among cybercriminal LLM purveyors, many cybercriminals have elected to abuse legitimate LLMs instead. The main hurdle that cybercriminals need to overcome are the training alignment and guardrails that prevent the LLM from responding to prompts with unethical, illegal or harmful content. A form of prompt injection, jailbreak attacks aim to put the LLM into a state where it ignores its alignment training and guardrails protection.
There are many ways to trick an LLM into providing dangerous responses. New jailbreaking methods are constantly being researched and discovered, while LLM developers respond by enhancing the guardrails in a sort of jailbreak arms race. Below are just a few of the available jailbreaking techniques.
By obfuscating certain words or phrases, these text-based jailbreak attacks seek to bypass any hardcoded restrictions on specific words/topics, or to cause the execution to follow a nonstandard path that might bypass protections put in place by the LLM developers. These obfuscation techniques may include:
These attacks are somewhat like obfuscation and encoding tricks. Instead of modifying the tokens in the prompt itself, adversarial suffix jailbreaks involve appending random text to the end of a malicious prompt to elicit a harmful response.
This type of attack involves prompting the LLM to adopt the persona of a fictional universe/character that ignores the ethical rules set by the model’s creators and is willing to fulfill any command. This includes jailbreak techniques such as DAN (Do Anything Now), and the Grandma jailbreak which involves asking the chatbot to assume the role of the user’s grandmother.
Meta prompting involves exploiting the model’s awareness of its own limitations to devise successful workarounds, effectively enlisting the model in the effort to bypass its own safeguards.
This covers several different jailbreak techniques including:
The math prompt method evaluates how well an AI system can manage malicious inputs when they’re disguised using mathematical frameworks such as set theory, group theory, and abstract algebra. Rephrasing harmful requests as math problems can allow attackers to evade safety features in advanced large language models (LLMs).
In this scenario, the attacker guides the LLM to merge several prompts in a way that produces harmful output. While texts A and B may seem benign when considered separately, their combination (A+B) can result in malicious content.
This method makes harmful content appear acceptable by framing it as part of a research or educational discussion. It takes advantage of the model’s interpretation of academic intent and freedom, often using scholarly language and formatting to bypass safeguards.
This strategy tries to trick the model into believing it is functioning in a unique mode where usual limitations are lifted. It leverages the model’s perception of system-level functions or maintenance states to circumvent safety mechanisms.
In December 2024, Anthropic, the developers behind the Claude LLM, published a report detailing how its users were utilizing Claude. Using a system named Clio, they summarized and categorized users’ conversations with their AI model. According to Anthropic, the top three uses for Claude were programming, content creation and research.

Analyzing the feature sets advertised by the criminal-designed LLMs, we can see that cybercriminals are using LLMs for mostly the same tasks as normal LLM users. Programming features of many criminal LLMs include the ability to assist cybercriminals in writing ransomware, remote access trojans, wipers, code obfuscation, shellcode generation and script/tool creation. To facilitate content creation, criminal LLMs will assist in writing phishing emails, landing pages and configuration files. Criminal LLMs also support research activities like verifying stolen credit cards, scanning sites/code for vulnerabilities and even helping cybercriminals come up with “lucrative” criminal ideas for their next big score.
Various hacking forums also shed additional light on criminal uses of LLMs. For example, on the popular hacking forum Dread, users were discussing connecting LLMs to external tools like Nmap, and using the LLM to summarize the Nmap output.

Any new technology typically brings along with it changes to the attack surface, and LLMs are no exception. In addition to using LLMs for their own nefarious ends, attackers are also attempting to compromise LLMs and their users.
A vast majority of the models available at Hugging Face use Python’s pickle module to serialize the models into a file that users can download. Clever attackers can include Python code in the pickle file, which runs as part of the deserialization process. Thus, when a user downloads an AI model and runs it, they may be running code placed into the model by an attacker. Hugging Face uses Picklescan, among other tools, to scan the models uploaded by users in an effort to identify models that misbehave. However, there have been several recent vulnerabilities in Picklescan, and researchers have already identified Hugging Face models containing malware. As always, make sure any file you plan to download and run comes from a trusted source and consider running the file in a sandbox to mitigate any risk of infection.
LLMs that utilize Retrieval Augmented Generation (RAG) make calls to external data sources to augment their training data with up-to-date information. For example, if you ask an LLM what the weather is like a particular day, the LLM will need to reach out to an external data source such as a website to retrieve the correct forecast. If an attacker has access to submit or manipulate content in the RAG database, they may poison the lookup results, perhaps adding additional instructions for the LLM to alter its response to the user’s prompt, even targeting specific users.
As AI technology continues to develop, Cisco Talos expects cybercriminals to continue adopting LLMs to help streamline their processes, write tools/scripts that can be used to compromise users and generate content that can more easily bypass defenses. This new technology doesn’t necessarily arm cybercriminals with completely novel cyber weapons, but it does act as a force multiplier, enhancing and improving familiar attacks.
Cisco Talos Blog – Read More
Researchers have uncovered three vulnerabilities in the popular content management system, Sitecore Experience Platform.
By combining the first vulnerability with either of the latter two, an attacker can achieve remote code execution (RCE) on a server running the Sitecore Experience Platform.
There’s currently no evidence of these vulnerabilities being exploited in the wild; however, the detailed analysis published by watchTowr contains enough information for threat actors to weaponize them at any moment.
The Sitecore CMS includes several default accounts, one of which is sitecoreServicesAPI. Naturally, passwords for all accounts are stored in a hashed (and even salted) form. However, this doesn’t make much difference if the password consists of just the single letter “b”. Such a password can be brute-forced in about three seconds.
Notably, Sitecore’s developers advise against modifying default accounts, warning that “editing a default user account can affect other areas of the security model” (whatever that means). Site admins following the official instructions are thus unlikely to change these passwords. As a result, such default accounts are likely present in most websites using this CMS.
That said, the sitecoreServicesAPI user has no assigned rights or roles, so simply authenticating through the standard Sitecore login interface isn’t possible. However, the researchers found a way to bypass the database check required for successful authentication (for details, see the original research). As a result, the attacker obtains a valid session cookie. They still don’t have administrator rights, but this cookie can be used for further attacks.
Sitecore has a file upload mechanism which any authenticated user can use. So having a valid session cookie, an attacker can create an HTTP request to upload and automatically extract a ZIP archive. The essence of CVE-2025-34510 is that due to flawed input sanitization, an authenticated attacker can perform a path traversal. You can read more about this type of vulnerability — known as Zip Slip — in our post on ZIP file processing. In essence, the attacker can extract the archive to any location — for example, the website’s root folder. This way, the attacker can upload anything — such as their own web shell.
CVE-2025-34511 is an alternative way to compromise Sitecore. This vulnerability is present in the Sitecore PowerShell Extensions module, which is required for a number of Sitecore extensions to function — for example, the Sitecore Experience Accelerator, one of the most popular extensions for this CMS.
Essentially, this vulnerability works in much the same way as CVE-2025-34510, only slightly simpler. The Sitecore PowerShell extension also has its own file upload mechanism, which can be exploited by an authenticated user. Through HTTP requests, an attacker can upload any file with any extension to the CMS, and save it to any directory on the website. This means there’s no need to prepare a custom ZIP archive and path, and the result is basically the same: a web shell upload.
Patches for these three vulnerabilities were released back in May 2025. If your company uses Sitecore, especially in combination with Sitecore PowerShell Extensions, we recommend updating the CMS as soon as possible. According to NIST descriptions, CVE-2025-34509 affects Sitecore Experience Manager and Experience Platform versions 10.1 through 10.1.4 rev. 011974 PRE; all variants of 10.2; 10.3 through 10.3.3 rev. 011967 PRE; and 10.4 through 10.4.1 rev. 011941 PRE. CVE-2025-34510 is present in Experience Manager, Experience Platform, and Experience Commerce versions 9.0 through 9.3 and 10.0 through 10.4. Lastly, CVE-2025-34511 affects all versions of Sitecore PowerShell Extensions up to version 7.0.
The researchers who discovered these flaws claim to be aware of four other, much more interesting vulnerabilities. However, since patches aren’t ready yet, they’ve said they will disclose these vulnerabilities later. As such, we recommend keeping an eye on upcoming updates from the Sitecore developers.
Kaspersky official blog – Read More
When malware infiltrates a system, it doesn’t always make noise. In fact, some of the most dangerous threats operate quietly embedding themselves deep within the system and ensuring they come back even after a reboot. One of the most common ways they achieve this is by abusing the Windows Registry.
In this article, we’ll walk through how registry abuse works, the signs to watch out for, and how security analysts can catch it using interactive sandboxes, such as ANY.RUN.
The Windows Registry is an important part of the operating system. It stores configuration settings that determine how Windows behaves, how software runs, and even how users interact with the system. From startup routines to driver settings and user preferences, the registry touches almost every part of the OS.
As it’s central, the registry is also a target for malware authors. By modifying registry keys and values, malware can silently manipulate system behavior to:
Traditional security tools often miss subtle but critical signs of registry abuse, especially when malware hides behind scripts or legitimate-looking processes.
By running suspicious files or links inside ANY.RUN’s interactive sandbox, analysts can observe real-time registry changes as they happen, without waiting for static scans to catch up.
Now, let’s look at how malware abuses the registry in practice and how ANY.RUN makes it easy to detect.
This sample shows how the malware (BootstrapperNew.exe) abuses the registry to ensure it launches automatically every time the system boots; a classic persistence mechanism.

As shown in the analysis, the malware modifies the following registry key:
HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun
It adds a new value:
You can check all these details by checking the “BootstrapperNew.exe” process from the right part of the screen.

Click on the tactic to get all the details:

This modification triggers Windows to execute the malicious file at every user login, giving the attacker a reliable foothold on the system.
ANY.RUN also flags this behavior with the MITRE ATT&CK sub-technique T1547.001 (Registry Run Keys / Startup Folder), clearly highlighting the persistence mechanism used. The visual process tree further confirms the execution flow, registry operation, and background network activity.

With static detection tools, this behavior might go unnoticed. But in ANY.RUN’s sandbox, the threat is immediately identified, tagged, and visually traceable in real time, from registry edit to scheduled task creation.
In this example, the malware identified as FormBook manipulates the Windows Registry to aid in stealth and persistence.
Right after execution, FormBook writes a new registry entry under:

Custom registry values like this aren’t random. They’re typically placed in obscure subkeys (SOFTWARESoftina in this case) to avoid detection and logging by standard monitoring tools, but in ANY.RUN’s sandbox, it’s instantly visible and tied to MITRE technique T1112: Modify Registry.

Some malware doesn’t act immediately. Instead, it quietly profiles the environment to decide how (or whether) to execute. That’s exactly what we see in this sample, where the malware queries the registry to gather detailed system information.
One of the first actions taken is a read operation targeting:

This query fetches CPU information, such as model name and vendor. While this might seem benign, it plays a crucial role in anti-analysis and evasion tactics.
Why malware reads CPU info:
But this is just the beginning. According to the MITRE ATT&CK technique T1012: Query Registry, this sample retrieves a wide range of values:

This shows how malware can treat the registry as a rich source of system intelligence. Each value queried helps build a clearer picture of the host environment, guiding the next malicious action.
This sample involves a process (_virlock.exe) that uses reg.exe, a legitimate Windows utility, to modify the registry. This kind of activity isn’t inherently malicious, but in the context of malware execution, it often signals stealthy post-infection behavior.
Shortly after execution, the malware launches a command: reg add HKCUSoftwareMicrosoftWindowsCurrentVersionExplorerAdvanced /v HideFileExt /t REG_DWORD /d 1
This command modifies the registry to hide file extensions for known file types, a well-documented trick used by malware to disguise malicious executables (e.g., invoice.pdf.exe appears as invoice.pdf).

Why it’s suspicious:

This case is a good reminder that not all registry abuse is about persistence. Some changes are purely meant to deceive the user, reduce visibility, or mask malicious actions.
With ANY.RUN’s behavioral analysis, this tactic becomes immediately visible, showing which registry key was changed, how, when, and by what process, including full command-line context.
In this sample, we see a Windows Script Host process (wscript.exe) modifying the registry, not through a typical executable, but via script-based interaction. This kind of behavior is harder to detect, especially if you’re relying on traditional static analysis.
Thanks to ANY.RUN’s Script Tracer, we can observe the exact call and parameters used:

This script creates a new key and writes what appears to be an obfuscated or encoded payload into the registry; a technique commonly used to:
The registry key name (OJXVOPIitLTnYNg) is randomly generated and meaningless, a common trait of obfuscated malware activity.
We can see how the script writes a long block of hexadecimal content, which may later be decoded and executed, without ever dropping a traditional file on disk.

These modifications fall under MITRE ATT&CK technique T1112: Modify Registry, and ANY.RUN labels this behavior as Dangerous (13 instances).

Without behavioral analysis, this kind of registry manipulation would be nearly invisible, but with Script Tracer, security analysts can follow every step the script takes, down to the exact method calls and values.
Registry modifications are a common and powerful tactic used by malware to stay hidden, persist through reboots, and weaken your defenses. But with the right tools, these threats become much easier to spot, investigate, and respond to.
ANY.RUN’s interactive sandbox doesn’t just show you what malware is doing, it visually breaks down every behavior, from registry edits to process injection and data exfiltration, in real time.
See how ANY.RUN’s interactive sandbox reveals the behavior behind modern threats in real time, and with full context.
Access all capabilities of ANY.RUN’s Interactive Sandbox with a 14-day trial
The post How to Spot Registry Abuse by Malware: Examples in ANY.RUN Sandbox appeared first on ANY.RUN’s Cybersecurity Blog.
ANY.RUN’s Cybersecurity Blog – Read More