One of Cobalt Strike's most valuable features is its ability to modify the behavior of the Beacon payload. By changing various defaults within the framework, an operator can modify the memory footprint of Beacon, change how often it checks in, and even what Beacon's network traffic looks like. All of these features are controlled by the Malleable C2 profile, which is chosen when starting the team server.
Designing, deploying, and managing a comprehensive security program is not an easy task. An organization's security design is influenced and pressured from multiple, often competing, sources. This includes customers, compliance, management, peers, budget, public opinion, and news. This process is complex and challenging, but an organization is generally able to overcome the pressures and implement what is considered to be a robust security program. An organization is able to please the various parties and, at least on paper, describe a strong security program designed to stop malicious cyber-attacks. Audit and compliance checks pass with a green light. Robust patch management systems are deployed. Vulnerability assessments and penetration tests are conducted. In general, the organization has good security hygiene. These are all great steps in defending a network from attack, but unfortunately, often fall short in achieving the primary goal of preventing, detecting, and responding to real threats. Why? What is missing? The real question to consider is:
A twitter post by Casey Smith (@subtee) inspired me to update a tool written by Andrew Chiles (@andrewchiles) and I a few years ago.
This post is intended as a follow-on to Jeff Dimmock's detailed write-up on creating communication profiles for Empire. Empire 1.6's “DefaultProfile” setting for modifying C2 indicators doesn't directly allow modification of the server-side parameters. When faced with an experienced group of defenders, default C2 server indicators can quickly reveal your infrastructure. HTTPS listeners with valid certificates can certainly hinder traffic monitoring, but isn't a silver bullet.
Domain name selection is an important aspect of preparation for phishing scenarios, penetration tests, and especially Red Team engagements. It is increasingly common to be faced with web filtering in a network based on domain reputation and categorization. Often traffic to very new and/or uncategorized domains is completely blocked by such appliances – stopping your phishing payload or C2 agent in their tracks. There's been a lot of talk about Domain Fronting and High Trust Redirectors in the security community lately to deal with this same issue, but that's an extra layer of configuration and complexity that's probably not necessary for every engagement. See MDSec – Domain Fronting via Cloudfront Alternate Domains and Raphael Mudge's blog for more on those techniques.
Web applications continue to be a valuable door for attackers to use to gain remote access to a network. If a web application is compromised, the webserver itself can be used to enable a command and control (C2) channel and provide a platform for post exploitation. The use of web shells is a common method to provide this capability. Like other malicious code, security protections must be considered and understood to bypass their protections. Specific Tools, tactics and procedures (TTPs) must be designed into a web shell to minimize detection. Many current web shells have no protection against common network security defenses.