Posts

Securing Windows environments

Image
Intro Securing windows environments in a way that prevents lateral movement and/or escalation of privileges has become an incredibly difficult task. The research and tools created in the past 2-3 years have been simply amazing, which helped to identify new attacks and vulnerabilities, while lowering the sophistication required to exploit them. The easiest way to ensure that your environment is built in a secure manner, is to rebuild it from scratch with a security architect behind the design. As Microsoft states, one may never trust Active Directory, if it has been compromised, unless it is possible to return to a known good state. Unfortunately, creating a new environment is unrealistic, so in this post, I'll focus on identifying common and deadly "flaws" in the current implementation and provide techniques and procedures that I recommend, to increase your Cyber maturity and capabilities to withstand an intrusion or limit the impact of one, should it occur. The informa…

AppLocker - hash *bad*listing

Image
Application whitelisting is one of those actions on organization's security roadmaps, which either never happens or is adopted to fit the current environment rather than having it implemented to its full extent.  Although far from perfect, with a large number of bypasses for its whitelisting capabilities (described in the Github repository here), AppLocker is still a great, free* tool which introduces resilience in the environment. Many of the bypasses rely on abusing Microsoft signed executables, as they are whitelisted by default and have the capability to launch other executables. In the previously linked Github repository, the author has made an effort to provide AppLocker rules to prevent the bypasses, however, many of these are likely to break things in a fully-functional real-world environment with "legacy" systems.

One of the most common (unfortunately) implementations is a blacklisting approach. In this implementation, everything is allowed to execute by default…

Routed SQL Injection

Image
I encountered what is known as Routed SQL Injection a couple of times but it was never required to exploit the vulnerability to the full extent. Recently, I discovered an online challenge on the topic and decided to look at it in depth. An explanation of the vulnerability with a vulnerability code which is described in the beginning this post, can be found here.

To better understand the vulnerability, lets examine the following piece of code:

The magic here is that - the output of the first query is used as the input of the second query and it is the second query which displays output back to us. Or in other words, in order to exploit the SQL Injection vulnerability, we need to control the input for the second query - the variable sec_code (which happens to be the output of the first query). You may have already noticed that, due to the fact that the first query is vulnerable to SQL Injection, we can control and set sec_code to an arbitrary value.

Let's exploit that in the online…