From Spoofing to Tunnelling: New Red Team's Networking Techniques with Shu Hao Tung

Next talk. So our next speaker uh is Shuha Tong. Uh originally from Taiwan, Shuhao is currently advancing studies at Vancouver Community College with a specialization on web technologies, Windows AD, and networking. His dedication to cyber security is evident through notable achievements including owning NASN pioneering research into stateless tunneling techniques. In this session, Shua will present from spoofing to tunneling new red team networking techniques for initial access and evasion. He will explore cutting edge methods for intranet internet infiltration that bypasses traditional fishing and exploitation tactics using stateless tunnels like GRE and VXLAN. Shua will also highlight evasion strategies, environments lacking IP filtering, examine VXLAN vulnerabilities in the Linux kernel and router OS, and share practical mitigation techniques

for defenders. Shuh, over to you. >> Yeah, thank you everyone. I'm I'm Suhal and thank you all for joining my session today and this is my first presentation at Bside. I am cycling to share some practical right timing network technology with you guys today and so let so let me take you to my typical day in my IT life and seeing my LDAP logs on the LDA server and there's a login from Frank and there's a login from Bob and oh there's a invited login from public IP9 and And there's a lot of invited login. And how and why this can happen? This is a intranet server without destination NAT. So as a bruter, I just bend that bad IP

999. And then the new logs appear and why does this happen? How is that possible that this uh public IP address is attacking our internal network server? And this is a key point that we are going to discuss today. This presentation will explore way of low-level network present uh penetrate testing through the virus of turning protocols. This techniques can be used for advice red team exercise or can block before they are abused by the malicious attackers in Europe cooperate networks. Before we dive into details, let me briefly introduce myself. Hi, I'm Suha uh from Taiwan. I'm a former red teamer at Troy Micro and a graduate of National Chinua University. I have present this presentation at Blackhead USA and Defcon

this year. I'm certainly study at VBC VCC and also I'm seeking a rating penetrate testing or IT part-time job in Vancouver. is yours company is looking for a qualified penetrator please connect me under the okay so you can find the tool to today's on my GitHub and some materials for my research on for this this presentation okay let's this is today agenda and first I will share some red techniques using IP is moving and how we can use that for initial access. Then I'll reveal a night RVX len including internal hijacking and how a buggy routing protocol can lead to IP hijacking and even a domain compromise. And finally I will wrap up with some key

takeaways before we move on the Q&A. So let's let's go for the easy one. First talk about some of the spoofing in source IP in when so we all know that in even recent year package spoofing is still available on public network also please know that all the IP are example address not any common n public IPs and attacker with a IP 2.3.2.2 to can send a DNS request with a source IP 3.3 which not does not belong to it and when 1.1.1 has received the packet it have no way to verify whether the packet is a spoofy packet or a valid one so it will just reply the spook packet and reply it to the

reply the DNS response to 33-3 and 33.3 will receive the DNS response without making a request. This is a typical DDoS DNS amplification attack and it still works nowadays. So also we can we have dived into the company network infrastructure how an it will block computer from assessing a public network for security purpose. So for best practice when a packet sent from a crucial server to a public IP when it arrived to the firewall the firewall would drop the packet. However, some it we saw they just disable the nat mechanism. So the packet will still forward out to the wer network and to the destination. So the remote server will see that the source IP is not valid because it's a

private address and it will either drop the packet or respond to a unknown address and the client will not receive the message. So when your cord is completely messy still works. So how if we consider both situation together what happen if we spoof the source IP on a intranet. Imagine a rating scenario. The attacker hack a compromised device like for example that 1.3. He can create a tunnel between the C C2 server the comp and the compromised device the orange tunnel and after that it can create a DNS request through the terminal which source IP is a attacker public IP which is 9.9. So when the packet arrived to the compromised device, it will forward to

the company intranet router. After that the router received the packet. It will root look up its its IP routing table and forward it to the second victim. As we know if there is no firewall for the second limit 1.2, to the respond packet will send back to the attackers through the public internet because the destination is a public address. Then the attacker will receive the packet which there is no evidence that the packages come from 13. The entire TCP or UDP stream only shows that the IP source address is 9.9 and IP internal IP address is.1.2. So why why IR is hard for this situation? In typical later movement attacks, the attacker use the IP address of a

