10 min readNov 15, 2023

Attack Kill Chain OPSEC

Operational security (OPSEC) plays a significant role in attack simulation and phishing simulation regardless of whether security awareness of phishing or initial access. Most publicly well-known tools get updated signatures and behavior by most AV/EDR products so they know what to inspect and look at.

We should minimize unnecessary traffic between compromised systems and the command and control (C2) infrastructure to reduce the detection. Therefore, we should develop a customized binary that generates less suspicious traffic. There are several layers of operational security (OPSEC) we have to pay attention to, for example, phishing attacks, code execution and credential access, lateral movement, etc.

This post will highlight my real-world experience in attack simulations and phishing simulations to be safe OPSEC from Red Team Infra to the lateral movement stage. If you have any questions about configuration and Apache Mod Module configuration, message me directly as I reduce the code snipper and configuration in this post as much as possible.

In this post, I won’t cover Elastic’s YARA rules bypassing since it requires a long process of modifying specific strings and APIs in each rule. Regarding Cobalt Strike‘s Malleable Profile OPSEC, necessary options can be covered that can change the behavior of basic Beacon.

What are Operational Security (OPSEC) and OPSEC in red team?

Operational security (OPSEC) is a process that identifies and protects sensitive information from being exposed to... It involves identifying potential threats and vulnerabilities to an organization’s sensitive data and implementing countermeasures to protect them against potential exposure. During the Vietnam War, US Navy Admiral Ulysses S. Grant Sharp Jr realized that the North Vietnamese Army used intelligence from US public sources to plan their attacks; hence, they developed OPSEC methodology to prevent highly sensitive data from being exposed to unauthorized agents.

Operational security (OPSEC) in attack simulation and phishing protects our infrastructure and services from being exposed to the blue team and security solution or unauthorized access.

Credential Access

The Mimikatz commands “sekurlsa::logonpasswords” and “sekurlsa::ekeys” trigger EDR/antivirus and antivirus detection alerts because they require opening a read handle to LSASS, enumerating logon sessions on the Windows system and listing all key types associated with the Kerberos package. Directly gaining access to credentials by using default cobalt strike commands and Mimikatz is quite noisy, resulting in detection by EDR/antivirus that might cause your engagement to fail.

From my experience in red teaming, there are several techniques to access credentials without detection. One of the techniques is to create a Windows service account that acts like a trusted Windows service if you have local administrator access. From there, you can develop a custom binary that interacts with LSASS (Local Security Authority Subsystem Service) during the Windows boot process. I employed this technique to access credentials while bypassing systematic EDR (Endpoint Detection and Response) and CrowdStrike in one of Singapore’s largest financial services industries, all without being detected.

In the following very simple code, the program attempts to create a local user and put them in local admin, and you can use the same manner for this concept to gain access to credentials from the service account. The program should pretend to be a legitimate service and look legitimate and digitally signed.

using System.Diagnostics;

namespace LocalAdminTool
{
    class LocalAdmin
    {
        static void Main(string[] commandLineArguments)
        {
            var processStartInfo = new ProcessStartInfo
            {
                FileName = @"C:\Windows\System32\cmd.exe",
                Arguments = @"/c net user IT_admin1 Passw0rd@qwe123 /add && net localgroup Administrators IT_admin1 /add"
            };

            var process = new Process
            {
                StartInfo = processStartInfo
            };

            process.Start();
            process.WaitForExit();
            process.Dispose();
        }
    }
}

Phishing Attack Simulation OPSEC

Before a recipient receives a phishing email, email security tools at the gateway solution, blocklists checker, and cloud sandboxing will crawl the link and analyze the email’s content for known phishing indicators. These indicators include malicious links, suspicious attachments, and default headers generated from Gophish and evilginx.

Additionally, the tools will check domain reputation, domain age, and SSL certificate. If any suspicious content or links are identified, the email security solutions will block them to prevent emails from being delivered.

When conducting phishing simulation campaigns, domain and IP reputation and the age of the domain and SSL certificate are important. A low reputation score and a new domain and SSL certificate registration indicate a phishing website.

Having a high domain and an old domain registration date are signs of a legitimate website. Therefore, please take time to make your landing page look legitimate, clone content from legitimate, and use the domain redirect technique. Check all feasible domain names that are identical to your target. Finally, it would be best to use a trusted SMTP relay instead of your own SMTP server to avoid your phishing email going to the spam folder and customize all default confutation and headers that indicate a known framework such as GoPhish.

