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…
In my Securing Windows environments post, I touched upon logging and SIEM but I didn't go deeper as the post became too lengthy already. As a reference, I stated the following:
"... All of the things described up to this point, aim to reduce the attack surface (reducing the risk of successful compromise) and the impact should one occur ... Now, if you think about this, the Penetration testers will be running tools and scripts, which are not normally executed in your environment so that puts you a step further, because it will all be executed on a device that you own. At this point, having and analyzing logs (default Windows logs only are insufficient to trace activity) is fundamental. In fact, in 2019, there should be no excuse for not having a SIEM system, even if it is a free of charge one - ELK stack or Graylog (although it may not have every feature you wish it did)."
The above refers to utilizing the available logs to perform Threat Hunting. Threat hunting is …
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.