In this post, we look at different techniques to hide Windows API imports in a program in order to fly under the radar of static analysis tools. Especially, we show a method to hide those imports by dynamically walking the process environment block (PEB) and parsing kernel32.dll in-memory to find its exported functions. Let’s dive in!
Unquoted Service Paths is a widely known technique to perform privilege escalation on Windows machines – but one can also leveraged it to establish stealthy persistence by creating new services purposely vulnerable to this flaw.
Most modern EDR solutions use behavioral detection, allowing to detect malware based on how it behaves instead of solely using static indicators of compromise (IoC) like file hashes or domain names. In this post, I give a VBA implementation of two techniques allowing to spoof both the parent process and the command line arguments of a newly created process. This implementation allows crafting stealthier Office macros, making a process spawned by a macro look like it has been created by another program such as explorer.exe and has benign-looking command line arguments. I am not the author of these techniques. CreditsContinue reading… Building an Office macro to spoof parent processes and command line arguments
Cloudflare is a service that acts as a middleman between a website and its end users, protecting it from various attacks. Unfortunately, those websites are often poorly configured, allowing an attacker to entirely bypass Cloudflare and run DDoS attacks or exploit web-based vulnerabilities that would otherwise be blocked. This post demonstrates the weakness and introduces CloudFlair, an automated detection tool.
I recently worked on a small toy project to execute untrusted Python code in Docker containers. This lead me to test several online code execution engines to see how they reacted to various attacks. While doing so, I found several interesting vulnerabilities in the code execution engine developed by Qualified, which is quite widely used including by websites like CodeWars or InterviewCake. The combination of being able to run code with network access and the fact that the infrastructure was running in Amazon Web Services lead to an interesting set of vulnerabilities which we present in this post.