Kill a Linux Card Skimmer: Cron, Network Checks, Firewall

If your Linux backend is quietly shipping card data off-box, this guide walks you through killing the skimmer path: deep terminal network checks, tearing down hidden malicious cron jobs, and locking outbound traffic so the backdoor stays dead.

This is written for Australian homeowners, sole traders, and small e-commerce operators who run Linux VPS or bare-metal backends (Ubuntu/Debian-style). You will isolate active connections, purge persistence, rebuild a clean dependency path, and verify no further exfiltration. Fixwebnode handles this work remotely for individuals and local operators across Australia via website repair Australia when DIY stops being safe.

Scope assumes SSH root or sudo access, a payment or checkout stack on Linux, and that you can take a short maintenance window. Always snapshot or back up configs before you delete anything.

Why a corrupted Linux dependency skimmer matters

Modern skimmers rarely drop a loud webshell. They hitch a ride on a compromised Composer/npm/system package, a poisoned shared library path, or a post-install hook that rewrites a payment helper. Card fields leave over HTTPS to a lookalike host while your storefront still looks healthy. In Australia that means PCI exposure, bank disputes, and downtime for sole traders who cannot afford a multi-day outage.

The kill chain you need is boring and effective: prove outbound theft with terminal network checks, remove every hidden cron and systemd timer that reinstalls the payload, replace the corrupted dependency, then enforce strict outbound firewall rules so only known destinations remain reachable.

How do you confirm and kill a silent card skimmer on a Linux backend in Australia?

Confirm theft by correlating unexpected ESTABLISHED outbound sockets with processes that touch checkout code, then remove the persistence (cron, timers, drop-in scripts) and the corrupted package. Finish by denying unknown egress with nftables or ufw and re-testing that card flows only reach your payment provider.

Common issues unique to this skimmer pattern

1. Hidden outbound HTTPS during checkout only

Symptoms: storefront pages load fine; card capture fails intermittently; ss shows short-lived connections to unfamiliar ASNs when a test order runs. CPU stays low so hosting panels look green.

2. Malicious cron or systemd timers reinstall the dropper

Symptoms: you delete a suspicious PHP/JS file and it returns within an hour; crontab -l looks empty for your user but root or www-data still has base64 one-liners; systemctl list-timers shows odd .timer units under /etc/systemd/system.

3. Corrupted backend dependency with a clean-looking version string

Symptoms: lockfile says a normal package version; file hashes differ from upstream; a post-autoload or post-install script phones home; payment SDK wrapper includes an extra file_get_contents or curl to a non-provider host.

4. Lax outbound firewall lets the backdoor live after “cleanup”

Symptoms: malware binary is gone but a new process still reaches the C2 because egress is wide open; only inbound 80/443 were ever restricted.

Issue 1 — Deep terminal network checks to catch live exfiltration

Goal: prove which PID is shipping data and where.

Step 1 — Snapshot listening and established sockets

sudo ss -tulpen
sudo ss -tpn state established
sudo lsof -iTCP -sTCP:ESTABLISHED -n -P

Note foreign addresses on 443/80 that are not your CDN, payment gateway, email provider, or OS update mirrors.

Step 2 — Tie sockets to processes and binaries

ps auxf
sudo ls -l /proc/$(pgrep -n php-fpm)/exe 2>/dev/null
sudo readlink -f /proc/<PID>/exe
sudo tr '\0' ' ' < /proc/<PID>/cmdline; echo
sudo ls -l /proc/<PID>/cwd /proc/<PID>/fd 2>/dev/null | head

Replace <PID> with each suspicious PID from ss/lsof.

Step 3 — Capture a short packet sample during a controlled test checkout

sudo timeout 60 tcpdump -i any -nn -c 500 'tcp port 443 or tcp port 80' -w /root/skimmer-check.pcap
sudo tcpdump -nn -r /root/skimmer-check.pcap | awk '{print $3,$5}' | sort | uniq -c | sort -nr | head

Compare destinations to your known allowlist. Unexpected hosts during card entry are high signal.

Step 4 — Inspect web and PHP-FPM logs for the same window

sudo tail -n 200 /var/log/nginx/access.log
sudo tail -n 200 /var/log/nginx/error.log
sudo journalctl -u php8.2-fpm -n 200 --no-pager

Adjust service names (php8.1-fpm, apache2) to match the host. Look for POSTs to checkout endpoints paired with odd upstream calls.

Step 5 — Quarantine the live process (temporary)

sudo kill -STOP <PID>
sudo mkdir -p /root/forensics && sudo cp -a /proc/<PID>/exe /root/forensics/skimmer.bin 2>/dev/null
sudo kill -9 <PID>

