The life of a modern head of information security (also known as CISO – Chief Information Security Officer) is not just about fighting hackers. It’s also an endless quest that goes by the name of “compliance”. Regulators keep tightening the screws, standards pop up like mushrooms, and headaches only get worse; but wait… – there’s more: CISOs are responsible not only for their own perimeter, but what goes on outside it too: for their entire supply chain, all their contractors, and the whole hodge-podge of software their business processes run on. Though the logic here is solid, it’s also unfortunately ruthless: if a hole is found at your supplier, but the problems hit you, in the end it’s you who’s held accountable. This logic applies to security software too.

Back in the day, companies rarely thought about what was actually inside the security solutions and products they used. Now, however, businesses – especially large ones – want to know everything: what’s really inside the box? Who wrote the code? Is it going to break some critical function or could it even bring everything down? (We’ve seen such precedents; example: the Crowdstrike 2024 update incident.) Where and how is data processed? And these are the right questions to ask.

The problem lies in the fact that almost all customers trust their vendors to answer accurately when asked such questions – very often because they have no other choice. A more mature approach in today’s cyber-reality is to verify.

In corporate-speak this is called supply-chain trust, and trying to solve this puzzle on your own is a serious headache. You need help from vendors. A responsible vendor is ready to show what’s under the hood of its solutions, to open up the source code to partners and customers for review, and, in general, to earn trust not with nice slides but with solid, practical steps.

So who’s already doing this, and who’s still stuck in the past? A fresh, in-depth study from our colleagues in Europe has the answer. It was conducted by the respected testing lab AV-Comparatives, the Austrian Economic Chamber (WKO), the MCI Entrepreneurial School, and the law firm Studio Legale Tremolada.

The main conclusion of the study is that the era of “black boxes” in cybersecurity is over. RIP. Amen. The future belongs to those who don’t hide their source code and vulnerability reports, and who give customers maximum choice when configuring their products. And the report clearly states who doesn’t just promise but actually delivers. Guess who!…

What a great guess! Yes – it’s us!

We give our customers something that is still, unfortunately, a rare and endangered species in the industry: transparency centers, source code reviews of our products, a detailed software bill of materials (SBOM), and the ability to check update history and control rollouts. And of course we provide everything that’s already become the industry standard. You can study all the details in the full “Transparency and Accountability in Cybersecurity” (TRACS) report, or in our summary. Below, I’ll walk through some of the most interesting bits.

Not mixing apples and oranges

TRACS reviewed 14 popular vendors and their EPP/EDR products – from Bitdefender and CrowdStrike to our EDR Optimum and WithSecure. The objective was to understand which vendors don’t just say “trust us”, but actually let you verify their claims. The study covered more than 60 criteria: from GDPR (General Data Protection Regulation – it’s a European study after all) compliance and ISO 27001 audits, to the ability to process all telemetry locally and access a product’s source code. But the authors decided not to give points for each category or form a single overall ranking.

Why? Because everyone has different threat models and risks. What is a feature for one may be a bug and a disaster for another. Take fast, fully automatic installation of updates. For a small business or a retail company with thousands of tiny independent branches, this is a blessing: they’d never have enough IT staff to manage all of that manually. But for a factory where a computer controls the conveyor it would be totally unacceptable. A defective update can bring a production line to a standstill, which in terms of business impact could be fatal (or at least worse than the recent Jaguar Land Rover cyberattack); here, every update needs to be tested first. It’s the same story with telemetry. A PR agency sends data from its computers to the vendor’s cloud to participate in detecting cyberthreats and get protection instantly. Perfect. A company that processes patients’ medical records or highly classified technical designs on its computers? Its telemetry settings would need to be reconsidered.

Ideally, each company should assign “weights” to every criterion, and calculate its own “compatibility rating” with EDR/EPP vendors. But one thing is obvious: whoever gives customers choices, wins.

Take file reputation analysis of suspicious files. It can work in two ways: through the vendor’s common cloud, or through a private micro-cloud within a single organization. Plus there’s the option to disable this analysis altogether and work completely offline. Very few vendors give customers all three options. For example, “local” reputation analysis is available from only eight vendors in the test. It goes without saying we’re one of them.

Raising the bar

In every category of the test the situation is roughly the same as with the reputation service. Going carefully through all 45 pages of the report, we’re either ahead of our competitors or among the leaders. And we can proudly say that in roughly a third of the comparative categories we offer significantly better capabilities than most of our peers. See for yourself:

Visiting a transparency center and reviewing the source code? Verifying that the product binaries are built from this source code? Only three vendors in the test provide these things. And for one of them – it’s only for government customers. Our transparency centers are the most numerous and geographically spread out, and offer customers the widest range of options.

The opening of our first transparency center back in 2018

Downloading database updates and rechecking them? Only six players – including us – provide this.

Configuring multi-stage rollout of updates? This isn’t exactly rare, but it’s not widespread either – only seven vendors besides us support it.

Reading the results of an external security audit of the company? Only we and six other vendors are ready to share this with customers.

Breaking down a supply chain into separate links using an SBOM? This is rare too: you can request an SBOM from only three vendors. One of them is the green-colored company that happens to bear my name.

