Evaluation of an IT Department’s Response to a HR System Hack

Abstract

This paper describes a scenario where an employee was able to hack into the Company’s Human Resource system to modify paycheck amounts. The first section details and evaluates the scenario. The second section critiques the efforts of the Information Technology department to respond to, contain, and recover from the incident.

Introduction

Recently, an employee of this organization effectively exploited several information system vulnerabilities in order to adversely affect the pay of several employees, including the President, while also increasing the amounts of the attacker’s paycheck. This report will detail the incident, describe the preliminary incident reporting steps that should be taken in the event of incidents like this one, and describe methods of containing the damage, eradicating the threat, and recovering the affected systems. Additionally, this paper will evaluate how the IT staff responded to the attack, particularly with regard to highlighting any attack vectors that the staff overlooked, and recommend additional prevention and mitigation efforts that should be employed to prevent or mitigate against all of the attack vectors which were exploited by the attacker during this incident.

Description of the series of  events that led up to the incident

This was a very severe attack which seems to have been completed by an employee of this organization. The attack began with the employee spoofing an IP address on the network in order to eavesdrop on the network traffic. With this information, the employee was able to identify where the pay records were stored on the network. Then the employee was able to identify and exploit vulnerabilities in that HR Pay system in order to modify information and change their paycheck amount. This employee received two paychecks with the new amount.

This change did not go unnoticed. An auditor noticed enough anomalies to decide to notify several people via email with their concerns. However, the attacker was intercepting those emails and created fake responses to the auditor. The attacker and the auditor continued this back and forth until the attacker was able to gain access to additional financial information. The attacker used this information to modify the paychecks of several other employees, including the President.

Notification Requirements

Using the criteria of NIST 800-61, Computer Security Incident Handling Guide, this incident has a medium functional impact, due to integrity loss, that could be predictably recovered using existing resources (Cichonski, Millar, Grance, Scarfone, & Department of Commerce, 2012, p. 33). The impact was limited to internal systems users, so there is no requirement for notifying public affairs. The company does not have US-CERT reporting requirements.

However, the incident will likely lead to criminal charges of computer fraud against the employee, and so forensic techniques should be employed along with incident response. This requires notifying people across several functions:

1. The system owner, and all those responsible for maintaining the security of the affected information system, including the local information security officer and the director of IT/CIO. These people will be responsible for restoring normal business operations using whatever resources are not being quarantined for evidence gathering and handling.
2. The legal department, who would appropriate law enforcement notification.
3. The Cyber Forensics team, who will initiate procedures for evidence handling and gathering.
4. Human Resources, who will oversea the employer/employee communication and assist in establishing the grounds for any actions against the employee.
5. Payroll, who will assist the system owner in validating the data recovery.
6. The executives and all other employees who were impacted by the data breach and need their paychecks corrected.
7. The auditor and all of the individual members who the auditor emailed would have at least limited notification, as forensic investigators will need to rule out that their computer end-points were compromised during the breach.

Containing the Incident

This incident is not as simple as recovering from malware. The containment strategy for this incident must include managing the need for evidence preservation and for establishing both an immediate workaround for managing the impacted payroll information while the system owners complete the near-term information system recovery (Cichonski et al., 2012, p. 35). Containment steps should include:

1. Revoking all information system access of the employee who hacked the system.
2. Following all evidence gathering quarantining steps, including taking systems offline for complete forensics evaluation.
3. Quarantine all payroll records for the known impacted employees, and process payroll through manual means for the affected employees while the investigation/audit is in review.
4. Perform an audit of all payroll records to identify any other anomalies or other potential targets.
5. Perform an investigation into the mail system, and the computer end-points of both the auditor and the “several individuals” whose emails were intercepted when the auditor emailed them to report the potential problem.

Factor Eradication

Once the incident has been contained, it is necessary to determine how to eradicate any remaining factors that related to the breach.

The first step at eradication is to determine the full breadth of the breach and identify all compromised components  (Cichonski, Millar, Grance, Scarfone, & Department of Commerce, 2012). This includes the Human Resource system, the network infrastructure, the Mail Server system, and the end-point computers or devices used to compromise them.

In addition to the issues brought to light specifically from the types of attacks the employee used, the investigators would be looking for any evidence of additional malevolent items left behind by the attacker.

Eradication tasks include removing any malevolent items found, disabling any accounts that were compromised, and either mitigating or eliminating all vulnerabilities which were exploited during the incident.

