Incident Response – Case Studies

In this week’s edition of our blog, we wanted to wrap up our theme of hacking and incident response with some case studies. The cybersecurity incident case studies below will put some meat on the bones of what we have been describing over the past couple of weeks.

Case Study 1 – Wedding Planning

This incident response case study involved a client that managed accounts for their clients.  After about $100,000 was transferred from an account, the client contacted us to determine what occurred.  More importantly, their insurance company requested that a forensic analysis be performed to indicate whether the loss of money was due to an inside job or whether it was due to a hacked computer.

Analysis of the computer indicated that a keylogger was installed on the computer.  A keylogger is an application, usually running unbeknownst to the user, that records all keystrokes.  The keystrokes can be recorded in a file to be transmitted later or may just be recorded in memory, again to be transmitted later.  The data may be in plain text or may be encrypted.  However, before we go further, let’s take a step back to see how we got to this stage.

Digital forensics analysis of the computer indicated that during a lunch hour, the computer operator was doing some wedding planning.  Various apparently harmless web sites were visited.  However, not all is what it seems.  When you go to a website whether it is CNN.com, ChicagoBears.com (best website ever in the history of websites) or Facebook.com you get delivered content from the main site.  However, quite often the advertisements you see on the page (or even other content) come from other websites who pay the main website to advertise or place content.  So while you are looking at the home page for CNN.com, you are actually being delivered content from a whole host of other sites at the same time.

In this hacking case study, it was another site that was the culprit.  Some advertisement was coming from a website that had been hacked.  This is not an uncommon occurrence and we refer to it as a drive-by-download.  The hacked web site exploited a vulnerability in our client’s computer in order to gain control over the computer.  The vulnerability was one that was known and Microsoft had released a patch for it months or maybe a year prior (which is the reason why security experts like Vestige urge clients to patch their computers regularly as part of a multi-pronged security posture).  After taking control of the computer, a keylogger was downloaded, installed and made persistent (meaning it was set to launch every time the computer was rebooted).

This keylogger wasn’t your ordinary, average, everyday keylogger.  It was an efficient keylogger (just like your efficient Vestige forensicator).  This keylogger concentrated on just those websites that dealt with banking or other financial information.  Not only would it log keystrokes, it also logged the website title and address in the keylogger file.  This additional logging made it easier for the hacker to pinpoint the information he was seeking.

Fortunately for our client, they had two factor authentication.  Their computer’s IP address was registered with the bank, but the hacker’s wasn’t.  So, when the hacker tried to logon from the hacker’s computer, the hacker was prompted for a second password which was unknown to the hacker because our client never had to enter it.  Unfortunately, in this case, the bank, upon noticing that someone was trying to enter under our client’s account from an unknown IP address, suggested to our client to change the second password.  I know, you are asking yourself “did I just read that right”.  Yes you did.  So our client innocently types in a new password, which the bad guy doesn’t have and a couple of days later the bad guy was using our client as a personal ATM.

The take away from this incident management case study? First, patch your computers, make sure you have proper Anti-Virus installed and practice other proactive security measures.  Second, it is not a bad idea to have computers that perform banking transactions set up for just that purpose.  Do not use those computers for daily tasks such as emails, opening documents and reading the web.

Case Study 2 – Not everything is as it seems

Usually the work that hackers perform is akin to picking a lock, breaking open a window or getting into your “house” in a sneaky matter.  This case, unfortunately, was different.  In this case, the hacker basically walked into a door that was left open and unmonitored.

Our client contacted us because they were seeing unusual activity on their network.  Examinations of their logs indicated that someone was logging into their servers and properly authenticating themselves.  No malware, no Trojans, no nothing.  The bad guys just got into the network.