Of course, there are categories where everyone does well: all of them have successfully passed an ISO/IEC 27001 audit, comply with GDPR, follow secure development practices, and accept vulnerability reports.

Finally, there’s the matter of technical indicators. All products that work online send certain technical data about protected computers, and information about infected files. For many businesses this isn’t a problem, and they’re glad it improves effectiveness of protection. But for those seriously focused on minimizing data flows, AV-Comparatives measures those too – and we just so happen to collect the least amounts of telemetry compared to other vendors.

Practical conclusions

Thanks to the Austrian experts, CISOs and their teams now have a much simpler task ahead when checking their security vendors. And not just the 14 that were tested. The same framework can be applied to other security solution vendors and to software in general. But there are strategic conclusions too…

Transparency makes risk management easier. If you’re responsible for keeping a business running, you don’t want to guess whether your protection tool will become your weak point. You need predictability and accountability. The WKO and AV-Comparatives study confirms that our model reduces these risks and makes them manageable.

Evidence instead of slogans. In this business, it’s not enough to be able write “we are secure” on your website. You need audit mechanisms. The customer has to be able to drop by and verify things for themselves. We provide that. Others are still catching up.

Transparency and maturity go hand in hand. Vendors that are transparent for their customers usually also have more mature processes for product development, incident response, and vulnerability handling. Their products and services are more reliable.

Our approach to transparency (GTI) works. When we announced our initiative several years ago and opened Transparency Centers around the world, we heard all kinds of things from critics – like that it was a waste of money and that nobody needed it. Now independent European experts are saying that this is how a vendor should operate in 2025 and beyond.

It was a real pleasure reading this report. Not just because it praises us, but because the industry is finally turning in the right direction – toward transparency and accountability.

We started this trend, we’re leading it, and we’re going to keep pioneering within it. So, dear readers and users, don’t forget: trust is one thing; being able to fully verify is another.

Kaspersky official blog – ​Read More

Thanks to the convenience of NFC and smartphone payments, many people no longer carry wallets or remember their bank card PINs. All their cards reside in a payment app, and using that is quicker than fumbling for a physical card. Mobile payments are also secure — the technology was developed relatively recently and includes numerous anti-fraud protections. Still, criminals have invented several ways to abuse NFC and steal your money. Fortunately, protecting your funds is straightforward: just know about these tricks and avoid risky NFC usage scenarios.

What are NFC relay and NFCGate?

NFC relay is a technique where data wirelessly transmitted between a source (like a bank card) and a receiver (like a payment terminal) is intercepted by one intermediate device, and relayed in real time to another. Imagine you have two smartphones connected via the internet, each with a relay app installed. If you tap a physical bank card against the first smartphone and hold the second smartphone near a terminal or ATM, the relay app on the first smartphone will read the card’s signal using the NFS and relay it in real time to the second smartphone, which will then transmit this signal to the terminal. From the terminal’s perspective, it all looks like a real card is tapped on it — even though the card itself might physically be in another city or country.

This technology wasn’t originally created for crime. The NFCGate app appeared in 2015 as a research tool after it was developed by students at the Technical University of Darmstadt in Germany. It was intended for analyzing and debugging NFC traffic, as well as for education purposes and experiments with contactless technology. NFCGate was distributed as an open-source solution and used in academic and enthusiast circles.

Five years later, cybercriminals caught on to the potential of NFC relay and began modifying NFCGate by adding mods that allowed it to run through a malicious server, disguise itself as legitimate software, and perform social engineering scenarios.

What began as a research project morphed into the foundation for an entire class of attacks aimed at draining bank accounts without physical access to bank cards.

A history of misuse

The first documented attacks using a modified NFCGate occurred in late 2023 in the Czech Republic. By early 2025, the problem had become large scale  and noticeable: cybersecurity analysts uncovered more than 80 unique malware samples built on the NFCGate framework. The attacks evolved rapidly, with NFC relay capabilities being integrated into other malware components.

By February 2025, malware bundles combining CraxsRAT and NFCGate emerged, allowing attackers to install and configure the relay with minimal victim interaction. A new scheme, a so-called “reverse” version of NFCGate, appeared in spring 2025, fundamentally changing the attack’s execution.

Particularly noteworthy is the RatOn Trojan, first detected in the Czech Republic. It combines remote smartphone control with NFC relay capabilities, letting attackers target victims’ banking apps and cards through various technique combinations. Features like screen capture, clipboard data manipulation, SMS sending, and stealing info from crypto wallets and banking apps give criminals an extensive arsenal.

Cybercriminals have also packaged NFC relay technology into malware-as-a-service (MaaS) offerings, and reselling them to other threat actors through subscription. In early 2025, analysts uncovered a new and sophisticated Android malware campaign in Italy, dubbed SuperCard X. Attempts to deploy SuperCard X were recorded in Russia in May 2025, and in Brazil in August of the same year.

The direct NFCGate attack

The direct attack is the original criminal scheme exploiting NFCGate. In this scenario, the victim’s smartphone plays the role of the reader, while the attacker’s phone acts as the card emulator.