previous compromised machine to attack the next system. This means when alarming trigger an IR team could simply use network log to trace the attacker path from one compromised machine to the previous one. So the IR team could find a reverent log on the previous compromised machine and identify the initial SS point. Then shut down the entire attack chain step by step. However, when spoofing techniques are involved, the source IP in the log will not be the predest compromise machine. So the IR team will not be able to find the attacker path. they could only see the public IP is attacking their domain controller. Thus, the previous compromised machine will not be caught even if a long bus

sticker and it can change to another public source IP and continue to the attack. Overlooking the attack path, the malicious packet source and destination address only shows 9.9 and internet internal IP.1.2. two thus no one will know the previous compromised machine is 1.3 on the other hand the turnout IP is a HTTP traffic with a source IP 7.77 if 99.9 is bended the attacker can simply simply switch to another public IP and attack a different target the IR need to check every router for layer 2 port logs in order to identify by the previous machine. Also, the source MAC address can be forged at the first hop. So, what if the ISP filter the package

with a private source IP address? We can use uh H323 NIT pass through to enable the temporary destination NAT. The attacker can send a special packet to 99.9. The NAT router will then create a temporary destination NAT for internet intranet IP3 port 4445 and it's probably IP port 445 sorry it's allow the attacker to assess 13 on port 445 via 99.9 this is a quick demo we can see that 241 has a web server at80 port initial Usually the attacker 142 could not access the inter internal web server via public IP. After that we can create a server and send a H323 package from the compromised machine. We receive this package from the victim router and gives

us a plan destination to connect to the in internal web server. Also we can see that the web log source IP is from a public IP rather than than a private IP. This create breakpoint for the attack chain. Another method disco from my friend Jimai involves sping a fake TCP sync packet from the pro compromised device using the next target IP address as the source IP. It's for example is.13 and sending it to the attacker server. The SNAT mechanism can be abused as a destination NAT to connect internal service. So here's another quick demo. We can see that the device does 35 has a web server running at80. Initially the 131 attacker cannot access intranet web server via

public IP. After we spoof a s packet from the compromised machine using the next target IP and the port as the source IP and send it to the server. We can use the destination NAT mechanism to to use we can use the SNAT mechanism to use as a destination NAT mechanism. So we can connect to the internet server. Additionally, we can see that the web server log shows the source IP as a public address rather than a private one. So this also create a break point for the entire attack chain. So do we replace can we replace the C2 server tunnel with a official VPN? The answer is yes. In some cases there are many commercial SSLVPN solution that can

spoof the source IP from the client. As the showing diagram commercial SSLVPN like lo discussed at cyberstack 2025 may allow this behavior. On the other hand, whether opensource VPN solution like VG guard or openVPN are affected depends on their configuration. So where's the initial assets? Do we have a chance to do this without a initial foothold in the intranet? Can we use any existing terminal? The answer is yes. Again on the internet exchange, everyone is on the same layer to turn. Attacker can set a private network lens as a next hub to the router of the company you want to attack. Also, we can abuse existing tunnel such as GRE IP or SIT terminal. But again, a good

firewall configuration code can call this to fail. So, let's talk about the inter internet exchange first. If we compromise a router at the internet exchange or we can just um lease one and we can force a private subnet as the next hub to the victim company's router like this. We can create a connection using our own public IP as a source IP and a private subnet at a destination IP. The victim router will forward the packet to its internal subnet and respond to the attacker public IP. And the another method is is abusing a existing tunnel like GRE. GRE. What is GRE? GRE is a status layer three terminal. It is widely used because it is easy to set up by only it

to config its protocol public IP GRE interface IP and routing table also known as next hub. So who who know who use GRE now? Nowadays there are still a lot of company use G terminals like cloud fair magic transate and its customer they are they can choose between IPSC or G IPS is saver and AWS transit gateway also support J internally but it is only used for internal network also security week report that a groups like salt tone create J internal to collect traffic for from compromised device last there are still a lot of comp company use G to to make a connection between two site. So how does G works? When a package want

