Signals relating to DarkHotel operator tradecraft have been flagging our CTI engine since early November 2019. Over the past three weeks, we have seen PoC exploit code become publicly available that has directly copied suspected DarkHotel activity (WizardOpium Attack Chain). It wasn't until I received an email from a colleague early this morning, asking if I had insight into the attack on The World Health Organization (WHO), that I began to correlate these signals. The resulting analysis may indicate that adversaries (not necessarily DarkHotel) may adopt and utilize DarkHotel tradecraft on unpatched systems. Systems that have slightly out-of-date patches due to lack of automation or specific environmental requirements, may be at significant risk of being breached by former, chained, zero-day exploits that were presumably used by DarkHotel, in the WizardOpium campaign. Specifically, Google Chrome versions below 78.0.3904.70 and various unpatched versions of Windows are affected – both Personal and Server operating systems. Furthermore, there is a significant amount of how-to documentation, commentary and publicly available exploit code to drastically reduce the barrier-to-entry, for this level of sophisticated attack. It has been our experience thus far, that when former, advanced operator, zero-day code becomes publicly available, an increase in system breach occurs – regardless of community security awareness or patch availability. Given the recent attack on WHO, the suspected attribution to DarkHotel and former DarkHotel zero-day signals trending across our sensors, we feel that the WizardOpium attack chain may be leveraged against unpatched systems in the coming future, by other malicious actors, or actors looking to fly a false flag operation. Lastly, this wealth of knowledge may be used as a jump-off point and empower the next generation of zero-day exploit vectors.
WizardOpium Attack Chain
"The WizardOpium attack chained together the Chrome zero-day (CVE-2019-13720) as well as a Windows zero-day privilege elevation vulnerability to install the malware. 'During our investigation, we discovered that yet another 0-day exploit was used in those attacks. The exploit for Google Chrome embeds a 0-day EoP exploit (CVE-2019-1458) that is used to gain higher privileges on the infected machine as well as escaping the Chrome process sandbox,' Kaspersky explains.
The Windows zero-day is tracked as CVE-2019-1458 and it was used to gain elevated privileges on Windows machines and escape the Chrome sandbox to install the malware payload. Both of these vulnerabilities have now been patched and this exploit chain is broken. "
Additionally, the WizardOpium attack chain was initially delivered through drive-by compromise. “A drive-by compromise is when an adversary gains access to a system through a user visiting a website over the normal course of browsing. With this technique, the user's web browser is typically targeted for exploitation, but adversaries may also use compromised websites for non-exploitation behavior such as acquiring application access tokens. ”
Technical details and PoC source code can be found referenced by number, below. - “WizardOpium Attack Chain Timeline”.
WizardOpium Attack Chain Timeline (CVE-2019-13720 & CVE-2019-1458)
Advances in detections for offensive PowerShell set the stage for an epic tradecraft migration into C#. Now, with the inclusion of more advanced AMSI (Antimalware Scan Interface) functionality in .NET 4.8, offensive C# tactics look to migrate so as to not become obsolete. Offensive DLR (Dynamic Language Runtime) not only makes AMSI and ScriptBlock Logging detections a distant thought, but it also allows threat actors to access the power of .NET libraries with simple scripting languages like IronPython. Influential development clusters within the security community have already begun weaponizing offensive DLR, and it won’t be long before adversaries look to migrate their .NET narrative to match.
PowerShell, the Holy Grail
PowerShell is thought by many red teamers as the holy grail of offensive .NET tradecraft. This is in part due to it being a scripting language, installed on endpoints by default, allowing for in-memory injection and its ability to interact with .NET APIs. The problem is that offensive PowerShell has become highly detectable with security features like AMSI and ScriptBlock Logging , or limitations imposed on it by constrained language mode. Even though bypass methods  exist to bypass PowerShell detections, the results are typically less than ideal. These advances in detections caused a migration of tradecraft which gave birth to offensive C# tools like Covenant C2 . Many of these tool systems aimed to replicate functionality found in popular Offensive PowerShell systems, just ported to C#. To compound this idea, many developers who originally authored those offensive PowerShell systems also authored the new C# tools.
What is .NET?
Maybe right now is a good time to step back and look at what .NET actually is. ".NET Framework (pronounced as "dot net") is a software framework developed by Microsoft that runs primarily on Microsoft Windows. It includes a large class library named as Framework Class Library (FCL) and provides language interoperability (each language can use code written in other languages) across several programming languages. Programs written for .NET Framework execute in a software environment (in contrast to a hardware environment) named the Common Language Runtime (CLR). "
Trouble in C# Paradise
One of the biggest problems besides overhead for offensive C# happened with the release of .NET 4.8 and its increased anti-malware functionality. "In previous versions of .NET Framework, Windows Defender or third-party antimalware software would automatically scan all assemblies loaded from disk for malware. However, assemblies loaded from elsewhere, such as by using Assembly.Load(byte), would not be scanned and could potentially carry viruses undetected. .NET Framework 4.8 on Windows 10 triggers scans for those assemblies by Windows Defender and many other antimalware solutions that implement the Antimalware Scan Interface. We expect that this will make it harder for malware to disguise itself in .NET programs. "
What is DLR?
"The purpose of the DLR (Dynamic Language Runtime) is to enable a system of dynamic languages to run on the .NET Framework and give them .NET interoperability. " So that’s the legitimate purpose, but what opportunities does this grant adversaries? DLR allows the embedding of compilers/engines within other .NET languages (e.g PowerShell & C#) while still remaining Opsec safe & executing in memory. This vector also allows threat actors to access the power of .NET libraries with simple scripting languages like IronPython, IronRuby and Boo. Lastly, evasion benefits are greatly increased - “all your 'evil' can be coded in the language of your embedded engine/compiler. If you do this using PowerShell, ScriptBlock Logging sees nothing since all the magic happens in the DLR .”
As with what happened with the advances in PowerShell detections that pushed Offensive PowerShell to migrate to Offensive C#, the same has happened with C# detections now continuing to push the evolution of .NET tradecraft. The weaponization of DLR is that advancement and is being leveraged in tools like SILENTTRINITY . SILENTTRINITY is a Command and Control, post exploitation framework that is actively being developed by a brilliant developer cluster, connected to some of the most influential flavors of .NET tradecraft. We anticipate the weaponization of DLR and tools like SILENTTRINITY to become a staple in the advanced adversary toolkit for two reasons - other than the reasons stated above. The authors of SILENTTRINITY and their development micro-cluster are contributing developers to some of the most authoritative tools that have shaped adversary tactics. This gives the developers an enormous amount of credibility as to whether or not their emerging tradecraft will be effective. Second, adversaries watch the security community, but specifically, they watch community influencers and adopt their tactics accordingly. The more social reach a tool system has, the more likely adversary adoption is. Some key features of SILENTTRINITY are:
We are just getting our feet wet with this vector and plan to do many tests with various tools and techniques encompassing offensive DLR. In our opinion, this is a great evolution of .NET tradecraft, backed by influential developers and leverages systems with inherent complexity and that usually translates into an attack surface that is difficult for defenders to lock down.
Adversaries track developments within the security community to look for effective ways to skirt modern defenses. Our sensing technology (Guru) that surveils the security community has been effective at ingesting signals relating to emerging attack vectors, sometimes 3 – 6 months ahead of confirmed campaigns. The signals we consume originate from social influencers, code repositories, CVE PoCs, community chatter and research blogs from within the security community. A recent example of where our emerging threat technology was confirmed by actual adversary events was the Fox Kitten Campaign. This campaign was masterfully articulated in a report written by ClearSky Cyber Security which recounted the activities of the suspected Iranian APT groups involved. Drilling down, we will focus on the methods utilized by the attackers which allowed for credential access and were signaled in advanced by our platform, as early as July 2019.
Mimikatz and Endpoint Security
Mimikatz has long been an adversary staple for gaining credential access. Most endpoint security solutions will now easily detect the signatures and(or) behaviors associated with Mimikatz, forcing adversaries to find new methods to skirt defenses. Additionally, default security features like Virtualization-Based Security for Win 10 enterprise users will significantly hinder credential dumping techniques as the processes involved are shielded within a virtual environment. “The Microsoft hypervisor creates VSM and enforces restrictions which protect vital operating system resources, provides an isolated execution environment for privileged software and can protect secrets such as authenticated user credentials. With the increased protections offered by VBS, even if malware compromises the operating system kernel, the possible exploits can be greatly limited and contained because the hypervisor can prevent the malware from executing code or accessing secrets”. That being said, there is a significant part of the computer population not running enterprise edition but still possessing security solutions able to chew up tools like Mimikatz. This is where the security research in the latter half of 2019 focused and how adversary tradecraft migrated in response.
Procdump + Mimikatz
Starting early fall of 2019, our sensors saw an explosion of activity in the security community relating to credential dumping techniques and tools. The first family of signals surrounded the use of ProcDump (a legitimate Microsoft tool) to dump LSASS memory, and then parse the output with Mimikatz on an attacker controlled endpoint. An interesting caveat to this technique was that if the command “procdump -ma lsass.exe lsass.dmp” was used without the PID for LSASS being specified, Defender would catch the behavior. Within the recently documented Fox Kitten Campaign, this command was issued to dump credentials during the attacks. In addition to the tradecraft chatter regarding ProcDump, our sensors ingested purpose-built tools that capitalize on this vector. Examples of exploit tools that utilize this vector are lsassy - “Extract credentials from lsass remotely” and spraykatz - “Credentials gathering tool automating remote procdump and parse of lsass process ”. Had defenders realized in advance that this vector was gaining significant traction, these attacks may have been prevented or detected earlier.
MiniDump + Mimikatz
Additional LSASS attack vectors were also simultaneously trending within the security community. Taking advantage of the Windows library “Dbghelp.dll”, attackers may exploit the function "MiniDumpWriteDump” to dump LSASS memory. Examples of tools that utilize this technique are MiniDump - “an alternative to procdump written in C# (perfect for execute-assembly)” and SharpDump - “SharpDump is a C# port of PowerSploit's Out-Minidump.ps1 functionality”. Other tools utilizing this vector can possess additional advanced functionality like API unhooking and command and control integration. A great example of such a tool is Dumpert - “LSASS memory dumper using direct system calls and API unhooking ”.
Had Defenders had access to forward-looking cyber intelligence, they may have been able to mitigate or minimize some of the attacks associated with the Fox Kitten Campaign. While we have seen direct correlation between Guru’s ingested signals relating to dumping LSASS memory and recent adversary behaviors, other variations aimed at targeting LSASS can also be assumed to be in play (MiniDump). Defenders should look at how adversary tradecraft migrated from the security community (the use of ProcDump to dump the LSASS + offline Mimikatz) to an actual adversarial campaign (Fox Kitten). Defenders should threat hunt for indicators relating to coexisting exploit vectors that are developing within the security community, aimed at dumping LSASS memory.
A Preamble on Link Analysis
Graphing relationships adds another level of context when looking at emerging exploit technologies. For instance, if a new exploit tool is connected with a development cluster that has produced other effective exploit technologies, the probability is high that this tool will also be effective. Following that train of thought, typically authors within a development cluster are also connected to other similar projects and insights may be obtained with this reasoning. This became apparent when our sensors ingested the tool evilginx2 and then proceeded to map the development cluster for that tool. It was because of this mapping (seeing the other projects the developers were working on) that we found an entire colony of exploit tools targeting 2-factor authentication 6 months before the FBI released an official Private Industry Notification warning about these technologies. “At the June 2019 Hack-in-the-Box conference in Amsterdam, cyber security experts demonstrated a pair of tools--Muraena and NecroBrowser—which worked in tandem to automate a phishing scheme against users of multi-factor authentication. The Muraena tool intercepts traffic between a user and a target website where they are requested to enter login credentials and a token code as usual. Once authenticated, NecroBrowser stores the data for the victims of this attack and hijacks the session cookie, allowing cyber actors to log into these private accounts, take them over, and change user passwords and recovery e-mail addresses while maintaining access as long as possible.” Lastly, we know that adversaries surveil the security community to look for innovative ways to migrate their tradecraft and skirt modern defenses. By analyzing connections within the graph, the level of social influence imposed by a development cluster can be assessed and an exposure probability for an exploit tool can be determined. Our analysis indicates that adversaries are more likely to migrate their tradecraft to new technologies where they already know and follow the authors in some capacity. To summarize this idea, exploit tools coming from development clusters with low social influence may still be quite effective but may lack the overall exposure to be widely adopted by adversaries.
Continuing with the example development cluster above, additional mapping revealed a tool connected to the evilginx2 development cluster which automated the setup of these tools targeting 2FA. “Phish-Composer is a docker-compose project intended to spin up three docker images often used together for phishing. The individual components of this infra are GoPhish, Evilginx2, and Postfix.” While this automation framework leverages evilginx2 to phish 2FA, we felt another tool within the cluster was also of notable mention. “Muraena is an almost-transparent reverse proxy aimed at automating phishing and post-phishing activities.” It will be of great value for adversaries to setup advanced initial access tooling in a repeatable and secure fashion utilizing automation.
Red-Baron is part of a development cluster that has prolific exploit tool makers. One such maker goes by the alias byt3bl33d3r and has co-developed tools like SILENTTRINITY, CrackMap and Empire. “Red Baron is a set of modules and custom/third-party providers for Terraform which tries to automate creating resilient, disposable, secure and agile infrastructure for Red Teams. During Red Team assessments, infrastructure creation and management can be a huge time sink. This project tries to alleviate this by attempting to automate some (if not all) aspects by providing a set of modules and example configurations: testers can pick & choose the infrastructure to be created and configure it to their needs.” This tool can create complex infrastructure, such as redirector and command and control servers, across multiple cloud platforms.
“Redcloud is a powerful and user-friendly toolbox for deploying a fully featured Red Team Infrastructure using Docker. Harness the cloud's speed for your tools. Deploys in minutes. Use and manage it with its polished web interface. Ideal for your penetration tests, shooting ranges, red teaming and bug bounties! Self-host your attack infrastructure painlessly, deploy your very own live, scalable and resilient offensive infrastructure in a matter of minutes.” Similar to Red-Baron, this tool aims at deploying full-featured adversary infrastructure but with its own polished interface.
It stands to reason that setting up adversary infrastructure in an automated fashion will become a standard. Considering the efficiency and operational security advantages, setting up an infrastructure in a repeatable and secure manner can have huge benefits for adversaries. Using automation to setup more complex components like redirector servers (Apache mod_rewrite) automatedly, could eliminate operators deciding on default infrastructure deployments that are easily located by blue teamers.
Over the past few years, Cobalt strike has become an industry standard for professional red teamers, state sponsored actors and cyber criminals alike. Cobalt Strike is defined as “a commercial, full-featured, penetration testing tool which bills itself as “adversary simulation software designed to execute targeted attacks and emulate the post-exploitation actions of advanced threat actors. Cobalt Strike’s interactive post-exploit capabilities cover the full range of ATT&CK tactics, all executed within a single, integrated system.” Cobalt Strike has been leveraged by advanced persistent threat groups like APT19, APT29, APT32, FIN7 and Cobalt group to facilitate various campaign objectives. In order to try and keep this powerful tool out of the hands of malicious actors, Strategic Cyber LLC (creators of Cobalt Strike) impose export controls and monitors for illicit usage. Despite software licensing for Cobalt Strike being strictly controlled, adversaries crack trial versions of the software and disseminate them across various channels frequented by the criminal underworld. Some of these cracked versions are sold, and some are distributed for free, but a free version most likely means you are sharing your experience with someone else via a backdoor.
Fingerprinting Cobalt Strike Servers
Researchers at Fox IT and Recorded Futures started utilizing fingerprints unique to Cobalt Strike team servers to find adversary C2 infrastructures in the wild. June 18th, 2019, Recorded Futures published a report detailing the features they employed to fingerprint team servers and expounded on their effectiveness. The methods used to fingerprint Cobalt Strike servers were to look for default security certificates, to see if the DNS server would respond to any DNS request, port 50050 usage, a unique 404 response code and versions prior to 3.13, a null space in the HTTP response could be used to identify the team servers. This actually proved quite effective as many operators seemed to run on default configurations even after these security publications - “The continued identification of Cobalt Strike servers using an outdated version of the framework (via the null space in the HTTP header) and the default configurations may indicate that a large population of Cobalt Strike servers are cracked or stolen versions. It may also be an instance of operators not reading security publications, but the answer may be more simple than that — most targets are not likely searching for Cobalt Strike servers, and the payloads remain effective, so why change their behavior?” In response to these advancements in breaching adversary operational security, “Cobalt Strike operators were encouraged by Strategic Cyber LLC in their February study to make use of an Apache or Nginx web server as a “redirector” to proxy their traffic; this precludes simple detections of Cobalt Strike servers by removing the anomalous HTTP responses, default security certificates, and other such identifiers from the equation”. In closing thoughts, the report stated “Obstacles other than intentional tradecraft may prevent the patching of Cobalt Strike servers, including lack of knowledge of the update due to a language barrier, operational comfort with currently installed versions, or other modifications that prevent the installation of the update.” But, things are never so neat in reality..
Increased Cobalt Strike Momentum
Starting mid-summer of 2019, our intelligence sensors started ingesting significantly more material related to Cobalt Strike, emanating out of the Chinese security community. Our investigations led us to an actor presumed to be Chinese (Mrxn) that was creating and disseminating cracked versions of exploit software on his/her personal blog. One post in particular caught our eye which was entitled “CobaltStrike3.14破解 / English: CobaltStrike3.14 crack” and was published one day after Recorded Futures released their report mentioned above.
In the following blog post, we see actor Mrxn talking about the operational security problems related to cobalt strike versions pre 3.13, confessing to cracking and distributing a cracked version of Cobalt Strike 3.14, briefly explaining which files to alter to crack the software and providing links to cracked and trial versions of Cobalt Strike.
Our sensors continued to ingest material related to Cobalt Strike, this time they found aggregations of red team resources being translated into Chinese. These vast lists contained detailed information on a wealth of adversary topics, but it was the in-depth explanation on red team infrastructure that made us realize that a language barrier was actually no barrier at all. In a code repository entitled “RedTeam-BCS” we found a detailed explanation of Cobalt Strike infrastructure tactics. Under the heading “基础设施架构设计部署 - Infrastructure architecture design and deployment” we saw the detailed teachings of how a redirector server functions and how it is used operationally.
A key theory we based building our backend cyber intelligence tooling on was “tradecraft migration”. We define “tradecraft migration” as an adversary’s willingness to shift their TTPs (Tactics, Techniques and Procedures) to skirt innovation in cyber defenses, while expending the least amount of resources to do so. Actually, adversaries just need to employ a good cyber intelligence program to accomplish this, leveraging and building off innovation that is taking place within the security community already. We see security researcher content consistently shared and discussed on criminally controlled communication assets. The above scenario is an excellent representation of tradecraft migration for these reasons:
Our analysis indicates that more advanced forms of adversary infrastructure obfuscation such as leveraging redirectors, domain fronting or utilizing legitimate web services will become a standard in adversary tradecraft, if it’s not already. Defenders should not presume a language barrier is any kind of obstacle preventing adversaries from learning and deploying advanced infrastructure obfuscation tactics. As we indicated above, that is clearly not the case. Using tradecraft such as redirector servers to obscure Cobalt Strike infrastructure makes blue team detection strategies significantly less effective – especially when redirectors are paired with proper domain categorization and HTTPS. Knowing adversarial capabilities in near real-time is a powerful tool for defenders and must be utilized to come up with new, innovative detection methods for things like Cobalt Strike team servers.