The June 2017 Petya (Petna, Petrwrap, etc.) outbreak injected some much un-needed excitement into an IT sector just starting to come to terms with the implications of the WannaCry outbreak a few weeks beforehand.
In the immediate wake of WannaCry there was a discussion around what could have been done to reduce the impact of the outbreak, but even without the benefit of hindsight it was easy to point to slow patching cycles and the questionable architectural/configuration decision of allowing SMB traffic from external addresses past the network boundary.
However, as discussed in our earlier blog post, June 2017’s Petya campaign appears to have been deployed via a malicious software update and used PsExec and WMIC commands in addition to the now-notorious ‘Eternal’ SMB exploits to spread laterally across compromised networks. Do these observations and recommendations therefore still hold true for Petya?
Gartner Market Guide for User and Entity Behavior Analytics
By what help?
"Who, what, and where, by what helpe, and by whose:
Why, how, and when, doe many things disclose"
As with WannaCry, the what and where parts of the analysis have been thoroughly covered by this point, albeit with some tug-of-war over semantics: whether the malware was released in an unfinished state or what a piece of malware incapable – at least under certain circumstances – of restoring a victim’s files should be called are matters of speculation and debate.
Any answers to who and why are similarly speculative until a smoking gun can be found: the former is attribution and the latter is inextricably tied to attribution.
The excitement in Petya stemmed from its ability to self-propagate. While this behaviour was apparently limited to the local network (unlike WannaCry it didn’t attempt to spread itself to external, Internet addresses) it had multiple methods of completing this goal.
Assuming that all of the systems on an affected network are patched and up-to-date, propagation via EternalBlue shouldn’t be viable. That leaves us with the rather less discussed (and less glamorous) PsExec and WMIC approaches to spreading.
The use of these tools is of note because they are both legitimate administrative tools in use across almost all Windows environments (indeed, WMIC has been pre-installed in all versions of Windows from 2000 onwards). As a result, when combined with valid credentials and malicious intent they can be used to do a large amount of damage.
To understand how, we need to appreciate what these tools actually do. Through this we can also see why their usage is preferable to exploits such as EternalBlue for more skilled attackers.
PsExec dates back to 2001 and while its name (these days, at least) could imply an association with PowerShell, that is not the case. Rather than being a built-in component of Windows, it is part of the PsTools suite that allows properly authenticated users to both run commands on remote machines and redirect their output to the local machine.
Despite the fact that it isn’t a component that ships with Windows and therefore needs ‘dropping’ on a target system before it can be used, it has been popular with the authors of malicious code for well over a decade, with its author noting in an article from 2004 that…
“Several viruses use PsExec to propagate within a network, and as a result, several major antivirus products flag PsExec as a Trojan horse program or a worm. Remember that PsExec works on remote systems only if it runs within an account that has administrator group membership on the remote system. In other words, unless the account from which you run it has administrative access to a remote system, PsExec won't be able to execute a process on the remote system. In addition, PsExec's functionality can be achieved in other ways; thus, PsExec is only a convenience for virus writers, who could otherwise easily implement the functionality that PsExec provides.”
WMI & WMIC
WMIC is the command-line interface to WMI (Windows Management Instrumentation) and older still than PsExec, having been an optional download during the Windows NT 4.0 era before coming preinstalled from Windows 2000 onwards.
WMI provides a huge amount of functionality for the administration of Windows-based networks allowing users with the right credentials to do anything from launch processes to modify the security settings on the remote machine. These capabilities can and have been used by APTs including Fancy Bear and Cozy Bear to implement fileless persistence mechanisms on compromised systems.
Image: The WMI Command-line interface
Abuse of privilege
Both of these tools require administrative credentials to do real damage. In the case of the June 2017 Petya outbreak this was gathered through the use of built-in credential stealing code, although in more targeted attacks there’s every chance that the credentials will have been stolen during an earlier phase of the attack.
Given this need for valid login details, it may initially seem odd that malicious actors choose to use these tools when an exploit would likely get the job done more quickly and easily. In reality, this is far more reflective of the behaviour of skilled hackers and penetration testers: exploits are ‘unnatural’ traffic on a network and using them significantly increases the risk of detection.
Abusing administrative tools, on the other hand, results in malicious activity blending into the background noise of a big network allowing attackers to maximise their dwell time on networks.
Security vs usability
So how do we secure against tools that are ubiquitous within Windows networks? Especially tools for which there are a range of legitimate uses?
To some extent there’s a limit to what can be done: banning knives in your home would certainly prevent a house guest with a questionable sense of humour from shredding your wardrobe, but it would equally make cooking dinner rather difficult.
Access to administrative tools should be limited, but generally speaking this is already the case: very few corporate networks (hopefully no corporate networks) allow all users unfettered permissions on their system.
This largely leaves us with detection, and with so much administrative activity taking place at any point in time on a typical network even this is no easy task. Successful security monitoring against more advanced threats typically requires input from a number of sources and this situation is no different. While these options may not be viable for all networks, you may want to consider:
- Monitoring for remote administration traffic from unexpected machines: While admins may often need to log in to workstations to diagnose or fix faults, they are unlikely to need (or want) to perform bulk administration tasks from a machine in the accounts department.
- Sudden changes in the behavioural profile of an administrative account: Though it requires the development of a good baseline for the behaviour of individual users, deviations from this baseline may indicate a potential compromise. A sudden increase in login activity from a given administrative account may simply be indicative of legitimate deployment activity, but hopefully security operations are already aware of any major planned work of this type…
Behavioural monitoring of human interaction is no simple task, but Security Information & Event Management (SIEM) products can help by pulling disparate log sources together and providing both alerting and a holistic view of activity on a network. For example, while an internal IDS may be configured to detect large amounts of Remote Procedure Call (RPC) traffic, this information will likely need to be combined with other log sources such as Windows event logs to confirm the user accounts involved.
To this end, it is worth considering the architecture of new networks (or extensions of old networks). Flat networks pose almost no architectural barriers to lateral movement and rarely offer suitable ‘choke points’ for protection and monitoring devices. While not a panacea, network segmentation provides these choke points for the deployment of IPS devices and firewalls which may allow for a degree of damage limitation in the event of a compromise.
Overall, some general advice does still stand under these circumstances: prevention is better than cure. While all the patching in the world may not protect you from an insider threat or malicious software update, minimising the number of vectors available to external actors through a combination of real time monitoring and secure network design can help stop a lot of attacks before they start.