Hi there,Sorry to hear about the breach — it's all too easy to lose track of legacy VMs, and unfortunately, attackers love finding these low-hanging fruits.
Now, onto your main issue:
You're seeing files that can't be deleted even as root, and lsattr shows i (immutable) and a (append-only) flags, but chattr -i doesn’t seem to remove them — even though SELinux is off and you're on ext4.
This behavior strongly suggests that either:
The filesystem is being manipulated at a lower level — possibly with a rootkit or kernel module that intercepts and spoofs system calls. What you see with lsattr or chattr may not reflect reality because the kernel is compromised.
Immutable attributes are being re-set immediately by a background process or watchdog script set up by the attacker (common in sophisticated malware kits). You could try monitoring inotify events or using lsof to see if a specific process keeps reopening or resetting file attributes.
Root isn't root anymore — if capabilities have been limited or if namespaces/cgroups are used to restrict actions inside what appears to be a full root session, your control could be just an illusion.
How to proceed:
Boot the VM from a live ISO image or mount the disk elsewhere (e.g., another clean VM). From there, you can operate on the disk offline, bypassing whatever malware may be running.
Once mounted, re-check the file attributes and try removing the malware.
If you're not planning to keep the VM, wipe and rebuild is strongly recommended — CentOS 6 has been EOL for a long time and likely has many unpatched vulnerabilities.
Now, regarding your mention of HBA & Storage Controllers:
This reminds me of how malware can manipulate low-level I/O behaviors, much like HBAs (Host Bus Adapters) or RAID controllers https://serverorbit.com/hba-and-controllers/accessories/cach... do. In enterprise environments, HBAs with caching or advanced RAID controllers can "abstract" actual disk behavior from the OS — similar in concept to how a rootkit may abstract the truth of file attributes or presence.
Just like a RAID controller cache can buffer write/delete operations and present a consistent (but not necessarily real-time) view to the OS, a rootkit or compromised kernel module can present fake responses to commands like chattr, making you believe attributes are changing when they're not.
Similarly, if you’re ever dealing with corrupted or infected systems on bare-metal servers, it’s good practice to check whether the RAID controller cache might be holding onto data (especially with write-back caching enabled). Sometimes, malware can even hide in firmware or unused partitions, especially if BMC/IPMI has been exposed.
Вариант для распечатки
(ok), 03-Июн-25, 16:43 
