As companies become more aware of the importance of increasing cybersecurity and incorporating red teaming evaluations into their advancing security practices, their capabilities to build security features into their products grow too. This leads companies that have adopted advanced security practices like red teaming assessments to utilize multiple security tools that automatically respond to potential attacks by identifying and blocking known malicious activity.
These tools may include:
- XDR/EDR products that are used to monitor the behavior of processes and provide an automated response. The higher the security maturity level of the company, the more prevalent these tools are across computers and servers and the better their utilization by security teams to detect patterns and signs of an attacker’s activity.
- Web proxies and firewalls that monitor domain traffic activity, including SSL interception.
- NDR products that monitor suspicious activities in the internal network.
These companies with mature security practices usually also have a dedicated team of security experts whose job it is to continuously search for ways to improve the company’s security posture. Red teams servicing mature companies must constantly upgrade their tools and techniques, moving beyond the readily available or commercial tools out there, and creating custom tools that will allow them to continue providing value.
Here are a few common initial access methods used by malicious attackers or red teams:
- Password spraying from several IPs using tools such as CredMaster against SSO/VPN/VDI/cloud infrastructure provider. MFA can help protect against this type of attack and should be enabled across all users and services.
- Simple MFA prompts (such as the ones that ask for “Accept” or “Deny” approval) from the target’s country of residence still put users at risk of compromise. This type of attack may be circumvented by disabling simple MFA prompts across the organization.
- Evilginx coupled with blocking the IPs of automated defensive scanners still does the trick and prevents your domain from being blacklisted (bonus points for using expired domains), and works even better with SMS phishing (Smishing). The effect of this attack can be reduced with conditional access or similar security measures.
- Misconfigurations that can be abused to remotely execute code.
- Taking advantage of new vulnerabilities that allow for remote code execution (such as the MS Exchange’s numerous vulnerabilities, VPN provider’s vulnerabilities, etc.)
Assuming that the attacker has already gained access to the internal network, let’s discuss a few important points to consider from the perspective of post-exploitation.
Communication Channel
Bypassing domain monitoring and SSL interception is situational and depends on the segment the attacker made his way into (for instance, certain segments might not have outbound HTTPS, and no access to the organizational proxy).
There are those of the belief that due to the increased monitoring of HTTPS, it’s best not to use it and rely instead on other “normal” organizational traffic (such as ICMP and DNS tunneling, DNS over HTTPs, Outlook COM object). In my opinion though, a project that utilizes HTTPS nicely is by WithSecure (previously known as F-secure) that offers an effective way to enhance your HTTPS C2 communication channels, building on various chatbot service APIs (Slack, Discord to name a few).
WithSecure offers an opensource solution that supports Cobalt Strike and Covenant out-of-the-box. Their implementation of peripherals, connectors, and channels allows a dedicated team to implement their own channels along with a different execution logic.
Execution Features
Several things to keep in mind when developing your own offensive infrastructure: ensure its interoperability with existing tools, reduce development time, and make use of cool open-source tools!
There are a lot of existing opensource tools written in C/CPP that utilize the logic of loading C# tools in memory and the parsing of the arguments to pass onto the C# program (also being utilized by Microsoft Signed binaries legitimately, which is another thing to consider if you want to “blend in”) and redirect its STDOUT/STDERR to a mailslot (in-memory named pipe).
Similarly, there are existing community tools that can be used to load Beacon Object Files (BOF). These and other community tools are continuously updated and are available for security teams to use and integrate with their own infrastructure.
Delivering these payloads through your channel without the creation of a sacrificial process (such as the fork and run commonly used by execute-assembly in CS), in the memory of your process (minimizing the risk of crashing your process by setting exception handlers to your thread), disabling AMSI and ETW before execution and without the payloads ever touching the disk, is vital for evasion.
Application Whitelisting Bypass
I don’t think this method gets enough credit. Here’s an example of basing an entire payload delivery around a signed, well-known software, with a (hopefully signed by an Extended Verification Certificate) DLL sideloaded into it.
This has the benefit of adding other legitimate software to your payload, and running your payload within less-scrutinized software, which appears to have a great effect on a product’s decision to scan its memory at regular intervals.
Shellcode/DLL Encryption and Entropy Reduction
Payload encryption is very common these days (and still very necessary), with products determining if your loader contains malicious code simply by examining its entropy. Replacing your shellcode with English dictionary words (which will have the adverse effect of increasing your final payload size significantly) and adding common strings from known binaries (such as web browsers) will go a long way in entropy reduction.
Compile-Time String Obfuscation
This one is pretty self-explanatory. You should minimize the strings that can be used to determine your usage of different APIs or other strings present in your binary that are or can be used as a detection logic against your payload.
This library does the trick well.
Anti-Sandbox
Anti-sandbox is extremely important when designing your payload, because it cannot follow common anti-sandbox techniques. It should be tailored to your payload delivery tactics, while taking into account the operators’ ease of use, and not adding extra hurdles or possible bugs that completely prevent the execution of your payload. Below are some great examples to understand the logic of anti-sandbox. However, these ideas should be adapted with care because some might be suspicious on their own:
Separate Loader Project
Performing process injection these days is far less detected when performed within the process itself (opposed to remote process injection), even more so when the process is a signed binary, and even more so when it’s signed by Microsoft.
Sideloading your payloads (like in the demonstration at the application whitelist bypass) goes a long way into making even post-exploitation items (such as inline dotnet execution) not detected by automated scanners, due to these well-known executables receiving less scrutiny (in the defensive products attempt at avoiding false positives).
Hiding your actual implant within a loader project that is constructed in a manner that combines all of the above does the trick well, in conjunction with hiding your implant in memory when it is sleeping (demonstrated also here), and of course spoofing the thread call stack to further aid in hiding malicious process behavior.
Combine this with spoofing of the thread start address (by placing a trampoline over a legitimate module’s function that is never used by the process, though you should definitely double check that) along with the removal of the “Mark of the Syscall” (excellently explained here) and of course implementing all of the above will help your loader remain under the radar.
