Rubeus vs YARA: Who will win? Discover the key to evasion.
Celia Catalán
Introduction
In corporate environments, the execution of tools such as Mimikatz, Rubeus, and other widely known binaries is often blocked due to the implementation of advanced security measures, such as antivirus (AV) solutions and EDRs. These barriers represent a significant challenge when it comes to demonstrating security vulnerabilities. In light of this problem, there are two main approaches:
- Use alternative tools that implement the same exploitation techniques in a different way.
- Modify the existing tools to prevent them from being detected.
Aim
In this pill, we will focus on the second approach: how to modify a tool whose source code is available, without compromising its functionality. To do this, it is essential to understand the methodologies that detection systems use to identify and catalog these tools as malicious. Generally, these systems employ two main strategies:
- Static analysis of the binary: Examines the file without executing it to identify patterns, signatures, and malicious artifacts.
- Dynamic analysis and behavior detection: Monitors the running binary, evaluating its actions and how it interacts with the system.
In this case, we will focus on static analysis, which, in practical terms, is based on signature detection. Static analysis tools can decompile binaries and search for specific patterns in the code, determining whether a tool could be malicious. For example, function names, static strings, or characteristic byte sequences can be flagged as suspicious.
If we adapt this concept to the use of YARA rules, the explanation becomes more intuitive. YARA rules are used by security analysts and detection tools to identify suspicious files through a defined set of patterns. These rules consist of:
- Hexadecimal chains: Define specific binary patterns or bytes in the file
- Text strings: Identify relevant words or phrases
- Regular expressions: Allow defining more complex and flexible patterns
In the example, there are certain strings from $a - $d defined initially that are later used in the condition of the rule. If $a or $b is met and $c or $d is met, the rule will be executed and displayed as a result of the sample analysis.
Example
For the following example, we will use a combo of predefined rules from Yaraforge to evade Rubeus.
Rubeus is a tool written in C# to interact with and abuse Kerberos, allowing attacks such as Kerberoasting, ASREPRoasting, Overpass-the-Hash, Pass-the-Ticket, resource delegation abuses, and persistence in Active Directory. The source code can be found in its repository. It comes with a yara rule already provided by the creator and is easy to understand.
If one of the two conditions (defined with the logical operator AND) is not met, the rule will not be executed, bypassing it. The string refers to the default project GUID, so by creating a new GUID and modifying it in the project properties, you should be able to bypass the rule.
To know the rules that apply to the Rubeus project, one must have:
- Initial compiled Rubeus
- YARA binary to check the rules
- The rules of Yara Forge
'The following syntax will execute the initially compiled binary. Four yara rules that will be evaded can be seen below, using Visual Studio with the Find and Replace utility.'
Rule: FIREEYE_RT_Hacktool_MSIL_Rubeus_1
'We already discussed this rule previously, as it is the same as the one in the repository. By modifying the project's GUID with another valid one, it will be possible to bypass this rule.'
'The GUID in the Rubeus project code is modified. When we recompile and launch the yara rule scan, we will remove the detection capability based on this rule.'
Rule: SIGNATURE_BASE_HKTL_NET_GUID_Rubeus
'During the execution of the previous scan, we will realize that we not only removed one, but that two were included. This is because this rule also considers the project's GUID for its detection.'
Rule: ELASTIC_Windows_Hacktool_Rubeus_43F18623
The following rule aims to search for the literals of the output messages from Rubeus. In this case, the logical operator OR considers both sides to take into account both the GUID and obtaining four of the previously defined literals. Since the GUID no longer exists on the left side due to the project change for the previous rules, we only need to remove four of the eight literals. All of them share something in common, the identifier [Y] where Y can be a value between *, +, X, or !. If we use the Find and Replace functionality, we can change all these values within brackets to eliminate the match with the literal. This change is safe since brackets are usually used as decoration in the output messages, but depending on the scenario, we need to check that we do not lose usability of the binary.
We repeat the process on the remaining symbols by removing the detection of the yara rule.
Rule: DITEKSHEN_INDICATOR_TOOL_PWS_Rubeus
This last rule includes names of the functions used internally by Rubeus, as well as some of the input parameters. In the first case, there is no difficulty in modifying the code, but with the parameters, special consideration must be taken, as we are altering input parameters that must be taken into account. One of the cases is rc4opsec used as a query parameter to forge a secure ticket. For the rule to break, being an AND operator, one of the segments must be removed, for example, that there are eight of the ten literals defined earlier. With the modification of three of them, this rule will no longer be flagged.
"We look for three literals and modify them with alternative names to meet the requirements. For example:"
We repeat this process with the following literals:
- WriteUserPasswordToFile for WriteTheUserPasswordCredentialsToFile
- rc4opsec by errec4opsec
'This rule will no longer be executed, removing the detection capability of defense systems that use this scan.'
Conclusions
In this delivery, we have explored how, in a simple way, it is possible to hide tools by modifying their original code. This approach aims to eliminate Indicators of Compromise (IOC) and typical traces of known tools, which are often quickly detected in protected environments. However, in real scenarios, the complexity is much greater, and these basic modifications are often insufficient to evade modern Antivirus (AV) and EDR solutions, due to factors such as:
- Proprietary detection rules: Each security product has specific non-public rules, making evasion more complicated.
- Dynamic analysis: In addition to signatures, many EDRs incorporate behavioral analysis that monitors how tools interact with the system.
"Below, we list some key points and challenges that must be considered when designing more advanced evasion techniques:"
- Advanced YARA Rules: Some rules not only detect literal strings or specific functions, but also consider byte patterns or more complex structures (as happens if we use the same scenario but with Mimikatz)
- Proprietary rules for security products: Non-public detections require extensive testing and an iterative approach to find effective evasion techniques.
- Additional factors: Beyond static rules, security systems evaluate suspicious actions, digital signatures of the binary, and anomalies in the execution flow, so evasion must be comprehensive.
Axel Losantos, Senior Offensive Security Consultant at Zerolynx by Cybertix
