Tyrael — audit

2026-05-02T12:06+00:00 · audit #6 · 383s · history

NRG cPanel cluster — last 24h audit

1. WHM root login SUCCESS on cham from external IP 5.2.230.242 at 09:56:32 EEST today — same IP had Accepted password for root SSH on ist yesterday 12:58 EEST. Need yes/no: was this you?

Evidence (Graylog, ossec rule 11009 "WHM login success"):

The mix is unusual: customer webmail + customer cPanel + WHM root + root SSH-password, all from one residential RO IP. If 5.2.230.242 is yours, this is admin activity. If not, the root credentials for both ist and cham are owned. Confirm or rotate root passwords on ist and cham now.


2. SSH config drift: ist, jah and cham accept root password login over SSH; sur denies it. Root-password auth was actually used on ist yesterday.

24h breakdown of SSH password failures:

Combined with finding #1 (root password actually accepted on ist), this is a real exposure not just a hardening nit. Recommendation: set PermitRootLogin prohibit-password (or no) on ist, jah, cham to match sur. Force key-only for root.


3. 22 SSHD publickey logins as locksmith from 82.76.239.154 on ist in 7 minutes (20:00–20:07 EEST). Need yes/no: is locksmith your deploy automation?

All 22 successes in the 24h window have the same fingerprint (ED25519 SHA256:dzYBty9L+ROyyQTWPQy2DWHFn7bdaecU/xnuWzjbKS8) and the same source IP (RO RDS residential). The IP also tried GET /cpsess0345293844/json-api/loadavg against ist:2087 WHM and got 403 (no valid WHM session). Tight burst pattern is consistent with a deploy script or admin running a sequence of cap-style commands; a key-only attacker would normally pivot to a shell, not loop. Low risk if it's yours — high risk if not.


4. WHM brute-force in progress against the cluster — ~200 failed root logins in 24h from distributed cloud IPs. None succeeded that I can see, but the pressure is constant.

Top sources hammering /login/?login_only=1 and /cpsess*/json-api/version as root:

Heavy AWS prefixes (3.x / 13.x / 34.x / 54.x) — rented attack infrastructure. Recommendation: confirm cPHulkd is set to brute-force-protect and consider geo/ASN blocking of WHM ports (2086/2087) to RO+admin VPN only.


5. Repeat-offender SSH brute-forcer 141.11.21.145 hit 3 of 4 cPanel hosts (ist, jah, sur) — 32 coordinated attempts.

Cross-host attackers in 24h:

Top single-host volumes: 122.187.219.78 259 attempts on jah; 51.77.158.34 55 on ist; 52.233.193.61 53 on cham. Routine noise individually, but the multi-host pattern means someone is iterating the cluster. Recommendation: drop these at the perimeter (cluster-wide fail2ban or upstream firewall).


6. Snowshoe spam forging FROM addresses at multiple NRG customer domains — 185.169.4.10 hits all three mail-bearing hosts.

Inbound exim rejections from 185.169.4.10 (random short HELO names like bWsOtNqKLv, fgpxGd) using these forged senders:

All blocked locally — but downstream receivers worldwide getting these will damage the reputation of those customer domains. Recommendation: confirm SPF/DKIM/DMARC are tight on nemesis.ro, gabrosprod.ro, gecauto.ro, info-jobs.ro, frial.ro; offer to publish DMARC p=reject if any are still p=none.


What I skipped

LSAPI saturation on cham (chronic, per playbook), Apache IM360 WAF: Track spam warnings (block noise), Imunify routine INFO logs (no actual MALWARE_DETECTED hits in 24h), Ceph cluster health is not OK on Zabbix (single 01:37 event, no follow-up — flag if it recurs).

Action priority for you

  1. Confirm or deny 5.2.230.242 (finding #1). If not yours: rotate ist+cham root creds and check last/auth.log for what that session did.
  2. Confirm or deny 82.76.239.154 / locksmith (finding #3).
  3. Lock down root SSH on ist/jah/cham (finding #2) regardless of #1's answer.