Alerts This Week
Warning Icon 1 677
Alerts This Week
Warning Icon 1 677

Stay Ahead With Linux Security News

Filter Icon Refine news
X Clear Filters
X Clear Filters
View More

Get the latest News and Insights

Get the latest Linux and open source security news straight to your inbox.

Community Poll

What got you started with Linux?

No answer selected. Please try again.
Please select either existing option or enter your own, however not both.
Please select minimum {0} answer(s).
Please select maximum {0} answer(s).
/main-polls/150-what-got-you-started-with-linux?task=poll.vote&format=json
150
radio
0
[{"id":483,"title":"Self-taught through trial and error","votes":545,"type":"x","order":1,"pct":78.42,"resources":[]},{"id":484,"title":"Formal training or courses","votes":30,"type":"x","order":2,"pct":4.32,"resources":[]},{"id":485,"title":"A job that required it","votes":34,"type":"x","order":3,"pct":4.89,"resources":[]},{"id":486,"title":"Other","votes":86,"type":"x","order":4,"pct":12.37,"resources":[]}] ["#ff5b00","#4ac0f2","#b80028","#eef66c","#60bb22","#b96a9a","#62c2cc"] ["rgba(255,91,0,0.7)","rgba(74,192,242,0.7)","rgba(184,0,40,0.7)","rgba(238,246,108,0.7)","rgba(96,187,34,0.7)","rgba(185,106,154,0.7)","rgba(98,194,204,0.7)"] 350
bottom 200
Loading...

Explore Latest Linux Security news

We found -3 articles for you...
210

Cisco: SNMP Critical Linux Rootkit Exploit CVE-2025-20352 RCE