First, the fraudsters trick the user into installing a malicious app disguised as a banking service, a system update, an “account security” app, or even a popular app like TikTok. Once installed, the app gains access to both NFC and the internet — often without requesting dangerous permissions or root access. Some versions also ask for access to Android accessibility features.

Then, under the guise of identity verification, the victim is prompted to tap their bank card to their phone. When they do, the malware reads the card data via NFC and immediately sends it to the criminals’ server. From there, the information is relayed to a second smartphone held by a money mule, who helps extract the money. This phone then emulates the victim’s card to make payments at a terminal or withdraw cash from an ATM.

The fake app on the victim’s smartphone also asks for the card PIN — just like at a payment terminal or ATM — and sends it to the attackers.

In early versions of the attack, criminals would simply stand ready at an ATM with a phone to use the duped user’s card in real time. Later, the malware was refined so the stolen data could be used for in-store purchases in a delayed, offline mode, rather than in a live relay.

For the victim, the theft is hard to notice: the card never left their possession, they didn’t have to manually enter or recite its details, and the bank alerts about the withdrawals can be delayed or even intercepted by the malicious app itself.

Among the red flags that should make you suspect a direct NFC attack are:

• prompts to install apps not from official stores;
• requests to tap your bank card on your phone.

The reverse NFCGate attack

The reverse attack is a newer, more sophisticated scheme. The victim’s smartphone no longer reads their card — it emulates the attacker’s card. To the victim, everything appears completely safe: there’s no need to recite card details, share codes, or tap a card to the phone.

Just like with the direct scheme, it all starts with social engineering. The user gets a call or message convincing them to install an app for “contactless payments”, “card security”, or even “using central bank digital currency”. Once installed, the new app asks to be set as the default contactless payment method — and this step is critically important. Thanks to this, the malware requires no root access — just user consent.

The malicious app then silently connects to the attackers’ server in the background, and the NFC data from a card belonging to one of the criminals is transmitted to the victim’s device. This step is completely invisible to the victim.

Next, the victim is directed to an ATM. Under the pretext of “transferring money to a secure account” or “sending money to themselves”, they are instructed to tap their phone on the ATM’s NFC reader. At this moment, the ATM is actually interacting with the attacker’s card. The PIN is dictated to the victim beforehand — presented as “new” or “temporary”.

The result is that all the money deposited or transferred by the victim ends up in the criminals’ account.

The hallmarks of this attack are:

• requests to change your default NFC payment method;
• a “new” PIN;
• any scenario where you’re told to go to an ATM and perform actions there under someone else’s instructions.

How to protect yourself from NFC relay attacks

NFC relay attacks rely not so much on technical vulnerabilities as on user trust. Defending against them comes down to some simple precautions.

• Make sure you keep your trusted contactless payment method (like Google Pay or Samsung Pay) as the default.
• Never tap your bank card on your phone at someone else’s request, or because an app tells you to. Legitimate apps might use your camera to scan a card number, but they’ll never ask you to use the NFC reader for your own card.
• Never follow instructions from strangers at an ATM — no matter who they claim to be.
• Avoid installing apps from unofficial sources. This includes links sent via messaging apps, social media, SMS, or recommended during a phone call — even if they come from someone claiming to be customer support or the police.
• Use comprehensive security on your Android smartphones to block scam calls, prevent visits to phishing sites, and stop malware installation.
• Stick to official app stores only. When downloading from a store, check the app’s reviews, number of downloads, publication date, and rating.
• When using an ATM, rely on your physical card instead of your smartphone for the transaction.
• Make it a habit to regularly check the “Payment default” setting in your phone’s NFC menu. If you see any suspicious apps listed, remove them immediately and run a full security scan on your device.
• Review the list of apps with accessibility permissions — this is a feature commonly abused by malware. Either revoke these permissions for any suspicious apps, or uninstall the apps completely.
• Save the official customer service numbers for your banks in your phone’s contacts. At the slightest hint of foul play, call your bank’s hotline directly without delay.
• If you suspect your card details may have been compromised, block the card immediately.

Kaspersky official blog – ​Read More

ANY.RUN’s team conducted an extensive malware analysis of CastleLoader, the first link in the chain of attacks impacting various industries, including government agencies and critical infrastructures. 

It’s a unique walkthrough of its entire execution path, from a packaged installer to C2 server connection, as well as an overview of a parser developed to extract initialized local variables and automatically decode indicators of compromise (IOCs) featured in them. 

Key Takeways 

• CastleLoader is a stealthy malware loader used as the first stage in attacks against government entities and multiple industries. 

• It relies on a multi-stage execution chain (Inno Setup → AutoIt → process hollowing) to evade detection. 

• The final malicious payload only manifests in memory after the controlled process has been altered, making traditional static detection ineffective. 

• CastleLoader delivers information stealers and RATs, enabling credential theft and persistent access. 

• A full-cycle analysis allowed us to extract runtime configuration, C2 infrastructure, and high-confidence IOCs. 

CastleLoader as an Initial Access Threat 

CastleLoader is a malicious loader malware built to deliver and install other malicious components. It lays the groundwork for the attack, becoming its starting point. 

