In its second annual Velocity healthcare data breach report, Stern Security has critically analyzed over 5,000 data breaches since the Department of Health and Human Services (HHS) began tracking the information in 2009. Stern Security utilized data from their HealthcareBreaches.com website as well as published information from HHS to create this comprehensive study. Stern Security augmented the HHS data by investigating each breach in 2022 to fully understand the cause of the incident.
This report shows critical insights into healthcare breach trends over the past 13 years. It covers everything from the number of breaches attributed to ransomware to the number attributed to third-parties (business associates). This year, Stern Security has added a new breach categorization – the number of breaches due to analytics software including Meta (Facebook) Pixel. Once again, a new breach record was established with more healthcare breaches occurring in 2022 than any previous year. This report puts forth a detailed analysis.
In its first annual healthcare data breach report, Stern Security has critically analyzed over 4,000 data breaches since the Department of Health and Human Services began tracking the information in 2009. Stern Security utilized data from their HealthcareBreaches.com website as well as published information from Health and Human Services to create this comprehensive report.
This report shows thought-provoking insights into healthcare breach trends over the past 12 years. It covers everything from the number of breaches attributed to ransomware to third-party (business associate) breaches. More healthcare breaches occurred in 2021 than any other year and this report illustrates the detailed analysis.
Healthcare breaches have recently reached a grim milestone. As of June 10th, 2022, the number of Protected Health Information (PHI) records breached has reached 341,995,928. To put in prospective, this number surpasses the United States population which is at 332,759,097 (United States Census Bureau, 2022).
As the graphs show on HealthcareBreaches.com, this startling loss of data is almost entirely due to hacking.
It must be noted that these numbers only include reported healthcare breaches containing 500 or more PHI records. Healthcare breaches under 500 records are not listed publicly. To view additional trends, please visit our healthcare executive data breach dashboard at https://www.healthcarebreaches.com/ and utilize the control panel on the left side to fine-tune your area of interest.
Works Cited
United States Census Bureau. (2022, June 10). U.S. and World Population Clock. Retrieved from United States Census Bureau: https://www.census.gov/popclock/
One would think that most data breaches were caused by hacking as those are the breaches that are always mentioned in the news. However, up until the end of 2019, Theft was still the top cause of breaches in healthcare according to data compiled from the U.S. Department of Health and Human Services (HHS) Office for Civil Rights.
Utilizing the Healthcare Breach Executive Dashboard at https://www.healthcarebreaches.com, we could see the breach trends changing. While breaches due to Theft were increasing at a slow pace, Hacking/IT Incident breaches were steadily climbing at a rapid pace. It was only a matter of time before Hacking topped the charts.
Why is the rate of breaches due to theft slowing down? One possible explanation is encryption. Most breaches due to Theft occur from stolen laptops, USB Drives, desktops, etc. that contain Protected Health Information (PHI). Thefts still frequently, however, organizations are getting better at encrypting drives. If a stolen drive is encrypted, it is not reported as a breach.
Even though Hacking only recently past Theft as the top source of healthcare breaches, there has been no competition for the source of the number of records lost. Hacking has far surpassed all other breach categories for the top cause of patient records compromised.
If breaches from Theft could be slowed down, perhaps Hacking can as well. Organizations must do all they can do increase security posture and reduce risk. Continue checking HealthcareBreaches.com for more trend updates.
Stern Security Labs analyzed a Locky ransomware sample. The following video shows an actual Locky ransomware attack on a Windows 7 machine. Watch how fast the ransomware encrypts the files on the computer. The computer is encrypted within one minute of clicking on the malicious “invoice.pdf” file!
We have recently received two samples of Locky maldoc (malicious document) ransomware from a healthcare institution. Ransomware is a devastating piece of malware that encrypts important files on an infected computer and demands ransom to decrypt the files. We will examine two samples.
Both samples arrived via email and were not detected by spam filters or antivirus when saved to the computer.
While analyzing the Word documents, it was discovered that the file format was actually a .mht Web Archive or a single file web page, and not an OLE Word document. If you take a .mht file and rename it as .doc Word will treat it the same.
The simplest way to convert it to an OLE document is to open it in Word and save it as a Word document.
Open the file in Word
Now we can analyze the document again. For this we used OLE Dump, a great tool for analyzing and extracting data from OLE files.
Streams with an uppercase ‘M’ are the more interesting VBA Macros.
I started by looking at stream 11: ./oledump.py –s 11 –v
As expected the script is obfuscated, but while reviewing the script one line stood out.
This line means there is more data in UserForm1.textbox 1and 2, but the data in textbox1 is base64 encoded. This time I look for any objects that contain UserForm1.
I reviewed stream 10 first since it was the largest and turns out it does contain the data we are looking for.
The value of textbox1 is base64 encoded and textbox2 is in plain text and does contain the URL for the payload. At this point I could just stop and go grab the payload and analyze it, but me being me, I want to see what the reset of the scripts are doing.
I tried to decode the base64 value I pulled with oledump but there was an issue with the value that was returned. So I went ahead and removed the VBA password from the document with a hex editor and pulled the value from Word. Below are the steps I followed.
Search for DPB in a hex editor and change it to DPX then save the document.
Open the document in Word, go to the Developer tab and press the Visual Basic button. Hit ‘Yes’ on the dialog box pertaining to the invalid key ‘DPX’ and hit ok on the next box.
Now the Visual Basic designer will open, under the project tree right click the project and open the properties. On the Protection tab un-check ‘Lock project for viewing’ and press Ok. Hit the save button in the Visual Basic designer and close, then save and close the document.
Now reopen the document select the Developer tab and press Macros. In the Macros list select the macro you wish to view and press Edit.
Now you have full access to the scripts and forms.
From here I was able to pull the base64 encoded value from textbox1 and did notice there was a difference. You can copy this value to linux and use base64 –decode but in this instance I just used www.base64decode.org.
After some deofuscation of the script I ended up with the following:
After some additional deobfuscation on the VBA macro I combined the 3 parts to reveal full script and the actions performed.
VBA macro creates file %temp%\arra.bat
Writes decodes and writes value of textbox1 and textbox2 to arra.bat
Executes %temp%\arra.bat
Arra.bat in turn creates %tmp%\dasdee.vbs
Echo’s the script contents to the dasdee.vbs script
Executes dasdee.vbs using cscript
dasdee.vbs performs a GET request to the http address passed in parameter %0% and saves the response to the location in parameter %1%
The bat file then executes the file save by the vbs script, deletes the vbs scripts and deletes itself.
Between the two samples the above steps did not change, the only differences were the number of UserForm1 textboxes and the URL. The Word document VBA macro obfuscation was also different but the base64 encoded script was the same in both samples.
Now that we have the URL for the PE file we can go and download it. One thing to note that sometimes to download the file you will need to match the Agent string in the script. For these samples this wasn’t required.
I started testing by changing the network for the VM so it was contained on its own network and blocked all outbound requests except for DNS on the perimeter firewall.
Sample1 was an older sample and I only saw DNS queries for what appeared to be DGA domains Command and Control servers(C&C).
I went ahead and removed the access restriction on the firewall and watched the POST requests. Only one of the DGA C&C hosts was still accessible and the one that did accepted the POST request closed the connection.
Since no response was received from the C&C Server, Locky just continued to the send POST requests and never proceeded beyond that point and did not encrypt any files.
Sample2, a newer sample, immediately tried to access a list of hardcoded IP addresses and sent a POST request. Once communication was established the malware only communicated with that host.
Reviewing the HTTP traffic from Sample1 and 2 I noticed the contents of the first POST request from the victim were encrypted but also that between the two samples the values were the same. This means that the network traffic is encrypted with a static value or at least the POST request is.
Once communication is established with the C&C server an RSA encryption key is transferred to the victim and stored in the ‘pubkey’ value of registry key ‘HKCU\Software\Locky’.
Now that Locky has the encryption key the below steps occur.
Delete Volume Shadow copies
Add startup registry keys
Output intructions.txt/.bmp
Encrypt Files
Some additional notes regarding Locky.
The file extension for encrypted files is always “.locky”
When files are encrypted the file is renamed as such, the first 16 characters of the filename is the value stored in the ‘id’ value of registry key ‘HKCU\Software\Locky’ and the second set of 16 characters are randomly generated.
Locky creates the registry key ‘HKCU\Software\Locky’ and sets the following values:
If Locky is executed from outside of %TEMP%, it copies itself to %TEMP% as svchost.exe and removes the original file.
I also fired up the debugger to see if I could recover the value used to encrypt the HTTP traffic. Unfortunately I wasn’t able to locate this value but I did locate some other interesting data.
Static IP address list to communicate to the C&C servers:
185.22.67.27 – PS Internet Company LLC Network, Kazakhstan
31.184.197.119 – Petersburg Internet Network ltd., Russian Federation
This is a list of OS ‘s that are targeted by the malware:
VSS Admin command:
Registry Key:
Conclusion:
Locky is a relatively new player to the ransomware scene but it appears to be on par with functionality of current ransomware families. Also with the amount of data that appears to be reported to the C&C servers, if filenames are reported in either the ‘path’ or ‘encrypted’ HTTP properties and those filenames contain PHI, an infection could be considered a breach.
If any new details are discovered we will updated this post.
We have recently received two samples of Locky maldoc (malicious document) ransomware from a healthcare institution. Ransomware is a devastating piece of malware that encrypts important files on an infected computer and demands ransom to decrypt the files. We will examine two samples.
Both samples arrived via email and were not detected by spam filters or antivirus when saved to the computer.
While analyzing the Word documents, it was discovered that the file format was actually a .mht Web Archive or a single file web page, and not an OLE Word document. If you take a .mht file and rename it as .doc Word will treat it the same.
The simplest way to convert it to an OLE document is to open it in Word and save it as a Word document.
Open the file in Word
Save as .doc
Now we can analyze the document again. For this we used OLE Dump, a great tool for analyzing and extracting data from OLE files.
Streams with an uppercase ‘M’ are the more interesting VBA Macros.
I started by looking at stream 11: ./oledump.py –s 11 –v
As expected the script is obfuscated, but while reviewing the script one line stood out.
This line means there is more data in UserForm1.textbox 1and 2, but the data in textbox1 is base64 encoded. This time I look for any objects that contain UserForm1.
I reviewed stream 10 first since it was the largest and turns out it does contain the data we are looking for.
…
The value of textbox1 is base64 encoded and textbox2 is in plain text and does contain the URL for the payload. At this point I could just stop and go grab the payload and analyze it, but me being me, I want to see what the reset of the scripts are doing.
I tried to decode the base64 value I pulled with oledump but there was an issue with the value that was returned. So I went ahead and removed the VBA password from the document with a hex editor and pulled the value from Word. Below are the steps I followed.
Search for DPB in a hex editor and change it to DPX then save the document.
Open the document in Word, go to the Developer tab and press the Visual Basic button. Hit ‘Yes’ on the dialog box pertaining to the invalid key ‘DPX’ and hit ok on the next box.
Now the Visual Basic designer will open, under the project tree right click the project and open the properties. On the Protection tab un-check ‘Lock project for viewing’ and press Ok. Hit the save button in the Visual Basic designer and close, then save and close the document.
Now reopen the document select the Developer tab and press Macros. In the Macros list select the macro you wish to view and press Edit.
Now you have full access to the scripts and forms.
From here I was able to pull the base64 encoded value from textbox1 and did notice there was a difference. You can copy this value to linux and use base64 –decode but in this instance I just used www.base64decode.org.
After some deofuscation of the script I ended up with the following:
After some additional deobfuscation on the VBA macro I combined the 3 parts to reveal full script and the actions performed.
1. VBA macro creates file %temp%\arra.bat
2. Writes decodes and writes value of textbox1 and textbox2 to arra.bat
3. Executes %temp%\arra.bat
3.1. Arra.bat in turn creates %tmp%\dasdee.vbs
3.2. Echo’s the script contents to the dasdee.vbs script
3.3. Executes dasdee.vbs using cscript
3.3.1. dasdee.vbs performs a GET request to the http address passed in parameter %0% and saves the response to the location in parameter %1%
3.4. The bat file then executes the file save by the vbs script, deletes the vbs scripts and deletes itself.
Between the two samples the above steps did not change, the only differences were the number of UserForm1 textboxes and the URL. The Word document VBA macro obfuscation was also different but the base64 encoded script was the same in both samples.
Now that we have the URL for the PE file we can go and download it. One thing to note that sometimes to download the file you will need to match the Agent string in the script. For these samples this wasn’t required.
I started testing by changing the network for the VM so it was contained on its own network and blocked all outbound requests except for DNS on the perimeter firewall.
Sample1 was an older sample and I only saw DNS queries for what appeared to be DGA domains Command and Control servers(C&C).
I went ahead and removed the access restriction on the firewall and watched the POST requests. Only one of the DGA C&C hosts was still accessible and the one that did accepted the POST request closed the connection.
Since no response was received from the C&C Server, Locky just continued to the send POST requests and never proceeded beyond that point and did not encrypt any files.
Sample2, a newer sample, immediately tried to access a list of hardcoded IP addresses and sent a POST request. Once communication was established the malware only communicated with that host.
Reviewing the HTTP traffic from Sample1 and 2 I noticed the contents of the first POST request from the victim were encrypted but also that between the two samples the values were the same. This means that the network traffic is encrypted with a static value or at least the POST request is.
Once communication is established with the C&C server an RSA encryption key is transferred to the victim and stored in the ‘pubkey’ value of registry key ‘HKCU\Software\Locky’.
Now that Locky has the encryption key the below steps occur.
1. Delete Volume Shadow copies
2. Add startup registry keys
3. Output intructions.txt/.bmp
4. Encrypt Files
Some additional notes regarding Locky.
The file extension for encrypted files is always “.locky”
When files are encrypted the file is renamed as such, the first 16 characters of the filename is the value stored in the ‘id’ value of registry key ‘HKCU\Software\Locky’ and the second set of 16 characters are randomly generated.
Locky creates the registry key ‘HKCU\Software\Locky’ and sets the following values:
If Locky is executed from outside of %TEMP%, it copies itself to %TEMP% as svchost.exe and removes the original file.
I also fired up the debugger to see if I could recover the value used to encrypt the HTTP traffic. Unfortunately I wasn’t able to locate this value but I did locate some other interesting data.
Static IP address list to communicate to the C&C servers:
185.22.67.27 – PS Internet Company LLC Network, Kazakhstan
31.184.197.119 – Petersburg Internet Network ltd., Russian Federation
This is a list of OS ‘s that are targeted by the malware:
VSS Admin command:
Registry Key:
Conclusion:
Locky is a relatively new player to the ransomware scene but it appears to be on par with functionality of current ransomware families. Also with the amount of data that appears to be reported to the C&C servers, if filenames are reported in either the ‘path’ or ‘encrypted’ HTTP properties and those filenames contain PHI, an infection could be considered a breach.
If any new details are discovered we will updated this post.
Open the file in Word
…