Attackers are using a new Linux rootkit to compromise Cisco network devices and keep access long after the initial breach. The exploit begins in the SNMP service, where a privilege flaw provides the necessary foothold to access the kernel. From there, the code blends in with regular system activity and hides everything that matters. . Once it’s running, the rootkit masks processes, rewrites logs, and filters what monitoring tools can see. A system check might look clean while the attacker still has control. That’s what makes this campaign so effective — it doesn’t break anything loud enough to notice. For security teams managing Linux infrastructure, this is a clear reminder of how persistence has evolved. It’s not about desktop malware or file infections anymore. It’s about attackers targeting the kernel itself, which means Linux security must extend beyond routine visibility. What Is the Cisco SNMP Vulnerability and Why It Matters for Linux Security The issue at the center of these attacks sits in Cisco’s SNMP service — software most admins rarely think about until something goes wrong. It’s been part of network infrastructure for decades, meant for management and monitoring, not for intrusion. But a small flaw in the way it handles packets has opened a door that attackers are now walking through. CVE-2025-20352 Overview and Technical Details The flaw is triggered by a malformed SNMP request that overflows a buffer in the SNMP handler. This is not a blind internet-wide RCE — attackers need SNMP access, such as a community string or SNMPv3 credentials, typically with write privileges. Once authenticated, they can deliver a packet that overflows the handler and leads to code execution and full device compromise. Where it lives: The SNMP service listens on UDP port 161. In many networks, it’s still exposed because the service predates the current approach to segmentation. Who’s affected: Devices running older builds of IOS and IOS XE firmware arevulnerable. Cisco confirmed this in its Cisco advisory , which also lists the firmware versions that need immediate patching. Severity and timeline : The flaw carries a critical CVSS score of 7.7. Cisco moved quickly to issue updates once it was reported, and the NVD listing later confirmed the technical vector — remote code execution through SNMP. At its core, this is a simple overflow with complex consequences. It turned a background management protocol into a direct path for kernel-level control. That’s why it matters for Linux security — because it shows how deep attackers can go when old services stay exposed. How Attackers Exploited the Flaw to Deploy a Linux Rootkit Once word got out, attackers didn’t waste time. They scanned for exposed devices, found ones running vulnerable SNMP builds, and sent carefully crafted packets to trigger the flaw. From there, they gained root access and installed a Linux rootkit built specifically for persistence. Entry and escalation: The exploit begins with reconnaissance. Attackers identify reachable SNMP endpoints, confirm firmware, and trigger the overflow to execute code as root. Payload deployment: After gaining control, they drop the rootkit into the system — code that integrates with the kernel and hides its presence from both local tools and remote monitoring. Evidence in the wild: Analysts have seen traffic leading to command servers and system binaries replaced by modified versions. Infected devices still respond normally to most commands, which makes detection slow. The NVD CVE-2025-20352 record confirms how the exploit works. What matters more is what happens next — the rootkit turns that one-time vulnerability into a lasting foothold inside the system. Inside the Linux Rootkit: What It Does and How It Hides So far, observed behavior indicates the implant’s purpose is stealth and persistence rather than autonomous propagation. It hooks directly into the kernel, intercepts calls that listprocesses or files, and forges clean results when admins check what’s running. Persistence: The implant loads with the kernel itself, giving it the same privileges as the operating system. Once active, it can reload after reboots and survive most basic recovery steps. Concealment: It filters out its own entries in process lists and hides active network sockets. If you run ps or netstat, everything looks fine. Communication: It maintains encrypted contact with its command servers through ports that blend into routine SNMP and HTTPS traffic. Detection challenges: Firmware-level inspection tools may catch signs of tampering, but traditional monitoring will not. The deeper it sits, the quieter it gets. For teams focused on Linux security, the lesson is clear: visibility has to extend below the surface. The hardest part about defending against a Linux rootkit isn’t removing it — it’s realizing it’s there in the first place. The Impact of This Attack on Linux Security and Network Infrastructure This attack doesn’t just target Cisco devices — it goes after the Linux core that runs beneath them. It’s a reminder that network infrastructure is part of the Linux ecosystem, and when attackers reach the kernel, the rest of the stack follows. Devices and Systems at Risk The affected devices include Cisco routers and switches running older versions of IOS and IOS XE firmware. Both rely on Linux kernels that can be modified once attackers gain system-level access. The issue is less about model numbers and more about configuration and patch discipline. Enterprise environments: In corporate networks, SNMP remains widely deployed for visibility. Many devices still use legacy credentials or public community strings that make them easy to enumerate. Attackers can scan the internet for exposed SNMP services, identify outdated firmware, and exploit it remotely. Industrial networks: In manufacturing and energy sectors, firmware updates require downtime thatrarely happens. That’s left many installations running years-old builds — stable, but vulnerable. Persistence risk: Once the exploit lands, the Linux rootkit embeds itself in the kernel and can possibly survive firmware updates that don’t fully rewrite the affected components. That persistence turns a short-term exploit into long-term control. This isn’t an isolated case. The Houken kernel rootkit used the same approach earlier this year in attacks against Ivanti Connect Secure gateways. Different target, same concept — compromise the Linux kernel on an appliance that most defenders consider “infrastructure,” not “endpoint.” That’s what makes this shift significant for Linux security: it blurs the distinction between where the operating system ends and where the network begins. Why This Attack Matters for Linux Security Defense Strategies Rootkits have always been a blind spot in Linux defense, but this campaign shows how much harder detection has become. Once attackers gain kernel access, they control what the system reports. Metrics, process lists, even logs — all can be rewritten to look normal. For teams managing Linux-based infrastructure, this demands a shift in priorities. Detection has to rely less on what the system says and more on what can be independently verified. Validate kernel modules and hashes against known-good baselines. Monitor firmware integrity, not just software configuration. Restrict SNMP and other management services to isolated segments. Large-scale campaigns like Cyclops Blink and VPNFilter used the same principle: compromise network gear running Linux, stay quiet, and move laterally through trusted traffic. What’s different now is how refined that persistence has become. As shown in the analysis of how secure Linux is , even hardened systems can be manipulated once attackers move below the user space. It’s not a Linux weakness — it’s a matter of depth. Once the kernel is compromised, everything above itbecomes unreliable. What the Cisco Exploit Reveals About Linux Rootkit Evolution The Cisco campaign underscores how far rootkits have evolved and how well attackers now understand embedded Linux. They’re not brute-forcing visibility anymore — they’re shaping it. Embedded Linux as a platform: Nearly every modern router, switch, and firewall runs on some form of Linux. Once attackers figure out kernel behavior on one platform, that knowledge scales across others. Open architecture, dual impact: Transparency has always been Linux’s strength, allowing defenders to inspect and verify the system at every level. It’s also what makes development easier for attackers who can study the same codebase to refine their implants. Future trajectory: The focus is shifting from infection to persistence. Rootkits like this don’t aim to disrupt; they aim to disappear. That persistence gives attackers time to watch, map, and move. For defenders, the message is straightforward. Linux security can’t stop at patches or intrusion alerts. It must include continuous verification of the kernel, the firmware, and the intervening systems. Because once control slips below the surface, you can’t defend what you can’t see. How to Mitigate the Vulnerability and Strengthen Linux Security Threat Vector Mitigation Strategy Linux Security Rationale SNMP service exposure Disable or restrict SNMP to local networks Reduces the attack surface on Linux-based systems and limits remote exploitation paths Unpatched firmware Apply Cisco firmware updates immediately Eliminates the remote code execution vector before it can be weaponized Rootkit persistence Re-flash firmware or verify kernel integrity Restores a trusted state and re-establishes kernel-level assurance Applying these mitigations quickly is critical to maintaining Linux infrastructure trust.Disabling exposed SNMP services closes off the entry point that attackers used here. Firmware updates and kernel verification prevent persistence — the step that turns an exploit into a long-term breach. These actions aren’t just reactionary. They’re part of the broader discipline of continuous hardening and visibility that defines strong Linux defense today. As outlined in current best practices for how to optimize Linux security , maintaining kernel integrity and enforcing tight patch cycles are central to preventing deep compromises like this one. Together, they move Linux systems back toward a known, verifiable state — the foundation of effective incident recovery and resilience. How to Mitigate the Vulnerability and Strengthen Linux Security Start with the entry point. If SNMP isn’t needed, disable it. If it is, keep it local and monitored. Most of the exposure seen in these attacks comes from management ports left open to the internet. Reducing that reach cuts off the simplest path to compromise and limits what an attacker can touch inside Linux-based systems. From there, patch fast. Cisco’s firmware update closes the flaw that makes remote code execution possible. Unpatched devices stay visible to automated scans, and attackers have already shown they’re looking for them. Firmware maintenance isn’t optional anymore — it’s a baseline for keeping Linux infrastructure trustworthy. If a system’s already been hit, persistence is the problem. Rootkits can live below what most tools see. Re-flashing the firmware or verifying the kernel against a trusted baseline is the only way to be sure the system’s clean. Once the kernel is trusted again, everything above it can be trusted too. These aren’t one-off fixes; they’re habits. This kind of hygiene — limiting exposure, patching quickly, validating integrity — is what separates recovery from recurrence. It’s the same principle behind every effective Linux security program: keep the surface small, keep the kernelverified, and never assume what you can’t confirm. What This Incident Teaches About the Future of Linux Rootkit Threats This attack makes one thing clear: Linux security doesn’t stop at servers. The same kernel runs in routers, VPN gateways, firewalls, and appliances that rarely get attention until something breaks. When attackers plant a rootkit in one of those systems, they’re not just stealing access — they’re taking control of the infrastructure that everything else depends on. The shift we’re seeing isn’t just about tools. It’s about awareness. Adversaries understand Linux well enough now to build implants that live quietly inside trusted systems. They know defenders are watching processes and logs, not kernel hooks and firmware calls. That’s where the next fights will happen — at the level most teams still treat as static. Improving defense means going deeper. Open-source firmware audits, kernel integrity checks, and shared research between vendors and the community aren’t optional anymore. They’re how we keep visibility in places where attackers now live. The focus needs to stay here: Rootkit research: Track how attackers are modifying kernel behavior before it reaches production environments. Embedded system defense: Apply Linux hardening and monitoring to the infrastructure layer, not just endpoints. Open-source transparency: Keep sharing what’s found, fixing it fast, and making those fixes public. Linux was built on that kind of openness. It’s what gives defenders a chance to stay ahead — if we keep looking where the code actually runs . Explore the impact of Cisco's SNMP flaw leading to Linux rootkit installations, emphasizing critical security insights.. Cisco SNMP Flaw, Linux Rootkit, Kernel Exploitation, Network Security, Cyber Threats. . MaK Ulac

