I've been hacked! Phising site installed

I don't know if it is bad luck or what but I've had 2 servers get Phishing sites installed in the last week.  The first one I do not have much control over so it wasn't up to date or even a well setup server so I'm leaving it out of the discusion for the most part.  

The second server however I am very involved with and I thought I had it buttoned down very well.  First a little background information.  This server gets attacked more then any other server I have out there (I manage small business networks so I have a lot of single server networks out there)  There are frequent failure adudits in the security log of people from remote IP addresses trying to login with generic names.  But since most of the attempts are for usernames like bob, mike, administrator, etc... which do not fit the naming structure of the domain I never worried too much.  Administrator account has been renamed long ago and accounts lockout after 3 attempts.  

Now I get contacted that a phishing site has been deteched.  I find that on March 28 at 9 PM Apache webserver was installed and the website was created.  I do more digging and find a username Paul that should not be on the server and what do you know, he is an administrator.  I find that Paul logged in shortly before the software was installed from an outside IP address (Bulgaria of course).  I was curious and saw that his account was showing logged in at the moment but idle.  So I changed his password and logged into the server with his account to find his open session still there with the documents open.  I know how to remove the apache server, website, and his account but I want to know how he got in and how to stop it in the future.  Any ideas or thoughts.


Matt
LVL 6
chilidsAsked:
Who is Participating?
 
btanConnect With a Mentor Exec ConsultantCommented:
I treat this as part of incident response for website hacking. This is an external attack for unauthorised access. The priority is to contain and eradicate the threats, stop it from propagation (esp not to "springboard" to internal lan), recovery for business continuity and evaluate security controls to prevent such incident (or similar).

Take a look at this useful document for reference
@ http://www.antiphishing.org/reports/APWG_WTD_HackedWebsite.pdf

Need to keep the mgmt informed. The callbacks (or the source ip in specific) need to be blackholed by the firewall, keep security folks informed. As for further reporting to external law enforcer or open community such as anti-phishing workgroup, it really depends on mgmt decision and concerns. Beef up internal security is key for recovery in long term.

Some more thing to consider first
- Change all password and other accounts esp the privileged ones such as admin and service/system accounts
- Assess to check whether there are more affected system
- As of now, we see the intrusion can be blackholed by the callbacks, do so immediately. Note this is only for this case, it would be challenging if source is going through some proxifier or anonymiser.
- Asess the extent of damages e.g. data loss - any further then just unauthorise account created, such as any document or related siphoned off.

Some key extracts from the paper:

The only way to ensure that your servers are “clean” is to rebuild from original install media or to do an OS restore from known-good backups in offline mode, as recommended above. (If you cannot rebuild or restore offline, do so online but behind a firewall).

In short do have regular health check as well - penetration testing the website. Your staff can perform a security assessment using a web application vulnerability scanner. Free and open source examples of such tools include Backtrack, HackerGuardian, Nessus, Nikto, and Sandcat (Note: a search engine query for “web application scanners” will yield multiple trusted download sites for these and similar applications).

A careful security assessment should compare the content on your web server against known-to-be correct versions—the content you intended to host. Eye-balling files or comparing file sizes is not sufficient: use checksums generate by applications such as Open Source Tripwire to assure that files are identical. When you perform such assessments, generate a detailed report that can be used in accordance with a predetermined incident reporting and response plan.

Save copies of your web site and all event logs that may be useful for incident analysis offline, e.g., on a DVD, CD, or on increasingly affordable portable hard drive devices. Include (digitally signed) checksums or hashes of your web pages on this DVD/CD so that it is easy to distinguish your intended and authentic content from unauthorized substitutions and additional content. Many hash generator programs and file-system anti-tampering software are available for this purpose. Consider creating images of compromised web server operating system and application partitions for forensic analysis and follow up.
0
 
marchioriCommented:
Could it be social engineering ?
0
 
chilidsAuthor Commented:
No it wasn't social engineering.  After awhile of going through security logs and examing the server I finally realized what happened.  There was an account created a couple of weeks ago for testing purposes with the username paul and the password the same.  It was suppost to be deleted but of course got overlooked.  So the attacks that I talked about finally succedded and they were able to log in.  I noticed a login and then out right away and then several hours later they came back, installed Apache, and downloaded the preconfigured website.  I then saw several visits back and forth checking on the status of the phishing site.  I noticed the user still had an active TS connection that was idle so I reset the password and logged into his session and found things just as they were left.  It looks like they didn't touch or even look through the server but only installed the website and monitored it.  I did find a text document that he had open that appears to be bank account numbers and passwords.  So my final questions is what are the htoughts about reporting this and what steps to take?
0
Will You Be GDPR Compliant by 5/28/2018?

GDPR? That's a regulation for the European Union. But, if you collect data from customers or employees within the EU, then you need to know about GDPR and make sure your organization is compliant by May 2018. Check out our preparation checklist to make sure you're on track today!

 
yuliang11Commented:
i think u should run a nessus scan to check whether your server is vulnerable
0
 
astralcomputingConnect With a Mentor Commented:
1. Nessus or other to check for vulnerabilities in the application code/versions.
2. Port scan to check for unauthorized open ports.
3. Overall security posture review of the server as well as the site.
4. Logging mechanism for the server, IPS/IDS
5. Lock down your IIS folder, monitor/audit for changes.
6. Patch management on that server with auditing/reporting
Among other things, these will help.

You main concern now is discovering the vector of attack. This is not something that can be quickly attained because there are way to many factors involved.

Couple of questions that might help me.
1. OS on the server
2. What are you running on the server - e-commerce app, straight web server, VPN server, etc...
3. Do you  have any logging/log files.

0
 
eeRootConnect With a Mentor Commented:
- Enforce domain and local polices to make passwords complex and ensure that passwords cannot match or contain the username.

- The external source for this hack should not be able to get direct access to you web server, make sure that a firewall is present and set to allow web traffic and is blocking everything else.
0
All Courses

From novice to tech pro — start learning today.