On 10 January 2019, Singaporean authorities finally released a report detailing how the attack against Singapore’s largest group of healthcare organizations, SingHealth, occurred. The breach took place between August 2017 and July 2018, resulting in the compromise of 1.5 million patient records, including personally identifiable information (PII) such as medical records, prescriptions, full names, National Registration Identity Card (NRIC) numbers, addresses, and dates of birth. In our last extended edition of ShadowTalk, Dr Richard Gold joined me to discuss the implications of the report.


What happened?

Perhaps unsurprisingly, the attackers did not use a dreaded zero-day exploit for initial intrusion. Early reports suggested the attack started through a phishing attempt. The authors of the final report said they were unable to nail down the initial vector; however, they also suspected it was phishing.

One compelling hypothesis doing the rounds on social media is that the attackers achieved their intrusion through an open source penetration-testing toolkit called Ruler. Here the attackers seemingly targeted a known vulnerability that SingHealth had failed to patch. This vulnerability allowed the attacker to modify a user’s Microsoft Outlook homepage. Armed with credentials, the attackers feasibly could have logged in to Outlook Exchange as that user and set their Outlook to be a piece of malicious code. If this hypothesis is true, then in essence this is a fully-remote attack conducted using Ruler, rather than a phishing attempt.

Another point to note is that the attackers were in the network for at least a year. Once they broke in, they then laid dormant for several months before moving laterally within the network and accessing the medical database they were after.

How might attackers use the stolen data?

The post-mortem report states that personal and outpatient data belonging to Singaporean Prime Minister, Lee Hsien Loong, was repeatedly targeted and accessed, which indicates there may be a political aspect to this attack. Nevertheless, with over 1.5 million records stolen, other motives beyond political-espionage need to also be considered.

If we think of how this data can be monetized, the detailed personal data included in the database can be used for financial purposes such filing fraudulent tax returns, or credit card and loan applications. With this amount of detailed information on an individual, you can effectively authenticate as another person. If combined with other datasets such as travel records or hotel stays – as seen in the Marriott breach – then this could be significant from a counter-intelligence perspective. There is therefore an overlap here between political-espionage and financial uses for the data.


Was this the work of an APT group?

Attributing attacks to Advanced Persistent Threat (APT) groups is fashionable, and we generally look at such claims with a degree of skepticism. In this case, however, there does appear to be some truth in it.

If we look at characteristics of the attack, the level of persistence displayed by the attackers fits the profile of an APT group. The attackers accessed a Citrix virtualization environment that allows you to connect to backend databases, including ones holding medical data. Here the attacker was able to gain access to the Citrix environment through credential reuse, but once they got in, there were a number of different servers and not all of these had the access they required. They tried numerous ways to access these and it is this tenacity that demonstrated the attackers had a goal – or set of goals – which they were clearly very motivated to achieve. In other words, they moved around the environment until they obtained the credentials they needed and the appropriate server to access the medical database.

This does not appear to be an opportunistic attack: for example, one where the attackers hoover up everything and anything they can find. Instead they specifically wanted access to a particular database. In the end, all these different attempts were what alerted the administrators that something suspicious was happening.


What are the main points security teams should take away from this report?

There are both technical and process failures here that we should pay attention to. On the technical side, we saw known vulnerabilities being exploited when patches were available. The organization had recently employed penetration testers whose findings were ignored. The tests addressed a lack of network segmentation (which allowed attackers to move laterally), and no multi-factor authentication for administrator accounts.

With regards to process, two key findings stand out. First, the report authors judged that the staff didn’t have the appropriate cyber security awareness or resources to respond effectively to the attack. While they picked up the activity, they didn’t understand it in the context of what APT attacks looks like, which severely limited how they could respond.

The second point is that key security personnel (those in charge of IT, security, incident response, and reporting) failed to take timely action. Put another way, those making decisions didn’t make any decisions. Something as significant as the Prime Minister’s medical records being repeatedly targeted and stolen should have been escalated to the Singaporean Cyber Security Agency (CSA), which has a background in APT activity. The security management personnel in question did not seem to know what a security incident was or how to respond. For example, they made unrealistic demands such as needing 100 percent confidence that it was malicious activity (you are never 100 percent sure until it’s too late). Even more alarmingly, they were reluctant to escalate the issue in case it was a false alarm and it would not reflect well on them.


For more analysis of the SingHealth breach post-mortem report, listen to the full episode of ShadowTalk: Episode 57: Singapore Healthcare Breach.


To stay up to date with the latest in digital risk protection, subscribe to our threat intelligence emails here.