Tcp redirector driver#
Alternatively, we could bypass driver signing protections by loading an existing vulnerable signed driver and exploiting it to get ring0 code execution. For example, a custom driver would require obtaining a code signing certificate to load the driver. We considered several alternative designs, including writing a custom device driver, but these introduced operational hurdles for deployment. When designing PortBender, we decided to leverage the existing WinDivert driver by Basil00 for performing network traffic interception and modification.
These requirements included factors such as the ability to execute the tool in memory as a reflective DLL, integration with Cobalt Strike, support for Duqu 2.0 style backdoor persistence, leveraging static linking for all dependencies, and the use of an object-oriented design using C++ to promote modularity and code reuse. However, in this case, we decided to create a new and separate utility to satisfy some of our unique requirements. When designing PortBender, we based much of the initial design on the DivertTCPConn tool by Arno0x0x. To satisfy these requirements we have developed the PortBender utility.
Tcp redirector portable#
We also needed to integrate the capability with multiple C2 frameworks, so any mechanism for implementing in-memory execution should be portable across various C2 frameworks. Furthermore, we wanted to execute the tool entirely in memory with a minimum on-disk footprint. We wanted a tool that we could run for a short period to redirect traffic without rebooting and then subsequently stop redirecting traffic after performing an attack. Therefore, this option, while viable, was not sufficient for our requirements. However, we typically try to avoid making any permanent system changes or modifications during red team operations (and avoid rebooting production systems). Īnother option we considered was disabling SMB services on the host and rebooting.
Tcp redirector windows#
Francisco Dominguez also notes this limitation of the “NetSh PortProxy” interface in his article titled “Remote NTLM relaying through meterpreter on Windows port 445”. However, in this case, it appears that this mechanism doesn’t work for redirecting traffic destined for the SMB service running on port 445/TCP. Our initial attempt at performing SMB relaying through Cobalt Strike attempted to use the “NetSh PortProxy” mechanism to redirect traffic destined for port 445/TCP. Methods for Performing SMB Relaying on Windows We have also included a feature in PortBender which allows an attacker to simulate the PortServ.sys persistence technique leveraged by the Duqu 2.0 threat actor. For example, a user may wish to modify traffic destined for the 445/TCP port to 8445/TCP. To overcome this operational hurdle, we have developed a custom utility named “PortBender” which allows us to redirect traffic from an incoming TCP port to an alternative TCP port. Unfortunately, in previous scenarios, we have been primarily limited to passive credential collection and unable to perform relaying attacks when obtaining credentials through SMB. Furthermore, it is not uncommon for our team to perform name resolution poisoning during red team engagements to harvest credentials within an environment. Often, we need to perform this attack from a compromised Windows system where the built-in SMB service is already listening on port 445/TCP. Colloquially we often refer to this as a “Computer AdminTo Computer” vulnerability.Įxploiting this issue in practice during a red team engagement has often historically been difficult. In a previous article titled “ Active Directory Computer Account SMB Relaying Attack,” we discussed how an attacker could leverage computers assigned administrative rights to other computers to escalate privileges or move laterally using the printer spooler service.
0 kommentar(er)
