My droplet has been compromised and is sending an outgoing Flood or DDoS. What do I do?

Posted May 25, 2014 121.6k views
Here is some advice for trying to find evidence of virus and trojans on your server causing issues. Log into your server using the console in our control panel. The link looks like this: where XXXXX is your droplet's ID. You'll need a password for root, so if you don't have one please contact support for further advice. On the console once logged in, use one of these commands to try to find a unfamiliar process running: This command, if installed, shows programs holding open a network socket.
lsof -i
This command will show all running processes:
ps -ef
adding a pipe to a output paging program may help for long output, example:
lsof -i | less 
ps -ef | less
This command, if you replace XXXX with a Process ID (PID) will show you the path to a executable file that is the origin of a process:
ls -al /proc/XXXX/exe
Common places trojans hide are /boot /tmp /run and /root. This command you can list all content, including "dot files", in /boot
ls -al /boot
If you find something you know is foreign, check the ownership of the files for hints on what user privileges were used to instal the code, kill the process, remove the files, and review your log files to try to find out how the code was installed so that you can work on preventing it form happening again. If you need any advice, send support whatever data you are looking at that you need help with and they will try to point you in the right direction. The best way is to screenshot the console showing the data you are uncertain of, upload to a file sharing service (ex:, and send the URL in the ticket. Some programs that may also help are:
  • rkhunter
  • chkrootkit
  • maldet
  • clamscan
If you can't find anything, let support know via a support ticket for advice. If you have success finding stuff, post your results here to help other people, and if you have suggestions for updates to this please add a comment below! Regards, Will Support Agent DigitalOcean
  • How can I do this if I can’t ssh, or anything to the droplet!!!!!

    I use git for transfering code to the droplet, and I’m making a web page for a fotographer so OF COURSE there are big files getting in and out.

    I think is so very irresponsible of you to just lock the droplet because of this. I have the customer on the phone complaining why the site is not updated and up, and I can’t do anything because you don’t even answer to my ticket ffs!!!!!

  • A famous columnist write my website on newspaper and also he gave a link. Therefore a lot of people want to reach my website but you stopped my service. It was not attack.

    You don’t answer to my ticket.

    Thanks Digital Ocean you are so professional.

  • How to get my files back if network is disabled?
    How can I test if I solved the problem without network?

  • Google sfewfesfs if your droplet compromised. I met this problem recently.

  • Show 6 more comments

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

42 answers
Hey Sikora,

The most common reason that we see Droplets compromised is as a result of a weak root password. One thing we recommend is making the switch to using SSH keys, which offer far greater security (and the extra benefit of never having to wait for a password e-mail!)

If you need any help with setting them up, we have a few guides on using them:

Of course, if you have any specific questions, or get stuck anywhere, we're happy to help you in a support ticket.

We also have a great guide on basic security steps here:

DigitalOcean Support
by Justin Ellingwood
Linux security is a complex task with many different variables to consider. In this guide, we will attempt to give you a good introduction to how to secure your Linux server. We will discuss high-level concepts and areas to keep an eye on, with links to more specific advice.
  • So… This didn’t prevent an ‘attack’ on my droplet… I only ever use SSH keys - which of course means that I cannot log into the console since I have no password and I can’t get in from SSH since you’ve killed the network - gj! :)
    DO should probably analyse their network stack a bit better imo before pointing the blame at droplet owners…

could you please offer copy-paste function on the web-based console? It’s extremely painful to do inspection on the console without this!

I got hit by this in the last days. The attack seems to use methods similar to the one described here In short - a Java application that do not sanitize input that is later evaluated as an expression in either OGNL or MVEL scripting engines. Nothing to do with the DigitalOcean security.

In my case I had ElasticSearch bound to all network interfaces leaving it open to the world. ElasticSearch allows for scripting in some of its queries so that's for me the most probable entry point (no proof though). I also had a Jetty server running with a small java application, that's my second probable point of entry.

I've set both java processes now to bind only to local interfaces.

Some more reading (in chinese, but there are links and code samples) :
Maybe follow the guide they gave you..

Block the droplet network its an insane action. At least you should notify with 2 or 3 days before. Specially when the support team takes more than 2 hour to reply.

I’m so frustrated. Also moving to vultr.

Look this is totally wrong who is this company CNSERVERS LLC who is attacking any of servers on Digital Ocean, looks like this company work to stop DDoS but they first DDoS you as happen to me right now

“[ SYN flood ] ( dropletID: 3584777 ) –towards–> [ CNSERVERS - CNSERVERS LLC,US ] 2417 mbps, 333586 packets/second”

why i should attack this Company CNSERVERS LLC why this company is company who offers DDoS support ? why this one why not something else but this company ?

Digital team need to take look deep on this not just stop servers.


