Tuesday, February 27, 2018

Veil Framework (II): Evasion (no encryption / no encoding)

ANTIVIRUS EVASION / Veil Framework (II): Evasion (no encryption / no encoding)

- Layout for this exercise:

- The goal of this exercise is to check the rate of Anti Virus evasion success using the Veil Framework with Evasion.

- The success rate will be good, though in this simple exercise we aren't using encryption or encoding for the generated payload.

- On next exercises the success rate will be improved because encryption and encoding will be used.

1 - Generating a payload with Veil-Evasion

- Launching the program:

- Listing the available tools:

- Using Evasion:

- Listing Evasion payloads:

- Taking the number 7) payload, a meterpreter reversion shellcode:

- Setting Kali Linux as LHOST:

- Generating the payload:

- Giving a name test1.exe:

- The Veil files are created and stored in these folders:

2 - Launching the attack

- The generated executable test1.exe is here:

- Setting up a simple web server:

- Transferring the file to the victim Windows 10:

- The reference file test1.rc is here:

A handler session is created, launching Mestasploit taking test1.rc as a reference 

- Running test1.exe at Windows 10:

- The attack is successful and a Meterpreter session is achieved:

3 - Checking the Anti Virus evasion rate

- Checking test1.exe against Virus Total a rate of 59% evasion success is achieved:

- Checking test1.exe against No Distribute a rate of 56.7% evasion success is achieved:

Veil Framework (I): Installation and Setup

ANTIVIRUS EVASION / Veil Framework  (I): Installation and setup

- Layout for this exercise:


1 - Introduction to Veil Framework

- The Veil Framework is a collection of security tools that implement various attack methods focused on evading antivirus detection.

- The most recent version at this moment (Veil 3.1.4) is composed  of these tools:

a) Evasion generates payload executables that bypass common antivirus solutions.

b) Ordnance quickly generates Metasploit stager shellcode.

2 - Installing Veil Framework

- In this exercise we are using a Kali Linux distribution.

- In case git is not installed:

- From Veil github, copying to the clipboard:

- Cloning:

- A new directory Veil is created:

- Setting up the framework:

3 - Browsing Veil Framework options

- Launching the program:

- Veil provides some commands. For instance the command list displays the two available tools, Evasion and Ordnance:

4 - Evasion

- Choosing Evasion:

- Listing the 41 Evasion payloads:

                  ......................... etc ............................................................

5 - Ordnance

- Choosing Ordnance:

- Listing Ordnance payloads:

- Listing Ordnance encoder (XOR):

Sunday, October 15, 2017

Port Redirection with RINETD to HTTP and Remote Desktop Protocol servers


- Layout for this exercise:

1 - Introduction

rinetd redirects connections from one IP address and port to another with basic IP based access control.

- rinetd is a single process server which handles any number of connections to the address/port pairs specified in the file /etc/rinetd.conf

- Since rinetd runs as a single process using nonblocking I/O, it is able to redirect a large number of connections without a severe impact on the machine. 

- This makes it practical to run services on machines inside an IP masquerading firewall.

2 - Port redirection to HTTP server

- Installing the service rinetd at the Kali Linux machine:

- Editing /etc/rinetd.conf:

- The configuration parameters are:

bindadress          = (Kali Linux)
bindport               = 3333 (redirected port at Kali Linux)
connectaddress  = (CentOS where the HTTP server is enabled)
connectport         = 80 (HTTP port at CentOS)

- Restarting the service rinetd:

- Now, connecting from Windows 7 normally to (port 80) the Apache Server home page at Kali Linux is displayed:

- However, when connecting from Windows 7 to port 3333 ( there is a redirection to the Apache Server located at CentOS Linux machine:

- Running netstat at Kali Linux, the redirected connection from Kali Linux local port 3333 to remote CentOS port 80 is displayed:

- It is interesting to notice that the CentOS Linux HTTP server does not have any news from its "hidden client" Windows 7 (, because the only "connection" to its port 80 detected by netstat  is the one coming from the proxy Kali Linux (

3 - Port redirection to Remote Desktop Protocol server

- Editing again /etc/rinetd.conf:

- The configuration parameters are:

bindadress          = (Kali Linux)
bindport               = 5555 (redirected port at Kali Linux)
connectaddress  = (Windows Server 2008 where RDP server is enabled)
connectport         = 3389 (RDP port at Windows Server 2008)

- Restarting the service rinetd:

- Connecting from Windows 7 with RDP to Kali Linux trough port 5555:

- Authenticating:

- The RDP connection to (Windows 2008) is successful, but let's notice that the connection is being redirected trough (Kali Linux Machine):

- Running netstat at Kali Linux, the redirected connection from local port 5555 to remote port 3389 is displayed:

- Interestingly, running netstat shows that  Windows 2008 is totally unware of the "hidden client" Windows 7 ( that originated and actually is taken advantage of the RDP connectionIn other words, the only connection detected by Windows 2008 is from the proxy Kali Linux (