Cisco Talos is closely tracking UAT-8837, a threat actor we assess with medium confidence is a China-nexus advanced persistent threat (APT) actor based on overlaps in tactics, techniques, and procedures (TTPs) with those of other known China-nexus threat actors.
Based on UAT-8837’s TTPs and post-compromise activity Talos has observed across multiple intrusions, we assess with medium confidence that this actor is primarily tasked with obtaining initial access to high-value organizations.
Although UAT-8837’s targeting may appear sporadic, since at least 2025, the group has clearly focused on targets within critical Infrastructure sectors in North America.
After obtaining initial access — either by successful exploitation of vulnerable servers or by using compromised credentials — UAT-8837 predominantly deploys open-source tools to harvest sensitive information such as credentials, security configurations, and domain and Active Directory (AD) information to create multiple channels of access to their victims. The threat actor uses a combination of tools in their post-compromise hands-on-keyboard operations, including Earthworm, Sharphound, DWAgent, and Certipy. The TTPs, tooling, and remote infrastructure associated with UAT-8837 were also seen in the recent exploitation of CVE-2025-53690, a ViewState Deserialization zero-day vulnerability in SiteCore products, indicating that UAT-8837 may have access to zero-day exploits.
Post-compromise actions
UAT-8837 can exploit both n-day and zero-day vulnerabilities to gain access to target environments. Most recently, UAT-8837 exploited a ViewState Deserialization zero-day vulnerability in SiteCore products, CVE-2025-53690, to obtain initial access.
After UAT-8837 gains initial access, they begin conducting preliminary reconnaissance, leveraging the following commands:
ping google[.]com
tasklist /svc
netstat -aon -p TCP
whoami
quser
hostname
net user
The threat actor disables RestrictedAdmin for Remote Desktop Protocol (RDP) to obtain credentials for remoting into other devices:
A shell console may subsequently be opened via “cmd.exe” to conduct hands-on keyboard activity on the compromised endpoint. Multiple artifacts are then downloaded to the following directories which were extensively used for staging artifacts:
UAT-8837 may use a variety of tooling throughout the course of an intrusion. This variation in tooling may be because many of these tools are detected and blocked by most security products such as Cisco Secure Endpoint (CSE) which often leads the threat actor to cycle through different variants of the tools to find versions that are not detected.
GoTokenTheft
The GoTokenTheft utility is a tool for stealing access tokens. Written in GoLang and deployed at C:Users<user>Desktopgo.exe, it may be used to steal tokens to run commands with elevated privileges:
Earthworm is network tunneling tool that has extensively been used by Chinese-speaking threat actors in intrusions to expose internal endpoints to attacker-owned remote infrastructure. UAT-8837 deploys multiple versions of Earthworm to determine which are not detectable by endpoint protection products. The undetected version is then used to create a reverse tunnel to attacker-controlled servers, as seen in the commands below:
UAT-8837 deploys DWAgent, a remote administration tool, to make it easier to access the compromised endpoint and drop additional malware to the system:
Per Talos’ observations, UAT-8837 downloads SharpHound with the intention to collect Active Directory information:
C:WindowsTempSharpHound.exe
Impacket
UAT-8837 makes several attempts to download Impacket-based binaries to use in their operations:
C:WindowsTempwec.ico
When Impacket is detected and blocked, Invoke-WMIExec is downloaded to run commands with elevated privileges:
C:WindowsTempInvoke-WMIExec.ps1
GoExec
In one intrusion, after cycling through a number of tools, UAT-8837 deployed GoExec, a GoLang-based remote execution tool to execute commands on other connected remote endpoints within the victim’s network:
It is worth noting here that the usage of GoExec was likely an on-the-fly decision by the operator, necessitated by the constant detection and blocking of the threat actors tooling by CSE.
The threat actor also attempted to download and execute SharpWMI in the compromised environment, which was again detected by CSE:
C:WindowsTemps.ico
Rubeus
Rubeus, a C# based toolset for Kerberos abuse may also be deployed:
C:WindowsTempr.ico
C:WindowsTemplo.txt
Certipy
UAT-8837 also deploys Certipy, a tool for AD discovery and abuse, to:
C:WindowsTempCertipy.exe
Hands-on-keyboard activity
UAT-8837 may run a series of commands during the intrusion to obtain sensitive information, such as credentials from victim organizations:
findstr /S /l cpassword [\]policies*.xml
The system’s security configuration is also exported using secedit:
secedit /export /cfg C:windowstemppol.txt
Windows Local security policies extracted via secedit include password policies, user rights and audit settings. This information may be valuable to adversaries who seek to evaluate an endpoint’s security posture including network security settings.
In one victim organization, UAT-8837 exfiltrated DLL-based shared libraries related to the victim’s products, raising the possibility that these libraries may be trojanized in the future. This creates opportunities for supply chain compromises and reverse engineering to find vulnerabilities in those products.
Domain reconnaissance
The net commands typically used to query domain groups and users are:
net group domain admins /domain
net localgroup administrators /domain
net group <name> /domain
net user <user> <password> /domain
net user <user> /domain
net accounts /domain
net user <user> /domain
nltest /DCLIST:<domain>
nslookup <subdomina>.<domain>
The setspn command is used to list and query Service Principal Names (SPN) data from Active Directory:
setspn -L
setspn -Q */*
Active Directory reconnaissance
UAT-8837 deploys a combination of tools to perform AD reconnaissance in the compromised environment. These tools include SharpHound and Certipy. The threat actor also uses the Windows-native tool “setspn” to query for AD data. However, UAT-8837 also brings their own living-off-the-land (LOTL) tooling. In one intrusion, the actor deployed dsget and dsquery to query for specific properties in the AD:
dsquery.exe user -limit 0
dsquery.exe user -name <name>
dsget user -samid -display -email -upn
dsget.exe user -samid -display -email -upn
dsquery.exe user -samid <id>
dsget.exe user -display -email -upn
dsquery.exe user -name admin
dsget.exe user CN=<id>,OU=ServiceAccounts,OU=Production,DC=prod,DC=<domain>,DC=com -samid -display -email -upn
dsget.exe user CN=<id>,OU=ServiceAccounts,OU=Production,DC=prod,DC=<domain>,DC=com -upn
dsget.exe user CN=<id>,OU=ServiceAccounts,OU=Production,DC=prod,DC=<domain>,DC=com –memberof
dsget.exe user CN=<id>,OU=ServiceAccounts,OU=Production,DC=prod,DC=<domain>,DC=com –disabled
dsquery * DC=prod,DC=<domain>,DC=com -filter (objectClass=user) -attr * -limit 0
Backdoored user accounts
The threat actor created user accounts to open up another channel of access to the compromised environment:
net user <user> <password> /add /domain
In another instance, UAT-8837 added an existing user account to local groups:
net user <user>
net localgroup <group> <user> /add
Coverage
The following ClamAV signature detects and blocks this threat:
Win.Malware.Earthworm
The following Snort Rules (SIDs) detect and block this threat:
Snort 2 – 61883, 61884, 63727, 63728
Snort 3 – 300585, 63727, 63728
Indicators of compromise (IOCs)
The IOCs for this threat are also available at our GitHub repository here.
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2026-01-15 11:06:402026-01-15 11:06:40UAT-8837 targets critical infrastructure sectors in North America
In busy SOC environments, every minute spent waiting for threat validation slows containment and impacts response metrics. The ANY.RUN integration with Tines delivers trusted verdicts and enriched context in seconds to cut mean time to respond (MTTR) and keep investigations flowing without delays.
ANY.RUN X Tines Integration: Faster Triage with Behavior-Driven Context
The new integration lets your SOC team pull actionable verdicts and intel from Interactive Sandbox and Threat Intelligence Lookup straight into the Tines workflows you already use. Instead of jumping between different tabs to confirm behavior or collect indicators, analysts can validate alerts, prioritize critical events, and enrich incidents with behavioral intelligence without leaving the Tines interface.
It is available to all ANY.RUN customers with API access, including Enterprise Sandbox, TI Lookup Premium, and trial users. You can run everything through the Tines visual interface or make direct API calls if you prefer more flexibility.
The goal is simple: bring fast detonation results and fresh intelligence right into your workflow, so investigations keep moving without extra steps slowing you down.
Tines story automating URL analysis with ANY.RUN
The Difference You’ll See in Your SOC
The integration affects several parts of the investigation workflow, improving both speed and decision quality:
Reduce mean time to respond (MTTR): Automate detonation and enrichment, so analysts get verdicts and IOCs within minutes, shortening investigation cycles and resolution times across the SOC.
Improve triage accuracy and cut false positives: Behavioral verification from ANY.RUN delivers ground truth for detections, helping the team focus on real threats and reduce wasted effort.
Handle more incidents without adding headcount: Routine analysis and enrichment run automatically in Tines, maintaining coverage during alert spikes while freeing analysts for complex cases.
Meet SLAs consistently as an MSSP: Automated sandboxing and enrichment help MSSPs deliver fast, quality services, and scale response capacity without extra integration overhead.
Combined, these improvements shorten detection‑to‑mitigation time from hours to minutes, lower analyst workload, and boost SOC throughput.
Speed up investigations inside Tines with ANY.RUN Scale response without adding headcount
ANY.RUN’s Interactive Sandbox integration with Tines brings live, behavior‑based malware analysis into your Tines workflows. Instead of relying on static detections or manual uploads, you get real‑time verdicts, IOCs, and behavioral data in the same environment that runs your automation.
Capabilities
Submit suspicious files or URLs from any Tines story for automatic detonation and observation.
Retrieve verdicts, IOCs, and full HTML reports as structured outputs.
Reuse sandbox results across workflows or forward them to SIEM/EDR platforms through API actions.
ANY.RUN sandbox verdict for a URL shown in Tines, including malicious activity detection and extracted IOCs
Example: Suspicious email attachments can be automatically sent for sandbox analysis. The resulting verdict and IOCs flow back to Tines, which then updates your SIEM or blocks the relevant indicators.
Benefits
Faster validation: Confirm if a file or link is malicious before escalation.
Consistent triage: Every sample is processed with the same standard, eliminating delays or missed steps.
Actionable context: Behavioral data and network activity indicators feed directly into response actions.
Threat Intelligence Lookup in Tines
ANY.RUN’s Threat Intelligence Lookup integration with Tines adds context‑rich intelligence to automated processes. Each time a new IP, domain, or hash appears, you can check it against ANY.RUN’s continuously updated database of recent malware activity to enrich your decisions.
Capabilities
Automatically perform lookups for IOCs inside any Tines story.
Retrieve brief overviews or full JSON data with reputation, threat family, and activity history.
Combine Lookup results with internal data sources to refine correlation and playbook logic.
TI Lookup results returned inside a Tines story, showing verdict, threat level, and IOC details
Example: When a newly observed IOC triggers an alert, Tines can automatically query TI Lookup for reputation data and campaign context, helping analysts decide whether to escalate or suppress the event.
Benefits
Higher detection fidelity: Real‑world sandbox intelligence helps distinguish live threats from noise.
Smarter prioritization: Know which IOCs are still active and which are already dormant.
Efficient workflow chaining: Lookup results are ready to power next‑step actions like blocking, reporting, or case validation.
ANY.RUN helps security teams understand threats faster and take action with confidence.
The solution is trusted by over 500,000 security professionals and more than 15,000 organizations across sectors where speed and accuracy define successful response.
ANY.RUN’s Interactive Sandbox lets teams safely run suspicious files and links, watch real behavior unfold, and confirm threats before they spread. Paired with Threat Intelligence Lookup and Threat Intelligence Feeds, it delivers the context needed to sort alerts, cut uncertainty, and stop advanced attacks earlier in the response cycle.
What problems does the ANY.RUN × Tines integration solve?
It removes the need to switch between tools to validate alerts. Sandbox results and TI Lookup context arrive directly inside your Tines stories, helping your team move investigations forward without stopping for manual checks.
What does ANY.RUN return to Tines after analysis?
You get verdicts, behavior summaries, IOCs, network activity, risk scores, and optional full HTML reports; all as structured outputs that Tines can use in later steps.
How fast do results come back?
Most verdicts return within minutes. ANY.RUN reveals the majority of malicious behavior in the first 60 seconds, so playbooks don’t stall waiting for enrichment.
Is the integration available for trial users?
Yes. Anyone with ANY.RUN API access, including trial users, can use the integration.
Will sandbox detonations slow down my playbooks?
No. Detonations run in parallel on ANY.RUN’s side, and Tines continues the story when the result is ready. Most verdicts return within minutes.
Can I use the output to update SIEM or EDR tools?
Yes. Tines can pass ANY.RUN results to your existing systems as part of automated response actions.
Does the integration support high-volume alerting?
Yes. It’s built to run reliably during spikes, so routine detonations and lookups continue without interruption.
Can I create custom workflows with the integration?
Absolutely. The prebuilt stories are only a starting point; you can adapt them to match your escalation rules, correlation logic, or existing playbooks.
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2026-01-15 09:06:412026-01-15 09:06:41Is it time for internet services to adopt identity verification?
Cisco Talos is kicking off the new year with a behind-the-scenes look at incident response through the eyes of Terryn Valikodath, Senior Incident Response Consultant at Talos. In this episode, Amy sits down with Terryn to explore the realities of a job that blends technical know-how with communication skills, proactive planning, and a passion for problem-solving. Terryn’s path to cybersecurity started with a fascination for criminal forensics and a knack for jailbreaking his family’s tech — interests that eventually steered him toward the fast-paced world of digital investigations.
Join us as Terryn shares what keeps him motivated during high-pressure incidents, the satisfaction he finds in teaching others during cyber range trainings, and the creative outlets that help him recharge
Amy Ciminnisi: Can you tell us a little bit about what you do here in Talos?
Terryn Valikodath: Absolutely. I’m a Senior Incident Response Consultant, so essentially an incident responder. The unique thing about our team is that we handle both proactive and reactive work. On the proactive side, we help develop incident response plans, run tabletop exercises, threat hunts, training, and similar tasks. On the reactive side, we step in when an organization experiences a security event, investigate, and provide recommendations to get them back up and running. It’s rewarding to see both sides of the work.
AC: On my end, I’m always amazed at all the different services Cisco Talos Incident Response provides. Is it difficult to balance them, and is there a part of the job you enjoy most?
TV: It definitely takes some getting used to since most cybersecurity roles focus on either proactive or reactive tasks, not both. But it’s helpful, because our direct experience informs the advice we give. For example, when we develop an incident response plan, we can reference real situations we’ve handled. That builds trust with customers. My favorite aspect is running cyber range trainings — a three-day course where we teach technical folks how to handle incident response. I’m passionate about teaching, both externally and within our team. I enjoy demystifying the field and showing people that it’s about dedication and learning, not just being a specialist.
Want to see more? Watch the full interview, and don’t forget to subscribe to our YouTube channel for future episodes of Humans of Talos.
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2026-01-14 11:06:442026-01-14 11:06:44Brushstrokes and breaches with Terryn Valikodath
Manufacturing companies have quietly become one of the most hunted species in the modern threat landscape. Not because they are careless, but because they are operationally critical, geographically distributed, and often rely on complex IT and OT environments that attackers love to probe.
Key Takeaways
Manufacturing is among the top industries targeted by ransomware groups and advanced campaigns, often with region-specific lures.
Attackers continue to favor invoice-themed and supplier-related emails, carefully localized to increase trust and click-through rates in manufacturing environments.
Files detected by only one or two vendors often indicate fresh attacks designed to bypass traditional defenses, making early discovery critical.
The reuse of WebDAV, known vulnerabilities, and familiar RAT families across cases helps analysts distinguish structured campaigns from background noise.
Filtering threats by sector and country dramatically improves relevance, allowing teams to focus on attacks that are most likely to impact their business.
By identifying campaigns before alerts trigger, organizations can shorten dwell time and prevent disruptions that are especially costly for manufacturing operations.
By correlating industry, geography, techniques, and indicators, Threat Intelligence Lookup helps manufacturing companies uncover active campaigns early and turn threat intelligence into a preventive control, not just a reference source.
The Threat Landscape: Manufacturing Under Siege
ANY.RUN‘s data, based on sandbox submissions of over 500K analysts and 15K SOCs, shows increased malicious activity against manufacturing companies. While this uptick aligns with patterns across other industries, manufacturing consistently shows slightly higher-than-average attack rates, confirming its status as a priority target.
Attacks on manufacturing companies vs attacks on other sectors
Top businesses operating in the industry rely on Threat Intelligence Lookup to track the latest attacks and campaigns conducted against manufacturing enterprises.
This enables SOC teams to timely update their defenses before the attackers have a chance to strike. By acting proactively, organizations are able to protect their infrastructure, prevent downtime, and avoid incident response costs.
Threat Hunting for a German Manufacturing Company
NOTE: This case study demonstrates how malware analysts use proactive threat hunting with ANY.RUN’s Threat Intelligence Lookup to identify and analyze real-world attacks targeting manufacturing companies, specifically focusing on a sophisticated campaign against German industrial firms.
(We have substituted the actual company’s name by a COMPANY_NAME placeholder.)
Let’s assume we are conducting continuous threat hunting for a manufacturing company based in Germany. Our objective is simple but critical: identify phishing emails as potential initial access vectors before they reach production systems.
Searching for phishing emails targeting German industry
With a 90-day analysis window, the search yielded over 30 real-world cases representing potential intrusion attempts against organizations similar to ours.
Reduce operational risk with proactive visibility
Update defense with live attack data from 15K SOCs
One case stood out for its sophistication and targeted approach.
A malware analysis session in ANY.RUN’s sandbox
The attack leveraged the brand of a popular software provider in Germany, indicating specific targeting of German companies. What made this case particularly noteworthy was the combination of:
Exploitation of a recently disclosed vulnerability,
Simultaneous deployment of two Remote Access Trojans (RATs): AsyncRAT and XWorm,
Highly convincing social engineering tactics.
Enrich indicators with live attack data in TI Lookup
Speed up triage & response with critical context
The attack targeted a German construction and engineering services company through a carefully crafted phishing email:
Sender Spoofing:
Display name: “COMPANY_NAME eG” (legitimate company name),
Actual sender: g.bader-gmbh@gmx[.]de (German domain for additional authenticity).
Phishing mail: real company sender name, non-related local email address
Email Content:
Designed as an invoice notification from COMPANY_NAME,
Included document number and date for legitimacy,
Professional design increasing click-through probability,
Malicious link embedded in the message.
Phishing email text and malicious link
Clicking the link redirected victims to Dropbox, where a file named “COMPANY_NAME -Rechnung Nr. 21412122025.pdf.zip” awaited download.
Obfuscation Techniques:
Double file extension (.pdf.zip) to disguise the true file type;
Archive contained “COMPANY_NAME-Rechnung Nr. 21412122025.pdf.url”, a shortcut file masquerading as a PDF;
Formatting designed to encourage victims to open the file
Archive containing malicious shortcut disguised as .pdf
Detection Evasion:
At the time of analysis, this file was flagged as malicious by only one vendor on VirusTotal. That low detection rate strongly suggests a fresh sample designed to bypass traditional security controls.
VirusTotal file analysis
The attack leveraged CVE-2024-43451, a vulnerability that enables automatic WebDAV connections without actually opening the .url file. During archive processing or interaction with the attachment, the system automatically connects to a remote resource.
Vulnerability exploit detected by ANY.RUN’s Sandbox
Malicious file analysis in the Sandbox
Execution Flow:
Opening the .url file from the ZIP archive;
Remote resource displays as a network directory;
Contains .lnk file disguised as a PDF;
Launching this file triggers subsequent attack stages;
This combination provides attackers with redundancy and persistence, increasing the chances of maintaining access to the victim’s environment.
Process Graph in the Sandbox shows trojan deployment
Notably, similar WebDAV-based techniques exploiting this vulnerability have been observed in APT activity, confirming that this is not opportunistic noise but a well-established attack pattern.
Expanding the Investigation: Campaign Scope Analysis
Identifying one attack is only the beginning. The real value of proactive threat hunting lies in understanding scale, patterns, and relevance.
Using Threat Intelligence Lookup, we pivot from the original case to search for related activity: emails and PDFs containing“COMPANY_NAME” in file names; hashes associated with the malicious documents.
Searching for similar malware samples via TI Lookup
Query Results:
35 analyses matching the specified parameters;
Almost all of them uploaded starting November 4, confirming recent activity;
Multiple instances showing Dropbox connections for ZIP archive delivery;
Generated indicators suitable for enriching detection systems.
When we analyze the industry and geography breakdown, the picture becomes even clearer. Manufacturing remains one of the top targeted industries, with nearly two-thirds of executions occurring in Germany. The same core techniques appear repeatedly: CVE-2024-43451, WebDAV abuse, AsyncRAT, and XWorm.
TI Lookup results Overview: targeted industries and locations; associated malware families
Hash search of the PDF file employed in the attack shows 40% of submissions from manufacturing industry and 100% of uploads by ANY.RUN’s Sandbox users from Germany:
Since AsyncRAT and XWorm are widely used, we narrow our focus to the vulnerability itself. A lookup for CVE-2024-43451 shows that most samples originate from the EU, with Germany accounting for roughly half of them. Manufacturing once again appears among the primary targeted industries. WebDAV connections are present in all samples, indicating standardized attack logic.
Search by the vulnerability’s name returns sandbox analyses tagged WebDAV
This level of repetition is exactly what threat hunters look for. It provides solid arguments to prioritize the threat, enrich internal detection systems with relevant indicators, and proactively hunt for similar behavior in logs, email gateways, and network traffic.
Discovering Industry-Specific Patterns
Threat Intelligence Lookup also allows us to search for malicious activity tied to industry-specific domain patterns. By querying domains containing fragments like “manufactur” and filtering for confirmed malicious activity, we uncover more than 100 sandbox analyses and dozens of suspicious domains.
Explore industry-specific threats and gather indicators in TI Lookup
These findings help extend detection beyond known campaigns and uncover infrastructure that may be reused in future attacks against manufacturing organizations.
Key Findings and Implications
This case clearly shows that attacks using COMPANY_NAME-themed lures, WebDAV and CVE-2024-43451 abuse remain highly relevant for manufacturing companies, especially in Germany. More importantly, it demonstrates how proactive threat hunting changes the security posture entirely.
Instead of reacting to alerts after compromise, malware analysts can:
Identify active campaigns targeting their industry and region;
Understand attacker techniques before they reach production;
Prioritize threats based on real-world repetition and relevance;
Feed high-confidence indicators into detection and prevention systems.
With ANY.RUN’s Threat Intelligence Lookup, threat intelligence becomes a living, searchable environment rather than a static feed. For manufacturing companies facing constant operational pressure, this proactive approach can mean the difference between uninterrupted production and costly downtime.
Stay Ahead of Attacks with ANY.RUN
ANY.RUN helps security teams move earlier in the attack lifecycle by combining real-time malware analysis with actionable threat intelligence.
With the Interactive Sandbox, analysts can safely execute suspicious files and instantly observe attacker behavior, techniques, and indicators to accelerate MTTD and MTTR.
Threat Intelligence Feeds help your company catch new threats early
Threat Intelligence Feeds expand threat coverage with verified malicious network IOCs from real-time attacks on 15K+ orgs. Delivered instantly from ANY.RUN’s sandbox in flexible STIX/TAXII for seamless SIEM/SOAR integration.
TI Feeds empower SOC teams to ensure:
Early Detection: IOCs added right after live sandbox analysis—proactively spot new threats in your SOC before they hit.
Expanded Coverage: 99% unique indicators from global attacks (phishing, malware) that traditional feeds miss.
Reduced Workload: Malicious-only alerts, filtered to slash Tier 1 time on false positives.
For manufacturing facing targeted campaigns and high downtime costs, it provides visibility into real attacks as they unfold, allowing them to spot risks before production halts.
Expand threat coverage and speed up MTTR Integrate real-time intel from 15K SOCs
ANY.RUN supports more than 15,000 organizations worldwide, including leaders in finance, healthcare, telecom, retail, and tech, helping them strengthen security operations and respond to threats with greater confidence.
Designed for speed and visibility, the solutions provide interactive malware analysis and live threat intelligence, giving SOC teams instant insight into attack behavior and the context needed to act faster.
1. Why are manufacturing companies frequently targeted by cybercriminals?
Manufacturing organizations combine high operational impact, complex IT and OT environments, and tight downtime tolerance. This makes them attractive targets for ransomware groups and espionage-driven campaigns seeking fast leverage.
2. What role does phishing play in attacks on manufacturing companies?
Phishing remains one of the most common initial access vectors. Attackers often use localized and industry-specific lures, such as invoices or supplier documents, to increase credibility and user interaction.
3. What is proactive threat hunting and how does it differ from traditional detection?
Proactive threat hunting focuses on identifying active or emerging attack patterns before alerts are triggered. Instead of waiting for detections, analysts search threat intelligence data for techniques, indicators, and campaigns relevant to their industry and region.
4. Why is industry- and region-specific threat intelligence important?
Threats are rarely random. Campaigns are often tailored to specific countries, languages, and industries. Filtering threat intelligence by industry and geography helps analysts focus on the most realistic risks to their organization.
5. What makes vulnerabilities like CVE-2024-43451 especially dangerous?
Such vulnerabilities enable stealthy execution paths and are often abused before widespread detection signatures exist. Their repeated appearance across campaigns makes them strong indicators of active attacker playbooks.
6. How can malware analysts use threat intelligence to prioritize threats?
By identifying recurring techniques, delivery methods, and malware families across multiple cases, analysts can distinguish isolated noise from systematic campaigns and prioritize threats that are most likely to impact their environment.
7. How does proactive threat hunting benefit manufacturing businesses?
It reduces dwell time, lowers the chance of operational disruption, and enables earlier defensive action. For manufacturing, where downtime equals financial loss, early visibility can prevent incidents rather than merely respond to them.
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.
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2026-01-14 09:06:392026-01-14 09:06:39How we set the standard for transparency and trust | Kaspersky official blog
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2026-01-14 06:06:412026-01-14 06:06:41Your personal information is on the dark web. What happens next?
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.
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.
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2026-01-13 22:06:372026-01-13 22:06:37Direct and reverse NFC relay attacks being used to steal money | Kaspersky official blog
Microsoft has released its monthly security update for January 2026, which includes 112 vulnerabilities affecting a range of products, including 8 that Microsoft marked as “critical”.
In this month’s release, Microsoft observed one of the included “important” vulnerabilities, CVE-2026-20805, as being exploited in the wild. Out of 8 “critical” entries, 6 are remote code execution (RCE) vulnerabilities in Microsoft Windows services and applications including Windows Local Security Authority Subsystem Service (LSASS), Microsoft Word, Microsoft Excel, and Microsoft Office. The two remaining “critical” entries are elevation of privilege (EoP) vulnerabilities affecting Windows Graphic Component and Windows Virtualization-Based Security (VBS) Enclave.
CVE-2026-20822 is a critical elevation of privilege vulnerability affecting Windows Graphic Component. This vulnerability is due to a use-after-free (UAF) bug that could enable an attacker to obtain SYSTEM privileges on affected systems if exploited. This vulnerability was issued a CVSS 3.1 base score of 7.8 and would require an attacker to successfully win a race condition to achieve successful exploitation. Microsoft has assessed that exploitation of this vulnerability is “less likely” and that it has not been publicly disclosed.
CVE-2026-20854 is a critical remote code execution vulnerability affecting Windows Local Security Authority Subsystem Service (LSASS). This vulnerability was issued a CVSS 3.1 base score of 7.5 and could enable an authorized attacker the ability to execute code on affected systems over a network. Successful exploitation of this vulnerability does not require elevated privileges. Microsoft has assessed that this vulnerability is “less likely” to be exploited and that it has not been publicly disclosed.
CVE-2026-20876 is a critical elevation of privilege vulnerability affecting Windows Virtualization-Based Security (VBS) Enclave. This vulnerability is due to a heap-based buffer overflow that could enable local privilege elevation if successfully exploited by an authorized attacker. Successful exploitation of this vulnerability could grant an attacker Virtual Trust Level 2 (VTL2) privileges on affected systems. This vulnerability was issued a CVSS 3.1 base score of 6.7 and has been assessed by Microsoft to be “less likely” to be exploited and has not been publicly disclosed.
CVE-2026-20944 is a critical remote code execution vulnerability affecting Microsoft Word. This vulnerability is due to an out-of-bounds read and could enable an attacker to execute arbitrary code on affected systems. To exploit this vulnerability, an attacker would need to convince victims to open a specially crafted malicious file on a vulnerable system. This vulnerability was issued a CVSS 3.1 base score of 7.8. Microsoft has assessed that this vulnerability is “less likely” to be exploited and has not been publicly disclosed.
CVE-2026-20952 and CVE-2026-20953 are critical remote code execution vulnerabilities affecting Microsoft Office. These vulnerabilities are due to user-after-free conditions and could enable an unauthorized attacker to execute arbitrary code on affected systems. To successfully exploit either of these vulnerabilities, an attacker would need to log on and run a specially crafted application or convince a victim to open a malicious file on affected systems. Both vulnerabilities were issued a CVSS 3.1 base score of 8.4. Microsoft has assessed that these vulnerabilities are “less likely” to be exploited and neither were publicly disclosed.
CVE-2026-20955 is a critical remote code execution vulnerability affecting Microsoft Excel. This vulnerability is due to an untrusted pointer reference and could be leveraged by an unauthorized attacker to execute arbitrary code on affected systems. To successfully exploit this vulnerability, an attacker would need to convince a victim to open a specially crafted malicious file. This vulnerability was issued a CVSS 3.1 base score of 7.8 and was assessed by Microsoft to be “less likely” to be exploited. Microsoft has also noted that this vulnerability has not been publicly disclosed.
CVE-2026-20957 is a critical remote code execution vulnerability affecting Microsoft Excel. This vulnerability is due to an integer underflow that could be leveraged by an unauthorized attacker to execute arbitrary code on affected systems. To successfully exploit this vulnerability, an attacker would need to convince a victim to open a specially crafted malicious file. This vulnerability was issued a CVSS 3.1 base score of 7.8 and was assessed by Microsoft to be “less likely” to be exploited. Microsoft has also noted that this vulnerability has not been publicly disclosed.
CVE-2026-20805 is an important information disclosure vulnerability affecting Desktop Window Manager. This vulnerability could allow for exposure of sensitive information on affected systems. This vulnerability was issued a CVSS 3.1 base score of 5.5 and was assessed by Microsoft to have already been previously exploited. Microsoft has noted that this vulnerability has not been publicly disclosed.
Talos would also like to highlight the following “important” vulnerabilities as Microsoft has determined that their exploitation is “more likely:”
CVE-2026-20816: Windows Installer Elevation of Privilege Vulnerability
CVE-2026-20817: Windows Error Reporting Service Elevation of Privilege Vulnerability
CVE-2026-20820: Windows Common Log File System Driver Elevation of Privilege Vulnerability
CVE-2026-20840: Windows NTFS Remote Code Execution Vulnerability
CVE-2026-20843: Windows Routing and Remote Access Service (RRAS) Elevation of Privilege Vulnerability
CVE-2026-20860: Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability
CVE-2026-20871: Desktop Windows Manager Elevation of Privilege Vulnerability
CVE-2026-20922: Windows NTFS Remote Code Execution Vulnerability
A complete list of all the other vulnerabilities Microsoft disclosed this month is available on its update page.
In response to these vulnerability disclosures, Talos is releasing a new Snort ruleset that detects attempts to exploit some of them. Please note that additional rules may be released at a future date, and current rules are subject to change pending additional information. Cisco Security Firewall customers should use the latest update to their ruleset by updating their SRU. Open-source Snort Subscriber Ruleset customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.
Snort 2 rules included in this release that protect against the exploitation of many of these vulnerabilities are: 65498, 65499, 65663-65676.
The following Snort 3 rules are also available: 301344, 301368-301374.
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2026-01-13 19:06:552026-01-13 19:06:55Microsoft Patch Tuesday for January 2026 — Snort rules and prominent vulnerabilities
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.
Prevent attacks by tapping into 99% unique IOCs Integrate TI Feeds for better proactive defense
The launch of CastleLoader sample in ANY.RUN. Suspicious processes and network activities detected
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).
CastleLoader installer analyzed in 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.
Files extracted from Inno Setup installer
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:
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.
A breakpoint at CreateProcessW function. A jsc.exe child process is created with CREATE_SUSPENDED flag
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.
A breakpoint at VirtualAllocEx. The memory area allocation in the child process with permission to launch (PAGE_EXECUTE_READWRITE)
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.
A breakpoint at WriteProcessMemory. Malicious PE image is written into the allocated memory area
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.
A breakpoint at ReadProcessMemory. Extraction of PEB.ImageBaseAddress of the child process to replace it with the base address of the injected PE
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.
A breakpoint at SetThreadContext, writing an EntryPoint of the injected module into EAX registry before renewing the flow
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
Dynamic analysis from ANY.RUN: Boost DR by 36%, cut MTTR by 21 minutes
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.
WinMain entry point in Ghidra decompilator. Early analysis of the malicious code’s structure
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.
GetProcAddressByHash function, dynamic resolution of API addresses by hash names
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.
Equates table. Correlation of hashes with names of imported WinAPI functions
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.
InitSession function – calling for WinHttpOpen for the initialization of a HTTP session
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.
GetMalwareConfig calling and configuration handover to InitSession for the establishment of the 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.
A function for getting the configuration — XOR decoding of configuration strings with a cyclic key at the stack
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.
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.
Detect any threat in under 60 seconds
Integrate ANY.RUN’s Sandbox in your SOC
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.
https://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.png00adminhttps://www.backbox.org/wp-content/uploads/2018/09/website_backbox_text_black.pngadmin2026-01-13 09:06:392026-01-13 09:06:39CastleLoader: A Deep Dive into Stealthy Loader Targeting Government Sector
