In our previous post, we talked about the problem of structured data in the post-exploitation community. We touched on the existing relationship between our tools and data and covered some of the domain-specific challenges that come with offensive data collection.
The article discusses the challenges of post-exploitation workflows, which involve collecting data from a target system and processing it for further analysis. It outlines the current approaches to data collection, which range from neutralizing endpoint detection and response (EDR) to obfuscating existing tools to pulling data in an unprocessed form and processing it off the target host. The article then focuses on two specific challenges: mining document stores and privilege escalation.
Mining document stores involves downloading potentially “interesting” documents from a target system or document store, transferring them to an attacker system, and then opening and reading them. This process is often highly manual and requires the operator to have a good understanding of the data they are looking at. It also requires the operator to remember relevant details days or weeks later as they gain more context. Privilege escalation is another common step in many attack chains. It usually involves finding a program that is running with elevated privileges and influencing its execution through attacker-controlled data inputs. To do this, the operator needs to gather data sources such as process listings, service listings, named pipe listings, open TCP/UDP ports, drivers, SDDLs, and registry settings.
The article then discusses the use of offensive data protection application programming interface (DPAPI) abuse, which is a game changer for SpecterOps. It provides an alternative way to retrieve sensitive data, like cookies or even user credentials in some cases, without having to be elevated or touching local security authority subsystem service (LSASS). The main DPAPI-specific abuse tools used are Mimikatz, SharpDPAPI, and Impacket. To triage individual DPAPI protected files, a custom-written DPAPI data collection script is triggered in the C2 agent to queue up the downloads of a dozen+ files.
To address the manual triage process, SpecterOps has developed a system called Nemesis. It contains an abstracted API that any tool can post to and performs a number of processing and enrichment steps for a variety of data types. It will help enable the emerging discipline of offensive data analytics, provide structured data for future data science/machine learning (ML) opportunities, provide a method for data-driven operator assistance, and more. Nemesis will be released open-source at https://www.github.com/SpecterOps/Nemesis just before the BlackHat Arsenal presentation. SpecterOps will be presenting more details about Nemesis at BlackHat Arsenal Station 2 on Wednesday August 9, 20
📓 Challenges In Post-Exploitation Workflows
👉🏽 In our previous post, we talked about the problem of structured data in the post-exploitation community. We touched on the existing relationship between our tools and data and covered some of the domain-specific challenges that come with offensive data collection. 👉🏽 The article discusses challenges in post-exploitation workflows and data collection. 👉🏽 It outlines current approaches, including neutralizing endpoint detection and response. 👉🏽 Data can be collected in an unprocessed form for further analysis. 👉🏽 Specific challenges include mining document stores and privilege escalation. 👉🏽 Mining document stores involves downloading and reading potentially interesting documents. 👉🏽 Privilege escalation involves influencing the execution of a program with elevated privileges. 👉🏽 Offensive DPAPI abuse provides an alternative way to retrieve sensitive data. 👉🏽 Tools like Mimikatz, SharpDPAPI, and Impacket are used for DPAPI-specific abuse. 👉🏽 SpecterOps has developed a system called Nemesis to address manual triage processes. 👉🏽 Nemesis enables offensive data analytics and data-driven operator assistance.
#postexploitation #datacollection #privilegeescalation #DPAPIabuse #offensivedataanalytics