Paying the ransom v. back-ups

    Over the last three years, hospitals and medical offices have been increasingly targeted by attackers. This trend will continue this year and well beyond. Hancock Health, a regional hospital located in Indiana, red-flagged suspicious activities indicative of an attack on January 1 of this year.

    The end manifestation of the attack was the employees being locked out of their systems and received a welcoming ransomware. This may not appear to be that debilitating, however when the extent of the encryption was noted, the issue was significant. The target was great than 1400 files. The file extensions were modified to add “.imsorry” at the end of the file. This rather daunting message was met with the hospital paying the ransom to secure the decrypt key. In the environment, this is not the norm. There are a number of significant issues with paying the ransom, including the attacker not providing the decrypt key, leaving behind a bit of special malware to be used later, other access points, and many other reasons not to pay.

    The hospital indicated no evidence of their patient information being released or sold. The curious aspect to this was hospital paid $55k to the attackers for the ransom, while they had viable back-ups. This is the anomaly, as it is mostly advised not to pay this. The rationale was the process to restore the back-ups would have cost more than the ransom. This calculation does not seem as if this took into consideration all the germane factors.

    The successful attack was not due to a phishing campaign, but through the hospital’s remote access portal, using a third-party vendor’s credentials. The ransomware applied was SamSam or Samas.

    This provides a lesson for other operators. This could have been avoided or mitigated with training and alert users. There are a number of programs available for training the users, which should be done throughout the year.

Attackers-2; Indiana Hospitals-0

            The healthcare industry has been and continues to be targeted by the attackers in their attempts to compromise systems, exfiltrate data and information, and collect fees from ransomware attacks. A handful of the recent attacks have been phishing oriented, due partially to their previous successes. Hospitals present a great source of sale-able data for the attackers. This includes, but is not limited to, the patient’s medical records with various data points that may be divided and sold separately or bundled into a packet for each patient. This includes the social security numbers, insurance information, home address, phone numbers, the patient’s point of contact, and other information.

            Recently Hancock Health had the opportunity to pay $55k arising from a successful ransomware attack. The attack vector here was a phishing attack. On the same day Hancock Health experienced their issue, Adams Memorial Hospital likewise was hit with ransomware. The other attack was successful due to an employee noticing something was not quite right with her system on December 11, 2017. She contacted the help desk and system Admins regarding the issue. Upon further examination, the files read “Sorry” and the network went blank. The ransomware tool used was believed to be a subset of the “Im Sorry” ransomware variant. This worked via appending files with “.imsorry” as they are encrypted. Post-encryption, a text file is placed on the system stating the instructions for paying the ransom.

            Due to this, the physicians were not able to access their patient’s history files or appointment schedules. The scope of the attack was relatively limited with only 60-80 patients affected. As of January 19^th, Adams Memorial Health had not stated if the ransom had been paid.

            This provides a valuable lesson for the Admins and the InfoSec department. The training to avoid such issues is needed and should be continued. This training would assist the staff in recognizing not only phishing emails, but also what to monitor for with other staff emails in the case these would have been compromised.

And you thought the Experian Compromise was Problematic

            Healthcare continues to bear the brunt of the attempted attacks. Over the last few years, the healthcare industry has been targeted repeatedly. This is due primarily to the data and information being held being marketable for a longer period of time than other forms of data and information. This coupled with lax security certainly is not helpful. For instance, with financial information, e.g. credit card numbers, the useful life is much shorter than other forms. Once the patient is aware of an issue arising from checking their accounts, a third party service or other form is contacted, the person simply has to call their credit card company, the present credit card number is voided by the credit card company, and a new card is issued to the user. The stolen credit card is no longer valid.

            With medical records, there is a different case. These have data that are useful for the attackers over a much longer period of time. Dependent on the record and the health care agency, the file’s composition may differ. These generally have the social security number, addresses, billing data, and other relevant, marketable data.

            The Health South-East Regional Health Authority, located in Norway, recently had the opportunity to experience an attack. The entity manages Norway’s hospitals located in its southeast region. Their system was compromised, which led to attackers to exfiltrate their client’s personal information and medical records. In the US, we are unfortunately becoming numb to this as there have been many of these over the last two years.

            Two factors stand out with this incident. The records exfiltrated counted at approximately 2.9M. This is over half of Norway’s population of 5.2M. This makes the breach relatively massive. In addition, the entity’s InfoSec staff did not notice any issues. The healthcare entity received a notification from HelseCERT regarding activity red-flagged as abnormal. Recently there had not been evidence of any patient issues arising from this compromise.

            The management does not quite appreciate though the long-term effects of this. The data is marketable for extended periods, which is inclusive of a few months. The attackers who compromised the systems don’t have to sell this immediately or use it for their gain within this time period.

