unSpawn asked for a follow-up.
although my team did not do a RCA that led to the vector of attack, we do know a fw rule was put in place during the install of the fw which opened many systems to the public on SSH (about 1+ years ago). SSH scanning was well underway when a few months back the compromised system was added as a static NAT to the fw, which inherently allowed SSH to the public due to the rules of installation.
customer installed a Nagios component using default uid/passwd and that account was compromised via a SSH dictionary attack. the attacker downloaded a 100MB file which looked to contain the data needed to create the files the attacker used to launch a UDP flood, a egress SSH scanner, and a IRC bot which connected to a Undernet IRC server in Tampa FL using.
The UDP flooder was a perl script. The SSH scanner was an ELF "pscan2", and we also found a ELF "hide" which could hide processes as alternate names.
There was a cron entry which would check daily for the existence of the ELF PID and re-launch if not found.
the system was an Oracle RAC cluster node, but customer deinstalled the node before i was able to look deeper into the Oracle stuff. however, there was no evidence indicating that the attacker files tried to query Oracle, nor were there any files that contained data the was present in the db. attacker only had limited access of the "nagios" account and thus had no access to db files directly.
the cisco IDS in place (module in ASA) is able to detect SS#'s, but since it would use to much resources such rule cannot be used (per crisco tac), so we were blind to that type of PII detection.
Last edited by Linux_Kidd; 11-22-2012 at 09:27 PM.