This loader has commonly occurred in cyber attacks since early 2025. It gained popularity due to its high infection rate and universal nature, making it a powerful yet evasive tool. 

One of CastleLoader’s malicious campaigns is known to impact a total of 469 devices. It became a significant threat to organizations, especially US-based government entities. Its broader scope includes industries like IT, logistics, travel, and critical infrastructures across Europe. 

CastleLoader is dangerous as a link in the chain delivering information stealers and  RATs, making credential theft and persistent network access a high risk. 

The loader’s popularity has inspired ANY.RUN’s malware analysis team to break down its malicious sample in order to uncover what it’s made of, retrieve signatures, and retrieve  malware configurations. 

Detect CastleLoader and More with Threat Intelligence Feeds 

Modern malware like CastleLoader is designed to evade traditional detection. To keep up with the pace of adversaries, security teams need threat intelligence that reflects what attackers are using right now. 

ANY.RUN’s Threat Intelligence Feeds provide real-time indicators extracted from live malware executions performed by thousands of SOC teams worldwide. With TI Feeds, they achieve: 

• Faster threat detection: Identify active loaders, stealers, and RATs as soon as they appear in real-world attacks thanks to 99% unique data extracted from the latest sandbox analyses by 15K SOCs and 500K analysts. 

• Higher confidence decisions: Indicators are backed by execution context, not guesswork or outdated reports. 

• Improved SOC efficiency: Fewer false positives mean less alert fatigue and better use of analyst time. 

• Stronger risk management: Early visibility into emerging malware families helps prevent business disruption. 

By combining real-time sandbox intelligence with immediate IOC delivery, ANY.RUN TI Feeds help organizations stay ahead of fast-evolving threats like CastleLoader. 

Initial Analysis: Sandbox Telemetry 

The analysis started with ANY.RUN’s Interactive Sandbox detonation.  

View analysis 

What instantly grabs our attention here is a system process chain, at the end of which a request to 94[.]159[.]113[.]32:80 was sent. To understand this activity better, we switched to the binary analysis. 

Static analysis: Inspecting Inno Setup Installer  

To get a basic overview of the binary, let’s process it via DIE (Detect It Easy).  

It reveals that the binary consists of Object Pascal (Delphi) and Inno Setup Module (installer). 

The next stage of the analysis requires the use of innoextract, a tool to unpack installers. We used a fork that allows you to unpack password-protected archives, which came in handy. 

Archive extraction reveals several executables. At this point, it’s Autolt3.exe and the compiled script freely.a3x that grab our attention most. These are the files that directly participate in the calling chain. Other files, as it turned out later, aren’t related to the malware execution, and their role is unclear. 

Next, let’s use Autolt-Ripper to extract compiled Autolt scripts from A3X containers. As a result of this, we get a file script.au3 containing 24,402 code lines. The majority of this code, which is responsible for the malicious chain, is unreadable: 

// A function’s minimal listing 

Func FUNC_38 ( $XGOHK_KNZJTRNG , $FRNQQSFKMV_ONCPFFG_IUESI , $OYJVN ) 

  Local $VAR_2745 [ 5 ] = [ ( $FOCOFQYNAZZDTMNK [ 0 ] [ 0 ] <= $VAR_1884 ? $APITY_TTXPNVODYF_UOFBAYSHE : 51205 ) , 51215 , ( $DCZH1PQYFZ0_9_S_KG8_Q3 < $WGCOD_JPCLUUNAEM [ 1 ] ? 51217 : $HQBFEELFMG_MKBEGBLQI ( ) ) , ( $XCEAEI_JVVDYWYNZG_VYLLS >= $G_HGLSAQTEAFZZZONMJ [ 6 ] ? $GVNKFKFUPA_XKWCWRP_GQDKXPY ( ) : 51193 ) , ( $UNPBEN < $G_HGLSAQTEAFZZZONMJ [ 8 ] ? 51205 : $VAR_1654 [ 1 ] [ 7 ] ) ] 

  Local $NWBSM 

  Local $JIQBD 

  For $JIQBD = ( $MON_GLZO__BPDFZTL [ 3 ] > $MON_GLZO__BPDFZTL [ 9 ] ? 0 : $VAR_364 [ 0 ] [ 0 ] ) To ( $G_HGLSAQTEAFZZZONMJ [ 6 ] <= $FOCOFQYNAZZDTMNK [ 0 ] [ 3 ] ? $VBTVZVORQTC : 4 ) 

    $NWBSM = $VAR_2745 [ $JIQBD ] 

    $NWBSM -= $JIQBD 

    $NWBSM += 14431 

    $NWBSM = $IGFABA_UFUGKAMKV ( $NWBSM , $JIQBD ) 

    $NWBSM = $RM_I2U_3RPS4_I5Y0IIHAZ1_6 ( $NWBSM , 65535 ) 

    $VAR_2745 [ $JIQBD ] = $IDBABKRDVSBFUNLRSLIOXWAD ( $NWBSM ) 

  Next 

  $VAR_2745 = $WWXHKDX ( $VAR_2745 , "" ) 

  Return $VAR_2745 

EndFunc

Still, we are able to learn about the loaded modules and WinAPI wrappers: 

