In the last two articles, I have covered Legacy AV solutions and why they are outdated when looking at the current threat landscape and the changing of the guard surrounding zero trust only security solutions. In this article, we are going to cover something that is a little more “personal” as it might hit a little bit closer to home than we would like. The current state of security operations/security engineering has become far too lenient in allowing tools of convenience to run amok within their environments causing self-inflicted incidents of utter chaos and panic once the tool has been weaponized.
What could possibly get into your environment that would not be detected and leave you so vulnerable? Some of these tools of convenience are already on your PC, such programs are Powershell, Process Explorer, PsExec, Process Hacker, etc. These programs are tools with “dual-use”. We call them “dual-use” tools as they are designed to make our lives easier, but they also make the job of malicious coders easier, as they leave your environment open to some extremely nasty points of entry/takeover.
A good example of dual-use tools being manipulated and wreaking chaos in an environment is Sodinokibi (also called REvil). By weaponizing this tool, attackers (bad actors) can compromise the dual-use RMM tools companies are using and leverage them to drop malware into the environment. This is most successful with a legacy AV solution being in place, which cannot detect file-less attacks via any form of efficient script prevention. That has been a commonplace attack vector since late 2018 and almost all of 2019 (although positive strides are being taken by RMM providers to enhance security and make 2FA mandatory). Read the white paper that we released on file-less malware.
I was recently challenged by a colleague who questioned how simple it could be to weaponize a consumer-based program and circumvent any end-point security installed. Challenge accepted! After downloading a common dual-use tool (name withheld purposely) I weaponized it (no details provided purposely) to enable the removal of crucial files. These files were initially self-protected by the endpoint security program. To no surprise, the endpoint security solution still showed “enabled” with no errors, any signs of any issues or manipulations required. I was then able to easily drop Dharma ransomware (Crysis variant) on the endpoint and fully encrypt it. Total time to prepare? 30 seconds to 1 minute! Total time of resulting chaos? Weeks to months! At the time of this test, a handful of vendors detected the tool I weaponized, but Deep Instinct actually halted it based on the potential behavior. It’s not uncommon for bad actors to probe an environment with different software to see what is detected and what is not. Sadly, I have previously seen this exact behavior with one unfortunate company where I assisted with the post-mortem analysis.
What did it look like when I ran through the process to encrypt the machine while the security solution was actively enabled? Below is the file flow utilized locally on the machine (this can also be done remotely with utilities like PsExec to execute the commands for the program in question).
Step 1: Getting the program downloaded (name omitted) and validating it was not detected by the enterprise security solution installed on the endpoint.
Step 2: Isolating the processes in question and finding the specific file we want to terminate.
Step 3: Gain access/delete the key file which should be protected via self-protection.
Step 4: Validating the program which still thinks it’s “active” even though it won’t do anything on the back end.
Step 5: Ransomware running while the program is “Enabled”.
Step 6: Complete lockdown of the machine via ransomware while the program is “installed” and running thanks to a dual-use tool.
Another great example that has been in the news recently (December 2019) is the “Snatch” ransomware which reboots machines to safe mode prior to running the encryption. This is new and unique as Safe Mode was primarily used to halt ransomware or to assist in remediation as it would prevent network communication and limit access to services/execution runtimes by design. Snatch ransomware does several different dumps to gather data, all of which are not outside the normal realm of operations for ransomware. However, what is different are the tools and methods for the infection. Legitimate tools are downloaded, such as Advanced Port Scanner, which is used to identify more targets in the environment. But the most lethal part of Snatch’s methods is from a dual-use tool called PsExec.
PsExec is a utility far too many admins rely on for permitting remote execution of commands on machines for convenience. However, this “convenience” is now a nightmare! The whole process of this ransomware (executing files, rebooting to safe mode, detonating payload) all hinge on the usage of PsExec interacting with user32.dll (a system process that is needed for your PC to work properly) and then a randomly generated file such as XXXXX_unpack.exe.
Legacy AV solutions require so much configuration to restrict anything which is not directly coded into their content files, by way of manual additions to either management consoles or policies. This brings about a certain level of complacency within most security teams because the programs are not inherently malicious. The thought of them being weaponized is generally overlooked until it’s too late and creates chaos in their environment.
Believe it or not, there already exists a solution that can handle all of this. This same solution has minimal management overhead and offers the ability to block all PUA (Potentially Unwanted Applications) outright via policy allowing your security team to spend their time working on actual issues.
Curious to know more about how it works? Reach out and let’s have a conversation!
Deep Instinct, we prevent what others can’t find!