Is it time for internet services to adopt identity verification?
Should verified identities become the standard online? Australia’s social media ban for under-16s shows why the question matters.
WeLiveSecurity – Read More
Brushstrokes and breaches with Terryn Valikodath
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.
Cisco Talos Blog – Read More
German Manufacturing Under Phishing Attacks: Tracking a Stealthy AsyncRAT Campaign
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.
Top businesses operating in the industry rely on Threat Intelligence Lookup to track the latest attacks and campaigns conducted against manufacturing enterprises.
Accessing an up-to-date threat landscape for your industry requires just one search query:
The service instantly delivers actionable intelligence on the latest cyber threats targeting companies around the world.
Learn more about threat landscape tracking with TI Lookup →
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.
Using ANY.RUN’s Threat Intelligence Lookup, we build a focused query:
industry:”Manufacturing” AND filePath:”*.eml” AND not threatLevel:”info” AND submissionCountry:”DE”
With a 90-day analysis window, the search yielded over 30 real-world cases representing potential intrusion attempts against organizations similar to ours.
A Closer Look at One Real Attack
One case stood out for its sophistication and targeted approach.
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,
- Highly convincing social engineering tactics.
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).
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.
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
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.
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.
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.
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.
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.
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:
SHA256:”8af19a103fbab4d5a2b9f59098e78e61df1721508e2d148fe9ba2b29e72900ca”
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.
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.
domainName:”manufactur*” and threatLevel:”malicious”
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 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.
About ANY.RUN
ANY.RUN supports more than 15,000 organizations worldwide, including leaders in finance, healthcare, telecom, retail, and tech, helping them strengthen security operations and respond to threats with greater confidence.
Designed for speed and visibility, the solutions provide interactive malware analysis and live threat intelligence, giving SOC teams instant insight into attack behavior and the context needed to act faster.
Request a trial or quote for your company →
FAQ: Proactive Threat Hunting for Manufacturing
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 post German Manufacturing Under Phishing Attacks: Tracking a Stealthy AsyncRAT Campaign appeared first on ANY.RUN’s Cybersecurity Blog.
ANY.RUN’s Cybersecurity Blog – Read More
How we set the standard for transparency and trust | Kaspersky official blog
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
Your personal information is on the dark web. What happens next?
If your data is on the dark web, it’s probably only a matter of time before it’s abused for fraud or account hijacking. Here’s what to do.
WeLiveSecurity – Read More
Direct and reverse NFC relay attacks being used to steal money | Kaspersky official blog
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
Microsoft Patch Tuesday for January 2026 — Snort rules and prominent vulnerabilities
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.
Cisco Talos Blog – Read More
CastleLoader: A Deep Dive into Stealthy Loader Targeting Government Sector
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.
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
EndFuncStill, 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 filesSince 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
| Name | MD5 | SHA1 | SHA256 |
|---|---|---|---|
| 8b7c1657f4d5cf0cc82d68c1f1a385adf0de27d46fc544bba249698e6b427856.exe (Inno Setup Installer) | 9A0960C674378A049B8D9AD0E1C641C3 | 0580A364AB986B051398A78D089300CF73481E70 | 8B7C1657F4D5CF0CC82D68C1F1A385ADF0DE27D46FC544BBA249698E6B427856 |
| freely.a3x (AutoIt Script) | AFBABA49796528C053938E0397F238FF | DD029CD4711C773F87377D45A005C8D9785281A3 | FDDC186F3E5E14B2B8E68DDBD18B2BDA41D38A70417A38E67281EB7995E24BAC |
| payload.exe (CastleLoader Core Module) | 1E0F94E8EC83C1879CCD25FEC59098F1 | 9E11E8866F40E5E9C20B1F012D0B68E0D56E85B3 | DFAF277D54C1B1CF5A3AF80783ED878CAC152FF2C52DBF17FB05A7795FE29E79 |
Network Indicators
C2 Server
- 94[.]159[.]113[.]32
HTTP Request
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
| Tactic | Technique | Description |
|---|---|---|
| TA0002: Execution | T1059.010: AutoHotKey & AutoIT | Execution via AutoIt script (freely.a3x) |
| TA0005: Defense Evasion | T1027.002: Software Packing | Multi-stage: Inno Setup → AutoIt → PE injection |
| T1055.012: Process Hollowing | Process hollowing into jsc.exe | |
| T1106: Native API | API resolution via hash-based GetProcAddress | |
| T1140: Deobfuscate/Decode Files or Information | Runtime XOR-decoding of configuration strings (C2, User-Agent, Mutex); obfuscated AutoIt script | |
| TA0007: Discovery | T1082: System Information Discovery | Collects computer_name, windows_version, machine_id |
| TA0011: Command and Control | T1071.001: Web Protocols | HTTP communication to 94[.]159[.]113[.]32:80/service |
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
deVixor: An Evolving Android Banking RAT with Ransomware Capabilities Targeting Iran
Executive Summary
deVixor is an actively developed Android banking malware campaign operating at scale, targeting Iranian users through phishing websites that masquerade as legitimate automotive businesses.
Distributed as malicious APK files, deVixor has evolved from a basic SMS-harvesting threat into a fully featured Remote Access Trojan (RAT) that combines banking fraud, credential theft, ransomware, and persistent device surveillance within a single platform.
Active since October 2025, Cyble Research and Intelligence Lab’s (CRIL) analysis of over 700 samples indicates with high confidence that the threat actor has been conducting a mass infection campaign leveraging Telegram-based infrastructure, enabling centralized control, rapid updates, and sustained campaign evolution.
Key Takeaways
- deVixor is a sophisticated Android banking trojan that combines financial data theft, device surveillance, and remote control into a single malware platform.
- The malware is actively distributed through fake websites posing as legitimate automotive businesses, tricking users into installing malicious APK files.
- deVixor extensively harvests SMS-based financial information, including OTPs, account balances, card numbers, and messages from banks and cryptocurrency exchanges.
- It leverages WebView-based JavaScript injection to capture banking credentials by loading legitimate banking pages inside a WebView.
- The malware includes a remotely triggered ransomware module capable of locking devices and demanding cryptocurrency payments.
- deVixor uses Firebase for command delivery and Telegram-based bot infrastructure for administration, allowing attackers to manage infections at scale and evade traditional detection mechanisms.
Overview
Android banking malware has progressed well beyond basic credential-harvesting threats, evolving into sophisticated remote access toolkits maintained as persistent, service-driven criminal operations.
During our ongoing analysis of malicious sites, we uncovered deVixor, a previously underreported Android Remote Access Trojan (RAT) actively distributed via fraudulent websites masquerading as legitimate automotive companies.
These sites lure victims with heavily discounted vehicle offers and trick them into downloading a malicious APK, which ultimately installs the deVixor malware on the device.
Some of the malicious URLs distributing deVixor RAT are:
- hxxp://asankhodroo[.]shop
- hxxp://www[.]asan-khodro.store
- hxxp://www[.]naftyar.info/naftman.apk
- hxxp://abfayar[.]info/abfa.apk
- hxxps://blupod[.]site/blupod.apk
- hxxps://naftman[.]oghabvip.ir/naftman.apk
- hxxp://vamino[.]online.infochatgpt.com/vamino.apk
- hxxps://lllgx[.]site/mm/V6.apk
CRIL identified more than 700 samples of multiple variants of the deVixor RAT from October 2025. Early versions of the malware exhibited limited functionality, primarily focused on collecting PII and harvesting banking-related SMS messages.
Subsequent variants showed a clear evolution in capabilities, introducing banking-focused overlay attacks, keylogging, ransomware attacks, Google Play Protect bypass techniques, and extensive abuse of Android’s Accessibility Service.
Our investigation also uncovered a Telegram channel operated by the threat actor, which was created shortly after the initial development of deVixor RAT and was actively used to publish version updates, promote new capabilities, and share operational screenshots.
Notably, screenshots posted in the channel reveal numerous devices that are simultaneously infected, each associated with a unique Bot ID (referred to by the actor as a “Port”), suggesting an active campaign operating at scale.
The channel’s growing subscriber base further supports the assessment that deVixor is being maintained and distributed as an ongoing criminal service rather than a short-lived operation. (See Figures 1, 2, and 3)
The deVixor RAT leverages a Telegram bot–based administrative panel for issuing commands. Each deployed APK is assigned a unique Bot ID stored in a local port.json file, enabling the operator to track, monitor, and control individual infected devices.
Once registered, the operator receives real-time updates via Telegram and can issue commands that are relayed to infected devices through backend infrastructure. Figure 4 illustrates the available administrative actions and operational updates as observed in the threat actor’s Telegram channel. (see Figure 4)
Multiple indicators suggest that the campaign is regionally focused. Linguistic artifacts observed in Telegram communications, operator messages, and hardcoded strings within the APK, combined with the exclusive targeting of Iranian banks, domestic payment services, and local cryptocurrency exchanges, strongly indicate that Iranian users are the primary targets of this operation. The use of Persian-language user interface elements in phishing overlays further reinforces this assessment.
DeVixor demonstrates how modern Android banking malware has evolved into a scalable, service-driven criminal platform capable of compromising devices over the long term and facilitating financial abuse.
Its active development, growing feature set, and reliance on legitimate platforms such as Telegram for command-and-control pose a significant risk to Android users. The next section provides a detailed technical analysis of deVixor RAT’s functionality, command structure, and abuse mechanisms observed across multiple variants.
Technical Analysis
Upon installation, the deVixor RAT prompts victims to grant permissions to access SMS messages, contacts, and files. In newer variants, it additionally requests Accessibility service permissions. (see Figure 5)
Once the required permissions are granted, the malware establishes communication with Firebase to receive commands from the threat actor. In parallel, deVixor decrypts a hardcoded alternate Command-and-Control (C&C) server URL, which is used to exfiltrate the collected data.
Overall, deVixor relies on two distinct servers for its operations: (see Figure 6)
- Firebase server – used for receiving commands
- C&C server – used for transmitting stolen data
Bank Information Harvesting
The deVixor RAT uses multiple techniques to steal banking information. One of its main approaches involves collecting banking-related data from SMS messages. In addition, deVixor leverages a WebView injection technique to redirect victims to banking pages, where JavaScript-based injections are used to capture login credentials and other sensitive financial information.
SMS-Based Banking Data Harvesting
deVixor has implemented multiple commands to harvest banking information, including card details, bank balance amounts, SMSs coming from banks and crypto applications, and OTPs:
GET_BANK_BALANCE CommandThe command scans up to 5,000 SMS messages on the infected device to identify banking-related content, extract account balances and OTPs, and associate them with known Iranian banks using a hardcoded set of sender and bank keyword signatures.
It applies regular expressions to parse balances and OTP codes, checks whether the corresponding official banking applications are installed, and exfiltrates the results as a structured JSON response under the GET_ACCOUNT_SUMMARY command.
The report includes the bank name, balance, OTP availability and value, app installation status, and the total number of identified banks. (see Figure 7)
GET_CARD_NUMBER Command
Similar to the previous command, deVixor scans all SMS messages in the infected device’s inbox to identify credit and debit card numbers. It uses regular expressions to detect and validate card numbers, then exfiltrates the extracted information to the C&C server.
GET_EXCHANGE Command
This command scans the victim’s SMS inbox for messages originating from cryptocurrency exchanges and payment services. It extracts recent messages for each identified sender and exfiltrates the collected data to the C&C server. The malware specifically targets SMS messages associated with the following cryptocurrency exchanges (see Figure 8)
- Binance
- CoinEx
- Ramzinex
- Exir
- Tabdeal
- Bitbarg
- TetherLand
- AbanTether
- OkExchange
- ArzDigital
- IranCryptoMarket
- Cryptoland
- Bitex
- Excoino
GET_BANK_SMS Command
Similar to the GET_EXCHANGE command, this command collects the most recent SMS messages sent by known banks and payment services. The harvested messages are returned to the C&C server as a structured JSON response labeled GET_BANK_SMS. Below is the list of banks and payment services targeted by deVixor (see Figure 9)
- Bank Melli Iran
- Bank Mellat
- Bank Tejarat
- Bank Saderat Iran
- Bank Sepah
- Bank Maskan
- Bank Keshavarzi
- Bank Refah
- Bank Pasargad
- Bank Parsian
- Bank Ayandeh
- Bank Saman
- Bank Sina
- Bank Dey
- Post Bank Iran
- Middle East Bank
- Iran Zamin Bank
- Eghtesad Novin Bank
- Karafarin Bank
- Shahr Bank
- Hekmat Iranian Bank
- Industry & Mine Bank
- Export Development Bank of Iran
- Tavon Bank
- BluBank
- Iran Kish
This SMS-based financial information harvesting enables attackers to carry out banking fraud and account takeovers, leading to wallet draining and significant financial losses for victims.
Fake Bank Notification and Credential Harvesting
deVixor uses the “BankEntryNotification” command to generate fraudulent bank notifications designed to lure users into interacting with them. When a victim taps the notification, the malware loads a legitimate banking website inside a WebView and injects malicious JavaScript into the login forms.
Once the user enters their username and password and clicks the login button, the credentials are silently exfiltrated to the C&C server. The figure below illustrates the JavaScript injection technique used for credential harvesting. (see Figure 10)
Ransomware Activity
The deVixor RAT includes an embedded ransomware module that can be remotely triggered using the “RANSOMWARE” command. Upon receiving this command, the malware parses the attacker-supplied parameters, including the ransom note, a TRON cryptocurrency wallet address, and the demanded payment amount.
These details are stored locally in a file named LockTouch.json, which serves as a persistent configuration file to retain the ransomware state across device reboots. The malware then sets an internal locked status and prepares the ransom metadata used by the lock-screen component.
Based on screenshots shared on the threat actor’s Telegram channel, deVixor locks the victim’s device and displays a ransom message stating “Your device is locked. Deposit to unlock”, along with the attacker’s TRON wallet address and a demand of 50 TRX.
The malware also generates a response containing device identifiers and ransom-related details, which is sent back to the C&C server to track victim status and potential compliance. (see Figure 11)
This functionality demonstrates that deVixor is capable of conducting financial extortion, in addition to its existing capabilities for credential theft and user surveillance.
In addition to the features described above, the malware is capable of collecting all device notifications, capturing keystrokes, preventing uninstallation, hiding its presence, harvesting contacts, and taking screenshots. We’ve compiled a full list of supported commands below:
deVixor v1 and v2 Commands
| V1 Commands | V2 Commands | Description |
| RUN_USSD: | RUN_USSD: | Execute USSD request |
| SET_OF_MOD: | SEARCH_APP: | Finds the targeted application installed on the device |
| – | SEARCH_ALL_SMS | Search SMSs with the keywords, store the result in sms_search_keyword.txt, and send the file to the server. |
| BankEntryNotification: | BankEntryNotification: | Generate a fake Bank notification to initiate bank login activity and harvest credentials using JavaScript injection. |
| – | SET_WARNING_BANK: | Displays a fake bank security warning to trick users into logging in on fraudulent banking pages. |
| CHANGE_SERVER: | CHANGE_SERVER: | Change C&C server |
| CHANGE_FIREBASE: | CHANGE_FIREBASE: | Change the Firebase server |
| – | RANSOMWARE: | Initiate Ransomware Activity |
| SEND_SMS: | SEND_SMS: | Send SMS to the number received from the server |
| SEND_SMS_TO_ALL: | SEND_SMS_TO_ALL: | Send SMS to all the contacts saved in the infected device |
| GET_HISTORY_SMS: | GET_HISTORY_SMS: | Saves all SMSs from the infected device to chat_history_*.txt and sends it to the server |
| ADD_CONTACT: | ADD_CONTACT: | Insert the contact into the infected device’s contact list |
| IMPORT_VCF | IMPORT_VCF | Collects the vCard file |
| GET_CAMERA_PHOTOS | GET_CAMERA_PHOTOS | Collects pictures captured using the camera |
| – | GET_ALL_SENT_SMS | Collects sent sms history |
| – | NOTIFICATION_READER | Collect notifications |
| UNHIDE | UNHIDE | Appears again in the applications |
| SET_VIBRATE | SET_VIBRATE | SET_VIBRATION_MODE |
| – | BANK_WARNING | Collect the active fake bank warning list. |
| ONCHANGE | ONCHANGE | Disguise as a YouTube app |
| GET_APPS | GET_APPS | Collects the application package list |
| – | GET_GOLD | Collecting SMSs that are coming from the mentioned mobile numbers |
| SMS_TO_ALL | SMS_TO_ALL | Collects SIM information |
| GET_BANK_BALANCE | GET_BANK_BALANCE | Collects bank balance from SMSs |
| GET_BNC_APPS | GET_BNC_APPS | Collects the banking application list |
| – | GET_ALL_RECEIVED_SMS | Collects all received SMSs |
| GET_SIM_SMS | GET_SIM_SMS | Get SIM information |
| HIDE | HIDE | Hides application |
| TAKE_SCREENSHOT | TAKE_SCREENSHOT | Captures Screenshot |
| – | REMOVE_RANSOMWARE | Remove Ransomware Overlay |
| GET_DEVICE_INFO | GET_DEVICE_INFO | Collects device information |
| SET_SOUND | SET_SOUND | Set notification sound |
| OFFCHANGE | OFFCHANGE | Disable disguise and appear using the original app icon |
| GET_EXCHANGE | GET_EXCHANGE | Collect SMSs related to crypto exchange and financial services |
| GET_IPS | GET_IPS | Collect the IP address of the infected device |
| GET_CARD_NUMBER | GET_CARD_NUMBER | Collects card numbers from SMSs |
| GET_BANK_SMS | GET_BANK_SMS | Collecting all SMSs coming from banks |
| GET_ACCOUNT | GET_ACCOUNT | Get account details from the infected device |
| REVIVE_FOREGROUND | REVIVE_FOREGROUND | Sends the device’s active status |
| GET_USSD_INFO | GET_USSD_INFO | Get SIM Info to support USSD operations |
| GET_LAST_SMS | – | Collecting recent SMSs |
| GET_ALL_SMS | GET_ALL_SMS | Collect all SMSs |
| – | KEYLOGGER | Collects Keylogged data stored in file keuboard_history.txt |
| GET_SCREENSHOTS | GET_SCREENSHOTS | Collects screenshots from the server |
| GET_PHONE_NUMBER | GET_PHONE_NUMBER | Collect the device phone number |
| SET_SILENT | SET_SILENT | Put the device on silent |
| GET_GALLERY | GET_GALLERY | Collect gallery media |
| GET_CONTACTS | GET_CONTACTS | Collect contacts |
Conclusion
deVixor is a feature-rich Android banking Trojan that reflects the latest evolution of Android malware. It combines SMS-based financial data harvesting, WebView-based JavaScript injection attacks, ransomware capabilities, and full remote device control to facilitate banking fraud, account takeovers, financial extortion, and prolonged user surveillance from a single platform.
The modular command architecture, persistent configuration mechanisms, and an active development cycle all indicate that deVixor is not an isolated campaign, but a maintained and extensible criminal service.
The targeted focus on Iranian banks, payment services, and cryptocurrency platforms highlights deliberate victim profiling and regional specialization.
Cyble’s Threat Intelligence Platforms continuously monitor emerging threats, infrastructure, and activity across the dark web, deep web, and open sources. This proactive intelligence empowers organizations with early detection, impersonation, infrastructure mapping, and attribution insights. Altogether, these capabilities provide a critical head start in mitigating and responding to evolving cyber threats.
Our Recommendations
We have listed some essential cybersecurity best practices that create the first line of control against attackers. We recommend that our readers follow the best practices given below:
- Install Apps Only from Trusted Sources:
Download apps exclusively from official platforms, such as the Google Play Store. Avoid third-party app stores or links received via SMS, social media, or email. - Be Cautious with Permissions and Installs:
Never grant permissions and install an application unless you’re certain of an app’s legitimacy. - Watch for Phishing Pages:
Always verify the URL and avoid suspicious links and websites that ask for sensitive information. - Enable Multi-Factor Authentication (MFA):
Use MFA for banking and financial apps to add an extra layer of protection, even if credentials are compromised. - Report Suspicious Activity:
If you suspect you’ve been targeted or infected, report the incident to your bank and local authorities immediately. If necessary, reset your credentials and perform a factory reset. - Use Mobile Security Solutions:
Install a mobile security application that includes real-time scanning. - Keep Your Device Updated:
Ensure your Android OS and apps are updated regularly. Security patches often address vulnerabilities that malware exploits.
MITRE ATT&CK® Techniques
| Tactic | Technique ID | Procedure |
| Initial Access (TA0027) | Phishing (T1660) | Malware is distributed via a phishing site |
| Persistence (TA0028) | Event Triggered Execution: Broadcast Receivers(T1624.001) | deVixor registered the BOOT_COMPLETED broadcast receiver to activate on device startup |
| Persistence (TA0028) | Foreground Persistence (T1541) | deVixor uses foreground services by showing a notification |
| Defense Evasion (TA0030) | Hide Artifacts: Suppress Application Icon (T1628.001) | deVixor hides icon |
| Defense Evasion (TA0030) | Impair Defenses: Prevent Application Removal (T1629.001) | Prevent uninstallation |
| Defense Evasion (TA0030) | Impair Defenses: Disable or Modify Tools (T1629.003) | deVixor can disable Google Play Protect |
| Defense Evasion (TA0030) | Masquerading: Match Legitimate Name or Location (T1655.001) | Masquerade as a YouTube app |
| Defense Evasion (TA0030) | Obfuscated Files or Information (T1406) | deVixor uses an encrypted C&C server URL |
| Credential Access (TA0031) | Access Notifications (T1517) | deVixor collects device notifications |
| Credential Access (TA0031) | Input Capture: Keylogging (T1417.001) | deVixor collects keylogged data |
| Credential Access (TA0031) | Input Capture: GUI Input Capture (T1417.002) | deVixor collects entered banking credentials |
| Discovery (TA0032) | Software Discovery (T1418) | deVixor collects the installed application list |
| Discovery (TA0032) | System Information Discovery (T1426) | deVixor collects the device information |
| Collection (TA0035) | Archive Collected Data (T1532) | deVixor compressing collected data and saving to a .zip file |
| Collection (TA0035) | Data from Local System (T1533) | deVixor collects media from the gallery |
| Collection (TA0035) | Protected User Data: Contact List (T1636.003) | Collects contact data |
| Collection (TA0035) | Protected User Data: SMS Messages (T1636.004) | Collects SMS data |
| Collection (TA0035) | Protected User Data: Accounts (T1636.005) | deVixor collects Accounts data |
| Collection (TA0035) | Screen Capture (T1513) | deVixor can take Screenshots |
| Command and Control (TA0037) | Application Layer Protocol: Web Protocols (T1437.001) | Malware uses HTTPs protocol |
| Exfiltration (TA0036) | Exfiltration Over C2 Channel (T1646) | deVixor sends collected data to the C&C server |
| Impact (TA0034) | SMS Control (T1582) | deVixor can send SMSs from the infected device |
Indicators of Compromise (IOCs)
The IOCs have been added to this GitHub repository. Please review and integrate them into your Threat Intelligence feed to enhance protection and improve your overall security posture.
The post deVixor: An Evolving Android Banking RAT with Ransomware Capabilities Targeting Iran appeared first on Cyble.
Cyble – Read More
Activity-masking infostealer dropper | Kaspersky official blog
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