Distributed Operationsīeacon became my primary agent for persistent access to compromised systems. I saw my DNS Beacon as an opportunity to very quietly hold access to a compromised host. I then built the Beacon variant that would issue A record requests to check for tasks before it made a connection. In one inspired night, I wrote Cobalt Strike’s initial DNS server. Just before I pushed Beacon, I decided to build a variant that would use DNS. By compiling Beacon into a reflective DLL, I made it possible to inject the payload into memory and deliver it with a Metasploit Framework exploit. If you’re not familiar with Reflective DLLs, they’re significant. I compiled Raven into a reflective DLL and built a user interface to generate tasks and host them on Cobalt Strike’s built-in web server. Later, I extended Raven to execute commands, change its sleep time, and inject arbitrary shellcode. To task Raven, I would manually generate shellcode for a desired payload and save it to the file Raven would check for.
Raven would connect to a web server every six minutes, request a file, and spawn a thread to execute the contents of the requested file. I wanted a quiet way to hold access to compromised hosts. I built Raven, an asynchronous persistent agent, for the 2012 Collegiate Cyber Defense Competition. If you’re a Cobalt Strike user, this post will help you reason about Beacon and fit it into your tradecraft. In this post, I’d like to share my insights and reasons for the design decisions I made.
This is my capability to model advanced attackers. One of the most important features in Cobalt Strike is its Beacon payload.
0 kommentar(er)
