# ⚔️ Implementation of One-Way Shellcoding in Windows 64bit Systems

Introduction
---
An interesting aspect of Penetration testing/exploit development is to discover a vulnerable service and exploit the service using the misconfigurations in the system. In a typical scenario exploiting the vulnerability in a real-time service and getting a shell from the server is not a simple task.

Lets assume one such a scenario where a vulnerable service is running on a Windows environment that is behind a firewall.

<!--https://i.imgur.com/ynsWEyT.png -->

The Firewall is configured in such a way that

a) It blocks all ports except for port of the vulnerable service (i.e. Connections are allowed only on port 4444 on which is used by vulnerable service)

b) It blocks all outgoing connections from the server

In this scenario, it won’t be possible to get a shell using traditional payloads. Because the only way to establish a connection with the server is through the port of the vulnerable service. Hence we need to tweak the custom shellcodes such that we can use the existing port of the vulnerable service to obtain a shell from the server. This technique of customising shellcodes is known as one-way shellcoding.

We will demonstrate a step-by-step process to construct and execute “Rebind Socket shellcode” which is a type of one-way shellcode.

Primer on Windows Memory Management
---
All the processes in Operating Systems (OS) use memory, the memory management is dependent on the OS. Processes do not have access to physical memory directly. Processes use virtual addresses which are translated by the CPU to a physical address when accessed.

On launching a process in a Win64 environment, only canonical addressess are used by the processes to which virtual addressess are assigned. Typically, in a Win64 environment, the canonical address range from
- 0x0000000000000000 to 0x00007FFFFFFFFFFF which are used for userland processes
- 0xFFFF0000'00000000 to 0xFFFFFFFF'FFFFFFF which are used for kernel processes.

The remaining address are referred as non-canonical addresses.

Each time a process calls a function, a stack frame is created. A stack frame stores things like the return address to return to on completion of the function and the instructions to be carried out by the function.

Development of the Shellcode for Windows 64bit
---

In a Windows 32bit system, when a buffer overflows in the vulnerable application, the EIP register will get loaded with the overwritten return pointer address on the stack. This is not the case with Windows 64bit applications, which will only load canonical addresses into the RIP register. For example, you cannot overflow a buffer with A's and expect to see RIP flooded with 0x41's as 0x4141414141414141 since it is not a canonical address as described earlier. However, we can overwrite the return pointer with a canonical address of some instruction set we would like to execute, and this address will be loaded into RIP and run as normal.

We can confirm the application is vulnerable to buffer overflow by sending a payload buffer of 3000 A's to target server and observe the stack in debugger. Python 2.7 with the socket library is used as scripting language for socket communication as shown below.

import socket

buf="A"*3000

s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.connect(("172.16.35.6",4444))
print s.recv(1024)
s.send(buf)
s.close()

Observing the stack at x64dbg we notice that the stack is overwritten with 4141414141414141 as shown in image below, but the RIP is not loaded with our payload buffer as it is a non-canonical address.

For further developing the exploit since we know we can override the return address in the current stack we will override return address with our desired address to jump to an address where we can control the stack.

### Determining location of retrun address in the stack

We will use `pattern_create` tool in kali linux to create a buffer of known pattern of 3000 bytes and send it as payload to determine exactly at which location the return address is overwritten. The command used to create a buffer is given below

./usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 3000

Modifying the above script with the output string from above command and crashing the application. In the x64dbg debugger we notice the bytes `0x` is the location where the return address of the stack is overwritten We will use pattern offset to query the location of the string in our payload buffer. The command used is given below

./usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -q 

The location of return address in our current stack is identified as

###### tags: `shellcoding` `exploit-dev` `64bit` `windows`