I’m going to start a series about agent architectures. This is one of the core building blocks of modern software systems, especially in security software. A basic agent architecture involves processes running on remote systems (the agents) that beacon home to a callback server to report information and possibly receive tasking. Agents are run in the background the entire time the system is running, and usually agents are uniquely identified so you can correlate them to a specific system and user and task single systems.

This architure is behind modern EDR (Endpoint Detection and Response) solutions, such as Bit9’s CarbonBlack and Crowdstrike’s Falcon, along with various remote DFIR tools, and many other types of security products.

Many malware samples use this architecture as well, because at a high-level, malware architecture and the code it uses is the same as security software. The main difference is the use case. For example, security software might search RAM for some type of IOCs, whereas malware might scan RAM for regions that match the Luhn algorithm which would indicate that memory region may be credit card numbers. For an open-source botnet, you can look at Splinter the Rat, which was written for educational purposes. You could also look at leaked sources for real malware such as Zeus, SpyEye, or HackingTeam’s tools.

It could be argued that agents are also used by:

• Auto-update software for every application, such as Google Update (aka Omaha) used by Chrome.
• Performance monitoring software on servers.
• DLP (Data Loss Prevention) to watch for files and content being copy/pasted and escaping the network.
• Software License Optimization solutions to see how many people actually use Microsoft Office and other software to determine how many licenses need to be paid for.

Agents are as common in software architecture as databases or message queues, but they tend to be created from scratch with much greater frequency and with much less prior knowledge. I’ve worked on the code bases for multiple agent architectures, so I want to discuss some lessons learned and ideas about them.

Agent introductions

Let’s start by introducing a few open-source infosec agent systems that we’ll be basing our discussion around. This isn’t going to be a bake-off to find the best one. These are all good, but solve different problems.

Google’s GRR

GRR is a recursive acronym for GRR Rapid Response, and it allows for remote live forensics for incident response against single systems, an entire network, or a subset of systems. It’s main tasks are pulling back files or memory dumps to be analyzed on the analyst’s system. It was created by Google in the wake of Operation Aurora which was a series of breaches across many companies in 2009 from China. Google wanted the ability to sweep it’s entire network for IOCs (Indicators of Compromise) and remotely hunt across their network or on individual systems. GRR can be thought of as an open-source alternative to FireEye’s MIR (Mandiant Intelligent Response).

Mozilla’s MIG

MIG stands for Mozilla InvestiGator. MIG was made after GRR because Mozilla didn’t like the idea of the security team being able to pull back arbitrary information from the employee’s systems, both from a privacy stand-point and security. The security concern is that agents can become a way for an attacker to compromise an entire network, much like if a domain controller is compromised. So MIG has fewer capabilities in terms of what it can do on an end-point in order to ensure greater privacy and comes from a more paranoid posture. Specifically, MIG is supposed to only be able to ask yes-or-no questions to it’s agents. Further, these requests are signed by an analyst, and this signing can be done on an off-line system. I’ll write more on this in a later article.

Immunity’s El Jefe

El Jefe is Spanish for “The Boss”, and is more like an EDR solution such as Crowdstrike’s Falcon or CarbonBlack, where it logs events on the host systems and sends those back to the central server. Unlike GRR or MIG, El Jefe can not receive tasking, so it’s not exactly a true agent, since by definition an agent performs actions on the behalf of another program, but as it is a complete system otherwise (ie. agents and a callback server), it does enough for us to talk about it.

Stay tuned!

Agent architectures are an important software architecture concept, and especially so in infosec. Stay tuned for future articles on agent lessons! In a few days I’ll post something about the concerns and solution strategies of installing and running agents on potentially compromised systems.