Face-Palm #89: Taiwanese Police Epic Fail

There are a limited number of instances that would warrant a face-palm. These are generally limited to the moments in time when you are wondering what they were thinking. One of these recently occurred in Taiwan. The government ran a cyber-security quiz sponsored by the Taiwan Presidential office. This was designed to exhibit the government’s focus on cybersecurity and the efforts to address this. These events as a rule of thumb have a give-away or SWAG which is handed out with business or entity names and emblems on them. The Taiwanese event was no different and handed out 250 flash drives. 

Unfortunately, 54 of these were infected with a virus. The virus wasn’t a plain, vanilla variety intent to annoy the user, but was coded to steal the user’s personal data and had been linked to fraud. Of the 54 infected drives, 20 had been recovered. 

 

The flash drives were manufactured in China. The malware however did not originate with the manufacturer, but with a supplier based in Taiwan. Allegedly, an employee intended to test the 54 flash drive’s storage. The malware, XtbSeDuA.exe, was on the employee’s system. This was coded to only affect 32 bit systems. 

Although the affected parties are limited, due to the 32 bit system target, the issue is much larger. The governance was significantly lacking in this instance.

30,000 Florida Medicaid Patient’s Now Have One More Thing to Worry About

In early January 2017, the Florida Agency for Health Care Administration notified approximately 30,000 Medicaid recipients their medical records and personal records had been accessed. This happens all too often as we have read about frequently. The attack vector varies with each attack based on the environment, tools applicable to the OS and configuration, etc. In this specific instance, the attackers used a phishing campaign, which have grown in use and popularity. The user fell victim to a simple phishing email on November 15, 2017. This was rather unknown until the agency was notified on November 20, 2017 from the Inspector General from the state.

The spoils from the successful attack included a large amount of data and information the attackers were able to access. This included the partial and full data with the the enrollee’s full name, Medicaid ID numbers, birth dates, addresses, diagnoses, medical conditions, and SSN. This has provided nearly all the data needed to take over the enrollee’s identity.

There are a number of issues associated with this, which are disheartening. The Agency had no idea they had been successfully phished and compromised. Their logs, internet access, and other areas had not been reviewed to a sufficient level and/or all of the data from the data exfiltrating the data and medical records for approximately 30,000 enrollees had not been noted. This is a fair amount of data that was moved from the business. Also the employee did not report the phishing email(s) or they had clicked on the email.

This breach provides a number of teachable lessons for others. The InfoSec Engineer should have been monitoring the logs via some form of SIEM or app (e.g. Splunk) for odd/anomalous activity, e.g. a mass amount of data being forwarded in a very short amount of time. The vast amount of data involved would not have lent itself well to a manual review on a regular basis. The access time of the day should have also been noted for these. This amount of data involved should have been significant enough to be noticed on some level. Also there should have been some form of phishing training for the staff. This may have been beneficial to the business in that this may have been avoided.

Granted the Agency may have budgetary constraints. This is a common issue, especially as tax dollars are decreasing while costs are increasing. There are however free and low cost alternatives to a full service phishing vendor’s offering. There are also free or lower cost SIEMs available for implementation.

As we look forward, the Agency could have used machine learning techniques and algorithms to better review the logs and other activities for anomalies and patterns. This would also function to require less processing time.

Biometric Authentication with a Selfie

For well over a decade there has been talk of the demise of the password. There have been multiple people in the industry who have claimed the password’s time is limited for years. Initially the password had a vital role of securing access to various files, the user’s email account, etc. Without this, any number of people would have access to the data and information that in theory should have been private and confidential. Initially, the password’s composition convention was relative basic. This was basic and not very robust or creative. As time passed and the attacker’s realized this, the systems began to add complexity to the password’s format. This necessity was driven by the potential issues. This addition assisted with mitigating the risk of the access being compromised. As a bi-product or secondary effect, this also increased the amount of time required for a successful brute force attack. 

 