// Some of the kernel32.dll module’s wrappers

Func _WINAPI_ASSIGNPROCESSTOJOBOBJECT ( $HJOB , $HPROCESS ) 

  Local $ACALL = DllCall ( "kernel32.dll" , "bool" , "AssignProcessToJobObject" , "handle" , $HJOB , "handle" , $HPROCESS ) 

  If @error Then Return SetError ( @error , @extended , False ) 

  Return $ACALL [ 0 ] 

EndFunc 

Func _WINAPI_ATTACHCONSOLE ( $IPID = + 4294967295 ) 

  Local $ACALL = DllCall ( "kernel32.dll" , "bool" , "AttachConsole" , "dword" , $IPID ) 

  If @error Then Return SetError ( @error , @extended , False ) 

  Return $ACALL [ 0 ] 

EndFunc 

Func _WINAPI_ATTACHTHREADINPUT ( $IATTACH , $IATTACHTO , $BATTACH ) 

  Local $ACALL = DllCall ( "user32.dll" , "bool" , "AttachThreadInput" , "dword" , $IATTACH , "dword" , $IATTACHTO , "bool" , $BATTACH ) 

  If @error Then Return SetError ( @error , @extended , False ) 

  Return $ACALL [ 0 ] 

EndFunc 

Func _WINAPI_CREATEEVENT ( $TATTRIBUTES = 0 , $BMANUALRESET = True , $BINITIALSTATE = True , $SNAME = "" ) 

  If $SNAME = "" Then $SNAME = Null 

  Local $ACALL = DllCall ( "kernel32.dll" , "handle" , "CreateEventW" , "struct*" , $TATTRIBUTES , "bool" , $BMANUALRESET , "bool" , $BINITIALSTATE , "wstr" , $SNAME ) 

  If @error Then Return SetError ( @error , @extended , 0 ) 

  Local $ILASTERROR = _WINAPI_GETLASTERROR ( ) 

  If $ILASTERROR Then Return SetExtended ( $ILASTERROR , 0 ) 

  Return $ACALL [ 0 ] 

EndFunc 

Func _WINAPI_CREATEJOBOBJECT ( $SNAME = "" , $TSECURITY = 0 ) 

  If Not StringStripWS ( $SNAME , $STR_STRIPLEADING + $STR_STRIPTRAILING ) Then $SNAME = Null 

  Local $ACALL = DllCall ( "kernel32.dll" , "handle" , "CreateJobObjectW" , "struct*" , $TSECURITY , "wstr" , $SNAME ) 

  If @error Then Return SetError ( @error , @extended , 0 ) 

  Return $ACALL [ 0 ] 

EndFunc 

Func _WINAPI_CREATEMUTEX ( $SMUTEX , $BINITIAL = True , $TSECURITY = 0 ) 

  Local $ACALL = DllCall ( "kernel32.dll" , "handle" , "CreateMutexW" , "struct*" , $TSECURITY , "bool" , $BINITIAL , "wstr" , $SMUTEX ) 

  If @error Then Return SetError ( @error , @extended , 0 ) 

  Return $ACALL [ 0 ] 

EndFunc 

Several WinAPI wrappers may potentially participate in attacks for further system infection, because it’s the Autolt scrip that prepares the environment and control handover. 

Key function calls 

This combination of functions looks suspicious and hints at cross-process manipulations: 

kernel32.GetProcAddress — Dynamic function resolution 

kernel32.CreateFileW — Working with files 

kernel32.CreateProcessW — Creating processes 

kernel32.CreateMutextW — Creating mutexes 

kernel32.OpenProcess — Opening process descriptors 

kernerl32.ReadProcessMemory — Reading the memory of other processes 

kernerl32.DuplicateTokenEx — Duplicating security tokens 

kernelbased.AdjustTokenPriviliges — Manipulating the privileges 

kernel32.WriteFile — Writing into files

Since full-scale deobfuscation would take up too much time, let’s switch to dynamic analysis for now. 

Dynamic Analysis: Tracing Execution 

Let’s launch Autolt3.exe in x32dbg with breakpoints at functions that we’ve listed above, with the compiled script freely.a3x as a parameter. 

Soon after the initialization of Autolt3.exe, we see a kernel32.CreateProcessW call, where jsc.exe, the final link of our chain, is located. 

Note: this is a JScript.NET compilator, a part of an older .NET Framework. What’s unusual is that no extra data is transmitted to lpCommanLine. 

Also, there’s a CREATE_SUSPENDED flag in dwCreationFlags, which points to an uncommon use of jsc.exe. But how does it get the payload? 

The next string of calls reveals this: 

• kernel32.CreateProcessW creates the jsc.exe process flagged as CREATE_SUSPENDED. 

• kernel32.GetThreadContext delivers registries — the context of the main flow. This is typical for the preparation to process hollowing. 

• kernel32.VirtualAllocEX allocates a 0x3B000-sized memory area in jsc.exe process with MEM_COMMIT | MEM_RESERVE flags and PAGE_EXECUTE_READWRITE protection. This allows you to place and launch any code. 

