1

This question already has an answer here:

Misc Situation:

-Server login is obtained by hacker, hacker places malicious brute force file in /hacked/bruteforce/

-Server password is then changed, hacker can still run script by navigating to their file on the server which will run upon their request (I am assuming?)

Question:

Would a combination of changing the server login password as well as adding a password protected .htaccess file to / stop the hacker in their tracks? Or can an .htaccess still be avoided in terms of rerunning the hacker's script?

I am very new to server security but am eager to learn anything and everything anyone can tell me! I highly appreciate any and all advice. Any recommended knowledge resources would also be fully utilised!

OUR SITUATION:

Here is the information provided to us by our host.

your Server/Customer with the IP: * has attacked one of our servers/partners. The attackers used the method/service: bruteforcelogin on: Sat, 14 Nov 2015 -exact time provided here-. The time listed is from the server-time of the Blocklist-user who submitted the report. The attack was reported to the Blocklist.de-System on: Sun, 15 Nov 2015 -exact time provided here-

Here is some more:

Lines containing IP-ip here-: NOT SORTED (from many different Machines)! DESTINATION-IP: -ip info here-

DESTINATION-IPs: -ip info here-

-ip here- - - [14/Nov/2015:-exact time provided here-] "POST wp-login.php HTTP/1.1" 200 4366 "referer-domain.tld" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0"

-ip here- - - [14/Nov/2015:-exact time provided here-] "POST /wp-login.php .... truncated .... 0"POST wp-login.php HTTP/1.1" 200 4366 "referer-domain.tld" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0"

-ip here- - - [14/Nov/2015:-exact time provided here-] "POST wp-login.php HTTP/1.1" 200 5117 "referer-domain.tld" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.0"

Regards, Jay.

marked as duplicate by Stephane, Deer Hunter, Philipp, Steffen Ullrich, Neil Smithline Nov 20 '15 at 15:23

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • I'd look at the wp-login.php to see if additional code has been added. In addition to that a checksum of the original and the current file could do as well. – Jeroen Nov 20 '15 at 8:01
  • When you talk about server, are you referring to the OS, or WordPress server? Meaning, have you been root compromised or is "only" your WordPress installation compromised. If you still have access to the filesystem, you could look for any new file or file changes from the time of compromise to identify what the attacker did. Remember closing his backdoor is one thing, closing the frontdoor you left open somewhere is another thing (you mention brutforcer, probably check your password strngths). Stupid question here, have you changed the password of your accounts that are on the system? – Zonk Nov 20 '15 at 9:30
  • @Zonk the issue we are having is that we don't even have wordpress installed, we still have root access to the server, the main problem we are facing is knowing of a method that will allow us to find the file(s) causing the issue so that we can take action. – Jay Nov 20 '15 at 11:25
  • Nuke from orbit! Don't fix. – Neil Smithline Nov 20 '15 at 15:23
  • okay wait, you don't have wordpress installed but wp-login.php. I only guess, but that's the webshell. You can find my e-mail in my profile. Can you please send me the file? I'm REALLY curious. – Zonk Nov 20 '15 at 15:26
1

Changing the server password or .htaccess will very likely not do anything now as the hacker has already gained access and installed malicious software on the system. On a Linux system I would at first check (as root) what sockets are open and what processes are using them:
netstat -anp | less
netstat -anp lists all sockets with the owning process and piping it into "less" allow to scroll through the list. If the server is a dedicated server you can capture the traffic by using the tcpdump utility and analyse it with for example wireshark. VPSs often do not allow sniffing. However if the hacker was clever and has covered his/her tracks the system may not display the sockets used by the malicious program. In this case a detailed security check of the entire system is needed.

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