Currently I have a compromised server (Ubuntu) that is running all services in Docker containers, but I found today a malicious program that was generating a DDOS attack.

I checked all services in Docker, and they are ok, they wasn't compromised, but the host was. I found an executable file /AAK in Ubuntu that I think it was the DDOS attack, and I found in the history of root the following entries:

netstat -antup
chmod 777 AA
chmod 777 AAK

It is clear for me that was the origin of the attack, and checking open ports on the server, a random 10XX port was open by this process, and another malicious process had a port open.

Another ports open: 80 (nginx in a Docker container), 22 (SSH, NOT using password, using keys instead), and 111 (was open by default and used by rpcbind).

How could I check how the attacker got root access to the server? If the application in a Docker container wasn't the origin, what could have caused this breach?

I don't want to recreate the server just to be hacked again using the same vulnerability.

Edit: Forgot to mention that I was using digital-ocean vagrant plugin.

  • I don't think they entered through one of the dockerized containers. Compromising the containers would have been fine for them. If we discarded sshd, rpcbind appear to be the only other (obvious) source, although ssh would be a much simpler way to enter into the server. What do the logs show? Even if you don't access to root using the password, passworded root access may be enabled in sshd_config – Ángel Jul 2 '16 at 22:53
  • @Ángel I have several entries like this one: CRON[#####] pam_unix(cron:session): session opened for user root – IAmJulianAcosta Jul 2 '16 at 23:01
  • 1
    those are normal. It means that a scheduled task was run as root. What about sshd entries? – Ángel Jul 2 '16 at 23:06
  • Only failed login attempts. – IAmJulianAcosta Jul 2 '16 at 23:15
  • 1
    A few years ago, DO had an issue in which they used the same key for all servers. This led to compromise of servers. I am not saying this is the entry point, there could be others. But if you pull the logs and look at root logging in, prevent root logins. Also you don't say when you last patched. – h4ckNinja Jul 3 '16 at 8:57

There are several methods you can investigate in order to answer your questions.

  1. Find the versions for SSHD and RPCbind and NGinx. Google each version for any remote or local exploits and vulnerabilities. The attacker could very well have used a blend of local and remote exploits or vulnerabilities, and not a single way to get in.

  2. Look through all the important logs (access, SSH, Kernel, etc) and try to pinpoint the closest you can when was the server compromised, and possibly how.

  3. Look through history files for all users, not just root.

  4. When were the files AA and AAK first created? Search through the logs in step 2 at least one week before those dates and look closely.

If you decide to rebuild the server, I would suggest to choose the most updated Kernel available, and close down RPCbind if not needed. Limit SSH to use Private Keys only (disabling all passwords as well). You can install many programs to check for file integrity right after the fresh install.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.