8/20/2020 Attacking Defender ATP’s New Block ModeIntro In this first scenario, we will create a very noisy attack chain based on our trending threat intelligence and see which parts ATP’s new Block feature will detect, block and(or) auto-remediate. The endpoint under test has been added to the automated investigations group and ATP’s EDR block mode has been enabled. “When endpoint detection and response (EDR) in block mode is enabled, Microsoft Defender ATP leverages behavioral blocking and containment capabilities by blocking malicious artifacts or behaviors that are observed through post-breach protection. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach [1].” - docs.microsoft.com Method: Noisy 1. We drop a malicious CMD to disk which invokes PowerShell (Invoke-WebRequest) to download a vulnerable driver (RTCore64.sys), PPLKiller and a shellcode injector that utilizes direct system calls to establish a channel with Covenant C2 (SYSTEM level integrity). The Micro-Star MSI Afterburner driver [2] is a signed Microsoft driver which can be exploited to allow arbitrary read/write access of kernel memory [3]. While this CMD script is not practical from a red team perspective (needs a UAC bypass / lots of things dropped to disk, visible console windows), it does generate some dangerous and noisy behaviors that will test ATP’s ability to detect and respond in an automated fashion. 2. Next, we see in the Device Timeline that ATP registers the driver (RTCore64.sys) being loaded and the PPLKiller process being created. 3. APT does issue a warning for a suspicious file being dropped to disk (PPLKiller.exe) and for a process privilege escalation. These events set off an automated investigations response but that does not result in the blockage of the malicious activity. 4. Next we execute our shellcode injector within the SYSTEM level shell, utilizing direct system calls to gain code execution. The device timeline did not register this injection but it did see S2.exe (the injector) make a network connection to the C2 channel - no warning or no remediations. 5. So far, we have raised two alarms (suspicious file drop and process PE), set off an automated investigation, but our behaviors have not been blocked and we are free to begin post-exploitation activities. For this part of the attack chain we are going to get extremely noisy, we are going to run the Mimikatz module that comes standard with Covenant C2 6. The use of Mimikatz did trigger the third and final alarm. At this point our actions are not blocked, we have executed code on the endpoint, dumped password hashes from LSASS and the automated investigation response is still assessing our behaviors. 7. The final conclusion of the automated response was that our activity, while suspect, was not found to be malicious. While any human hunt team would have surely had enough IOA’s to leap into full response mode, the point was to test ATP’s new feature's ability to BLOCK and REMIDIATE malicious behaviors, missed by the first stage antivirus. This was a fail. Method: Stealth Mode Now, we are going to attack the same setup but actually try and remain undetected. The CMD script still isn’t of professional quality as it needs UAC bypass, shows visible console windows, but we are just trying to replicate the above behavior (Download -> Execute -> Dump LSASS) without tripping any defenses. Again, the endpoint under test has been added to the automated investigations group and ATP’s EDR block mode has been enabled. 1. We recompiled the shellcode injector code, making minor changes to change its signature. Instead of Mimikatz to dump hashes, we will use b4rtik's SharpMiniDump [4], altering the code slightly to avoid detection. 2. The script starts by using Invoke-WebRequest (just like above) to download the LSASS dumper (g.exe) and the C2 shellcode injector (StealthFighter.exe), dropping them to disk. Defender’s device timeline registers the events but provides zero detections. 3. The device timeline articulates the PowerShell command “Start-Process” with the corresponding process creation, but still no detections. 4. Next, we can see g.exe open a handle to LSASS in order to dump the password hashes – no detections. Finally, we have generated a .dmp file (happy.dmp) and are able to ingest it into an offline copy of Mimikatz to extract the credential material. – No Detections 😊 Fail X2 1. https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/edr-in-block-mode
2. http://download-eu2.guru3d.com/afterburner/[Guru3D.com]-MSIAfterburnerSetup462Beta2.zip 3. https://br-sn.github.io/Removing-Kernel-Callbacks-Using-Signed-Drivers/ 4. https://github.com/b4rtik/SharpMiniDump Intro Simplicity can be powerful when operating in the murky world of the digitally complex. I know the sinking feeling of waging war against state-of-the-art endpoint defenses, only to get crushed at your most hopeful. You have probably spent days wrapping your head around concepts like API unhooking, found and edited PoC code to mount an attack, then only to be crushed by the swift response of multi-tiered machine learning. Well, todays story is different! Today, I will tell you of a battle won with clever simplicity, waged against the multi-headed beast Windows Defender ATP and all its machine learning minions. This battle was not won by replacing jump points in EDR occupied memory space, it was won by probing for weakness and making calculated strikes against the ML models. “So in war, the way is to avoid what is strong, and strike at what is weak.” ― Sun Tzu, The Art of War Multilayer ML Defender ATP (like other EDRs) employs a multi-tier approach to threat protection. It has hooks and sensors within the operating system, vast amounts of compute power and elaborate machine learning models that are continually classifying known good, from known bad. Yet, standing in opposition to this almost unsurmountable defense, there is a chink in the armor that is revealed to the astute observer. Like many complex systems, their complexity is both the root of their power and also their Achilles heel. Defender uses machine learning models in conjunction with static and dynamic analysis methods to classify bad things from good things. But how does it make these decisions? Well, that I’m sure is a very closely guarded secret by Microsoft, but we can make educated assumption’s by utilizing trial and error and interpreting the results. Machine learning models can be trained by using something called features. In this case, a feature could be an API call made in a malicious context, different offensive behaviors exhibited, or really any other indicator Microsoft feels is relevant. After the model is exposed to thousands, or even hundreds of thousands of features, it is ready to make predictions based on the features it has seen. Now, there are models that produce black and white answers (this file is good / bad) and others that provide an estimation. For this reason (to avoid many false positives), a threshold has to be established before Defender will block the file in question. The threshold Microsoft employs is a confidence score of 90% or greater that the thing in question, is malicious. It is in this area of complex decision making that we can manipulate the features being observed in combination and reduce the model’s confidence score to under 90%. If we do that, our malicious activity will not get blocked by endpoint defenses and we can proceed to inflict havoc as we see fit. “In order to avoid false positives, cloud protection service is configured by default to require at least 90% probability to block the malware [1]” “For the fastest classifiers in our layered stack, the features may include static attributes of the file combined with events (for example, API calls or behaviors) seen while the scanning engine emulates the file using dynamic translation. [1]” Where the Hooks At? I decided to revisit some process hollowing code in C# which now is getting consistently busted by Defender ATP. My intentions were to employ a much more complex attack vector which included switching out some of the API calls and utilizing unhooking techniques that we are seeing trend right now. Before jumping into all that, I started to review some of the circumstances surrounding the immediate quarantine of my injector. I knew that the standard API calls I was using for process hollowing would surely be raising some alarms (SuspendThread, NtUnmapViewOfSection, VirtualAllocEx, CreateRemoteThread, WriteProcessMemory). Looking back at the EDR history I saw definite evidence of that – a detection on NtAllocateVirtualMemory API call which is VirtualAllocEx’s lower-level cousin. After reading the article in which I took the above excerpts, I wondered if the combination of certain processes being created in conjunction with certain other API calls (like VirtualAllocEx) were what was pushing the model to a 90% confidence score. I decided to start to play with process selection and leave the current API calls intact – for now. So Many Process Injections While rifling through the system32 folder for processes to create in a suspended state, I soon made the discovery that selecting specific processes was enough to reduce the model’s confidence and let me inject with immunity. I actually got ridiculous with this; injecting 30 different processes with the exact same API calls…including VirtualAllocEx! The realization was clear, as long as I chose processes that the model must not have seen features for, I wouldn’t need to edit the C# injector code at all. Defenders ML model must put a high degree of emphasis on certain processes that are created in conjunction with certain API calls. As long as I avoided the processes it squawked on, I would run undetected – simple and clean. I decided to run through almost the entire system32 folder just to document my findings, as about half of the processes I tried did trip defenses. In the end, I had 30 different processes I could safely inject into, all with varying degrees of Opsec from human hunt teams. There were some other considerations I had alongside of Opsec. 1. Could I spawn a process without any arguments needed? 2. Will the process close immediately after executing? 3. Is there a visible window a user can see and(or) close? 4. What background processes could I use? 5. Should this process be connecting to the internet? Below, a video of my 30 processes running in all their glory as Covenant C2 Grunts.
Intro
While it is bold to claim your company possesses predictive cyber intelligence technologies, we (Cyber Mongol) can positively say that our technology regularly provides early warning signals for damaging cyber events. TALK IS CHEAP – that’s why we like to back up our dialogue with facts, posting signals and analysis publicly as we see it. This story encompasses the F5 Networks BIG-IP vulnerability (CVE-2020-5902), Cyber Mongol’s signals and early warning issued to the community, CISA (Cybersecurity & Infrastructure Security Agency) issuing its own warning and culminating this week with an FBI Private Industry Notification (PIN), confirming that advanced operator tactics are now including this vector. This story of exploitation begins like any other, a vulnerability is discovered (June 30th, 2020) which could potentially lead to exploitation; in this case full RCE (remote code execution) – a CVSS score of 10! Cyber Mongol doesn’t tune its instrumentation to listen for events indicating that a bug has been found. Instead, our sensors are tuned to identify when PoC (Proof of concept) exploit code becomes publicly available. Yes, exploits could exist far before and brokered in private deals, but it’s when an exploit such as this becomes freely available and integrated into exploit frameworks, that we see exploitation at mass-scale. Our CTI engine (PANDEMIC) started ingesting publicly available exploit code (June 4th / June 5th), the same time CISA (Cybersecurity & Infrastructure Security Agency) started initiating their own investigations [1]. CISA Investigations: Released on July 24 "On July 4, open-source reporting indicated a proof-of-concept code was available and threat actors were exploiting the vulnerability by attempting to steal credentials. On July 5, security researchers posted exploits that would allow threat actors to exfiltrate data or execute commands on vulnerable devices. The risk posed by the vulnerability is critical." - CISA "As early as July 6, 2020, CISA has seen broad scanning activity for the presence of this vulnerability across federal departments and agencies—this activity is currently occurring as of the publication of this Alert" - CISA Cyber Mongol: Sensor Ingestion Table
Cyber Mongol Public Statement & Resources: Released on July 9
Conclusion
The CISA investigations [1] into the BIG-IP exploitation wouldn’t become publicly available until July 24th, 15 days after Cyber Mongol released a public warning and an extensive resource containing links to more than 28 publicly available exploits and scanners [2]. Observing and reacting to Cyber Mongol produced signals would have given organizations an 18-day jump in preparation, assessing risks and patching vulnerable equipment. Moreover, on July 15th our sensors saw that CVE-2020-5902 became assimilated into the exploit framework Cobalt strike within the Chinese security community, indicating preparation for mass-scale exploitation. Intro If we think of the exploit frameworks Empire and Impacket as celestial bodies, they could be viewed as binary stars that are locked in a cosmic dance, bound by their gravitational attractions. If we change our perception of graph relationships and think of the edges as gravity, we can start to see the influential nature that certain nodes in the graph possess over others. Interesting parallels start to emerge when comparing a threat landscape and a cosmic universe. There are patterns of tradecraft collections bound together by relationships, born of central and influential nodes. This starts to sound a lot like how stars birth planetary systems, born of the same cosmic materials and orbiting because of the star’s influence - gravity. Just like humans map the stars and the systems they belong to, our team maps offensive tradecraft and the collectives they are related to. We could essentially think of the graph itself as a universe, containing many other influential star systems. These star systems give birth to planetary bodies that share a relationship to the stars that created them. It is in this context we look at our graphs, examining the relationships, proximities and the evolutions of offensive tradecraft. Just as objects in space suddenly or more predictably get caught by the forces of other galactic objects, we are able to observe changes in relationships and tradecraft patterns, within our graphs. Lastly, just as trained astronomers are able to make predictions by studying the heavens, we are able to start to predict migrations in tradecraft by studying our data. Let’s look at a practical example of the observations we are making. Circle back to the binary star example of Empire and Impacket as these can be viewed as the center of the .NET tradecraft system. Both of these frameworks are connected to many highly skilled, offensive .NET tradecraft developers. We will take a spin around this system to see how influential exploit frameworks give rise to emerging offensive tradecraft. Below, you will find images of our tradecraft universe that have been labeled with the corresponding articulations. A Closer Look at the .NET System Empire: "Empire is a post-exploitation framework that includes a pure-PowerShell2.0 Windows agent, and a pure Python 2.6/2.7 Linux/OS X agent. It is the merge of the previous PowerShell Empire and Python EmPyre projects. The framework offers cryptologically-secure communications and a flexible architecture. On the PowerShell side, Empire implements the ability to run PowerShell agents without needing powershell.exe, rapidly deployable post-exploitation modules ranging from key loggers to Mimikatz, and adaptable communications to evade network detection, all wrapped up in a usability-focused framework. PowerShell Empire premiered at BSidesLV in 2015 and Python EmPyre premeiered at HackMiami 2016." Repo: https://github.com/EmpireProject/Empire Impacket: "Impacket is a collection of Python classes for working with network protocols. Impacket is focused on providing low-level programmatic access to the packets and for some protocols (e.g. SMB1-3 and MSRPC) the protocol implementation itself. Packets can be constructed from scratch, as well as parsed from raw data, and the object oriented API makes it simple to work with deep hierarchies of protocols. The library provides a set of tools as examples of what can be done within the context of this library." Repo: https://github.com/SecureAuthCorp/impacket SILENTTRINITY: "SILENTTRINITY is modern, asynchronous, multiplayer & multiserver C2/post-exploitation framework powered by Python 3 and .NETs DLR. It's the culmination of an extensive amount of research into using embedded third-party .NET scripting languages to dynamically call .NET API's, a technique the author coined as BYOI (Bring Your Own Interpreter). The aim of this tool and the BYOI concept is to shift the paradigm back to PowerShell style like attacks (as it offers much more flexibility over traditional C# tradecraft) only without using PowerShell in anyway." Repo: https://github.com/byt3bl33d3r/SILENTTRINITY Covenant: "Covenant is a .NET command and control framework that aims to highlight the attack surface of .NET, make the use of offensive .NET tradecraft easier, and serve as a collaborative command and control platform for red teamers. Covenant is an ASP.NET Core, cross-platform application that includes a web-based interface that allows for multi-user collaboration." Repo: https://github.com/cobbr/Covenant Seatbelt: "Seatbelt is a C# project that performs a number of security oriented host-survey "safety checks" relevant from both offensive and defensive security perspectives." Repo: https://github.com/GhostPack/Seatbelt Sharp WMI: "SharpWMI is a C# implementation of various WMI functionality. This includes local/remote WMI queries, remote WMI process creation through win32_process, and remote execution of arbitrary VBS through WMI event subscriptions. Alternate credentials are also supported for remote methods." Repo: https://github.com/GhostPack/SharpWMI SharpSploit: "SharpSploit is a .NET post-exploitation library written in C# that aims to highlight the attack surface of .NET and make the use of offensive .NET easier for red teamers. SharpSploit is named, in part, as a homage to the PowerSploit project, a personal favorite of mine! While SharpSploit does port over some functionality from PowerSploit, my intention is not at all to create a direct port of PowerSploit. SharpSploit will be it's own project, albeit with similar goals to PowerSploit."
Repo: https://github.com/cobbr/SharpSploit |