Vestige was hired to determine what may have been taken and whether the hackers still had a foot in the door.  Vestige remotely imaged the servers involved.  Remote imaging is a technology that is fast and efficient in these types of matters, especially when the evidence is located hundreds or thousands of miles away and needs to be preserved now.  The data is preserved on encrypted drives before being shipped back to our lab.  The reason behind the encrypted drives is that if UPS loses the package or the trains carrying the package drives into a mountain, your data is safe because with the encryption, no one is going to get it (true story – we lost an indestructible Pelican case with Vestige’s equipment (no client data) because of a train accident that drove it into the side of a mountain).  Vestige can remote into the computer that needs to be preserved from anywhere in the world at any time of the day (yes, I have preserved computers while wearing fuzzy slippers) and preserve the data resident upon the computer.

After the data was preserved, we got on to examining it.  We confirmed for the client what they believed, the hackers had entered their network using an administrative account that had a very weak password.  We also were able to determine that no Trojans or malware was left behind nor were any additional accounts created for later use.  Once the client changed the password on the server, the hackers were locked out.

In examining the computer, we found that the hackers stole data, a good amount of it.  They compressed the data into RAR files (RAR is a technology similar to ZIP files).  The hacker was faced with a dilemma, though.  The client had good monitoring on the firewall to detect data transfer via FTP and cloud sites.  So, how was the bad guy going to get the data out?  The client had a legitimate web server.  The bad guy renamed the RAR files to appear to be JPG (picture) files.  The files were placed on the website in undetectable locations.  Then the bad guys merely visited our client’s website and downloaded the data as if they were downloading a legitimate picture.  Luckily at the end of the day, the data taken was not considered too confidential by the client.

What did the client learn from all of this?  First, they learned to audit their password policy to see that it is being enforced and to force changing of passwords regularly.  The client also monitored administrative accounts to see when they were used.  Second, the client learned to monitor more than just FTP and cloud site traffic, they were able to monitor data transfers from their website that appear to be unusual.

The next two incident response case studies are similar in the sense that the companies didn’t understand their infrastructure well enough to recognize their risks.

Case Study 3 – The Case of the Cyber Extorter

Waking up to find out that your systems have been breached is bad enough when you start considering the impact:  cost to investigate, cost to remediate, additional security, and of course the soft costs such as loss of revenue and potential reputational hit.  For this hacking case study, things were exacerbated when the realization of the data breach came in the form of an e-mail from a Russian Hacker group complete with a demand for $50,000 payment or the Russian Hacker group was going to release the fact that the organization had been breached to all of their clients.  To show that the hackers meant business, they accompanied the demand note with a list of the organization’s clients and the contacts within those clients.

The client was rightfully concerned about how the hackers got into the system and to ensure that whatever the method used, it could be identified so that it could be fixed.  Vestige was hired to perform this work.  As is typical with these kinds of matters, Vestige quickly got up-to-speed on the organization’s entire infrastructure.  We performed the requisite data mapping and testing of the infrastructure.  Because we knew at least some of the data that was exfiltrated from their systems, a thorough search of their infrastructure narrowed the number of potential systems that were compromised down from close to 50 systems down to 4 or 5 primary candidates.  Analysis of the organization’s firewall configuration, Internet log files and artifacts present on these systems identified the suspect device.

As it turns out, the organization actually had a decent Information Technology Security program.  They did many of the things that well controlled organizations do – some password management, specific focus on hardening servers and end user management to ensure that only authorized users get the permissions that they ought to.  All-in-all, if we were to grade this client’s InfoSec practices, they certainly would have been above-average…perhaps a B or B+.  Unfortunately, in today’s day-and-age, an organization’s security is only as good as its weakest link – and in this case, the organization’s Change Management process was to blame.  There was little segregation of duties between various IT individuals with the development team having full access to the production environment, with the ability to create, deploy and configure new servers at their discretion.

In this matter, the culprit system was a test server that had been deployed by one of the developers specifically to test some new features that were going to be deployed in a new version of this organization’s software product.  The only problem…those new features were deployed several years prior to the breach – but the system was never cleaned up by the development team.  The client data?  Test data that was placed on the server to allow the development team to ensure everything was working correctly.