As the password became more complex, the attackers have adjusted their methods to compensate for this. This cyclical relationship will continue. As this has been a relatively short-term fix, a new logging method has been in process. There have been many options researched, developed, and putin full and limited use. These have included retinal and iris scans, blood vessel locations in the hand and face, and various other methodologies. These have been met with various levels of success with the various uses. One of these authentication methods gaining more attention within the last year has been facial recognition.

Early On

The facial recognition software initially implemented algorithms which were rudimentary. These used non-advanced geometric models. These worked within the system to note the location of certain facial features from photographs or other data source. These could focus on the eyes, ears, nose, and mouth location. From the initial data points, the algorithm calculated the distances and subsequent ratios. Naturally over time, this function evolved and improved. These now use mathematical representations and matching processes.

Updated Uses

Initially, this was implemented for user validation and authentication. In most instances, this did work relatively well in most instances. In theory, this new and expanded application is safer than passwords. This is a step to address the need for improved security. The user is able to lose or forget a password. The user password could be cracked. In the alternative, there is only one face like the user, except in the case of a maternal twin, there is a single “form” of data. As a further benefit, this does take less time to process. 

 

One area this is being used as a new outlet, is using this for authentication for payments. The vendor predominantly implementing this has been Amazon. The selfie is used to authorize the Amazon online purchases. With this technology, the user’s image is used for the authentication. This also has been coded to also use motions or gestures for the authentication. With the motion integration, this is beneficial as the person has to show they are a person, and not a picture or other 2D representation. Amazon is confident in this technology’s application to the point they patented it with 20160071111 on March 10, 2016. 

 

Mastercard also plans on implementing a similar protocol. With their version, the users would blink for the online purchases to authorize the payment. Google was testing their own method also. Their product is termed “Hands Free”. This is intended to allow for persons to pay with their smart phone by simply saying “I’ll pay with Google”. Google reportedly was also going to use facial recognition. This project though had been shuttered.

Issues

We certainly live in an interesting time. These advances in technology continues to amaze not only the consumer, but the industry. The trajectory of advancements continues to be exponential. This increase in usefulness does come with a price. The progression has not taken the time to explore security or work through most of the use cases. If there were to be a breach and the database with the facial scan data compromised, there would be rather significant issues for multiple parties. This includes not only the entity having to forensically investigate the issue, seek the extent of the data exfiltrated, if it was being actively or passively sold on the dark web, securing the enterprise, and other assorted issues, but also for the users. Their facial recognition data would be compromised. They only have one face. The attackers and unauthorized parties could use this to their benefit for years and years. The users are not able to randomly change their face, bone structure, location of eyes, and nose structure at will, which are used in the computation for the authentication. This is not an isolated topic, and has occurred with government entities in the recent past (e.g. OPM). 

 

There would also be difficulties if the person were to be a victim of violence to the face or in a serious car accident. The user would not be able to follow the general process to reset their password. There would need to be many more steps involved with this instance with other departments to validate the issues leading up to this. 

 

Apple recently experienced issues with the facial recognition applications. Although this technology is advanced, it is not perfected. In this case with the new iPhone, there is the opportunity to use facial recognition to unlock the phone. With a quick smile, the user can be calling or connecting with the internet. There have however been at least one instance recorded where a mother unlocked her iPhone X, relocked it, and handed the phone to her child, who was likewise able to unlock the phone.

These advances are a natural progression of our society and efforts. These and other advances should be placed in use. These should however be tempered with security and full testing procedures.

Rootkit redux

In season 1 of Mr. Robot, the much exalted series, one of the female lead actors asks innocently during one of the conversation “What is a rootkit?” (eps1.0_hellofriend.mov, ~ 32 minute mark). Although this is known and appreciated in various levels, not all have been exposed to this issue. 

 

The attacks used have various levels of complexity with the implementation. These range from the simple phishing attack with an embedded link to the malicious site to the more sophisticated, complex attacks involving multiple steps, access to hardware or other steps which normally could be carried out only by someone with significantly more experience. This form is not the easiest, however would be seated in the middle portion of the spectrum, as averaged across the OS spectrum. 

 