Stopping first preserves a copy when the binary is deleted from disk but still mapped. If the process is a hijacked php-fpm worker, restart the pool only after you remove the malicious include (next sections).

Verification

sudo ss -tpn state established | grep -v -E ':(443|80).*(cloudflare|stripe|paypal|afterpay|square|amazon|google)' || true

Refine the filter to your real providers. Empty or only-known results after cleanup is the goal.

Issue 2 — Tear down hidden malicious cron jobs and timers

Goal: remove every persistence path that re-drops the skimmer.

Step 1 — List every crontab and drop-in

sudo crontab -l
sudo crontab -u www-data -l 2>/dev/null
sudo crontab -u nginx -l 2>/dev/null
ls -la /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /var/spool/cron/crontabs
sudo grep -RniE 'curl|wget|base64|python|perl|/dev/tcp|php -r' /etc/cron* /var/spool/cron 2>/dev/null

Step 2 — List systemd timers and suspicious units

systemctl list-timers --all
sudo systemctl list-unit-files | grep -iE 'timer|skid|update|helper'
ls -la /etc/systemd/system /lib/systemd/system | head -n 100
sudo grep -RniE 'ExecStart|curl|wget|base64' /etc/systemd/system /etc/systemd/system/*.timer 2>/dev/null

Step 3 — Remove malicious entries safely

sudo crontab -e
sudo crontab -u www-data -r 2>/dev/null
sudo rm -f /etc/cron.d/suspicious-name
sudo systemctl disable --now evil.timer evil.service 2>/dev/null
sudo rm -f /etc/systemd/system/evil.timer /etc/systemd/system/evil.service
sudo systemctl daemon-reload

Delete only names you confirmed. Keep a copy under /root/forensics/ first:

sudo cp -a /etc/cron.d/suspicious-name /root/forensics/ 2>/dev/null

Step 4 — Hunt common drop paths used with cron

sudo find /var/www /tmp /dev/shm /var/tmp -type f \( -name '*.php' -o -name '*.sh' -o -name '*.elf' \) -mtime -7 -ls 2>/dev/null
sudo find /var/www -type f -name '*.php' -exec grep -lniE 'eval\s*\(|base64_decode\s*\(|gzinflate|card|cvv|exfil' {} \; 2>/dev/null | head

Quarantine hits; do not leave them world-readable in the web root.

sudo mkdir -p /root/forensics/web
sudo mv /var/www/html/path/to/bad.php /root/forensics/web/
sudo chown root:root /root/forensics/web/*
sudo chmod 600 /root/forensics/web/*

Step 5 — Lock down cron so it cannot silently return

echo 'root' | sudo tee /etc/cron.allow
sudo chmod 600 /etc/cron.allow
sudo rm -f /etc/cron.deny
sudo chmod 700 /etc/cron.d
sudo systemctl restart cron || sudo systemctl restart crond

Verification

sudo grep -RniE 'curl|wget|base64' /etc/cron* /var/spool/cron 2>/dev/null || echo 'no obvious cron payloads'
systemctl list-timers --all

Issue 3 — Replace the corrupted backend Linux dependency

Goal: remove the poisoned package and restore a known-good tree without reintroducing post-install hooks that call home.

Step 1 — Identify package managers in use

command -v composer apt npm pip3 2>/dev/null
ls -la /var/www/html/composer.lock /var/www/html/package-lock.json 2>/dev/null
dpkg -l | grep -iE 'php|nginx' | head

Step 2 — Verify lockfile hashes against upstream (Composer example)

cd /var/www/html
composer validate --no-check-publish
composer status
sha256sum vendor/suspicious/pkg/* 2>/dev/null | head

If a package was added outside the lockfile or a path repository points at a writable cache, treat it as hostile until proven clean.

Step 3 — Remove the bad dependency and clear caches

cd /var/www/html
sudo -u www-data composer remove vendor/poisoned-package --no-interaction
sudo rm -rf /var/www/html/vendor/poisoned-package /root/.composer/cache /var/www/.composer/cache 2>/dev/null
sudo -u www-data composer clear-cache

For a deb-level compromise:

apt-cache policy package-name
sudo apt-get purge --purge -y package-name
sudo apt-get update
sudo apt-get install --reinstall -y package-name

Step 4 — Reinstall from pinned clean sources and audit scripts

cd /var/www/html
sudo -u www-data composer install --no-dev --prefer-dist --no-interaction
grep -nE 'post-install-cmd|pre-autoload|file_get_contents|curl' composer.json
sudo -u www-data composer show -i | sort

Strip unknown scripts from composer.json before the next install. Redeploy payment modules only from your provider’s documented packages.

Step 5 — Restart application services cleanly

sudo systemctl restart php8.2-fpm
sudo systemctl restart nginx
sudo systemctl --no-pager --full status php8.2-fpm nginx

Verification

sudo grep -RniE 'eval\(|base64_decode|gzinflate' /var/www/html/vendor /var/www/html/app 2>/dev/null | head
curl -sI https://your-domain.example | head

Issue 4 — Configure strict outbound firewall rules so the backdoor stays dead

Goal: default-deny egress; allow only what the shop must reach.

Step 1 — Inventory required destinations

List payment APIs, DNS, NTP, OS mirrors, and backup endpoints. Resolve them once and document IPs/hostnames. Prefer provider IP ranges you control over “allow the world on 443”.

getent ahosts api.stripe.com api.afterpay.com
getent ahosts archive.ubuntu.com security.ubuntu.com

Step 2 — nftables baseline (preferred on modern Debian/Ubuntu)

sudo apt-get update && sudo apt-get install -y nftables
sudo nft flush ruleset
sudo nft -f - <<'EOF'
table inet filter {
 set allow_dns {
 type inet_service
 elements = { 53 }
 }
 chain input {
 type filter hook input priority 0; policy drop;
 ct state established,related accept
 iif lo accept
 tcp dport { 22, 80, 443 } ct state new accept
 }
 chain forward {
 type filter hook forward priority 0; policy drop;
 }
 chain output {
 type filter hook output priority 0; policy drop;
 ct state established,related accept
 oif lo accept
 udp dport 53 accept
 tcp dport 53 accept
 udp dport 123 accept
 tcp dport 443 ip daddr { 1.2.3.4, 5.6.7.8 } accept
 tcp dport 80 ip daddr { 9.10.11.12 } accept
 }
}
EOF
sudo nft list ruleset
sudo systemctl enable --now nftables

Replace the example IPs with your real payment, mirror, and monitoring addresses. Keep SSH source-restricted if you have a fixed admin IP.

Step 3 — ufw alternative if you already standardise on ufw

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow in 22/tcp
sudo ufw allow in 80/tcp
sudo ufw allow in 443/tcp
sudo ufw allow out 53/udp
sudo ufw allow out 53/tcp
sudo ufw allow out 123/udp
sudo ufw allow out to 1.2.3.4 port 443 proto tcp
sudo ufw allow out to 5.6.7.8 port 443 proto tcp
sudo ufw --force enable
sudo ufw status verbose

Step 4 — Block the known C2 immediately (if still identified)

sudo nft add rule inet filter output ip daddr 203.0.113.50 drop
# or with ufw:
sudo ufw deny out to 203.0.113.50

Step 5 — Prove egress policy with positive and negative tests

curl -sI https://api.your-payment-provider.example | head -n 1
curl -sI --max-time 5 https://example.com || echo 'unexpected egress blocked (good)'
sudo ss -tpn state established

Checkout should still complete against the allowlisted gateway; random HTTPS should fail.

End-to-end verification that the backdoor is dead

Step 1 — Re-run network and persistence checks

sudo ss -tpn state established
sudo grep -RniE 'curl|wget|base64' /etc/cron* /var/spool/cron 2>/dev/null || echo clear
systemctl list-timers --all
sudo find /var/www -name '*.php' -mtime -1 -ls

Step 2 — Place a controlled test order with a non-production card path if your provider offers a sandbox. Watch sockets and logs during the attempt.

Step 3 — Rotate secrets the skimmer could have read

# rotate DB and API secrets in your app env, then:
sudo systemctl restart php8.2-fpm nginx

Invalidate old payment API keys in the provider dashboard. Force password resets for admin and SSH keys if root-level persistence was found.

When DIY is enough vs when to book Fixwebnode

DIY is reasonable when you have clean SSH access, a single obvious malicious cron, a clear bad package path, and egress rules stop the odd connections on the first pass. Stop and book a specialist if processes hide from ss, rootkits interfere with /proc, malware returns after full package reinstall, multiple hosts share the same poisoned artifact, or you must preserve forensic integrity for a bank or insurer in Australia.

Fixwebnode is a direct remote specialist—not a freelance marketplace. We work the same runbook at production depth: network proof, persistence teardown, dependency rebuild, and outbound lockdown, then hand you verification notes. Service coverage is listed on all service areas for Australian operators who need remote incident help without travelling on-site.

Book a remote cleanup conversation

If a silent zero-day skimmer is still touching card fields, or you want a second pair of eyes after the steps above, start a conversation with Fixwebnode. Remote diagnosis suits sole traders and small teams who need the backdoor confirmed dead without guesswork.

Book through the landing page for individuals, sole traders, and local operators: https://fixwebnode.com.au/website-repair-australia. Bring SSH access details, approximate when checkout anomalies started, and any IPs you already blocked—we will take it from the network checks through cron purge and outbound firewall hardening.