Network Security
system security Linux network
system security Linux network The romanticized image of the digital nomad – a laptop on a sun-drenched balcony – rarely accounts for the actual friction of maintaining a professional development environment on the move. . The friction is amplified with Linux. We are looking for a setup that respects our kernel configurations, handles volatile network handovers, and maintains a strict security posture without the hand-holding of a consumer-grade OS – so, put simply, more than just a laptop and a sunny deck. The hardware is...
May 26, 2026
Server Securityopen-source Linux administration
open-source Linux administration Cron has existed in Unix and Linux environments for decades, handling backups, cleanup scripts, patching jobs, log rotation, monitoring tasks, and other maintenance work that administrators do not want to run manually. Most Linux servers rely on it constantly, which is exactly why attackers continue abusing it for persistence after a system has already been compromised. . Persistence through cron is not complicated. Attackers do not need a rootkit or advanced malware framework to maintain...
May 25, 2026
Vendors/Productssecurity breach linux
security breach linux A major internal repository breach at GitHub has exposed a critical and overlooked blind spot in Linux supply chain security. Kernel exploits, exposed SSH services, weak firewall rules, and vulnerable daemons dominated the Linux threat model for years, and in many environments, they still matter. But recent supply-chain incidents involving GitHub ecosystems, npm packages, and malicious developer tooling point somewhere else entirely: the developer workstation. . The breach matters because...
May 21, 2026
Security Trends access control multi-tenant
access control multi-tenant Linux administrators often face an ugly choice in the cloud: prioritize convenience and cost-efficiency by sharing infrastructure, or sacrifice those benefits for the sake of total isolation. Most modern Linux workloads don't live on their own private servers anymore. They live in shared environments like Kubernetes clusters, where multiple teams and services run side-by-side. It sounds efficient, and it usually is. . But cloud isolation isn't as ironclad as it looks on the diagram. If you...
May 21, 2026
Vendors/Productsincident response cloud security
incident response cloud security Managed Extended Detection and Response (MXDR) has become one of the most sought-after security services in the enterprise market — and with good reason. It promises the holy grail: broad visibility across endpoints, network, cloud, email, and identity, combined with the 24/7 human expertise most organizations simply cannot build in-house. . However, the rapid growth of the market has produced a wide range of providers whose capabilities vary considerably beneath the surface. Choosing the...
May 19, 2026
Refine news
X Clear Filters
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?
Loading...
Explore Latest Linux Security news
We found -3 articles for you...
83
security advisoryUbuntumalwareLinux Users Targeted as Crypto-stealing Malware Hits Snap Packages
We’ve been telling ourselves that Snap apps are sandboxed, signed, and therefore low-risk. Not perfect, but good enough. That assumption has been holding for years, mostly because it hasn’t been tested in a way that mattered to day-to-day operations. . Recently, it was. Several crypto-stealing campaigns are using Snap packages to land quietly on Ubuntu Linux systems. No exploit chains. No privilege escalation. Just software that looked legitimate enough to install, then stayed resident long enough to make money. For attackers focused on cryptomining, that’s ideal. CPU is consumed slowly, the system keeps working, and nothing obviously breaks. This isn’t about one bad Snap slipping through review. It’s about how much trust we place in packaging ecosystems once they become familiar. Snap’s design favors convenience, automatic updates, and a clean user experience. Those same traits also reduce friction for abuse when something malicious does get through. What matters for admins is not whether Snap is “secure” in the abstract. It’s how these choices change risk in real environments. We’ll walk through how the attack worked, why Snap was a good fit for it, what similar abuse has looked like before, and what’s worth locking down now if you don’t want packaging convenience to quietly expand your attack surface. What Actually Happened with Malicious Snap Packages? The recent campaign itself was not technically impressive, which is part of the problem. Attackers published Snap packages that looked legitimate and behaved well enough to avoid attention. There was no snapd vulnerability involved, and no sandbox escape to dissect afterward. The entry point was trust, not code execution. Distribution leaned on normal Snapcraft usage. A user searched for a tool, found a package that looked right, and installed it. From there, the payload focused on cryptomining and, in some cases, credential harvesting. Nothing destructive. No ransom notes. Just quiet resource use thatblended into the everyday system load, especially on developer workstations and lightly monitored servers. You start to notice the trend when you look at timelines instead of spikes. CPU usage that never quite drops. Processes that respawn under names that don’t raise flags. Outbound traffic that looks like any other long-lived connection unless you already know where it’s going. In Ubuntu environments where Snap is enabled by default, this kind of activity can sit undisturbed for longer than most admins are comfortable admitting. Cleanup was also less clean than people expect. Uninstalling the Snap removed the visible package, but not always the whole problem. Persistence mechanisms varied, and in a few cases, admins had to hunt down leftover processes or user-level artifacts before systems actually returned to baseline. The important takeaway is not that Snap is broken. It’s that “official” packaging has been treated as a proxy for safety in Ubuntu security models, and this campaign shows the limits of that assumption. Once a malicious package looks normal enough, the rest of the system tends to cooperate. Why Is Snap Attractive to Attackers? Once you step back from the individual incident, the choice of Snap starts to make sense. This wasn’t about bypassing defenses. It was about fitting in. Snap’s design decisions, most of them reasonable on their own, create an environment where long-lived, low-noise abuse doesn’t immediately look wrong. A few traits stand out when you compare Snap to more traditional packaging approaches like apt, or even to other modern formats such as Flatpak . Centralized distribution gives attackers reach without having to build their own delivery channel. If a package is discoverable through Snapcraft, it already has an audience. Auto-updates are expected behavior. Users rarely question why a Snap changes over time, or what exactly changed. Confinement reduces obvious breakage. A malicious Snap that stays within its sandbox can keep thesystem stable while still doing useful work for the attacker. Background services are normal. Many Snaps run persistently, so a process that never exits doesn’t immediately look suspicious. Classic confinement is available and often granted with little scrutiny, expanding what a Snap can touch once it’s installed. Publisher trust is inferred from names and descriptions more than from active verification. Logging and monitoring around Snap execution is usually thinner than for system packages. This is where the contrast with other formats matters. Flatpak still carries supply chain risk, but its permission model and runtime expectations make quiet persistence harder to hide. Apps are not generally expected to run indefinitely in the background, so abuse tends to surface faster. Apt packages, on the other hand, are usually installed with a clearer sense that you’re modifying the base system, which changes how people think about trust. None of this makes Snap uniquely unsafe. It does explain why attackers targeting cryptomining workloads gravitate toward it. The platform makes it easier to stay boring, and boring is exactly what you want when the goal is to siphon CPU over time. For admins, this is the shift. Snap should be evaluated like any other third-party code source, not as a special case that inherits trust from the platform it runs on. This Isn’t the First Time Snap Has Been Abused If this were the first example, it would be tempting to treat it as an outlier and move on. It isn’t. Snap has seen malicious or deceptive packages before, and the pattern is familiar if you’ve been watching other software ecosystems long enough. There have been Snap packages that slipped through review while doing something other than what they advertised. Others leaned on lookalike names or vague descriptions to catch casual searches. In several cases, packages were only pulled after users reported odd behavior, not because automated checks caught anything definitive. That delaymatters. It’s the window where quiet abuse pays off. What’s happening here mirrors what played out earlier in npm, PyPI, and container registries. Once an ecosystem makes distribution easy and normalizes fast installs, attackers start probing its edges. They’re not looking for perfect exploits. They’re looking for places where trust is assumed, and verification is light. It’s also worth zooming out for a moment. This isn’t unique to Snap. Flatpak, AppImage, and even the old habit of piping a curl command straight into a shell all scale the same mistake. Convenience lowers friction. Lower friction increases the chance that something untrusted runs without much thought. Packaging format changes the mechanics, not the underlying risk. The practical implication is straightforward. This wasn’t a fluke tied to one bad package or one review failure. It’s a repeatable delivery path that will keep resurfacing as long as software ecosystems optimize for speed and ease of use. At that point, the question for admins stops being “will this happen again” and becomes “how prepared are we when it does?” What Does Crypto-stealing Malware Look Like on Linux in the Real World? On Linux, crypto-stealing malware rarely announces itself. It settles in and tries to look like part of the background. That’s why it’s easy to miss if you’re only watching for spikes, crashes, or obvious failures. What usually shows up first is a sense that something is slightly off. A workstation that never quite goes idle. A server that runs warm even when demand is low. Users start mentioning fans or battery drain, but nothing is broken enough to trigger an incident. When you dig in, the signs tend to cluster around a few patterns: CPU usage that stays modest but persistent, even during periods when the system should be quiet. Processes with generic or misleading names that respawn when killed. Outbound connections to mining pools, proxies, or unfamiliar hosts that remain open for longperiods. Executables running from Snap-specific mount paths rather than expected system locations. Resource consumption that looks “normal” in isolation but wrong when viewed over days instead of minutes. Logs that appear clean unless you correlate process behavior, network traffic, and user actions over time. This is also where differences between packaging systems start to matter operationally. On Flatpak-based systems, similar abuse tends to stand out sooner. Applications are not typically expected to run indefinitely in the background, so long-lived processes attract attention faster. With Snap, persistent services are common enough that they blend in more easily. The monitoring lesson here is uncomfortable but important. You don’t catch this kind of cryptomining by waiting for alarms. You catch it by paying attention to low-grade anomalies that never quite resolve themselves. Once you start looking for those patterns, you realize how long this sort of activity can sit unnoticed. Securing Snapcraft Apps Without Banning Snap Outright Most environments can’t just rip Snap out and move on. Developers rely on it. Some tools only exist there. The goal isn’t to make Snap disappear. It’s to make its presence deliberate instead of incidental. The first shift is mental. Snap packages are not part of the base operating system. They’re third-party software delivered through a convenient channel. Once you frame them that way, the hardening steps stop feeling heavy-handed and start feeling familiar. Start with inventory. Many teams don’t have a clean answer to a simple question. What Snaps are installed, and who put them there. Until you can answer that, everything else is guesswork. From there, publisher review matters more than package names. Well-known projects with verified publishers behave very differently, over time, than one-off utilities with thin histories. Classic confinement deserves special attention. It exists for good reasons, but it quietly undoes many ofthe assumptions people make about Snap safety. If a Snap needs classic confinement, that should be a conscious approval, not a default outcome of clicking through an install prompt. Server environments are where discipline usually slips. Snap auto-installation and auto-updates make sense on desktops. On servers, they introduce change outside your normal review cycle. Disabling or tightly restricting Snap aligns better with how most teams already treat change control, especially in regulated Ubuntu security contexts. It also helps to make decisions visible. Document why a Snap is allowed, what it’s used for, and what level of access it has. That record pays off later, when something looks odd, and you need to decide quickly whether a process belongs. None of this guarantees safety. What it does is shrink the space where quiet abuse can live. When Snap usage is intentional, deviations stand out faster, and response becomes less about cleanup and more about containment. Monitoring and Logging Snap Activity that Actually Helps The hardest part of this class of abuse is that it doesn’t trigger the alerts we’re used to trusting. Nothing crashes. Services stay up. Users keep working. If you only look for sharp edges, you miss the slow ones. Effective monitoring around Snap starts by treating it as its own execution layer. Install and update events should be visible outside the local system. If a Snap appears or changes, you want that fact recorded somewhere central, with a timestamp you can line up against everything else that happened that day. Runtime behavior matters more than package metadata. CPU, memory, and network usage tied back to Snap mount paths is where patterns start to emerge. A single host using a little extra CPU is easy to ignore. Ten hosts doing it in the same way, over the same time window, is not. A few monitoring actions consistently prove their value: Track Snap install and update events centrally, not just locally. Watch for long-running Snap processes onsystems that shouldn’t have them, especially servers. Correlate outbound network connections with Snap executables and user context. Look for resource usage that never quite returns to baseline. Retain logs long enough to see slow-burn behavior, not just short incidents. Assume an attacker’s goal is to look boring, not noisy. What tends to surprise newer admins is how little raw data you need once you know what to correlate. You don’t need deep packet inspection or exotic tooling to spot cryptomining behavior. You need time windows, context, and the discipline to look at patterns instead of peaks. Once Snap activity is visible alongside the rest of your system telemetry, it stops being a blind spot. At that point, the risk shifts from “we wouldn’t notice” to “we might miss it if we’re not paying attention,” which is a much more manageable place to be. Policy Decisions Linux Admins Should Revisit Now Most of the risk exposed by this incident isn’t technical. It’s procedural. Snap behaves the way it was designed to behave, and on Ubuntu, those behaviors are defaults. Snap is enabled out of the box. Auto-updates are on. Classic confinement is available. None of that is a flaw. It does mean those defaults quietly shape your risk profile, whether you’ve discussed them or not. This is where policy catches up with reality. If Snap is present in your environment, it is already making decisions on your behalf. The question is whether those decisions align with how you expect systems to be managed. There are a few areas where ambiguity tends to cause trouble: Are Snaps allowed everywhere, or only on user workstations? Who is allowed to install new Snaps, and under what conditions? What happens when a Snap is flagged as suspicious or outright malicious? How quickly can you inventory affected systems and remove a package at scale? Whether Snap usage is documented anywhere beyond tribal knowledge. How exceptions are handled when someone insiststhey need a specific Snap right now. It helps to frame these as defaults rather than judgments. You are not criticizing Ubuntu for enabling Snap. You are deciding whether those defaults make sense for your environment, your compliance obligations, and your tolerance for unmanaged change. Ubuntu security guidance gives you a baseline. Policy is where you decide how far beyond that baseline you need to go. Once these decisions are written down, a lot of the uncertainty disappears. Installs become intentional. Exceptions become visible. When something odd shows up in monitoring, you already know whether it belongs there. At that point, Snap stops being a background assumption and becomes just another managed input into your risk model. What Does this Change for Linux Security Going Forward? The most useful outcome of incidents like this is not a new rule or a new tool. It’s a quieter adjustment in how trust is handled. Linux systems are no longer ignored by attackers looking for steady financial return. CPU time, credentials, and persistence all have value now, even when nothing breaks. Packaging ecosystems are part of that reality. Snap made the mechanics visible, but the pattern applies anywhere software is easy to install and rarely revisited. Sandboxing still matters. It limits damage and contains mistakes. It does not tell you whether the code inside the sandbox deserves to be there. For admins, the shift is less about adding controls and more about knowing what is running, why it is there, and how it behaves over time. Asset awareness does more work here than another layer of detection. Once you see that, the focus naturally moves from chasing individual threats to managing assumptions. Cryptomining will keep showing up in different forms because it fits this model so well. It is quiet, persistent, and profitable enough to justify patience. That makes it a good stress test for how much implicit trust exists in your environment. When trust is explicit, accepted risk is easier toexplain and easier to defend. When it isn’t, packaging convenience quietly expands the attack surface without anyone signing off on it. The difference between those two states is not dramatic. It’s procedural. And once you notice it, it’s hard to unsee. . Recent campaign exposes how Snap packages can conceal crypto-stealing malware in Ubuntu systems, risking resource theft.. Crypto-stealing Malware, Snap Packaging, Linux Security, Ubuntu Administration, Package Monitoring. . Brittany Day
Jan 29, 2026
•
Hacks/Cracks
210
security advisoryprivilege escalationcritical flawCanonical Snap: CVE-2021-44731 Critical: Privilege Escalation Risk
Multiple security vulnerabilities have been disclosed in Canonical's Snap software packaging and deployment system, the most critical of which can be exploited to escalate privilege to gain root privileges. . Snaps are self-contained application packages that are designed to work on operating systems that use the Linux kernel and can be installed using a tool called snapd. Tracked as CVE-2021-44731, the issue concerns a privilege escalation flaw in the snap-confine function, a program used internally by snapd to construct the execution environment for snap applications. The shortcoming is rated 7.8 on the CVSS scoring system. The link for this article located at The Hacker News is no longer available. . A series of security flaws identified in Canonical's Snap manager may allow privilege escalation, threatening the integrity of system security.. Snap Package Manager, Privilege Escalation, Security Flaw, Canonical Snap. . Brittany Day
Feb 21, 2022
•
Security Vulnerabilities
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?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!
Discover faster search, smarter navigation, and deeper Linux security insights. Read More