Calendar 2 Oct 17, 2025 User Avatar MaK Ulac Security Vulnerabilities
79

An Introductory Guide to Techniques for Kernel Exploitation

I’m writing this post because I often hear that kernel exploitation is intimidating or difficult to learn. As a result, I’ve decided to start a series of basic bugs and exercises to get you started! Prerequisites Knowledge of the Linux command line Knowing how to read and write basic C may be beneficial Being able to debug with the help of a virtual computer or another system Able to install the kernel module compilation build requirements A basic understanding of the difference between userland and kernelland could be helpful Having a basic understanding of assembly can be beneficial for future episodes For this part, I wrote a simple Linux character device , /dev/shell . This driver will take two arguments, uid and cmd , and it will execute the cmd command as the specified uid . To understand how this driver works, I’ll explain a few things! . . Dive into the fundamentals of kernel exploitation and enhance your skills with straightforward Linux challenges and practical exercises.. Kernel Exploitation, Linux Challenges, C Programming. . LinuxSecurity.com Team

Calendar 2 Mar 27, 2021 User Avatar LinuxSecurity.com Team Security Projects
News Add Esm H340

Get the latest News and Insights

Get the latest Linux and open source security news straight to your inbox.

Community Poll

What got you started with Linux?

No answer selected. Please try again.
Please select either existing option or enter your own, however not both.
Please select minimum {0} answer(s).
Please select maximum {0} answer(s).
/main-polls/150-what-got-you-started-with-linux?task=poll.vote&format=json
150
radio
0
[{"id":483,"title":"Self-taught through trial and error","votes":545,"type":"x","order":1,"pct":78.42,"resources":[]},{"id":484,"title":"Formal training or courses","votes":30,"type":"x","order":2,"pct":4.32,"resources":[]},{"id":485,"title":"A job that required it","votes":34,"type":"x","order":3,"pct":4.89,"resources":[]},{"id":486,"title":"Other","votes":86,"type":"x","order":4,"pct":12.37,"resources":[]}] ["#ff5b00","#4ac0f2","#b80028","#eef66c","#60bb22","#b96a9a","#62c2cc"] ["rgba(255,91,0,0.7)","rgba(74,192,242,0.7)","rgba(184,0,40,0.7)","rgba(238,246,108,0.7)","rgba(96,187,34,0.7)","rgba(185,106,154,0.7)","rgba(98,194,204,0.7)"] 350
bottom 200
Your message here