AdSense
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.
https://www.veil-framework.com/framework/
https://github.com/Veil-Framework
- 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
PORT REDIRECTION WITH RINETD TO HTTP SERVER 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 = 192.168.1.27 (Kali Linux)
bindport = 3333 (redirected port at Kali Linux)
connectaddress = 192.168.1.15 (CentOS where the HTTP server is enabled)
connectport = 80 (HTTP port at CentOS)
- Restarting the service rinetd:
- Now, connecting from Windows 7 normally to 192.168.1.27 (port 80) the Apache Server home page at Kali Linux is displayed:
- However, when connecting from Windows 7 to port 3333 (192.168.1.27: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 (192.168.1.6), because the only "connection" to its port 80 detected by netstat is the one coming from the proxy Kali Linux (192.168.1.27):
3 - Port redirection to Remote Desktop Protocol server
- Editing again /etc/rinetd.conf:
- The configuration parameters are:
bindadress = 192.168.1.27 (Kali Linux)
bindport = 5555 (redirected port at Kali Linux)
connectaddress = 192.168.1.24 (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 192.168.1.24 (Windows 2008) is successful, but let's notice that the connection is being redirected trough 192.168.1.27:5555 (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 (192.168.1.6) that originated and actually is taken advantage of the RDP connection. In other words, the only connection detected by Windows 2008 is from the proxy Kali Linux (192.168.1.27):
Subscribe to:
Posts (Atom)