Does this really feel professional My server was disconnected at 11:44 and it’s almost 12:44 where i am running a huge news site on your servers and i don’t get a single response to multiple comments that i have dropped on the ticket.

This is really not appealing i will be moving to a different provider soon if this goes on

Thanks, Justaguy, this actually *is* the guide ;-)

I'm a Support Agent of DigitalOcean, and in the past 48 hours we've had to lock a lot of droplets for SYN and UDP floods, and this was the best way i could find to put it up some guide at a public URL that i could continually edit and tweak as more information and feedback came in.

Support Agent
Hi Will,

Any insight as to why you've had to lock so many droplets? We just had ours locked and we're looking into the cause. Any insight would be great.
Found out there are strange files running on /boot
.Iptables and .Iptablesx

It seems to be a general issue on DigitalOcean, I'm wondering if the attack happened due to some lack of security on our side or some other backdoor that's out of our reach.

Will, do you guys have any more information about the attacks?
We too have just had our droplets locked and these were practically brand new droplets. All of our droplets are managed by SSH keys. On the particular droplet the "SYN" attack originated from the only access was with ONE ssh-key (from my local Macbook). It's extremely unlikely my Macbook has been compromised.

Could this perhaps be a security issue on digital ocean?
Same problem here, root password is not weak at all, one ssh-key.
As a plus I cannot connect to the droplet using web console, there are some strange errors (iptables related, segmentation faults....) and I cannot login to investigate. What can I do? I don't want to loose my droplet!
Thank you
Hey Mirko,

I've just updated your ticket. There is a trojan known as IptabLes and IptabLex. You will likely be able to find it in your /boot directory, and by doing lsof -i.

There will be hidden files in your /boot that you will be able to find with:
ls -lah /boot and remove as necessary.

We can assure you that it is not a result of any security issue on our end- the most likely cause is some manner of vulnerability in software you have installed, or a weak password. Another possibility is some software you have used being misdiagnosed as abusive traffic due to extreme bandwidth usage.

