ClamAV Reports A Trojan

Home » CentOS » ClamAV Reports A Trojan
CentOS 4 Comments

This morning I discovered this in my clamav report from one of our imap servers:

/usr/share/nmap/scripts/irc-unrealircd-backdoor.nse:
Unix.Trojan.MSShellcode-21 FOUND

I have looked at this script and it appears to be part of the nmap distribution. It actually tests for irc backdoors. IRC is not used here and its ports are blocked by default both at the gateway and on all internal hosts.

However, I none-the-less copied that file, removed namp, re-installed nmap from base, and diffed the file of the same name installed with nmap against the copy. They are identical.

The question is: Do I have a problem here or a false positive?

I am not sure why nmap is on that host but evidently I had some reason last October to use it from that server. In any case I am going to remove it for good, or at least until the reason I had it there reoccurs or is recalled to mind.

4 thoughts on - ClamAV Reports A Trojan

  • If everything is rpm-installed you can say:
    rpm -q –whatprovides /usr/share/nmap/scripts/irc-unrealircd-backdoor.nse and see what package installed it and;
    rpm -Vv packagename to verify that the files still match what the package installed.

    (which, of course doesn’t tell you if the files are trojans or not, just that they came from a presumably signed package and haven’t been modified subsequently).

  • servers:
    distribution. It actually tests for irc backdoors. IRC is not used here and its ports are blocked by default both at the gateway and on all internal hosts. nmap from base, and diffed the file of the same name installed with nmap against the copy. They are identical. last October to use it from that server. In any case I am going to remove it for good, or at least until the reason I had it there reoccurs or is recalled to mind.
    /usr/share/nmap/scripts/irc-unrealircd-backdoor.nse that they came from a presumably signed package and haven’t been modified subsequently).

    I general:

    As both comparing checksums, perms etc of files with rpm database (rpm -V
    …) and just executing md5sum or sha1sum are executed locally on the suspect machine, all of these are not to be trusted. The best practice is to copy files over to trusted machine and run tests on the suspect file there. or better yet: mount drive from suspect machine on trusted machine. These would be general guidelines for forensics.

    In particular (someone more knowledgeable will correct me if I’m wrong):

    clamav is a scanner that is designed to detect viruses (virii I should use for plural as it is Latin word) that can attack MS Windows. In general, these viruses can not do anything to Linux system. Therefore, if clamav detects as “infected” one of the files belonging to Linux distribution, it should be considered a “false positive”. After all, it analyses/matches signatures of portions of file content. The only reason I run clamav on my Linux and Unix servers is to check e-mail, as some client machines can be Windows machines. Another portion of your filesystem you may want to scan for Windows viruses can be something dedicated to Windows machines, like SAMBA Windows share. Scanning the rest of your Linux of Unix machines does not make much sense for me.

    Just my $0.02.

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Hi,

    I believe this is definitely a false positive.

    Our mail server (CentOS 6.6) is reporting the very same “Trojan” on the very same file. I’ve already done our investigation and came to the conclusion it is a false positive based on a verification of files from RPMDB and also our intrusion detection system has not detected any changed files in /usr/share/ since before and after said “trojan”
    appeared.

    Top that with two people seeing the same thing at the same time in two completely different machines/companies chances are high its a false positive.

    Hope this helps set your mind at ease :-).

    Kind Regards, Jake Shipton (JakeMS)
    Twitter: @CrazyLinuxNerd GPG Key: 0xE3C31D8F
    GPG Fingerprint: 7515 CC63 19BD 06F9 400A DE8A 1D0B A5CF E3C3 1D8F
    —–BEGIN PGP SIGNATURE—

  • Thank you. We run aide on that box and it did not report any recent changes to that file. RPM and yum history corroborated the install date as being last October. We have concluded this is a false positive following a recent ClamAV update.

    We have none-the-less removed nmap from that host.

LEAVE A COMMENT