It is important to prioritize the order of eradication steps, since some of the steps can take days, weeks, or months to complete. Do not return any system or end-point to production until all factors related to the incident on that system or end-point have been eradicated. For this reason, one should prioritize systems over end-point and critical systems over ancillary systems.

System Recovery

Once a system or end-point has been evaluated for threat evaluation and all threats have been eradicated or appropriately mitigated, then the remaining recovery prodedures should be employed. This includes recovering any lost data from backups (or rebuilding systems from scratch), and applying any new security patches or system controls meant to prevent an attacker from using the same attack vector as this employee exploited (Cichonski et al., 2012)

Operational Verification

Once the system is recovered, prior to placing it back in production, the proper team should validate the systems and end-points are operational. In addition to testing the specific use cases which were exploited in the incident, recursive testing of all of the additional features used by the system and end-point should be completed. It is not enough to prove, for example, that an email from the auditor to one of the several individuals he emailed during the event is now not able to be intercepted. The team must also ensure that their mitigation and eradication steps did not adversely affect other functions and features relied upon by the users of the impacted systems and end-points. It is quite possible that the mitigation controls used to manage this attack vector may impact other functions and features, and so team members must make sure the recursive testing is thorough.

Areas Not Addressed by the IT Staff

While the IT staff did recognize the IP Spoofing was a threat that was exploitable due to insufficient authentication and encryption controls, they missed the threats contained in other areas. With their focus on network infrastructure, they appear to have overlooked the web application, database, and social vectors which were also exploited by the attacker.

Other Attacks in the Scenario

SQL Injection

The attacker also managed to make changes to the HR system. Those changes required some kind of Injection attack that exploited vulnerabilities in input validation or other SQL database vulnerability (OWASP, 2017). 

DNS Hijacking, Man-in-the-middle attack

The attacker was able to not merely eavesdrop on the emails sent by the auditor. The attacker also intercepted those emails and forged replies to the auditor. This could mean the attacker inserted an alternative mail server and routed the auditor’s email through that server via DNS hijacking. This kind of scenario is described in detail by Elie Bursztein, Google’s anti-abuse research team lead (Bursztein, 2016).

Social Engineering

Furthermore, the attacker was able to use the ability to intercept the emails being sent by the auditor to obtain access to other financial records. This represents a social engineering vector and implies the need to include improvements in Security Awareness Training in any recovery and mitigation efforts.

Type and Severity of the Attacks

SQL Injection: Severe

SQL Injection vulnerabilities pose a serious risk to the organization. They affect the integrity of the information that is being managed by the database. OWASP considers SQL Injection to be a “high impact” severity, since skilled attackers can use SQL injection attacks to “spoof identity, tamper with existing data, cause repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all the data on the system, destroy the data…and become administrators of the database server” (OWASP, 2016).

DNS Hijacking, Man-in-the-middle attack: Severe

The interception of the auditor’s emails represents one kind of Man-in-the-middle attack. This also represents a severe attack that can have a very detrimental effect on the organization. Once an attacker can intercept and modify the email communications of a given system, they can exploit that vector to gain other information, from private conversations to proprietary information and even other security credentials through effective social engineering techniques.

Social Engineering: Varying Severity

Social Engineering is another vector exploited by this attacker. This vector can result in a wide range of impacts on the organization, from negligible to quite severe. It is important to realize, however, that social engineering techniques like Phishing and Spear Phishing are nearly always included as a vector in the most significant breaches. Technical controls can be more difficult to overcome than human controls. Social engineering vectors exploit people’s need to be social, whether it is to be seen as helpful or important or to avoid being seen as difficult or “not a team player.” These social needs affect individual decision-making to varying degrees, and a skillful social engineer can create very significant attack vectors based on the information gained from a successful social engineering attack.

How to Prevent the Additional Attacks

The candidate provides an appropriate description, with sufficient detail, of how the additional attacks can be prevented in the future.

There are several things that can be done to prevent these additional attacks.

Authentication and Encryption