to go through a dry kernel the kernel will will pack the packet with a dry header and send it over the public internet. At the receiver side, the dry packet is unpacket and the inner packet is forward according to the router's routing table. GRE is status and doesn't provide any encryption which means it is possible for anyone can spoof J package just like spoofing a DNS request. So a normal dry ernal is is do like this for example that one.2 want to send a packet to 2.2 between the two site the packet will send to its default gateway and the gateway router will add a giator to its packet and send it over to the

public internet. After the gi packet arrive at 2.2 to it will remove the dry header and forward the inner packet according to its routing table and vice versa. When 2.212 send to 1.2 it send to its router and the router pack the packet to J format and send it over to the public internet and unpack it and sec to 1.2. Oh, so how can we find a dry eternal? We can use Austin techniques. For example, we can search for net flow dashboard like a bordo on Google and filter for dry traffic. This way we can obtain the IPS for both two ends of the terminal. Other oinking techniques also helps too. Next, we can use J spoofing technique to

scan for existing J ernal. First we can create a fake GR intern ernal using the command provide above. Then we can craft a G packet with a spoof source IP address once not does not belong to us and send it over the public network to the victim. If the victim has a dry internal pier config with the dry packet source IP for example 1.1.1 it will decapsulate the inner package and process it according to its routing table and forwarding to the inner package. So we can create and stand many different source IP address to br the correct beacon peers. For example, this one package the source IP is 1.2.3.4. If the victim doesn't recognize the

source IP as a no pier, it will drop the packet. On the other hand, if the source matches one of the victim no peers, the victim will accept the G packet and forward the inner packet according to its routing table. For scanning purpose, we set the destination of the inner packet to the victim itself. So the victim will immediately reply the inner packet with an ICMP response. Then the land then the attacker can identify the vict. So how do we know the pure address? We encode the information into ICMP edifer and sequence field which together can represent all 255 to the part of for possible IPv4 address. We also create a scanner script on GitHub. As you can see when the G source

address matches the remote G peers we can get the ICMP response and and get the right peer information. Then we can put everything together to get initial assets. Let's imagine a scenario where the victim 1.1.1 like a cloudfare IP using cloudfare trans has a turn general with 2.2.2. The attacker can forge a GI package that appear to send from 2.2.2. The internet package is a DNS request sent from the provider IP3.3 which is the attacker IP to an inter internal network IP. When the packet arrive the victim will trust and use the GI packet because it claims that it come from 2.2.2 but it doesn't. Then the victim router will unpack the G packet and discover that it contains a

DNS request which destination is a private network IP. The victim will then forward the packet to the company company intranet based on its routing table. When the internal DNS server received the DNS packet, it will respond and send the replies through the public in inter internet to the attacker server. Thus, the attacker can interact with the service on the victim intron including those using the TCP protocols. We have created a demo lab. The architecture is illustrate in the diagram. Um the victim at have a turn between the 1.1.1.1 IP which known as a cloudfare IPS for simulation for cloudfare magic transit. Yeah. Then the there's a internal web server at 192.168.1.2 two and its default gateway is the

target router. So the web server is host on IP.2. The server can access the public network via SNAT. On the other side, the router at IP 1.1 can direct access the intranet server. Also the router has a J tunnel with the IP address 1.1.1.1. You can see here J Pers.1.1. Initially the public IP of the attacker 142 cannot access uh intranet one 192.168.1.2. The get hacker can create a spoof journal to connect to the victim router and directly send a traffic to the in intranet 1.2 server through the fake journal. Then the attacker can directly assess the intranet with the internal west server. Similarly, it's a if it's a it is a layer two terminal

like G tab. Also, if we can leak the victim MAC address, we can also explain this in the same way. It is common to use the SNMP protocol to obtain list. So for a TLDDR summary we when a company does not configure configure its firewall and a daily turno has been used even it's a legacy configuration an attacker can exploited this terminals for initial access to the in internal internet so let's move to another party I'll reveal a nightmare default configuration of vxl. So first what is a vxl net? It's like a a dry eel but in layer 2 mode. It's also a stateless and unencrypted layer 2 terminal. It's pack layer 2 ethernet frame into a layer 4 UDP packet. Each