As difficult it is to perpetrate, this may be more difficult to detect by the non-IT personnel. Generally the users will have a vendor’s AV package, update it regularly, and run a scan periodically. As these have the full faith and credit placed in them by the users, these may be missing the rootkits, if present on the system. These have tended to be difficult to detect for many reasons. The primary issue has been these are active prior to the system’s OS booting. This allows the rootkit to customize certain aspects to make it recognizable as an authorized part of the system and to avoid being noticed, or other attributes. This coding and functionality allows the rootkit to be hidden so the user is inclined to believe the system has not been breached.

Defined

The broad, general definition is a software tool that is placed on the target system to allow the attacker access in some form at a later date. Due to their function, these are not coded to propagate on their own. To code these also requires a certain level of expertise. The person trying to code for this would need to do more than watch a few YouTube videos or visit two or three DIY websites. Coding an effective rootkit requires time. There are many uses for these. The coder may create and deliver to the target a rootkit to accumulate data from the user’s computer(s) and the user’s accessing the system. This data could then be exfiltrated and later sold on the dark web or used by the attackers themselves. Depending on the data, this could provide the affected users with years of headaches. This could also cause the system(s) to malfunction or BSOD. For the enterprising attacker, this could be used to originate spam, as it is send across the globe. This allows the attacker root access to the system. This is particularly useful over the long- and short-term.

Methods of Infection

As with many of the other malware infection and attack vectors, there are a number of ways the user may infect their system. The user could be fortunate enough to receive malware with the rootkit present and download it. This may be provided to the user with the usual email attachment, that has been used with so many other malware examples. The user while perusing through the internet and open a malicious site and inadvertently infect their system. These are a few examples, which could be mitigated with user training and awareness.

Types

The varied functionality has driven the number of rootkit types. Each type is used for the different types of targets. These may be application level, kernel level, or generally BIOS level kits. The ones mostly used at this point are the application and kernel level rootkits. With the application level rootkits, the executable files may be replaced with unauthorized files. With the kernel level rootkits, the attacker modifies the code or puts alternative code in place of the authorized code. With the Linux systems, this may be done with loadable kernel modules. 

 

The BIOS level rootkit is more advanced than the prior two methodologies. This is widely used, due to its increased functionalities. This is however more difficult to install. As these are saved onto a memory chip, the rootkit is more difficult to remove.

Samples

Over the years, there have been many different samples of the rootkit to become known in the industry. With such significant functionality, it is natural for this to be well-used with the different industries. This was first rootkit was coded in 1990 by Lane Davis and Steven Dake, targeting the UNIX OS. One of the first malicious rootkits was the NTRootkit, targeting Windows systems. The Mac platform was not left alone. The first Mac OS X rootkit was noted in 2009. This was coded to originate hidden system calls and kernel threads. 

 

As a rule of thumb, the rootkit is generally coded by the attackers for a malicious purpose. This has been repeated for years with other malware also. The attackers are not going to code this for something to do. Curiously one of the highest profile instances was with a corporation coding this for one of their products sold to consumers. This was intended to infect their clients starting in 2005 with the Sony BMG copy protection issue. Sony BMG happened to include a rootkit on their CDs which unbeknownst tot he user was engineered to limit the user’s access to the CD. This was rather significant and placed an unwanted spotlight directly on Sony for a long time. Other well known examples have been the t0rnkit in 2000, Zeus, Stuxnet, and Flame in 2002.

Detection

Although difficult to detect, this is not impossible and merely takes a bit more effort and time. The user or IT staff member tasked to assist the user may use an OS that is trusted and not infected for the search, use behavior based detection methods, scanning the system for the rootkits signature (if known), and analyzing a memory dump of the suspected systems.

Once found, the usual next step is to remove the issue. As easy as this appears, the process itself is much more complicated, and in certain cases impossible, as the rootkit is placed in the kernel. The user may have the pleasure of reinstalling their system’s OS.

Although rootkits have the potential to give the IT Department a rather powerful and extensive headache, there are training topics, much like the ones for other malware, that are available to increase awareness and mitigate the potential for infection, and hours of clean-up.