An interesting thought would be that our Elasticsearch database has auto-cluster turned on, and is in dev mode. (I.E; Not production ready). It will auto-join any other clusters on the same private network. It could be that an attacker used digital ocean's private network feature to exploit this ES auto-cluster feature and run some sort of javascript exploitation.
as reference for others with the same problem with Iptables/Iptablesx trojan:
- log to your droplet via web console
- if there are some strange errors (from the trojan) simply press ctrl+c to clear
- remove all trojan related files (I followed this guide:
- reboot
- ask support service to enable back your network interface
- install a firewall (this one is very easy to install:

thanks to support service!
My droplet too got DDOS attacks. Never changed anything in the droplet since 4 months. I had to restore from an old image. Lost some data. I have not had problems before except only once with the same issue. I am wondering if its a problem with DigitalOcean security?
Pavel, this confirms my suspicions of someone using ElasticSearch or more directly Java - to run malicious code. The auto-cluster feature likely just helps the attacker in finding other droplets using the private networking feature on DO.

Perhaps you could write a quick snippet up on how you told ES to bind to local interfaces only. It could help others here.

-Levi Roberts (Towner Co-Founder)
You can set "" in config/elasticsearch.yml to bind both the transport and the http layers on localhost only. Use "" if you only want to bind the http layer on localhost.

If you need to securely scale an elasticsearch cluster you might have to create an unicast discovery provider for digital ocean. See how it's done for the google compute engine -

Otherwise if you're running a limited number of nodes, just use unicast with the relevant firewall rules. The ES configuration should be something like this: false [“ip1”, “ip2”, "ip3"]
A simple solution to having a backup or Snapshots Drop support and ask to reserve the IP that is in use then destroy gout problems and create a new drop in the same region of the left Snapshots picture you have.
Another issue that has been reported is a vulnerable tomcat installation; one customer has passed along this as a potentially useful guide if your droplet has been locked and you were running tomcat:
vbamba; the security of servers is beyond the responsibility of digitalocean; they have no access to your servers and thus all security would be the responsibility of the client. there's also a difference between your server getting a ddos and your server doing a ddos; if you get a ddos the admins would likely blackhole your IP to prevent the traffic from flooding the network segment your server is on. in the case of an *outgoing* ddos, its almost always because there was a vulnerable piece of software, or weak password for root, a weak password for your VNC service, a mis-configured or weak password for Wordpress Admin, or many more reasons - and then someone used that vulnerability to install a virus or trojan.

My droplet just stopped, I assume because of ElasticSearch vulnerability. Can anyone please give instructions how to recover and prevent the problem?

Has anyone been infected by something else than Iptables? I cannot find these files anywhere

Ok so here is what I’ve found:
‘lsof -i’ reveals a suspicious process
.Linux_ti 26006 elasticsearch 3u IPv4 185516 0t0 TCP> (ESTABLISHED)

'ls -al /proc/26006/exe’ to identify it
lrwxrwxrwx 1 elasticsearch elasticsearch 0 Jul 8 06:54 /proc/26006/exe -> /tmp/.Linuxtimey_2015 (deleted)

By looking up the IP, it is known to be suspicious:

The IP address “” is located in the following region : Beijing, Beijing, China


Organization : CHINANET Guizhou province network

ASN : AS4134 Chinanet

Country \ Country Code : China \ ( CN )

City \ City Code : Beijing \ ( 0 )

Region : Beijing

Local PostCode :

Latitude : 39.9289

Longitude : 116.3883

Reverse domains on the same ip address(,,,,,,,,,,,,,,,,,,,,,,,,,

Reverse domains on the nearby ip address(,,,,,,,,,,,

other suspicious IP

ISP: China Telecom Jiangsu
Host Name:

Same here found /tmp/.Linuxtimey_2015

I assume all passwords are likely compromised from this attack?


Found the same files, plus a perl script which enabled shell access. ES was the entry point.

Here’s a link that we found which explains the Elasticsearch vulnerability and how to patch it:

Look for the section that says “How to secure against this vulnerability”

It’s very likely that this server is backdoored and cannot be recovered through normal means. This is a vulnerability that was always present with Elasticsearch, and your server was recently a victim of this compromise. This issue is not isolated to DigitalOcean.

Look for a tmp/ script that looks like this: … It appears to download a script from a server to then look for an exploit based on specific versions of the Linux kernel (hence the checking of uname and the whole if/else stuff there trying to get the appropriate exploit). This means that your system may not have actually been vulnerable or compromised depending on your system.

In fact, if you take a look at that pastebin (not mine, I just found it btw – so hopefully it’s still there). Line 10 has a call to actually remove the shell script (I assume in an attempt to cover up its tracks). So if you see the script on your server in /tmp … Then likely it was never executed, right? Because one of the first things it would have done would be to remove itself. So again, seeing that file doesn’t necessarily mean it ran and/or you were hacked.

However, that file does mean that something allowed it to be put there. Potentially Elastic Search exploit and potentially not. It could be something else. For example, do you have any scripts that allow user uploads?

We all like to jump to conclusions, but the fact is there’s soooooooo many possibilities at play. The best and safest course of action, if you believe your system was compromised (or if Digital Ocean believes it was), would be to bring on a new server and changed any passwords, API keys, SSH keys, etc. that were on the system.

Another place you can check is your .bash_history file to see if any commands were issued that you don’t recognize or don’t make sense. Yet another place to look would be at /var/log/auth.log (or /var/log/auth.log.1 etc.).

In my case I saw the same IP address in that script trying to SSH in via root user for a very long time (days, weeks maybe). All failed. So if I were more on top of things (or if I remembered to install sshblack on this machine…Like I typically do but didn’t in this case) this wouldn’t have gone on. Either way, there appeared to be no brute force breach in my case.

I would suggest using sshblack:

As far as that .Linuxtimey_2015 file is concerned… A quick Google search shed some light there:

This was an exploit in May. Look at that for timing…Right? So that fits…And after reading through that, you may then want to look for files in /etc/init.d that it may have created (listed on that page). Possibly /usr/bin/bsd-port/getty.lock as well. So if you don’t see those files, again, you may not have been vulnerable. Again, take safe precautions here.

I had the same problem. I tried accessing the droplet through console, but I am using SSH keys. I was unable to access the console through SSH keys, and opened a ticket with digital ocean, to reset the password,but unfortunately, they just do not respond. More than six hours now and no response. It is really bad.

  • Finally got a response, they reset the password. I inspected everything in the droplet. No IPtables issues, and I don’t have elasticsearch installed. I use only ssh keys to access the droplet. The funny thing is that I used the graph tool from the control panel, and not strange spikes in traffic seems to be at the time of disabling the interface !

I do not use elastic search. I did not find any iptables or other mentioned problems. The server was almost brand new (12 commands as root in history). However, history revealed that somehow, someone gained root access and ran the following:
chmod +x ssh66
chattr +i ssh66

That IP is in US (Whichita) but if you open the binary you will find some IPs in China. I suspect this binary was the culprit. However, I do not know how they gained root access (stock debian with few things installed like supervisor, nginx, postgres, mongo)

ps -A |grep ssh66
kill ssh66
chattr -i /root/ssh66
rm /root/ssh66

This does not seem sufficient to stop ssh66 yet. I still saw it in top. Also
killall sshpa
rm /etc/ssh/sshpa

Anyone else experience this?

These are suspicious IP addresses found in the ssh66 binary. They seem to be located in China:

I have more boxes with Rackspace and Linode. this is the first time I have this sorta problem
(SYN Flood Detected) anyone else has any similar experiences ?

I was also hit with this DDoS attack last night. After reviewing server logs, i found two new files had been added to my /root directory:

  • fake.cfg
  • gonne-sysadmin-admin

After speaking with DO, they mentioned at least one other droplet had these files added and they believed it was connected to this attack.

I don’t have ElasticSearch and I’m not seeing any of the .lptables issues that others have mentioned in this thread.

I have wordpress installed on this droplet using the one-click install. Thought I would mention that in case anyone else has had this same issue and has the same setup.

Three days ago I received the notification that my droplet would be blocked due to it sending DDOS attacks. The droplet is very small, only running 2 small ghost blogs. I’m still new learning on how to develop and I have past the last days trying to figure out what happened.

Using the function “top” I found that a process called MFXRHBSAU was sucking up 40% of the CPU. I followed the instructions here and deleted the folder that MFXRHBSAU was located. It was in a ghost theme that I recently had installed from github ( and also in the /root folder). Seconds later a new folder appeared in the /root folder and a new process also started showing using the same CPU power and with a just similar random name. Every time I deleted the folder or killed the process a new one showed up.

I searched for tips under the logs to what was happening and saw that for the past week I have been under strong attempts of logins from China each minute or so. Right now I’m without a clue on how to continue investigating the source of the attack. Any help on how to proceed to eliminate this threat would be more than welcome.

Also, I uploaded screenshots of the console with the informations of lsot -i, top and the other attempts that I made trying to find the source:

Thank you very much!

wow DO ?? its my first time using vps on ur server.. i installed server then download much package in my server from outside to, but 12 hours left u said its DDos and flood attack? how can? it my 1st time server setup and not published to public???? now i need to work u still disable the server? T__T’

I also found some suspicious files, created by elasticsearch user, inside /tmp/, which I deleted.

My droplet was block today as well. Trying to figure out what happened, did all proposed steps in this article and provided links - everything were looking OK.

I’ve checked my fail2ban log - were a lot of ban/unban the same scope of IP addresses, from all around the globe.
But again, no strange processes, no strange files in directories…

Except one, /tmp/.tmp
The content is:

-rw-r--r-- 1 nobody nogroup  129462 Jan      7  01:48  5k.txt 
-rw-r--r-- 1 nobody nogroup        1192 Dec  20  20:03  e
-rw-r--r-- 1 nobody nogroup        1135 Jan     7   01:33  new.html
-rw-r--r-- 1 nobody nogroup        490 Jan     7   01:49  ok
-rw-r--r-- 1 nobody nogroup  238443 Jan     7   01:55  okay

5k.txt - is the list of 5k email addresses
e - the perl script to send emails
new.html *- email content
- getting the e file from remote host log, the remote address is

with ip address
okay - the log of sent emails

crontab doesn’t have the record to start this e script. SO, I assume that is one time script… or I miss something and there is a way to relaunch it?

Wow, this seems to be rampant within Digital Ocean. I’ve run instances in Amazon Web Services for years and have thankfully never encountered this problem.

My droplet was also “severely root compromised” 2/2/15 as described by the support person Gd, but he/she could not provide any concrete data. All I’ve received so far is “We have seen this type of flood many times, and it is usually from a severe compromise of a droplet.”

How did she/he know I was running MySQL unless he/she was able to log in?

After running

ls -al /tmp

I discovered to suspicious file: fake.cfg and koi owned by my tomcat user. fake.cfg was empty and koi was unreadable. Someone got access to my tomcat manager and uploaded malicious content.

This will be the first and last time I skip the step of changing tomcat users.

Help me please, my server lose connection or disable.

Can you help me,
because my data in droplet very important.
2 years i use digitalocean, but my server and data lose everything.

im sad, ticket not respon.
:( help me.
pleaseee, help me pleasee.....

Hi all,

I received a message from DigitalOcean saying one of my droplets is attacking over servers over ssh.

Spent the last hour or so working out what happened. It turns out one of the server users was hacked by brute forcing the password and set up cron jobs to repeat the process aimed at other servers.

The fix was to delete the cronjobs created for the user

crontab -r Deletes all cronjobs for the logged in user

Deleting the cronjobs is important because if you reboot your droplet, the cronjobs setup the droplet to attack again after a reboot.

There was also some strange entries in a hidden folder called .ttp. Deleted these for good measure as well.

To prevent this in the future, I’ve setup ssh keys on the droplet so no one can brute force any of the users. Also setup some alerts to catch the CPU going above 80% for a set amount of time. The droplet CPU was maxed out at 100% for days whilst it was hacked, this should give me a heads up in the future if anything strange happens.

Hope this helps someone in a similar position.



THIS CUSTOMER SERVICE IS NOT FAST RESPONDING. I send email 24 hours ago, my application is urgently needed to be up again.


Submit an Answer