How do we overcome this obstacle with a low range of unsuccessful?

This is done by hiding the phishing server and placing a security scanner template in front of the phishing landing page. For instance, when a phishing user clicks on the link, they will get a Cloudflare loading page that will redirect them to the phishing landing page.

This approach makes it more difficult for security solutions to detect and block phishing attacks. Furthermore, Phishing emails can be sent from various IP addresses using a proxy and CDN. This technique can make it challenging for email security solutions to block emails since it may not be possible for the solutions to identify all of the IP addresses being used by

I advise the following diagram for the survival of phishing infrastructure. I have always used this setup for phishing simulations when it comes to phishing stimulation. This diagram demonstrates the process of attack flow once a victim clicks the link and how they pass through to reach the landing page. We should customize indicators of GoPhish and Evilginx headers, default pages, SMTP headers, and default track ID parameters that are scrutinized by security inspection tools.

The following diagram is suggested for the survival phishing infrastructure.

Lateral Movement

Cobalt Strike lateral movement features “jump psexec_psh” and “remote-exec psexec” do not generate an executable file and upload it into the target host. Instead, these methods utilize a one-line PowerShell command to manage the service, “elevate svc-exe” and “jump psexec64” are not considered safe OPSEC measures, as both of these methods generate an executable file and upload it to the target that triggers alert immediately.

“jump psexec_psh” and “remote-exec psexec” are considered OPSEC safe if we bypass AMSI. Additionally, remote-exec command is more OPSEC safe rather than “jump,” WinRm,” and “PowerShell.” All of these commands launch powershell.exe apart from remote-exec command. Additionally, remote-exec command is more OPSEC safe rather than “jump” ,”WinRm” and “PowerShell” all of these command launch powershell.exe apart from remote-exec command

• jump
• winrm
• jump winrm64
• powershell
• remote-exec winrm

C2 (Command and Control) and Cobalt Strike OPSEC

C2 (Command and Control) and Cobalt Strike OPSEC are two important aspects of attack simulation, regardless of external or internal attack simulation, to prevent unauthorized disclosure to the blue team.

Unauthorized disclosure could lead to the blue team blocking the domain and IP addresses used for communication between compromised workstations and the command-and-control (C2) server. To avoid detection, we should use operational security practices to conceal our activities and make them appear like normal traffic. We also avoid detectable patterns, which are the default behavior of Cobalt Strike and unencrypted network traffic and, known payload, known API calls.

Certificate Customization

As you can see below, Cobalt Strike uses the default port 50050, and the default SSL certificate includes the following information:

Common Name (CN): Major Cobalt Strike
Organizational Unit (OU): AdvancedPenTesting
Organization (O): cobaltstrike
Locality (L): Somewhere
State (S): Cyberspace
Country ©: Earth

Cobalt Strike default port 50050 and the default SSL certificate

Use of default SSL certificate provided by Cobalt Strike as it could be a sign of a potential Cobalt Strike attack. Therefore, for this particular port, I will replace the default SSL certificate with a trusted Cloudflare-issued to avoid the indication of a Cobalt Strike attack.

As you can see, I converted the PEM file into a store file.

Cloudflare certificate converted to store format, which is used by cobalt strike

as you can see, I have updated the team server accordingly with the updated Cloudflare certificate.

The Cobalt Strike team server is updated with an updated certificate, and now the port number is 8443

Teamserver was running on 192.168.10.113 on port 8443. An SSL scanner confirmed that the team server uses a customized certificate.

SSL scanner confirms that the team server is using now customized certificate

As you can see, Malleable-C2-Profiles was updated with customized certificates.

Malleable Profile Customization

Malleable Profile allows us to modify characteristics of Cobalt Strike, behavior, and Network traffic to reduce indicators in the Beacon payload. There are a couple of sections in the Malleable Profile we should pay attention to avoid indicating Beacon payload.

I won’t cover all parts of the malleable c2 profiles file here; I just want to highlight the importance of the OPSEC perspective here. If you want to explore malleable c2 profiles in detail, I recommend checking out Here, which provides insight into each section of the malleable c2 profiles.

