Threat Research: More Like This
I want to call out some impressive aspects of a report by Proofpoint.
I want to call out some impressive aspects of a report by Proofpoint: TA410: The Group Behind LookBack Attacks Against U.S. Utilities Sector Returns with New Malware.
There are many praise-worthy aspects of this report, starting from the amazing lack of hyperbole, and the focus on facts, rather than opinions. The extraordinary lack of adjectives is particularly refreshing, as is the presence of explanations for the conclusions drawn. ("This conclusion is based on the threat actor’s use of shared attachment macros, malware installation techniques, and overlapping delivery infrastructure.")
But most important to me is the clear and detailed exposition of how the attack itself worked. Proofpoint shared both sample emails, showing the human-level hooks, and the way the attacks worked ("Microsoft Word documents with malicious macros...the FlowCloud macro used privacy enhanced mail (“.pem”) files which were subsequently renamed to the text file “pense1.txt”. This file is next saved as a portable executable file named “gup.exe” and executed using a version of the certutil.exe tool named “Temptcm.tmp”.)
This is important because, as a defender focused on building products, I can use these details to conceptualize defenses. For example, we can see in their figure 6 the use of cmd. Perhaps we could block the use of cmd from macros, or require that the files executed be in certain locations? The malware copies certutil into %tmp% (I am unsure why.) Perhaps we could block execution of code in %tmp% (and %downloads%, while we're at it.) Perhaps we could block the renaming of files? That appears hard - once we can run arbitrary commands, there are a plethora of confusable deputies. Perhaps we could prevent anything inside a macro from making a file executable?
These models of the malicious acts and models of defense can be considered both for these details or other attacks. We might look at these attacks and their common features as we design new defenses. All too often, we only talk about what the malware does after it gets the ability to run code, not how it gets there. (For example, what we see in their Figure 9 is often Figure 1 or 2.) And while that's useful to the anti-malware community, more detail of the attacks help us design better defenses.
Very nice work by Michael Raggi, Dennis Schwarz, and Georgi Mladenov.