subnet is has a unique ID ID finder by a name called VNI. So how can we configure VXL then turn similarly to GRE by giving its remote IP local IP and destination port and VNI. However, this simple config is vulnerable. Does anyone know where the vulnerable? Yeah, everyone think it is safe because you have the remote IP, you have the local IP based on the previous configuration. Setting up a standard VX lampier is easy as usual. Just just change the remote IP and public IP from itself. How about hijacking a VXL internal? Yeah, here's the only difference. The only change is your local IP argument. So why does this happen? Does the Linux kernel don't don't check the source IP of VXL

package or why does it accept VXL package with a valid VNI and port even if the source IP is not configured. After looking at the Linux memo, you will see that this is a feature, not a bug. But it is unsecure and turn off by default. Before reporting, router OS couldn't turn off this feature. Now you can change the setting to off, but it's still on by default. So what happen when learning is enabled in VXL? Normally when a config pier send a VXL packet the kernel will add its MAC address to the FDB table also known as forwarding database table shown at the bottom on the slide. The next time a package sent to need to

be sent to a destination MAC address that is listed in the FDB table. The kernel will pack the packet and send the packet to the remote location using the information from the FDB table. Similarly, when learning mode is enabled, any VXL packet will with a valid VN port will be added to the V FDB table. Also, the remote IP could be any IP on the internet. Thus an attacker like 99.9 can create a VXL packet with the MAC address as a source IP MAC address FF ff and the Linux kernel will will add this MAC address to the list. Yeah, it will add a broadcast MAC address to the list. So when the kernel want to send a BCAT

address on the VXLAN interface, it will look up the FDB table and send it to the to 99.9 which is the attacker public address. So what does the attacker know in order to hide the VXL? We know our own IP but we don't know the victim IP port VNI and VXLAN in the subnet. However, all this information can be obtained by a simple scan. An attacker can discover the victim IP port and VNI by sending numerous packets. So, let's focus on how to determine the VXLAN in subnet range. We can gather information by sending a single VXL package where both the source and destination MAC address are set to the BCAT address FF ff. Then when a ARP

request sent from VXL interface, they will also be sent to the attacker VXL. Oops. Uh another method in involve sending a neighbor discover protocol packet. When a router always receive a broadcast neighbor discover protocol MAC address with its own it will it will reply the NDP message with its MAC address and its own IP. So we can send numerous VXM package with different VNI and ports configurerations. Each contains an inner network disco protocol package where both the source and destination MAC address are set to the broadcast address. When the VNI and the port matches the victim configuration, the victim device will add the attacker IP m IP to its FTP table. Where is the MAC address is FF

FFF. Then the victim will use that VXL packet and find out that is a NDP request, network discard protocol request. The victim router will re reply the NDP packet and try to send the respond to the broadcast MAC address which is FF FFF and it will check its FTP table and find out that the destination is 99.9 which is the attacker IP. So the router will pack the pack NDP packet again and send it to the routers uh send it to the attacker IP. Then the attacker has everything to hijack the VXL terminal. So we create a scanner. We can discover the victim IP port and VNI sending numerous P packets. VXL has default port

4789M A472 and VNI usually smaller than 100. Here's the scanner link.

We have also created a lab for VXL scanner demonstration which include a router OS router and a west server. As you can see, we a M2 scanner target at D 200. The scanner send a numerous packet with different default ports and different VNIs. Later, we receive an network discount protocol reply with a VN42 and a port A4 72 and the inner subnet is 10.0.0.1. Then we can simply simply create a VXL with this information about then we can direct access the VXLAN internal network also we scan for insecure VXLAN configuration worldwide usual using only VNI equals one and D4 ports we found that more than 900 VX endpoint respond to the scanner. Additionally, there are 4,000 IPs inside

the VX land submit. Some of these are public IP, which means we can hijack public IPs. Additionally, some endpoints replied with numerous broadcast package combined with IP spoofing. This could potentially lead to a DDoS attack. Lastly, some VXL package have source IP that are private address. This raised a question. Why are private address being used as a source IP on VXL packet? So if I use VXLAN in a encrypted terminal, I think I'm safe. The answer is no. You are not safe. VXL will still accept traffic in different interface. Due to VXL behavior, it still can be hijacked and scannable. For LT TLDDR, we can hijack a VXL tunnel using only three pieces of argument. The

