06/10/2009
ossec to the rescue
That’s why I love ossec:
OSSEC HIDS Notification. 2009 Oct 06 17:45:17 Received From: XXXX->rootcheck Rule: 510 fired (level 7) -> "Host-based anomaly detection event (rootcheck)." Portion of the log(s): Rootkit 'Suspicious' detected by the presence of file '/var/www/vhosts/YYYY.com/httpdocs/album_mod/.. /.../.log'. --END OF NOTIFICATION OSSEC HIDS Notification. 2009 Oct 06 17:45:17 Received From: XXXX->rootcheck Rule: 510 fired (level 7) -> "Host-based anomaly detection event (rootcheck)." Portion of the log(s): Rootkit 'Suspicious' detected by the presence of file '/var/www/vhosts/YYYY.com/httpdocs/language/lang_english/ /... /.log'. --END OF NOTIFICATION OSSEC HIDS Notification. 2009 Oct 06 17:45:17 Received From: XXXX->rootcheck Rule: 510 fired (level 7) -> "Host-based anomaly detection event (rootcheck)." Portion of the log(s): Rootkit 'Suspicious' detected by the presence of file '/var/www/vhosts/YYYY.com/httpdocs/language/ /... /.log'. --END OF NOTIFICATION
Just found this by copying some files for a client from his previous hosting company to one of the hosting servers of a company I work for.
There were actually 2 different sets of files.
The first one contained a tool that “hides” a process, called: “XH (XHide) process faker”, and the second one contained an iroffer executable.
Files:
i)xh-files.tar.gz
Listing:
.log/
.log/.crond/
.log/.crond/xh
.log/week~
.log/week
ii)iroffer-files.tar.gz
Listing:
.--/
.--/imd.pid
.--/imd.state.tmp
.--/imd.state
.--/linux
Mind the . (dot) of the directories containing the files.
Filed by kargig at 22:01 under Linux
Tags: iroffer, Linux, ossec, process hider, rootkit, security, vulnerability
2 Comments | 9,960 views
[…] This post was mentioned on Twitter by Alexos. Alexos said: RT: @danielcid: ossec to the rescue: http://bit.ly/IIIta […]
There is one thing to consider, however. You mentioned that Sguil didn’t alert on this traffic, which could pose problems if analysts rely on one ‘main’ tool to begin the investigative process. This has been a long-time problem with IDS tools; if a signature doesn’t exist, the security event may not be ‘caught’. The longer I work with an IDS centric defense approach, the more I see it as a shortcoming in attempting to detect security events on a network or infrastructure. SAGE SysAdmin #12 “Building a Logging Infrastructure” and “Security Log Management” by Sygnress help to show that IDS data should only be one of several inputs for the alerting process. Unfortunately, Snort doesn’t widely detect rate based attacks (DDos, unless looking for a specific type of packet related to one), and could lead to a late arrival in detection and defense. Understandably, nothing will catch everything, however, utilizing tools that rely on ‘signatures of known activity’ may not be the best approach either. Taking in IDS data, along with other network events (such as traffic throughput and host logs) to generate an alert, and then using session data for verification, may be a better way to tackle the problem.