To confirm this and extract the key module, let’s keep tracing the malware. The next critical call is kernel32.WriteProcessMemory. Among its arguments is a pointer to a buffer with loaded data, featuring familiar PE Magic and DOS Stub signatures. This clearly means that a PE file is injected into the jsc.exe process. 

At this stage, we can safely dump a clean binary from the memory. 

The payload is revealed, but we continue unraveling the entire chain until the final call — kernel32.ResumeThreat. This will help us make sure that the malware doesn’t do anything extra, like embedding another hidden process, before the control handover.  

The next critical step is the call of kernel32.ReadProcessMemory. At this stage, the threat obtains a pointer to the PEB (Process Environment Block) structure, from which it extracts a PEB.ImageBaseAddress (base load address). This address is further rewritten to the injected PE module. That’s crucial for standard loading mechanisms of Windows, including early ntdll.LdrInintializeThunk initialization, as this allows for the correct processing of import tables, relocating, and restoring of the image’s data. 

After this, kernel32.WriteProcessMemory is called, which completes the stage of replacing the base address in the PEB structure. 

Next, kernel32.SetThreadContext is invoked, almost finalizing the process hollowing. At this stage, the malware writes a pointer to the entry point of the injected module into the EAX register. 

After the call to kernel32.ResumeThread, control is handed over to ntdll.LdrInitializeThunk, which performs loader initialization and prepares the process execution environment. 

Once initialization is complete, ntdll.LdrInitializeThunk calls ntdll.NtContinue, restoring the execution context. 

As a result, the execution continues from the address stored in the EIP register. This is the beginning of the ntdll.RtlUserThreadStart procedure, which places the entry point from the EAX register onto the stack in accordance with the __stdcall calling convention and then hands over control to ntdll.__RtlUserThreadStart. 

Notably, this is not a common process hollowing. The regular method includes the extraction of the original memory area via NtUnmapViewOfSection. But in CastleLoader’s case, the malware dismisses this step intentionally. 

To monitoring tools like System Informed, the process doesn’t look off. It’s also not a part of an event chain known to EDR. 

This decreases the probability of detection without disrupting the processing of all tables and structures, ensuring normal functioning of the injected module. 

Preliminary Results 

The original Inno Setup installer turned out to be a container with a set of auxiliary files, among which the AutoIt3.exe + freely.a3x combination played a key role. We were able to extract and partially decompile the AutoIt script; however, most of its logic was heavily obfuscated and consisted of numerous wrappers around the WinAPI. 

Static analysis showed that the script prepares the environment and launches the next stage, while dynamic analysis confirmed that after jsc.exe is started, one of the process hollowing techniques is executed: another executable module is injected into the process’s address space. 

As a result, we discovered a fully functional PE file — the main CastleLoader module —  inside the process and successfully dumped it for further analysis. 

Such a sophisticated multi-stage execution chain was not implemented merely to complicate analysis, but specifically as an attempt to conceal the execution of the main payload from detection mechanisms. Using Inno Setup as a container, an AutoIt script as an intermediate layer, and process hollowing over jsc.exe, allows CastleLoader to distribute across several components that appearbenign at first glance. 

After the loader completes its execution, the files extracted by the Inno Setup installer remain on the disk. This may either be a deliberate attempt to mimic the normal behavior of legitimate software, which often leaves installation artifacts behind, or simply an implementation flaw. Given the relative novelty of the malware family, it’s probably the latter.  

This execution model reduces the likelihood of detection, as each individual stage appears legitimate, and the final payload only manifests in memory after the controlled process has been altered. As a result, static signatures, simple behavioral heuristics, and process monitoring systems become ineffective. A fully functional malicious module exists only at runtime, and only within an already modified process. 

Static signatures, simple behavioral heuristics, and process monitoring systems become ineffective 

Going Back to Static Analysis 

After uploading the memory dump to Ghidra, let’s start the analysis of its execution context. Right after opening the dump we see a kernel32.MessageBoxW call, which displays a fake error message: “System Error. The program can’t start because VCRUNTIME140.dll is missing from your computer. Try reinstalling the program to fix this problem.” 

After that, the execution of malicious code continues. 

During the analysis, we can see functions with unclear values. By studying their references, we see that they are actively called throughout the program’s execution. 

In FUN_00e469f0, the first argument of the function is a pointer to the start of the PE module. At first, the value is dereferenced and checked for a DOS heading 0x5A4D (“MZ”). This is followed by NT heading’s validation and decomposition of PE’s key structures. 

The function manually gets access to the export table, allowing for a rewrite of the basic module address (IMAGE_DOC_HEADER*). Then each exported character goes through an embedded hash function, while the calculated hash is compared to the initial value.  

Since we now know the origin of each digest and the way the function resolves the required APIs by hash, we can gather a set of potentially used network functions, run them through the hashing algorithm, and generate an enumeration (enum) for Ghidra. 

Using the script, we automatically replaced all hashes with their corresponding function names — the result can be seen in the Equates Table. Each hash is now tied with a readable API name, along with the number of cross-references to it. 

This also makes it easy to track all calls of these functions via the References section, where for each usage point there’s a reference to the corresponding API address. 