victim IP, the VX port, the VNI. There's no need to know about the pure IP or internal IP address. Furthermore, if your network stepby include public IP interface and the extent on any interface is highly vulnerable. So what can a hacker do after hijacking a tunnel? Not only can hacker gain access to intranet but they can also hijack IP communication or perform main in the middle attack between two site. Additionally, attacker can target layer 2 network service such as expedi vulnerabilities. IR is challenged because the source IP cannot be trust. Moreover, this terminal often runs routing protocols like BGP or OPF. Attacker can hijack IP that are not even training through the terminal such as loss of a domain control or exxi

server. So what is routing protocol? It is a protocol that router can exchange the routes and network information with other routers. Routing protocols help router to dynamically dynamagically learn about the networks around them and determine the best path for forwarding the packet. For example, router A has a has 192.168.1.0/24 zero slash24 and router C could learn the routes from router B by routing protocols. So we often see companies use VX internal to connect two site with routing protocols. But when we combine with the learning feature, yes feature, not a bug, we can hijack routing routers a IP address. Then we can announce like a domain controller IP in routing protocols with latch 32 which is smaller. So the traffic will

directly forward to the attacker computer. Outer router will receive and trust the routing for prefix and yes redirect the domain controller traffic to the attacker because it is most specific than the lens subnet. We have summarized the potential impact of hijacking different service IPs. If an attacker hijack the IP of a domain controller and anti relay if possible meaning SMB signing is disabled or ADCS ESC8 is present they can take over the entire domain. If the attacker hijack the IP of visia promark or any HTTPS service and the original SSL certificate is unsigned or not valid user may not notice. The attacker can then take over the account of or the for server. In short, hijacking this service IP can

lead to account take over, deny of service, DNS hijacking or even full domain compromise. And here's a bonus. A back config in the company's OPF lead to IP hijacking. This attack better has been published for years and we actually observe it during our rating simulation yet very few people discuss it. Do you check TCP dump after get into the internet? If you see this on the victim internet it might be vulnerable. Just like the exploitation method described in the previous slide. If you see a hello package, there is a highly potential that you can directly establish an OPF connection with the router and hijack the routes without any permission. Yeah. So these are the key take cares.

There are two ways for blue team. First check all unencrypted internals in your company's network. If you find any don't screw that including list including G IP IP sit G tab and VXL and including magic cloud magic transit J ernal they are not secure and can be abused by attacker. Next make sure you have a secure firewall in place. Your firewall could filter outbound in intranet traffic especially s-ac packet. Also check for IP spoofing within your internet. Ideally all ISPs to need to filter out IP spoof IP address but in reality this is really possible. Check if OSPF is only enabled on ports between routers. OPF should not be open on unnecessary port. Monitor your routing prefix for any anomalies.

Unexpect change in routing protocols can indicate an ongoing attack. Finally, set up a mean a stat prefix site in your routing protocols. For example, sl 24. And here's the key takeaway for rating. First, scan or use all to find vict encrypted ter. This can be a entry point in your in the network. Once you are inside the internet, check for the victims networks that are for spoofing. Use IP spoofing techniques during high-risk scanning to avoid detection. Look out for OPF hello message to identify it active routing protocols and potential attack path. Scan for misconfiguration VXL internal. If you find a vulnerable turn, hijack it to get a inter in internet access abusing abusing routing protocol and hijack IP

for later movement or or private exalation. Red teamers can continue looking for more vulnerability protocol in the future. Remember scan find hack. And here's our key key takeaways for two makers. First implement an intranet IP spoofing command and control tools. Develop automation tools to test the possible of IP spoofing. IP IP spoofing within a target intron automation save times create automated correct mechanism for mismatch between IP destination and source address within the same TCP station. Some routers still perform SNAT even the package is a survey response automate the process of sending H 323 packet or a new TCP package to ticker routing mechanism especially for ISP that filter private IP as a source IP address

develop tools for automation OSP IP hijacking attacks finally implement a most efficient GI scanner for global scanning similar what mascan does for TCP and thank you everyone and I'm open to