Explore top 10 tips to secure your open-source projects now. Read More
×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 attackers no longer need direct access to hardened Linux servers to compromise production environments. Trusted developer tooling and CI/CD automation can now deliver poisoned code upstream long before defenders realize anything changed. Modern Linux environments increasingly depend on GitHub Actions workflows, container registries, self-hosted runners, and automated deployment pipelines tied directly to developer systems. One compromised extension or dependency may be enough to quietly move malicious code into production infrastructure. Linux environments disproportionately rely on open-source tooling, containerized CI workflows, infrastructure-as-code automation, and developer-managed deployment pipelines. That trust relationship is now becoming one of the weakest points in the modern Linux security model. Why Developer Workstations Have Become a Linux Security Blind Spot Recent supply-chain incidents involving malicious npm packages, compromised developer tooling, and poisoned CI workflows have exposed a growing problem for Linux environments: trusted developer systems now sit directly upstream from production infrastructure. VS Code extensions carry an unusual level of trust inside modern Linux workflows. Developers install them constantly for: Linting and Git integration Container and Kubernetes management Terraform support and build automation Cloud deployment workflows Most teams barely review these extensions beyond install counts and marketplace ratings. Productivityusually wins over scrutiny. Once installed, a compromised extension may gain access to: GitHub session tokens SSH keys and signing credentials npm authentication tokens Kubernetes configurations Cloud secrets and CI environment variables Linux production systems often prioritize automation, minimalism, and operational efficiency over traditional endpoint-style monitoring. That makes trusted developer environments especially valuable to attackers looking for cleaner access paths into infrastructure. Attackers no longer need to fight through hardened Linux servers directly if they can compromise the trusted tooling developers already use upstream. Why the GitHub Supply-Chain Trend Matters for Linux Security Recent supply-chain attacks highlight a dangerous reality for Linux teams: production infrastructure increasingly inherits the trust decisions made upstream inside developer tooling and CI automation. Linux systems often sit at the very end of the attack chain. The broader npm and GitHub ecosystem attacks demonstrated how malicious code can move through legitimate CI infrastructure and trusted publishing systems without immediately triggering suspicion. In several incidents, poisoned packages appeared authentic because they were distributed through otherwise trusted automation pipelines. Even cryptographic provenance becomes less meaningful if the trusted CI pipeline itself has already been compromised. Traditional Linux security still matters. Kernel hardening, SSH lockdowns, segmentation, SELinux policies, and firewall rules remain essential. But they no longer represent the full attack surface. Attackers increasingly target trust relationships because trusted automation provides cleaner and quieter access than exploiting operating systems directly. How a Single Developer Workstation Can Poison Production The attack chain starts quietly. A developer installs or updates what appears to be a legitimate VS Code extension or npm dependency. The toolingbehaves normally enough to avoid suspicion while hidden functionality begins harvesting credentials and session data. From there, attackers can move directly into trusted automation systems. A compromised developer environment may expose: GitHub access tokens SSH keys and signing credentials Kubernetes deployment configurations Cloud authentication secrets CI/CD environment variables Once attackers gain access, CI/CD systems become the amplification layer. GitHub Actions workflows may be modified to inject malicious dependencies, alter build configurations, or poison deployment artifacts. Self-hosted Linux runners create additional exposure because they often maintain persistent credentials and broad internal network access. At that point, attackers no longer need direct access to hardened Linux servers. Trusted automation delivers the malicious code for them. A compromised extension on a developer workstation may ultimately lead to poisoned containers being automatically deployed into Kubernetes clusters or production Linux environments through infrastructure already trusted by the organization. Linux CI/CD Pipelines Are Increasingly Becoming the Real Target Security researchers increasingly view CI/CD systems as the primary target for modern supply-chain attacks in Linux environments. Pipeline compromise bypasses many traditional security controls because the malicious activity occurs inside systems already approved to build and deploy software. GitHub Actions workflows deserve particular scrutiny. Risky patterns such as pull_request_target workflows may allow attacker-controlled code from external pull requests to execute inside trusted repository contexts that may still have access to repository secrets, tokens, or workflow permissions under certain conditions. Self-hosted Linux runners create even larger blast radii because they frequently maintain: Long-lived credentials Access to internal repositories Container registry permissions Terraform state files Kubernetes deployment access Infrastructure-as-code compounds the problem further. Dockerfiles, Terraform manifests, Helm charts, and deployment workflows collectively provide attackers with detailed visibility into production architecture. For Linux teams, CI/CD infrastructure must now be treated as a high-risk security boundary rather than simple deployment automation. npm Supply-Chain Attacks Continue Targeting Linux Development Environments A surge in targeted npm attacks confirms that package ecosystems remain one of the weakest links in Linux-based development environments. Attackers increasingly rely on techniques such as: Typosquatting legitimate package names Maintainer account compromise Dependency confusion attacks Poisoned transitive dependencies Transitive dependencies make the problem significantly worse. Developers may trust a direct package while having little visibility into hundreds of indirect dependencies installed alongside it. By the time defenders detect suspicious behavior, malicious packages may already exist across: CI runners Container images Production workloads Cached deployment artifacts Package trust now directly impacts the integrity of the underlying Linux environment. How Linux Admins Can Detect Exposure Security teams are increasingly adopting new response protocols for supply-chain compromises tied to developer tooling and CI automation. Admins should immediately focus on: Repository activity: Look for unauthorized workflow edits, suspicious commits, or unexpected OAuth authorizations. Runner behavior: Monitor CI runners for unusual outbound traffic, package downloads, or unexpected job execution patterns. Credential rotation: Replace GitHub tokens, SSH keys, npm credentials, cloud secrets, and Kubernetes service accounts. Artifact integrity: Rebuild containers from verified sources and validate SBOMs against known-good baselines. Extension auditing: Reviewinstalled VS Code extensions across developer systems and remove unapproved tooling. Persistence checks are equally important. Malicious workflows, poisoned caches, and hidden automation hooks may survive standard credential rotations. Supply-chain attacks rarely stop at a single layer. Best Practices for Securing Linux CI/CD Pipelines Security teams are increasingly treating developer tooling and CI infrastructure with the same level of scrutiny traditionally reserved for production servers. Endpoint Hardening Restrict VS Code extension installations through allowlists and centralized policy controls. Isolate development environments using containers or disposable workspaces. Monitor workstations for unauthorized extension activity and credential access. GitHub and CI Security Avoid risky GitHub Actions patterns such as pull_request_target unless absolutely necessary. Use MFA, short-lived tokens, and tightly scoped GitHub permissions. Deploy ephemeral CI runners instead of persistent self-hosted systems. Segment CI infrastructure from production deployment networks. Dependency and Artifact Security Verify package provenance using Sigstore or cosign. Continuously audit dependencies and monitor for suspicious package updates. Validate SBOMs before deployment. Use tooling such as OpenSSF Scorecard, Syft, Grype, and Trivy to improve visibility into software supply chains. Visibility remains the final layer. Centralized logging, behavioral monitoring, and threat intelligence integration improve detection speed when trusted tooling becomes the compromise vector. Linux Security Now Starts Before Production Linux admins spent years hardening production infrastructure against direct compromise. Attackers adapted by moving further upstream into developer environments, package ecosystems, and CI/CD automation already trusted to deploy code into production. That shift changes the security model entirely. A fully patched Linux servermay still execute poisoned code delivered through a trusted pipeline, signed package, or compromised developer workflow. In many environments, the workstation now matters just as much as the production server itself. The modern Linux attack surface no longer starts at the edge firewall or exposed SSH port. Increasingly, it starts wherever developers write, build, and ship code. Stay ahead of emerging Linux supply-chain threats, CI/CD risks, and open-source security issues by subscribing to the LinuxSecurity newsletter . Get weekly analysis, practical hardening guidance, and security insights focused on real-world Linux infrastructure. Related Reading Why CI/CD Pipelines Became Targets in Software Supply Chain Attacks GitHub Actions Linux Self-Hosted Runners Security Risks Why Linux Supply Chain Attacks Are Becoming a Nightmare for DevOps Teams The npm Supply Chain Problem: Why Installing Packages Executes Untrusted Code GitHub Actions Critical Misconfigurations Expose Open Source Risks . Explore the risks in Linux supply chain security amidst GitHub's repo breach, revealing the importance of developer tool security.. Linux Supply Chain Security, GitHub Breach, CI/CD Security, Developer Tool Threats, Security Best Practices. . Dave Wreski
Ransomware has long been a severe threat to organizations and admins alike. Recently, cybersecurity researchers discovered a new variant called Cicada3301, which some experts believe has links with BlackCat (aka ALPHV) due to similarities in operations. Cicada3301 is a Rust-based ransomware that targets Windows and Linux/ESXi hosts. . To help you secure your systems and data, I'll explain how this ransomware operates and offer practical advice you can implement to mitigate risk. Understanding the Cicada3301 Ransomware The Rust-based Cicada3301 ransomware targets predominantly small to midsized businesses through targeted attacks. Vulnerabilities serve as initial system entryways, likely through exploits made available via vulnerability scans. One unique aspect of Cicada3301 is that it uses compromised user credentials to execute PsExec, an otherwise legitimate program used for remote execution. This makes detection difficult as PsExec remains legitimate and more challenging to spot than its alternatives. Cicada3301 utilizes ChaCha20 for encryption, fsutil to evaluate symbolic links and encrypt redirected files, IISReset.exe to stop IIS services and encrypt files that would otherwise be locked for modification or deletion, as well as IISReset.exe to stop these IIS services and encrypt any locked files which otherwise block changes and deletion. It follows similar behavior patterns to BlackCat in clearing all event logs, deleting shadow copies via the shadowcopy-delete command-line utility, and increasing MaxMpxCt value so it can support higher volumes of traffic, such as SMB PsExec requests. Source: morphisec Cicada3301 can also target Virtual Machines (VMs), shutting down backup and recovery services and hard-coded lists of processes. Additionally, this ransomware targets 35 file extensions: sql, doc, rtf, xls, jpg, jpeg, psd, docm, xlsm, ods, ppsx, png, raw, dotx, xltx, pptx, ppsm, gif, bmp, dotm, xltm, pptm, odp, webp, pdf, odt, xlsb, ptox, mdf, tiff, docx, xlsx, xlam, potm,and txt. Investigations unveiled additional tools like EDRSandBlast that utilize vulnerable signed drivers to bypass EDR detections. Cicada3301 has been observed using this technique—as used by the BlackByte ransomware group previously—which suggests they may have collaborated to gain initial access to enterprise networks. Analysis of the ESXi version of Cicada3301 uncovered that this ransomware could use intermittent encryption to encrypt files larger than 100 MB and use a parameter named "no_vm_ss" for encryption without shutting down virtual machines running on its host machine. Understanding who may fall prey to attacks by Cicada3301 is essential. The ransomware attacks primarily target small to midsized businesses through targeted opportunistic attacks exploiting vulnerabilities, likely with help from operators of Brutus Botnet to gain initial entry to enterprise networks. Practical Advice for Mitigating Risk Linux admins can take specific practical measures to mitigate ransomware attacks, including: Regularly updating operating systems and software. Using reliable antivirus programs and firewalls. Disabling unneeded services and ports. Making regular backups of critical files and database backups. Providing regular training awareness programs on how to avoid ransomware attacks and other forms of phishing and malware attacks. Offering regular backup storage systems offsite. Regularly training staff on how to recognize these types of attacks. Our Final Thoughts on Cicada3301 Ransomware The Cicada3301 ransomware variant is a hazardous threat that targets both Windows and Linux/ESXi hosts. It is capable of embedding PsExec, clearing almost all event logs, and using legitimate tools to cause damage. Due to these characteristics, it may be hard to detect or prevent. Therefore, sysadmins must take proactive measures to safeguard their systems against possible attacks by regularly updating systems with patches, training employees for increased awareness, andbacking up critical files regularly. These measures will significantly lower the risks associated with ransomware attacks. . Explore the workings of the Cicada3301 malware, including its tactics, and discover effective strategies to safeguard your networks from potential vulnerabilities.. Cicada3301 Ransomware,Rust-Based Threats,Cyber Attack Prevention,Data Recovery,Linux Security. . Brittany Day
On Tuesday June 26, 2001, a hacker named 'ThePike' managed to deface the European defacement mirror Alldas.de. Visitors to the site saw a modified news banner on the left side saying "ALLDAS GOT CRACKED! READ IT HERE". . . . . On Tuesday June 26, 2001, a hacker named 'ThePike' managed to deface the European defacement mirror Alldas.de. Visitors to the site saw a modified news banner on the left side saying "ALLDAS GOT CRACKED! READ IT HERE". The front page was modified to include a small rant/message from the defacer regarding current defacement activity. His message warned other defacers that "security is not something funny" and cautioned would-be defacers about using their scripts to deface companies that rely on data security. For details on the defacement from Alldas: See Alldas - Die Welt in Ihren Händen. For a mirror and the full text message left: It is interesting to note the amount of commands the attacker attempted to run and the likelihood that he shared the exploit with others. Given the command attempts came from 10 different IP addresses, one might wonder about the intentions of the OTHER people involved. Security web site Security.NL was contacted by someone, possibly from whiskunde.org, believed by some to be involved in the defacement. Security.NL posted an article (in Dutch) about the defacement, as well as mirror and screenshots: screenshots: mirror: Securitywatch article on the incident: It is refreshing to see Alldas.de provide details of the incident as well as make a mirror available on their site. It is that kind of integrity and honesty that is needed in the security community. - The information and commentary is Copyright 2001, by the individual author. Permission is granted to quote, reprint or redistribute provided the text is not altered, and the author and attrition.org is credited. The opinions expressed in this mail are not necessarily the opinion of all Attrition staff members. Commentary Archive: TheAttrition Mirror: Country/TLD Statistics: country.html Attrition Defacement Statistics: stats.html Operating System Graphs: Other Web Defacement Mailing Lists: Contacting Attrition Staff:
There is no doubt that the Internet has brought unparalleled connectivity to computers, especially in the last few years. But ironically, this very advantage has also been the bane of hundreds of corporations, all of which critically depend on these connections . . . . There is no doubt that the Internet has brought unparalleled connectivity to computers, especially in the last few years. But ironically, this very advantage has also been the bane of hundreds of corporations, all of which critically depend on these connections to conduct their daily business. The crux of the problem - security breaches in computer networks. "In most corporate networks today, the feeling of vulnerability - that their networks are potentially opened to hacking or intrusion - is what's driving them to protect their computer networks," says Barry Spinney, founder and chief technical officer of Top Layer Networks Inc. Top Layer, specialises in the development and production of networking devices that protect systems against hacking and intrusion. The link for this article located at Tech Central is no longer available. . There is no doubt that the Internet has brought unparalleled connectivity to computers, especially i. there, doubt, internet, brought, unparalleled, connectivity, computers, especially. . Anthony Pell
Threat actors linked to the IceFire ransomware operation now actively target Linux systems worldwide with a new dedicated encryptor. SentinelLabs security researchers found that the gang has breached the networks of several media and entertainment organizations around the world in recent weeks, starting mid-February, according to a report shared in advance with BleepingComputer. . When executed, IceFire ransomware encrypts files, appends the '.ifire' extension to the filename, and then covers its tracks by deleting itself and removing the binary. It's also important to note that IceFire doesn't encrypt all files on Linux. The ransomware strategically avoids encrypting specific paths, allowing critical system parts to remain operational. This calculated approach is intended to prevent a complete system shutdown, which could cause irreparable damage and even more significant disruption. While active since at least March 2022 and mostly inactive since the end of November, IceFire ransomware returned in early January in new attacks, as shown by submissions on the ID-Ransomware platform. . SteelWave malware has expanded its reach to MacOS platforms, implementing innovative encryption methods to prevent essential system file damage.. IceFire Ransomware,Linux Encryption,Cyber Threat Detection,Malware Analysis. . LinuxSecurity.com Team
Dropbox has revealed details of a phishing attack to which it fell victim. In the attack, a threat actor was able to steal code from the company after gathering employee credentials to GitHub repositories.. The security breach took place in the middle of last month, with GitHub notifying Dropbox of suspicious account activity on October 14. The cloud storage company says that the code that was accessed "contained some credentials -- primarily, API keys -- used by Dropbox developers" but insists that "no one's content, passwords, or payment information was accessed", and that its core apps and infrastructure were unaffected. In a blog post that goes into some detail about the incident, Dropbox says: "In today's evolving threat landscape, people are inundated with messages and notifications, making phishing lures hard to detect. Threat actors have moved beyond simply harvesting usernames and passwords, to harvesting multi-factor authentication codes as well. In September, GitHub detailed one such phishing campaign, in which a threat actor accessed GitHub accounts by impersonating the code integration and delivery platform CircleCI. We recently learned that Dropbox was targeted by a similar campaign. . Dropbox encountered a serious cybersecurity incident, in which source code was compromised from GitHub through phishing tactics; however, essential systems remain intact.. Dropbox Security, GitHub Phishing Attack, Code Theft Risk, API Key Protection. . LinuxSecurity.com Team
Some researchers from the University of Minnesota tried to slip bad patches into the Linux kernel as a "test." When they kept trying, Greg Kroah-Hartman, the Linux kernel maintainer for the stable branch, put an end to their efforts by banning their university from Linux development. . Thanks to the Solarwinds security breach , software supply chain attacks have become an important issue. Naturally enough, there's a lot of research being done into these attacks. Two graduate students at the University of Minnesota working on a paper entitled, " On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits " tried to put the Use-After-Free (UAF) vulnerability into the Linux kernel. This kind of Red Team security testing is commonplace… when the project includes people who know what's going on beforehand. That wasn't the case here. When they tried it again, Greg Kroah-Hartman, the Linux kernel maintainer for the stable branch, had had enough. Kroah-Hartman, one of the most respected of all the Linux kernel developers, tweeted, " Linux kernel developers do not like being experimented on , we have enough real work to do." . Thanks to the Solarwinds security breach, software supply chain attacks have become an important iss. researchers, university, minnesota, tried, patches, linux, kernel. . Brittany Day
If you're a cryptocurrency startup, would you face a huge backlash by hacking your own customers to keep their funds safe if you know that a hacker is about to launch an attack and steal their funds? . This is exactly what happened yesterday when the Komodo Platform learned about a backdoor in one of its older wallet apps named Agama. Knowing they had little time to act, the Komodo team said it used the same backdoor to extract users' funds from all impacted wallets and move them to a safe location, out of the hacker's reach. The link for this article located at ZDNet is no longer available. . This is exactly what happened yesterday when the Komodo Platform learned about a backdoor in one of . you're, cryptocurrency, startup, would, backlash, hacking, customers. . LinuxSecurity.com Team
Get the latest Linux and open source security news straight to your inbox.