First, with regards to the recommended control of installing a local root certificate authority, this paper recommends that the IT staff avoid the use of self-signed certificates when addressing the issue of authentication and encryption. As a high value, high impact system, the security certificate used for communication should not be self-signed. To implement a self-signed solution would have added a single step (finding and forging the certificate) to the attacker’s methodology. This is because self-signed certificates generate warnings that must be “clicked through” and would acclimate users to the practice of ignoring those warnings. While an authentication and encryption solution that uses self-signed certificates will prevent the initial traffic interception that was the first event in this incident, it does not address the subsequent man-in-the-middle attack.  Also, self-signed certificates don’t utilize a certificate authority. An improved security would be to implement a Certificate Authority on the network and issue certificates from that CA, or – if possible without exposing the HR system to the public network – to utilize a third-party CA for their internal certificates, like IntranetSSL, a product offered by GlobalSign (GlobalSign, 2019). If the GlobalSign CA solution had been in place, then the attacker would have had to compromise another network to gain the information needed to forge the certificate.

SQL Injection

With regards to controlling against SQL Injection, OWASP recommends three primary defensive techniques.  (OWASP, 2018).  First, all queries to the database should be “parameterized” rather than dynamic (meaning the software calls a statement from another location rather than creating a new statement each time). This should prevent the attacker from changing the “intent of the query.” Another defense, using stored procedures, is similar to parameterize queries, provided it is implemented correctly. Next, validating input against a whitelist of approved entries will help prevent unauthorized data entry from adversely impacting the database.

DNS Hijacking, Man-in-the-middle attack

Protection against man-in-the-middle attacks is accomplished through an adequate authentication solution, like the one described above. In addition, you must defend against DNS Hijackings. Some of the steps for defense against DNS hijacking include implementing multi-factor authentication, regularly auditing your DNS records to ensure they are resolving appropriately, and auditing your network for any encryption certificates which may be fraudulent, and revoking any certificates which have been forged (Rash, 2019).

Social Engineering

Since social engineering relies on techniques of influencing others, techniques like triggering a need to reciprocate, establishing authority, being likable, and creating a sense of scarcity (Chapple & Seidl, 2015), it is important that defenses against this attack vector focus on helping individuals resist efforts at influencing them. This should include training in the tools and methods attackers use to exploit their desire to be helpful, with specific examples that drive the reality of the risk home. Training should take place regularly and programs should be implemented on a steady basis so that security awareness remains at the forefront of all employee’s minds (Chapple & Seidl, 2015).

Recommended Recovery Procedure

This report recommends the company take the following steps to restore the information systems to a fully operational state. First, implement an incident response appropriate to the significance of this breach. In this case, that includes taking the extra steps of incorporating forensics investigatory methodology so that evidence can be collected which can be used to successfully prosecute the attacker for the criminal acts included in this malevolent action. This should take place as part of the general containment steps described above. After containment, the IT department should either restore or rebuild onto new or existing hardware (as appropriate), the needed data and features that were installed prior to the breach. Next, they should add the new features and controls which are intended to prevent a successful repeat of these attack vectors. Following that, they should perform both general feature functionality testing and regression testing to ensure that their new controls do not adversely affect other needed features of the systems. Once all of these steps are complete, they should be able to bring each affected system back into full production. As this may take some time, they should prioritize the recovery based on business requirements, preferably according to a triage scheme that was established prior to this incident. 

References

• Bursztein, E. (2016, January). How email in transit can be intercepted using dns hijacking. Retrieved August 3, 2019, from Elie website: https://elie.net/blog/security/how-email-in-transit-can-be-intercepted-using-dns-hijacking/
• Chapple, M., & Seidl, D. (2015). Cyberwarfare: Information Operations in a Connected World. Burlington, MA: Jones & Bartlett Learning.
• Cichonski, P., Millar, T., Grance, T., Scarfone, K., & Department of Commerce. NIST SP 800-61 Revision 2: Computer Security Incident Handling Guide. , (2012).
• GlobalSign. (2019). IntranetSSL: SSL Certificates for internal server names, reserved IP addresses & domain names. Retrieved August 3, 2019, from GlobalSign website: https://www.globalsign.com/en/ssl/intranetssl/
• OWASP. (2016, April 10). SQL Injection. Retrieved August 3, 2019, from OWASP Foundation website: https://www.owasp.org/index.php/SQL_Injection
• OWASP. (2017). OWASP Top 10—2017: The Ten Most Critical Web Application Security Risks. Retrieved from https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf
• OWASP. (2018). SQL Injection Prevention Cheat Sheet.
• Rash, W. (2019, April 22). How to Avoid the New DNS Hijacking Attacks. Retrieved August 3, 2019, from EWeek website: https://www.eweek.com/security/how-to-avoid-the-new-dns-hijacking-attacks