Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Anyone know this Linux Trojan? (Linux.DDOS.Flood.L)
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Anyone know this Linux Trojan? (Linux.DDOS.Flood.L)

tdttestertdttester Member

I have been suffering network problems for some days on one of my linux servers.
Today I have located an strange process in execution: VSE55000LML
I have located that it seems the binary source on /tmp/CCTV.SO file
Analyzing this file with some antivirus, it seems there is a Linux Trojan called: Linux.DDOS.Flood.L, Linux/BackDoor_c.CL, ELF:Elknot-AS [Trj] and some more names (depending the antivirus software).
I have mitigated the effects just killing the VSE55000LML and compressing the CCTV.SO file.
But I don't know what does this trojan and what's the exact method to clean it from the system.

Does anyone know anything about this?
Thank you.

Comments

  • ATHKATHK Member

    Reinstall your OS.

  • @ATHK said:
    Reinstall your OS.

    Why? Do u know this trojan?
    It's so dangerous?
    It's a production server with alfresco, tomcat, java, etc...
    Not easy to reinstall.

    Thanks.

  • AmitzAmitz Member
    edited May 2015

    Rule #1:
    Always reinstall a compromised system. Especially if it's a trojan. It does not matter how much work this causes. It is inevitable. Your system is compromised and you cannot "repair" this by deleting or isolating single files. Do you have backups (you normally should) from before the infection?

    Thanked by 1Clouvider
  • Reinstallaing is the most correct way. It's usually easier to reinstall than to clean trojan's from system. However most of them are very primitive and can be cleaned from a live system if there are no way for reinstall.

  • @Profforg said:
    Reinstallaing is the most correct way. It's usually easier to reinstall than to clean trojan's from system. However most of them are very primitive and can be cleaned from a live system if there are no way for reinstall.

    It's a goog idea to inspect the entire system with clamav for example?

  • ATHKATHK Member

    @tdttester said:
    Thanks.

    Its obvious your system has been comprised and a Trojan has been installed, reinstalling is your safest bet.

  • tdttester said: It's a goog idea to inspect the entire system with clamav for example?

    Antivirus programs can only catch so much. ClamAV may give some insight into this trojan (by checking the files in quarantine), however it won't give insight into how the trojan came to be. As everyone else mentioned, re-install and do a thorough hardening.

  • tdttester said: It's a goog idea to inspect the entire system with clamav for example?

    Unfortunately, clamav is rather useful against trojans. Manual inspection is the only way.

  • ClouviderClouvider Member, Patron Provider

    I agree with @Amitz you can put some sort of trojan in many files, it may be bespoke enough to remain undetected.

    To be safe, reinstallation of the OS is the only safe way.

  • hellb0yhellb0y Member

    Double check all hidden dirs in /tmp /var/tmp and /dev/shm . It looks like there is a flood bot installed and running on your system. Install rkhunter and do a deep check. Check users files to see if any recent changes ( check manually all users accounts hidden dirs and delete the compromised one)

  • jarjar Patron Provider, Top Host, Veteran
    edited May 2015

    You might check ownership first. For example, I would almost never reinstall a system due to a trojan file owned by my web server user, when I'm confident there are no reasonable methods of privilege escalation. This takes attention away from web application issues and may result in a vulnerable system being configured on reinstall. Being in /tmp, it is entirely possible this is not a root level compromise, making it far easier to isolate, find the point of entry from access logs, destroy it, and patch it.

    Otherwise shared servers should be reinstalled every time someone fails to update a wordpress plugin, which could then be argued to say that a VPS host should migrate people and reinstall the host OS because "you never know what you don't know," that's just not reasonable :)

    Thanked by 2netomx howardsl2
  • Try ClamAV.

  • @ATHK said:
    Reinstall your OS.

    Or just do rootkit hunter, see if theres a rootkit.

  • joepie91joepie91 Member, Patron Provider

    KwiceroLTD said: Or just do rootkit hunter, see if theres a rootkit.

    That's prone to the exact same issues as "just doing a virus scan". These tools are not infallible. You have no way of knowing how far the malware has spread.

    Reinstalling is the (only) correct option here.

    Thanked by 1netomx
  • time4vpstime4vps Member, Host Rep

    @joepie91 said:
    Reinstalling is the (only) correct option here.

    Re-install, backup restore or just hire experienced Linux system administrator (example: Rack911).

  • joepie91joepie91 Member, Patron Provider

    time4vps said: or just hire experienced Linux system administrator (example: Rack911)

    Who will probably advise you to reinstall and restore a backup :)

    Thanked by 1netomx
  • sinsin Member

    If I were you I would do like everyone else has said and reinstall, there's no way I would put anything on a server that has been compromised.

  • @joepie91 said:
    Who will probably advise you to reinstall and restore a backup :)

    How can he be confident that the backups aren't infected. It seems to be that he discovered the infection just now, but that it could've been running for many days. Unless he can find out exactly when he got infected, it could be in his backups too, couldnt it?

  • joepie91joepie91 Member, Patron Provider

    @joelgm said:
    How can he be confident that the backups aren't infected. It seems to be that he discovered the infection just now, but that it could've been running for many days. Unless he can find out exactly when he got infected, it could be in his backups too, couldnt it?

    Depends on what you restore. If you just restore the static files and database backup (assuming you're not running anything that executes PHP from the DB, which you're hopefully not...), you would likely be fine. Of course caution should still be taken.

  • jarjar Patron Provider, Top Host, Veteran
    edited May 2015

    @joepie91 said:
    Reinstalling is the (only) correct option here.

    They found one file in a directory has a high possibility of a 777 permission level. This could totally be a compromise below root level. Investigation should be done first. Else, they likely have a compromised web app that they will almost certainly restore with the vulnerability in place to their new server anyway, and the reinstall may be for absolutely no reason. You can know how far something spread below root, I've cleaned hundreds (if not thousands) of comp'd Wordpress installs without wiping out hundreds of other clients with a CentOS disk. Some included files in /tmp on a cpanel system. That reinstalling the OS is the only option, with the information we have here, is simply not a reasonable position. No offense :)

    If it's root owned then yeah, reinstall. Who knows where it's gone from that point, a root comp should be met with fire.

    (I recognize that privilege escalation is a thing and make all assumptions that packages are updated to reduce the chances, as well as the assumption that the process would be running as root if the intent was ever privilege escalation)

  • telephonetelephone Member
    edited May 2015

    @Jar That may be the case for you, but we're assuming the OP does not have as much Sysadmin experience.

    You're also comparing apples and oranges. A compromised WP, will usually have dozens of online articles, reports, or FAQ documenting the issue. Where as the OP's problem has ZERO useful articles to reference the issue.

    Yes (s)he could be the first to document this trojan. We could instruct the OP to run various commands to track down the source, but without physical access it's easier to instruct them to issue a re-install.

  • jarjar Patron Provider, Top Host, Veteran
    edited May 2015

    @telephone said:
    Jar That may be the case for you, but we're assuming the OP does not have as much Sysadmin experience.

    You're also comparing apples and oranges. A compromised WP, will usually have dozens of online articles, reports, or FAQ for fixing the issue. Where as the OP's problem has ZERO useful articles to reference the issue.

    Yes (s)he could be the first to document this trojan. We could instruct the OP to run various commands to track down the source, but without physical access it's easier to instruct them to issue a re-install.

    What the virus is named usually doesn't matter as much as what it does, what privileges it has, and where it came from. New ones pop up all the time, but that doesn't mean that it had any reasonable access to root on the system. You're looking at it from the virus name, but you should be looking at it from how it got there, what privileges it has, and what it does. These things they can know by stat, log investigation, possibly by simply reading the code, and strace. If it came in through a web app, it's no different than any of the WP comps I've dealt with. I never google searched any of them and rarely bothered to ask ClamAV for a name. The process would be mostly the same.

    But if you want articles, I bet there are a TON of articles about the point of entry, once that is found.

    I always assume someone is capable of dealing with it but just needs some advice. Why not teach people to solve problems instead of say "Well you're probably too dumb to investigate this so just reinstall."

    Teach people how to Linux. We're all better off for it. :)

  • joepie91joepie91 Member, Patron Provider

    Jar said: Else, they likely have a compromised web app that they will almost certainly restore with the vulnerability in place to their new server anyway, and the reinstall may be for absolutely no reason.

    And that is why you put a clean install back in place, restore custom code from version control, get the codebase audited, and only restore static assets, database, and other things that are extremely unlikely to have been affected.

    Jar said: You can know how far something spread below root, I've cleaned hundreds (if not thousands) of comp'd Wordpress installs without wiping out hundreds of other clients with a CentOS disk.

    As far as you know. I doubt you've audited the entire stack.

    Jar said: (I recognize that privilege escalation is a thing and make all assumptions that packages are updated to reduce the chances, as well as the assumption that the process would be running as root if the intent was ever privilege escalation)

    Those are dangerous assumptions to make, and I don't see why you're seemingly leaving out this consideration in the rest of your post.

    Thanked by 1jar
  • jarjar Patron Provider, Top Host, Veteran
    edited May 2015

    (Let me clear that I'm not "arguing" but rather discussing, as @joepie91 is good people)

    joepie91 said: Those are dangerous assumptions to make, and I don't see why you're seemingly leaving out this consideration in the rest of your post.

    Because if we assume that everyone can run with privilege escalation at any time, we have to consider all servers (or especially shared ones) compromised at all times. It's just not reasonable. You have to draw a line on the "what if" part somewhere. When you know who owns it and how it got there, you can reasonably determine the scope of the situation. Someone can always come along and make up "Well what if it did this thing that I can't prove it did and I don't really know how it would have but maybe the developer knew something that none of the rest of us do." That it can be suggested does not automatically make it the reasonable, logical train of thought. It certainly doesn't make it the standard for how someone should react, because then we just have to assume that everything is always compromised at all times, or at least consider it compromised the moment someone makes a suggestion that cannot immediately be disproven. A theory like that should be based on actual knowledge of the stacks/versions.

    I believe it should be a healthy assumption that people keep their repo controlled packages up to date as long as this assumption is made known so that the relevant party has the opportunity to say otherwise. I would like to assume that they would not be managing a server if they do not. Maybe I'm just an optimist these days ;)

    joepie91 said: As far as you know. I doubt you've audited the entire stack.

    So when someone doesn't update Wordpress on their shared host, your honest belief is that the only correct course of action is to wipe out every customer and tell everyone to start fresh? I mean we have to be reasonable or we can never accomplish anything. When there are no known vulnerabilities in your stack and the problem is isolated to a user, you can reasonably assume that the problem is isolated. It doesn't mean you don't monitor system activity, of course you still do that. It doesn't mean that there isn't some magic unicorn virus that hasn't worked it's way into everyone and everything, but if you make that assumption about everything then you have to simply consider all systems compromised, admit that you're either the smartest human of all humans (so that no one can outsmart you), or you are unfit to manage servers. The key here is within reason.

    joepie91 said: And that is why you put a clean install back in place, restore custom code from version control, get the codebase audited, and only restore static assets, database, and other things that are extremely unlikely to have been affected.

    Sure, but "just reinstall" is what this guy is being told here, and you and I both know that if this is an isolated issue, this advice could very well be equal to telling him to simply delete the file. If that happens to be the only file created by a direct exploit of his web application and "reinstall" is the only advice he follows, it is functionally equal to simply deleting that file if he creates a brand new stack and installs the same stack/app/version.

    I'm simply stating that the situation is not as simple as "just reinstall." It can sometimes be a quick fix, but it is far from what a system administrator should actually be doing. I stand by the idea that we have an opportunity to teach people to handle things properly, and I dislike giving people advice that could land them in the same situation, therefore wasting a lot of their time and teaching them nothing about how to approach the issue in a healthy way.

    So basically my suggestion is that they stat the file, find out who owns it and what time it was last modified. If that happens to be a low privilege user, investigate the logs of the services being run by that user to see if you can find the point of entry. If you can determine where it came in at then you may be able to follow the trail of activity. At that point would be the best time to make a decision on whether you can reasonably extract it's remains from your application and any directories that user could access, or whether a reinstall would be best followed by full evaluation of the web application. At least, by that point, you should hopefully have some knowledge of where improvement needs to be made.

    Of course, if it's root owned, just nuke it. Save logs and bash history, maybe you can find something to go on but anyone half decent is going to wipe vital evidence from root.

Sign In or Register to comment.