On 2014-07-31 21:45, Larry Linder wrote:
> Next It is back:
> Removed all of the files that are in / , /boot, usr/, /etc/rc.d/init.d
> It has set up files again in /boot.
> new IptabLes and IptabLex are now in /etc/rc.d as well as in /etc/rc.c/init.d
> 
> I built and run the "rpm" script and the number of UNVerified pretty large.  
> The common thing was that they all had to do with "iptables", and other 
> security files.
> Since I have reloaded the OS once and it came back.  I will lowlevel format 
> the disk and reinstall and change all passwords and permissions.
> The bad part is that the major disks containing our engineering files for last 
> 15 years may also have the program burried somewhere in the 39 G.
> There are also a number of new ports added to the system - !
> The only real file I saved from the old OS was the CUPS configuration file.
> I examined them but did not see anything that should not be there.
> Will have a list of rpm verification failures tomorrow.
> There were a couple of failures that dealt with "samba" - so they were able to 
> gain access to the M$ systems as well.
> The thing that has me worried is that they are changing things each time it is 
> back.  Slight differences.
> The US should just unplug China from Internet and a lot of the problem goes 
> away.
> To night we will simply unplug the box.
> 
> On Tuesday 29 July 2014 10:07 pm, Brandon Vincent wrote:
>> On Tue, 2014-07-29 at 17:23 -0400, Larry Linder wrote:
>>> If anyone is interested I will share the details.
>>
>> Larry,
>>
>> Are you running Apache Struts, Apache Tomcat, or Elasticsearch by any
>> chance? Please review CVE-2013-2115, CVE-2013-1966, and CVE-2014-3120 to
>> see if any of these apply to your system configuration. This type of
>> infection is typically due to the aforementioned vulnerabilities.
>>
>> As for removal, find and remove the following files with the system
>> offline:
>>
>> /boot/.IptabLes
>> /boot/.IptabLex
>> /usr/.IptabLes
>> /usr/.IptabLex
>> /etc/rc.d/init.d/IptabLes
>> /etc/rc.d/init.d/IptabLex
>> /.mylisthb*
>>
>> Let me know if you have any more questions.
>>

Removing only the files is useless until the process writing the files and the compromised binaries are identified.
Hide a process or files can be done with a simple statements, e.g.

echo "alias ps=/bin/ps $@ | grep -v malicious process" >> /etc/profiles.d/$random_file or /etc/bashrc or ...
echo "PATH=$malicious_binary_path:$PATH" >> /etc/profiles.d/$random_file or /etc/bashrc or ...
...

On a not compromised system copy ps, top and other utils to a read only medium (cdrom, even creating an iso would work)
E.g. ps -> $medium/new_p_s_$SHA1, top -> $medium/new_t_o_p_$SHA1

Now use the fresh tools to find the process writing this files, some examples how to monitor the file system can be found on
http://www.linuxquestions.org/questions/blog/unspawn-2450/rootkit-hunter-iptablex-iptables-36083/

Scan with a livecd, clamscan an the rhkunter signatures will not harm.

If you search for "/boot/.iptablex" you will notice you are not alone but it seems no one has identified how the infect was done.