After generating the enum and substituting API names in the Equates Table, we see that the binary uses WINHTTP.WinHttpOpen. Cross-references to the corresponding hash prove that. We annotated a function with this call to make it easier to follow the logic. Then, by examining the cross-references to this function, we can move to its caller — the point where the HTTP session setup begins. 

While examining the HTTP connection’s initialization stage, we identified a function that returns a pointer to the data structure used as the initial configuration for the network logic. The format of this structure isn’t clear; but the fact that it’s there suggests the presence of a dedicated procedure responsible for creating and populating the configuration structure. 

We annotated several references around the returned pointer and proceeded to analyze the function that forms the configuration structure. This is done to restore its components and understand which parameters are used for network connection. 

Several nested functions lead us to a large-scale procedure, during which the configuration data is prepared. Its values aren’t static strings, but a mass of encrypted bytes packaged into DWORDs with two UTF-16LE characters and placed right on the stack. This data is postprocessed with a simple bit-by-bit transformation into string buffers. 

The temporary buffers are then passed to UniStr::Copy and pasted into fixed global addresses. All of these addresses are laid out sequentially in .data sections, effectively forming a single contiguous configuration block. 

At the end, the function returns the address of the first element (0xE67830), allowing the entire data set to be used as an array or a structure with fixed offsets. 

An example of a decryption algorithm 

input[8] = 0x67; 

input[9] = 0x4a; 

input[10] = 0xda; 

input[0xb] = 0xb6; 

step = 0; 

input[0xc] = 99; 

input[0xd] = 0x7d; 

input[0xe] = 0xa0; 

input[0xf] = 0xe4; 

input[0x10] = 0x31; 

input[0x11] = 0x62; 

input[0x12] = 0x87; 

input[0x13] = 0xa7; 

input[0x14] = 0x62; 

input[0x15] = 0x49; 

input[0x16] = 0x98; 

input[0x17] = 0x98; 

input[0x18] = 0x6c; 

input[0x19] = 0x6d; 

input[0x1a] = 0xbf; 

input[0x1b] = 0xaa; 

input[0x1c] = 0; 

do { 

  output[step + 8] = (ushort)(byte)(&key)[step & 3] ^ input[step + 8]; 

  output[step + 9] = (ushort)(byte)(&key)[step + 1 & 3] ^ input[step + 9]; 

  output[step + 10] = (ushort)(byte)(&key)[step + 2 & 3] ^ input[step + 10]; 

  step = step + 3; 

} while (step < 0x15); 

UniStr::Copy(&DAT_00e67848,(short *)(output + 8)); 

// In this fragment, there’s a small static block of data (byte array) formed. 

// Then, bit-by-bit, it’s decrypted by undergoing XOR operation with a cyclic one-table key. 

// Decrypted bytes are extended to UTF-16LE characters and written into an exit buffer, which is then pasted into the global memory region 

// via UniStr::Copy. 

// Basically, this is a simple custom decryption of strings using fixed bytes arrays and cyclic XOR masking by index with transformation to Unicode.

Building a Custom Parser 

After manually decrypting several strings, we realized that the process could be automated. The extraction logic used by CastleLoader is known: it has a single UTF-16LE DWORD pattern, loop construct, and fixed addresses, from which the XOR bytes are taken. That’s enough to identify the repeating code fragments and write a Python script that extracts all strings from the dump in a single pass. 

Parser’s results 

E32E6D: %s/settings/%s  

E33F4C: windows_version  

E3417F: machine_id  

E33D70: access_key  

E35E40: %s/tasks/complete/id/%lu  

E37732: http://94[.]159[.]113[.]32/service (C2)  

E377D2: gM7dczM61ejubNuJljRx (UserAgent)  

E378A8: N3sBJNQKOyBSqzOgQSQVf9 (Mutex)  

E3F4E9: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36

… and so on. 

The analysis of the configuration function was the right call. We ended up with the entire strings array used by CastleLoader. As a result, we get the published script. 

Most importantly, the resulting strings feature the very C2 address which we saw in the sandbox analysis. Now it’s extracted not as a secondary effect of network activity, but as a part of malware configuration. This decisively confirms its role and proves that retrieved IOCs are reliable for detection and analysis. 

This decisively confirms its role and proves that retrieved [sandbox] IOCs are reliable for detection and analysis. 

Final Observations 

Since we wanted to demonstrate the entire analysis process from start to finish, we deliberately followed the extended analysis path, from coming up with hypotheses to testing and adjusting them. In practice, many of these stages could have been skipped. 

ANY.RUN provides sufficiently detailed telemetry to significantly shorten the analysis. 

ANY.RUN provides sufficiently detailed telemetry to significantly shorten the analysis. For example, we didn’t have to investigate the Inno Setup module, since the sample did not remove the extracted files afterwards. 

The final process could have been dumped immediately, too, to bypass the intermediate stages, as it was the only one that actually interacted with the network and generated traffic. 

Nevertheless, the full walkthrough proved valuable: it allowed us to reconstruct the entire execution chain, understand the loader’s internal logic, and verify that the extracted data really indicatesCastleLoader’s presence. This approach gave us not only the final set of IOCs, but also an understanding of the mechanisms behind them. 

About ANY.RUN 

