Attacking an EDR - Part 2

Introduction - Where we left off

DISCLAMER: This post was done in collaboration with Devid Lana. You can find his blog here: her0ness - Attacking an EDR Part 2

Continuing from our last research, we pursued the exploration of the attack surface of the EDR solution under our scrutiny, STRANGETRINITY. Last time we focused on identifying exclusions within the EDR’s configuration that allowed us to perform actions that would not be possible otherwise. This time around, our focus will be on the communication channel between the EDR agent and its tenant.

Attacking an EDR - Part 1

Introduction

DISCLAMER: This post was done in collaboration with Devid Lana. You can find his blog here: https://her0ness.github.io

This post is the first of what - we hope - will be a long series of articles detailing some common flaws that can be found on modern EDR products. By no means this will be a complete reference, but will hopefully provide some practical tools to analyze these gargantuesque products and attempt to understand their functionalities from a black box perspective.

Mockingjay - What is old is new again

Mockingjay - What is old is new again

There has been quite a lot of rumor recently around the release of a piece of research that discuss a new (?) process injection technique that evades EDRs (what does that even mean?). For reference, these are the blog post I am referring to:

• New Mockingjay process injection technique evades EDR detection

• Process Mockingjay: Echoing RWX In Userland To Achieve Code Execution

Random Notes on Task Scheduler Lateral Movement

• Introduction
  • File Replacement
  • Task Replacement
  • COM Handlers
  • Detection
  • Evasion
• References

Introduction

Reading FireEye’s UNC2452 writeup , I started to think about how to emulate them in purple teaming exercises. Despite the supply-chain bit is still a bit out of my reach, I noticed an interesting lateral movement vector that was used as part of that operation.

Quoting directly FireEye’s post (because I am lazy AF):

Streamlining BloodHound Analytics

Introduction

As a penetration tester, I often rely on BloodHound to assist me in Active Directory engagements. However, after a few of them it was clear that I was repeating the same actions (hence the same queries) over and over again. I felt that doing this initial process manually was not just time consuming but also introduced the possibility to make mistakes and miss some low-hanging fruits, this is especially true while analysing a considerable number of domains in a restricted amount of time.

Not All Paths are Created Equal

Introduction

BloodHound was a revolution for evaluating Active Directory (AD) security and identifying unintended paths that could lead to the compromise of sensitive groups such as Domain Admins. The community has been using it successfully in many engagements and against highly secure environments.

For those who’ve been living in a cave for the past couple of years, in a nutshell BloodHound is a tool that can be used by both defenders and attackers to identify hidden and unintended relationships between AD principals. It’s heavily based on the work published by Microsoft’s researchers: Heat-ray: Combating Identity Snowball Attacks Using Machine Learning, Combinatorial Optimization and Attack Graphs . Although BloodHound does not rely on machine learning yet, the data model is pretty similar to the proposed one.

Lateral Movement

• Introduction
• Find Where We Have Access
  • Local Group Membership - The Blind Approach
  • Local Group Membership - Group Policy Objects
  • Access to File Shares
  • Access Control Lists
  • MSSQL Access
• WMI
• Remote Service Creation
• Remote Desktop Protocol
• PowerShell Remoting
• Task Scheduler
• PsExec
• DCOM
• Password Spray
• Folder Redirection and Roaming Profiles
• RDP Hijack
• Pass-the-Hash
• Overpass-the-Hash
• Pass-the-Ticket

Introduction

Lateral movement is defined by MITRE as:

Modern C2 Infrastructure with Terraform, DigitalOcean, Covenant and Cloudflare

This is going to be a quick walkthrough of how I would set up a Command and Control (C2) infrastructure using the following technologies:

• Terraform (https://www.terraform.io/ )
• DigitalOcean (https://cloud.digitalocean.com )
• Cloudflare (https://www.cloudflare.com )
• Covenant (https://github.com/cobbr/Covenant )

The aim of this post is mainly practicing building reliable and reusable C2 infrastructures for red team engagements. I won’t be covering the installation of the various tools but we’ll go straight to the design of the infrastructure. I will also assume some familiarity with terraform, the introduction guide (https://learn.hashicorp.com/terraform?track=getting-started#getting-started ) will be enough for most of the stuff you’ll see here. I decided to use Covenant instead of Cobalt Strike mainly because I don’t have enough money for buying a personal license ¯\_(ツ)_/¯ but also because they have very similar functionalities and in the next few months it may be possible to use Covenant reliably during operations.