In the end, the client took the high road and proactively approached their clients, explained what had happened, armed with our report and the results we found, the organization was able to ensure their clients that their infrastructure had been secured, that the data that was compromised was minimal, and that the organization was using the breach as a means to shore up their overall security posture.  The $50,000 ransom ended up being a less expensive alternative as the organization went on to overhaul their entire InfoSec arena, spending many times more than the requested ransom on new security equipment, consulting, creation of procedures and training for their staff.

Lessons learned?  Just like every intrusion we investigate, it always comes down to low-hanging fruit that falls under the Best Practice recommendations that we consistently point out in our Pre-Data Breach Assessments.  Had they implemented procedures in advance, these kinds of vulnerabilities would never have had the chance to be exploited.

Case Study 4 – Gone Phishing

Our final incident response case study this week revolves around the loss of nearly $250k that evaporated from our client’s bank account overnight.  It highlights the dangers in shared credentials, and how easy it is to be fooled by creative social engineering.

Our story starts with a routine visit to the web-site of our client’s bank.  The bank, always concerned about security, provided true two-factor authentication to its business clients who used ACH transactions and wire transfers that could be initiated and approved on-line.  This two-factor authentication consisted of the typical user credentials as well as an RSA token (6 digit number) that is continually regenerated every 60 seconds.  To gain access to the bank’s site the credentials needed to be entered correctly as well as the right key generated from the RSA token.

Upon attempting this the first time during the day our client successfully authenticated but then was presented with a message that the site was temporarily down for maintenance and the user should attempt again in a few minutes.  This continued for 5 attempts over the next hour, when finally the client contacted the bank to find out why their site was down, only to learn that the site wasn’t down.  Flash forward 18 hours and the next morning four ACH transactions had been entered and approved amounting to close to a quarter of a million dollars stolen from the client’s bank account.

We were hired to determine how this occurred.  Our review quickly centered on one specific workstation that was used by the organization to interface with the bank.  We quickly discovered that the user of the workstation had received an e-mail purporting to be from the bank a day prior.  The e-mail discussed a security update that was being implemented by the bank and requested that the end-user visit the embedded link to install the update.  Upon doing so, unbeknownst to our client, malware was added to the workstation that secretly redirected traffic intended for the bank to go to a fake site that was setup to look and feel just like the real bank’s web-site.

The next day when the user successfully logged in but received the system maintenance warnings, believing that they were on the actual site, they kept entering and re-entering not only the user credentials, but the current RSA token.  The bad guys, being on the receiving end of that transmission, in complete control of the fake web-site, used that information to login to the legitimate bank site and proceed to create and authorize the ACH transactions that would eventually be pulled from our client’s bank account.

Luckily this hacking case study had a partially happy ending, as some of the money was recovered.  What consumers and businesses need to understand, however, is that in a situation like this the responsibility of securing the company’s workstations is paramount, as with most bank agreements, the liability for someone else using the assigned credentials rests with the customer if the bank can show that the breach occurred on the customer’s side.

Lessons to be taken from this matter include:

• always having up-to-date anti-virus software and definitions;
• hardening the servers and workstations above-and-beyond the mere defaults installed with anti-virus and other security software;
• watching out for the tell-tale signs of a spoofed e-mail or site;
• being vigilant against phishing expeditions by learning to recognize fake links and never clicking on something that you don’t know;
• ensuring that your systems are patched with any and all security updates; and of course,
• limiting the exposure of critical infrastructure (such as the system used to access the bank).

As always, being prepared up-front pays huge dividends.  Many of these risks can be identified and eliminated through a Pre-Data Breach Assessment. To learn more cybersecurity strategies or if you need help with an incident, contact Vestige LTD.

by Greg Kelley, EnCE, DFCP, Chief Technology Officer at Vestige Digital Investigations