ANY.RUN is a leading provider of interactive malware analysis and threat intelligence solutions trusted by security teams worldwide. The platform combines real-time sandboxing with a comprehensive intelligence ecosystem, including Threat Intelligence Feeds, TI Lookup, and public malware submissions. 

More than 500,000 security analysts and 15,000 organizations rely on ANY.RUN to accelerate investigations, validate TTPs, collect fresh IOCs, and track emerging threats through live, behavior-driven analysis. 

By giving defenders an interactive, second-by-second view of malware execution, ANY.RUN enables faster detection, better-informed decisions, and a stronger overall security posture. 

Discover how ANY.RUN can enhance your SOC — start your 14-day trial today. 

Appendix 1: IOCs 

Analyzed Files 

Network Indicators 

C2 Server 

• 94[.]159[.]113[.]32 

HTTP Request 

• http://94[.]159[.]113[.]32/service 

Mutex 

• N3sBJNQKOyBSqzOgQSQVf9 

User-Agents 

• gM7dczM61ejubNuJljRx 

• Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36 

YARA Rules 

rule CastleLoader { 

    meta: 

        author = "ANY.RUN" 

        date = "2025-12-02" 

        description = "Identifies CastleLoader malware samples" 

        threat = "CastleLoader" 

    strings: 

        $p1 = { 44 a0 2d 39 } //CreateMutexW 

        $p2 = { 82 06 d7 4e } //WinHttpOpen 

        $p3 = { 81 03 08 6f } //WinHttpConnect 

        $p4 = { 18 7b d4 2e } //WinHttpOpenRequest 

        $p5 = { e4 f4 96 33 } //WinHttpReceiveResponse 

        $p6 = { d8 da 54 96 } //ShellExecuteW 

        $p7 = { 5f 9e 43 16 } //GetUserNameW 

        $p8 = { b4 89 86 1b } //GetComputerNameW 

condition: 

        all of ($p*) 

}

MITRE ATT&CK Techniques 

The post CastleLoader: A Deep Dive into Stealthy Loader Targeting Government Sector  appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

Our experts have detected a new wave of malicious emails targeting Russian private-sector organizations. The goal of the attack is to infect victims’ computers with an infostealer. This campaign is particularly noteworthy because the attackers tried to disguise their activity as the operations of legitimate software and traffic to the ubiquitously-used state and municipal services website.

How the attack begins

The attackers distribute an email containing a malicious attachment disguised as a regular PDF document. In reality, the file is an executable hiding behind a PDF icon; double-clicking it triggers an infection chain on the victim’s computer. In the campaign we analyzed, the malicious files were named УВЕДОМЛЕНИЕ о возбуждении исполнительного производства (NOTICE of Initiation of Enforcement Proceedings) and Дополнительные выплаты (Additional Payouts), though these are probably not the only document names the attackers employ to trick victims into clicking the files.

Technically, the file disguised as a document is a downloader built with the help of the .NET framework. It downloads a secondary loader that installs itself as a service to establish persistence on the victim’s machine. This other loader then retrieves a JSON string containing encrypted files from the command-and-control server. It saves these files to the compromised computer in C:ProgramDataMicrosoft DiagnosticTasks, and executes them one by one.

Example of the server response

The key feature of this delivery method is its flexibility: the attackers can provide any malicious payload from the command-and-control server for the malware to download and execute. Presently, the attackers are using an infostealer as the final payload, but this attack could potentially be used to deliver even more dangerous threats – such as ransomware, wipers, or tools for deeper lateral movement within the victim’s infrastructure.

Masking malicious activity

The command-and-control server used to download the malicious payload in this attack was hosted on the domain gossuslugi{.}com. The name is visually similar to Russia’s widely used state and municipal services portal. Furthermore, the second-stage loader has the filename NetworkDiagnostic.exe, which installs itself in the system as a Network Diagnostic Service.

Consequently, an analyst doing only a superficial review of network traffic logs or system events might overlook the server communication and malware execution. This can also complicate any subsequent incident investigation efforts.

What the infostealer collects

The attackers start by gathering information about the compromised system: the computer name, OS version, hardware specifications, and the victim’s IP address. Additionally, the malware is capable of capturing screenshots from the victim’s computer, and harvesting files in formats of interest to the attackers (primarily various documents and archives). Files smaller than 100MB, along with the rest of the collected data, are sent to a separate communication server: ants-queen-dev.azurewebsites{.}net.

File formats of interest to the attackers

The final malicious payload currently in use consists of four files: one executable and three DLL libraries. The executable enables screen capture capabilities. One of the libraries is used to add the executable to startup, another is responsible for data collection, while the third handles data exfiltration.

During network communication, the malware adds an AuthKey header to its requests, which contains the victim’s operating system identifier.

Code snippet: a function for sending messages to the attackers’ server

How to stay safe

Our security solutions detect both the malicious code used in this attack and its communication with the attackers’ command-and-control servers. Therefore, we recommend using reliable security solutions on all devices used by your company to access the internet. And to prevent malicious emails from ever reaching your employees, we also advise deploying a security solution at the corporate email gateway level too.

Kaspersky official blog – ​Read More