Hardly a week (sometimes a day??) passes without some mention of ransomware, and another organization or municipality (or three) feeling the impact of a ransomware attack. In fact, just recently, the City of Durham, NC, was hit with a Ryuk ransomware infection, which by some reports, impacted their 911 capability. At the end of February, the BBC reported that two organizations impacted by a ransomware infection had been down for three weeks.
CrowdStrike recently released their 2020 Global Threat Report includes a great deal of information regarding ransomware, as viewed through CS's lens. The report includes more than a few pages of what CS had seen over the previous year, with some thoughts as to what they expect to see going forward.
In addition, just last week, Microsoft published an interesting blog post regarding human-operated ransomware attacks (with a very telling graphic available here). All of the events at which I spoke in 2019 focused on this very topic, that many of the ransomware attacks weren't about something that AV products would detect and prevent. The general perception of these attacks seemed to be predominantly, "oh, if I have AV or NGAV, I'm good..."; well, no. Because these are human-operated attacks, the human operator is able to modify the infrastructure to meet their needs. For example, pull plain text credentials from memory, in order to escalate privileges and extend their reach to other systems. The better part of this activity is missed by AV, because sometimes, malware isn't required to perform the "attack". Instead, attackers simply use the native MS tools provided within the operating system distribution, something referred to as "living off the land".
Further, as discussed in the CrowdStrike GTR, ransomware actors are increasingly modifying the infrastructure's they've targeted by disabling security products, enabling WinRM (sometimes through GPOs), and just making things easier for themselves. These changes often go unnoticed by the system owners but do serve as precursors to the actor deploying ransomware. This means that if these infrastructure modifications are detected, and there's a response plan in place, the overall impact of the ransomware being deployed can be obviated.
Impact
Something that is rarely discussed at length, or in an inclusive manner, is the impact of a ransomware attack, and why some organizations choose to pay the ransom. Sure, we're all generally aware of what happens...files are encrypted, everyone's caught by surprise, and suddenly things need to happen that no one was prepared to do. In some cases, such as with hospitals, diagnostics and patient record keeping gets reduced to by-hand processes, and the same is often true when a municipality's 911 services are taken down by ransomware.
I recently read this ZDNet article (similarly discussed in this NakedSecurity article), which discusses how 11 cases against six criminals were dismissed because the data was lost as a result of a ransomware attack. The article also provides a list of other similar issues (police depts experiencing ransomware attacks), going back to 2017.
The Windows Incident Response Blog is dedicated to the myriad information surrounding and inherent to the topics of IR and digital analysis of Windows systems. This blog provides information in support of my books; "Windows Forensic Analysis" (1st thru 4th editions), "Windows Registry Forensics", as well as the book I co-authored with Cory Altheide, "Digital Forensics with Open Source Tools".
Pages
▼
Wednesday, March 11, 2020
Tuesday, March 10, 2020
Revisiting Program Execution
As I prepare a presentation for a government agency, I've been thinking quite a bit about the idea of "program execution". I've actually blogged on this topic before, and I thought that maybe now was a good time to revisit the topic.
What does that mean? Well, generally speaking, it is accepted within the community that there are artifacts on systems that indicate that an application was executed. One popular example is Prefetch files; the existence of an application prefetch file indicates that an application was run. There are other artifacts, as well, including UserAssist subkeys, etc. Many of these artifacts tell us that an application was launched, or that a user launched an application (and when), but there's also a good bit that these artifacts don't tell us.
Here's an example...I was working a PCI case a number of years ago (and that "number" could be pretty big, like double digits...), and for those working those cases at the time, one of the things that Visa required of examiners was to populate a dashboard in the reports that included things such as "window of compromise", which is sort of what we refer to as 'dwell time'. In this case, the actor gained access to a system and loaded their malware on it, launched it, and left...and within a relatively short period of time, AV ran a scheduled scan, found the malware, and quarantined it. Through the analysis, we saw that it was another six weeks before the bad guy came back, found that the malware wasn't running, put a new version of the malware on the system and launched it.
Now, our finding was pretty huge, particularly for PCI cases. A lot of organizations are aware of the number of credit cards they process on a regular basis, and there's always a bump around the holidays. In this case, the malware was first placed on the system just prior to Thanksgiving, and wasn't refreshed until after the Christmas holiday. Visa used the number of transactions and the "window of compromise" values to help them determine fines; as such, being able to demonstrate that the malware was not running on the system for a specific time period really had a significant impact on that finding, and subsequently, the fine.
My point is, just because we know that an application was launched, do we then definitively know that it was run, or in the case a GUI application, what functionality was employed? The answer is no. I've seen a number of cases, during timeline analysis, where something was launched, only to have the system immediately respond with Application Error and Windows Error Reporting events in the Windows Event Log.
My previous blog post on this topic linked to another article I'd written, one that addressed analysis of one of the images from the DefCon 2018 CTF challenge. One of the questions I'd looked at specifically was question regarding the use of an anti-forensics application. In the three publicly available write-ups I'd reviewed, one had answered based on an item on the user's desktop, and the other two responded based on program execution artifacts. However, none of them had seen that attempts had been made to launch another anti-forensics application, and similarly, nor confirmed that actual anti-forensics had taken place, that anything had been deleted or modified.
The issue is that specifically with respect to GUI-based applications, the "program execution" artifacts will illustrate that the application was launched, but other efforts are required to determine what functionality was actually employed. After all, there aren't that many applications that record what options the user selected, nor which buttons they pushed. As such, "program execution" artifacts alone provide little qualitative difference between the user launching the application and letting is sit dormant on the screen, and the user actually using the application's functionality to do something. In fact, additional analysis steps are required; in the case of the DefCon 2018 CTF image, determining if the observed "program execution" artifacts truly resulted in the use of the applications' functionality.
What does that mean? Well, generally speaking, it is accepted within the community that there are artifacts on systems that indicate that an application was executed. One popular example is Prefetch files; the existence of an application prefetch file indicates that an application was run. There are other artifacts, as well, including UserAssist subkeys, etc. Many of these artifacts tell us that an application was launched, or that a user launched an application (and when), but there's also a good bit that these artifacts don't tell us.
Here's an example...I was working a PCI case a number of years ago (and that "number" could be pretty big, like double digits...), and for those working those cases at the time, one of the things that Visa required of examiners was to populate a dashboard in the reports that included things such as "window of compromise", which is sort of what we refer to as 'dwell time'. In this case, the actor gained access to a system and loaded their malware on it, launched it, and left...and within a relatively short period of time, AV ran a scheduled scan, found the malware, and quarantined it. Through the analysis, we saw that it was another six weeks before the bad guy came back, found that the malware wasn't running, put a new version of the malware on the system and launched it.
Now, our finding was pretty huge, particularly for PCI cases. A lot of organizations are aware of the number of credit cards they process on a regular basis, and there's always a bump around the holidays. In this case, the malware was first placed on the system just prior to Thanksgiving, and wasn't refreshed until after the Christmas holiday. Visa used the number of transactions and the "window of compromise" values to help them determine fines; as such, being able to demonstrate that the malware was not running on the system for a specific time period really had a significant impact on that finding, and subsequently, the fine.
My point is, just because we know that an application was launched, do we then definitively know that it was run, or in the case a GUI application, what functionality was employed? The answer is no. I've seen a number of cases, during timeline analysis, where something was launched, only to have the system immediately respond with Application Error and Windows Error Reporting events in the Windows Event Log.
My previous blog post on this topic linked to another article I'd written, one that addressed analysis of one of the images from the DefCon 2018 CTF challenge. One of the questions I'd looked at specifically was question regarding the use of an anti-forensics application. In the three publicly available write-ups I'd reviewed, one had answered based on an item on the user's desktop, and the other two responded based on program execution artifacts. However, none of them had seen that attempts had been made to launch another anti-forensics application, and similarly, nor confirmed that actual anti-forensics had taken place, that anything had been deleted or modified.
The issue is that specifically with respect to GUI-based applications, the "program execution" artifacts will illustrate that the application was launched, but other efforts are required to determine what functionality was actually employed. After all, there aren't that many applications that record what options the user selected, nor which buttons they pushed. As such, "program execution" artifacts alone provide little qualitative difference between the user launching the application and letting is sit dormant on the screen, and the user actually using the application's functionality to do something. In fact, additional analysis steps are required; in the case of the DefCon 2018 CTF image, determining if the observed "program execution" artifacts truly resulted in the use of the applications' functionality.