1. Need a yes/no: was that you on root@sur+cham+ist last night at 23:42–23:45 EEST?
Source IP 82.76.239.154 (Romanian, no failed_login history in 7 days, first seen 2026‑05‑01) authenticated as root via password on three boxes back‑to‑back:
sur 23:42:33 → cham 23:42:57 → ist 23:45:09 (all Accepted password for root).ist as locksmith via publickey twice.
That dual pattern (real key for locksmith, then password for root on a sweep of three hosts) reads as an admin doing maintenance, but root‑via‑password (not key) on three prod hosts in three minutes is the exact shape compromise also takes. Need: was this you / Codrut / NWS admin? If yes, I'll save the IP as a known operator and stop alerting on it. If no, treat as confirmed compromise on all three boxes (rotate root, audit ~root/.ssh/authorized_keys and crontab on each).2. Spoofed‑sender reconnaissance against ecnfg.com using NWS hostnames as the From
IP 129.121.89.126 (Microsoft Azure US) tried 3 deliveries, walking through our cluster:
ist: F=<it@ist.nws.ro> → cook@ecnfg.comjah: F=<it@jah.nws.ro> → cook@ecnfg.comcham: F=<it@cham.nws.ro> → cook@ecnfg.com
All three rejected by sender‑verify. Same source, same single recipient, three of our hostnames burned as fake From‑domains — this isn't spam, it's somebody trying to BEC cook@ecnfg.com while making the mail look like internal NWS IT. Recommend: warn ecnfg.com's admin contact directly, and consider an outbound block on 129.121.89.126 at the edge.3. Reputation attack on nemesis.ro (NWS‑owned domain) at cham.nws.ro
Two distinct sources spoofing nemesis.ro From: addresses, all blocked by HELO check:
86.122.71.166 (HELO DESKTOP-5LMOQV7, looks RDS Romanian) sent <gabriel.draghici@nemesis.ro> — gabriel.draghici reads like a real person's address; could be a real Gabriel sending from a misconfigured Windows box, could be impersonation. Worth confirming whether that mailbox actually exists.185.169.4.10 sent <knickknackery@nemesis.ro> 3× in 30 sec; same IP came back at 13:32–13:33 EEST and sent <movieola@nemesis.ro> 3× in 30 sec.
185.169.4.10 is a persistent abuser of the nemesis.ro brand — recommend dropping it at the edge and submitting to abuse.4. Cross‑host SSH config drift: sur, cham, ist accept root via password — jah doesn't (that we can prove)
The three root‑password successes in #1 confirm PermitRootLogin yes (or prohibit‑password=no) on sur/cham/ist. jah had zero Accepted password for root events in the same 24h despite getting hit harder than the others (2 731 brute attempts from 183.52.220.171 alone). Either jah is hardened to key‑only root, or just nobody legit logged in there. Either way the three‑host root‑password practice is the higher‑risk side of the drift — recommend moving sur/cham/ist to key‑only root in the next maintenance window.
5. Acronis cluster: Ceph OSD down on ve1.nws.ro at 12:30 EEST yesterday — no recovery event seen in 24h
Single Zabbix trigger, severity 4 (Ceph OSD down detected, objectid 27853), value=1, no matching value=0/recovery in the last 24h of ingested events. Could mean the OSD is still down, or the Zabbix recovery just wasn't ingested by Tyrael. Worth a 30‑second check on ve1 Ceph health — if the OSD is genuinely down 19h later, that's degraded redundancy on Acronis.
Did NOT find (deliberately checked): any new cPanel/WHM account creations, any Imunify malware detections (every scan in 24h returned total_malicious: 0; the only "extended‑suspicious" uploads were product JPGs from gregorco/ist and a6/cham — almost certainly false positives), any SSH success matching a brute‑force IP from the same 24h.
Top question I need answered before this gets escalated: #1 — was 82.76.239.154 you?