• Pratikar Technologies engaged with ABC Pharmaceuticals to investigate a recent cyber-attack on their corporate network. The attack included a Ransomware that had potential to sabotage the company’s operations by potentially deleting all data. However, an efficient backup strategy has saved the company from a catastrophe.

    1.     Network Vulnerability Analysis

    ABC-Pharma has a network of 80+ computers. However, there isn’t sufficient network security mechanism. Here are key affected items:

    1. The Network Router is accessible from the internet, which opens the network to a wide range of security threats – depending on the model of the router as well as the firmware it could be exploited to host malware or to infiltrate the network computers.
    2. The IP address 62.232.XXX.XXX which is public IP of the network reveals a lot of information including the network domain, mail server domains, as well as services running.
    3. It is easily possible to find the Dynamics Nav Server on the network which may be exploited at some extent.
    4. Remote Desktop connection is open (as on 25th May it is still open) which allows attacker to try combination of usernames and password.
    5. Network is on DHCP i.e. IP addresses are assigned to computers in sequence of time by which they have been turned ON. This makes it difficult to find out which user was using which computer from an investigative perspective.

     

    2.     Analysis – XYZ Server

    XYZ-Server is not accessible from the internet via Remote Desktop – we connected to it via AnyDesk.  Here are the key items observed:

    1. The server runs a very old operating system – Windows Server 2003 – which has reached official end of support cycle by Microsoft which means it no longer receives security updates, and hence may be vulnerable to attack. However, since it is inside the network it will be “acceptable”.
    2. The server was affected by the malware on 2nd March 2017, 20:55 PM.
    3. The malware was “dropped” on the server at the above-mentioned time.
    4. An exception in Windows Firewall was created by the malware to allow external communication from the server to hacker’s servers.
    5. The “Autorun” entry was created in Windows Registry to launch the malware when the system restarts.
    6. However, the server was never restarted – not until we got our hands on it.
    7. We removed the malware and cleaned the infected registry entries, because of which now there is no risk.
    8. The malware in question was not detected by ESET antivirus because it was totally new (ESET detected it on 9th March 2017 globally). This proves that the attack was a planned one.
    9. Security Logs from the XYZ Server did not show any unusual activity.
    10. The malware in question is a “self-propogating” malware that spreads itself into the network as soon as it is activated on any computer in the network. Since the malware on this machine was in dormant state it would be obvious to consider that XYZ-Server is not the source of malware.

     

    3.     Analysis – Small Business Server

    The Small Business Server was formatted and logs were extracted from it before it was restored from its backup. We received the logs and analysed them to come with the following points:

    1. The server was an important machine for the company and it was linked to all computers and drives in the network.
    2. Remote Desktop services on the server were enabled but not only that, the server was accessible from the internet.
    3. There have been 20,644 failed login incidents between the period of 1st March and 3rd March 2017.
    4. That amounts to almost 5 failed logins every minute i.e. every 10 seconds someone was trying to login to the server without proper username and password.
    5. For user account “Support”, the failure attempts are 412, compared to 75 successful logins. So, failure/success ratio is 550% (way too high)
    6. It appears that a “Brute Force” attack has been happened on the server with help of a cracking software that tries multiple username/password combinations to successfully sign in to the server.
    7. The attacks have been done by two different attackers, out of which one has been successful in gaining access to the “Support” account (after which attacks have stopped).
    8. The user account “Support” is accessed from an external network at least 5 times.
    Date Time User Domain Computer Name IP Address Location
    3/1/2017 15:00:19 support ABCPHARMA ABC-PHARMA 37.49.228.118 Reykjavík,

    Gullbringusysla, Iceland

    3/1/2017 15:31:20 support ABCPHARMA ABC-PHARMA 136.243.9.190 Germany
    3/1/2017 16:02:44 support ABCPHARMA ABC-PHARMA 136.243.9.190 Germany
    3/1/2017 16:52:14 support ABCPHARMA ABC-PHARMA 136.243.9.190 Germany
    3/2/2017 19:53:57 support ABCPHARMA ABC-PHARMA 136.243.9.190 Germany
    3/3/2017 1:30:09 support ABCPHARMA ABC-PHARMA 136.243.9.190 Germany

     

    1. As you can see, the user account “Support” was signed in from Germany at 19:53:57. This is almost one hour before XYZ-Server was infected by malware, and two hours before User-PC was infected.
    2. Suspicious login attempts from a user “dave” from United Kingdom have been observed. There have been 1367 failed login attempts and not a single successful login.
    3. It appears that “dave” is using “Vodafone UK” as a network for login.
    4. Several failed login attempts from “pragnesh” have been observed. However it appears that Pragnesh is official staff member and he has been able to successfully login many times.

     

    Reconstructed Timeline of Events

    • The password for Server was Weak.
    • Server was accessible from the static IP of the company.
    • Attackers were determined to access local network by hacking the main server.
    • Attackers launched brute-force attacks – one using a list of commonly used username/passwords, and second by enumerating important users in the network.
    • Attackers determined password of user account “support” which had administrative privileges.
    • Attackers signed into the server and planted the malware DMA Locker which was then activated manually AFTER disabling antivirus software.
    • The malware spread into certain weak systems where antivirus was not installed (XYZServer and User-PC both did not have ESET installed before the attack happened). User-PC, when started, got the malware to work, and all files were encrypted. \
    • XYZ-Server was safe because it was not restarted.

     

    Recommendations

    1. The malware could have been activated by person in the organization (however it is very unlikely since data shows it otherwise). However in this case it would be impossible to find out the name of perpetrator or threat in the organization because the staff members seem to exchange username and password frequently. We recommend setting up a strong security policy and education of staff discouraging this activity.
    2. Network IP Addresses are assigned using DHCP protocol which means that IP address of every computer will change everyday, in sequence of restart. This makes it further impossible to determine threatful insider. We recommend a proper network architecture along with documentation of IP addresses according to floor plan of building, which helps identify physical location of every computer.
    3. Your network is exposed to every external attacker – we recommend using a network security device like Fortinet, SonicWall etc. for protection from external attackers.
    4. XYZ-Server is running a very old version of Windows Server OS. It is recommended to upgrade the machine.
    5. It appears that staff members are using “Support” account to install programs, since it is an administrative account. We would recommend a strong Whitelisting policy where in only pre-installed apps can be used.
    6. We recommend doing a check on existing employees and mapping login accounts with them, which will circle out unused logins of ex-employees that can be subsequently disabled).
    7. We recommend training all employees for tackling malware issues instead of reactive reliance on IT Support team.

No prev case study

No next case study