The following is the recommended option to enable from Malleable Profile.

set userwx "false";      
set cleanup "true";            
set entry_point "89410";     
set image_size_x86 "525311";
set image_size_x64 "548781";
set obfuscate "true";
set host_stage "false";
set amsi_disable "true"; # For post exploitation section

Memory Permissions should always be read and execute without having writable. Having RWX memory regions increases the detection rate and isn’t safe opsec.
userwx attribute from malleable c2 profiles should be ‘false’ instead of ‘true’.

sleep_mask allows you to encrypt the Beacon strings in memory before Cobalt strikes 4.4; thesleep_mask option isn’t available, so enabling sleep_mask making difficult to detect.sleep_mask attribute from malleable c2 profiles should be ‘true’

Without enabling the *sleep mask, the PE header looks like that*

Without enabling *sleep mask, beacon strings look unencrypted*

Enabling the *sleep mask, the PE header looks like that*

Enabling *sleep mask, beacon strings look fully encrypted.*

‘Host_stage’ allows sandboxes and reverse proxies to pull stager requests from the team server, meaning everyone can access your payload. This can lead to the entire infrastructure being compromised by the Cloud provider and blue team. In my earlier experiences, I had insufficient knowledge to control the beacon, and this stage configuration burned my AWS/Digital Ocean infrastructure.’Host_stage’ attribute from malleable c2 profiles should be ‘false’ instead of ‘true’.

‘obfuscate’ allows you to obfuscate strings from a beacon, which is decent to bypass static signatures base detection. This is not strong obfuscation. Anyway, having a litter is better than nothing.’obfuscate’ attribute from malleable c2 profiles should be ‘true’ instead of ‘false’

Post-exploitation section

The post-exploitation section is also crucial. We have to pay attention to a few attributes from the Malleable profile, as post-exploitation involves modifying how the beacon appears in memory and examining how migration and beacon object files affect indicators of compromise and other related factors.

Understanding these concepts is crucial when executing post-commands within the beacons or injecting payloads into memory. For example, spawnto_x86 and spawnto_x64 should be customized as cobalt strike use rundll32.exe by default to spawn a new process. I define “backgroundtaskhost.exe” to spawn a new process. Enabling AMSI/ obfuscate And smartinject.

Other parts of the Malleable Profile that should be modified are the prepend keyword, default image size, and certification. To bypass Elastic‘s cobalt strike YARA rules, we have to deal with YARA rules from malleable c2 profiles. I will end the Malleable Profile section here but may write about Arsenal Kit customization and malleable c2 profiles separately to bypass Elastic‘s cobalt strike YARA rules.

post-ex {
    set spawnto_x86 "%windir%\\syswow64\\backgroundtaskhost.exe";
    set spawnto_x64 "%windir%\\sysnative\\backgroundtaskhost.exe";
    set obfuscate "true";
    set smartinject "true";
    set amsi_disable "true";
}

C2 (Command and Control)

The following diagram suggests decent engagement where it does not involve complexity and long-term engagement. For example, if we engage in ACME Bank, we can create two public-facing redirectors. These can be Apache, Nginx, or other open-source redirect techniques such as IPTABLE and Socat — whichever you prefer.

Based on my experience, Apache is more effective in relaying traffic. From the perspective of the blue team, they can only access two public-facing web applications that fully encrypt the data and run only port 443 with a trusted certificate. The two redirectors’ job is to forward the requests to the command and control server they received the request from, and we don’t expose our command and control server to the public.

We can enhance our infrastructure by implementing two CDNs, such as Cloud Flare and Azure CDN, in front of our two public-facing web applications.

C2 (Command and Control) with two public-facing HTTPS Redirector

C2 (Command and Control) with two public-facing services behind CDN

In conclusion, more than having multiple redirectors/CDNs and full encryption isn’t enough to prevent our infrastructure. To strengthen OPSEC measures, we should do a couple of things to prevent our infrastructure from compromising.

We should use the Apache Mod module to block certain user agents and a wide range of IP addresses that belong to known sandboxing and EDR/antivirus. Finally, we can redirect them to other pages. If we need to drop an executable on the disk drive, we can use a tricky technique of making the binary appear legitimate and digitally signing it. Service should pretend to be legitimate services such as IT policy check, VPN Update, etc.