No Need to Teach New Tricks to Old Malware: Winning an Evasion Challenge with XOR-based Adversarial Samples
Summary of seminar presented by Yash Shende and Pratik Nath; based on Ceschin et al. paper; CSCE 689 601 ML-Based Cyber Defenses
The paper is an extension of the attack methods used by the authors previously. This blog is originally written for CSCE 689:601 and is the 12th blog of the series: "Machine Learning-Based CyberDefenses".
Paper highlights
The paper outlines an overview of a competition involving attacking 3 distinct ML models and defending own ML models against other teams' attacks.
Criteria for defending models include achieving a False Positive Rate (FPR) of less than 1%, a False Negative Rate (FNR) of less than 10%, ensuring a response time of 5 seconds for any sample, and behavior validation.
Criteria for attacking models include bypassing defenses, executing black box attacks and ensuring that modified samples behave similar to the original.
The defender challenge initially used a baseline model with textual features but switched to the EMBER dataset due to bias concerns. EMBER's attributes were employed to train definitive models using 1.6 million labeled samples, including numerical, categorical, and textual components. Lief Python facilitated faster parsing of Portable Executable (PE) files. Model fine-tuning reduced the false positive rate (FPR) to less than 0.1%, and previous years' adversarial samples were utilized to enhance the model.
Attackers initially tried appending goodware strings and random bytes, using a dropper method, and testing their own model. However, detection of malicious activity hindered the dropper approach, prompting exploration of code manipulation tactics like adding dead code and transitioning architecture. To bypass the third model, they encoded the malware binary as base64 and XORed it with a key, adjusting compiling settings and implementing payload hiding for further obfuscation.
The ssdeep hashing algorithm was used to identify similarities between files based on their headers, helping in the assessment of file similarity and potentially evading detection.
The "dilution effect" occurs when a malicious payload loses its effectiveness when mixed with benign data, making it harder for security systems to detect.
Impact: low average number of queries, misclassifications by real AVs.
Takeaways
In this challenge, teams both attacked and defended, unlike previous challenge where only attackers participated. The challenge occurred in a black box environment, using Docker for querying. This limited participants' visibility into the models they targeted or defended against, mimicking real-world scenarios where attackers have minimal information about their targets.
Biased Methods: Authors' methods tend to lean towards classifying most items as malware, possibly due to rigorous defense mechanisms prioritizing caution to reduce false negatives.
Iterative Attack Approach: Initial attempts to bypass defenses by appending strings were ineffective. Attackers then shifted to a dropper approach to hide malicious code, emphasizing the importance of adaptive attack strategies.
Attackers aimed to reduce the number of queries to defense systems to minimize detection. Each evasion attempt incurred point deductions, so attackers adopted Attack Transference. They first targeted their own models to identify vulnerabilities, then applied these attacks to other models. This strategy relies on the principle that if a model can be successfully attacked once, similar attacks may work against other models.
The team utilized a mimicry attack strategy, crafting a dropper to imitate the benign calculator application. They added functions and features from the calculator into the dropper code, using benign samples classified as goodware by their model.
By mimicking the calculator application, attackers aimed to exploit the trust associated with commonly used and harmless applications. This used security systems' tendency to overlook or misclassify benign-looking software, facilitating successful evasion of detection mechanisms.
In the attack strategy, the malware was hidden within an "if" condition, while the "else" branch contained dead code mimicking the calculator functions. This made the dropper resemble the benign application, successfully evading the local model. Attackers then utilized this dropper to bypass other models, with around 50% success rate, highlighting the importance of functions within the dropper.
Attackers countered models overlooking benign functions by obfuscating the payload with methods like XORing byte by byte and additional encoding like base64. During runtime, they decoded the payload to execute the malicious code. These adjustments successfully bypassed all models with just up to 5 queries per sample, showcasing the refined attack strategy's effectiveness, combining mimicry and payload obfuscation techniques to evade detection.
Attackers substituted models by creating local copies, using legitimate queries to train surrogate/substitute models. This tactic helped evade direct attacks on originals, lowering detection risk. They emphasized testing malware samples locally to prevent widespread awareness among antivirus solutions.
Experimentation with droppers revealed an issue with ssdeep, a tool for file similarity analysis, where minor payload variations resulted in consistently high similarity scores. To overcome this, techniques like locality-sensitive hashing were explored, aiming to hash similar data points into the same or nearby buckets to identify similar items within a dataset.
In our pipeline, clustering similar samples will help in identifying similarities among variants, offering an effective means to group new incoming samples. This approach prioritizes similarity detection over reliance solely on machine learning models, emphasizing the importance of robust defensive strategies.
Multiple layers of encoding, such as XOR and Base64, are crucial because they:
Decrease accidental similarities between benign byte patterns and malware, reducing false positives and strengthening evasion techniques' robustness.
Prevent inadvertent generation of identical byte patterns during XOR operations between bytes with a key and the actual payload. This ambiguity can lead to misinterpretation of the payload, potentially causing significant issues.
In web attacks like Cross-Site Scripting (XSS), Base64 encoding is often used to hide malicious payloads, making it harder for security measures to detect and stop attacks. However, Base64 encoding only provides obfuscation, not encryption, and can be easily decoded. So, while it can bypass input filters, it's not secure and mainly used for obfuscation in XSS attacks.
XOR encryption can be reversible if the key is known or hardcoded. To mitigate this risk, avoid hardcoding the key; retrieve it dynamically, possibly from an external source. Dynamic key retrieval enhances attackers' chance to be hidden from AVs.
Frequency analysis is a cryptanalysis technique used to break encryption like the Caesar cipher. It analyzes the frequency of letters or characters in the ciphertext to deduce patterns and potentially find the encryption key. For instance, in English text, 'e' and 'a' are common letters, helping identify the offset or shift in the cipher.
Caesar cipher is a substitution cipher where letters are shifted by a fixed number of positions. For instance, with a shift of 3, 'A' becomes 'D'. Although simple, it's vulnerable to frequency analysis and other cryptanalysis due to its predictable nature.
In Portable Executable (PE) files, the standard header starts with the "MZ" flag (ASCII characters "M" and "Z"). Deviations from this flag could indicate potential exploits for extracting keys or identifying patterns within PE files. Analyzing such deviations may provide insights into the file's structure or properties, aiding in attacks or reverse engineering.
Encoding involves a reversible transformation of data that retains its fundamental properties. On the other hand, encryption makes data unreadable without the decryption key, altering its properties. Without the decryption key, encrypted data cannot be recovered to its original form.
In this paper, dead codes were depicted as strings. However, dead code can comprise more than just strings. It refers to parts of a program never executed during runtime, including unused variables, unreachable branches, or functions never called. While dead code may appear as strings, like in comments or debug messages, it can also exist as unused functions or conditional statements always false.
In developing a robust malware classifier, relying solely on name or string features may not suffice. Analyzing code behavior and structure, particularly using call graphs, is more effective. Call graph analysis helps differentiate between benign and malicious software by comparing known malware graphs with those of benign programs. Attackers may attempt to evade detection by mimicking or obfuscating call graphs. Other graph types like dependency or control flow graphs can also aid in detection, but they may require intensive computation, potentially impacting detection speed.