We are watching the traffic coming from Iran, and it’s starting to look unusual.
Some techniques that previously worked are now widely used, and they have become visible at the firewall level.

Let me give you some advice.

When you play chess against an opponent who is more experienced, has studied your games, and already controls the center of the board, you don’t rush your queen into the middle. The center is where the board is most contested. If your opponent already controls those squares, placing your most valuable piece there only makes it an easy target.

Instead, strong players develop quietly, protect their pieces, and look for indirect ways to challenge control of the board.

The Thirty-Eight Barrier is close to run !

New leak from Iran's regime censorship docs:
They’ve got ways to spot Starlink users and people on VPNs.
Some popular Iranian apps come bundled with hidden networking scripts that run in the background.
These scripts keep sending DNS queries and TCP requests outside your network — even when VPN is active (and in some apps, it doesn't even care if VPN is on).
They do it in 3 main ways:

to public/blocked servers (just to check if they connect)
to regime-controlled endpoints (to figure out how you're connecting)
to special DNS resolvers (to detect your leaks/IP)

Then they collect all this data and either send you threatening messages or pinpoint if you're on Starlink.
Be careful what apps you run. Stay sharp.
we  may publish a complete report later , but for now just learn to use  app proxing or split tunneling

We performed a controlled lab test on several messaging apps. Observations are based solely on network traffic; no payload decryption or app reverse engineering was done.

1. DNS behavior

Some apps (e.g., Bale) requested DNS from multiple sources outside the device’s configured servers.

At least three DNS servers were contacted, all located outside the country.

2. Tunnel-flag behavior

When the tunnel flag was toggled on and off (no real network change), some apps behaved unusually.

Eita repeatedly closed otherwise successful server connections when the tunnel was on.

This behavior did not occur when the tunnel was off.

3. DNS resolution inconsistencies

Eita sometimes resolved a domain to an IP (e.g., a.b.c.d) but connected to a different IP (e.g., a.b.c.e), ignoring the resolved IP for extended periods.

4. Reconnection and traffic patterns

Eita repeatedly re-established connections after closing them.

We saw forground netowork activity in app that first thought is for notifications.
We tested with a chat message showed the app did not load the message or notifications.
but meanwhile
Upload traffic volume was much higher than download, which is not typical for getting notification request

5. Comparison with other apps

Rubika: similar to Eita, opening multiple connections to different servers, sending data, and closing connections frequently.

Bale: maintained a single, persistent TCP connection to its server, behaving normally.

These apps exhibit unusual and potentially suspicious network behavior.

Some easy to undrestand info are in the zip below:

The firewall required a routing update, and several CDN service IPs were added to enable access for certain government‑affiliated individuals and organizations.
We have successfully injected most of the IP ranges from the company’s cloud-based NS (AWS, Akamai, etc.) into the routing table. The changes are currently propagating and are expected to be fully applied by 06:00 AM Iran local time. Connectivity should now be smoother, allowing most users to connect more easily.
For now, focus on the following ranges (eventually, the full subnets will be applied):
2.144.x.x/24
3.160.x.x/20
18.154.x.x/24
23.49.x.x/20

You can also scan the range under 50.x.x.x, which has now been fully applied.

The change is now completely applied and many ranges are open
Scan and find them out

Based on the traffic we observed in Iran, it appears that TCI has started implementing domain whitelisting on their DNS servers.
This might be a configuration mistake, but according to our logs, since this morning most domains have been resolving to the internal IP 10.10.34.35.
Some of the most frequently used domains were occasionally corrected, but many services such as bale.ai, zarebin.ir, and several others have still not been fixed.

Updated: every thing got normal in later check.

Th changes came back on TCi. Dns request for most of the sites get the same ip and
They also started blocking other dns-servers even local ones.

Looks like somone need to pass network+ again...

Below is a list of new dns servers list in TCP(port 53), which hasn't been restricted by firewall yet.
With proper set-up (multiplexing, mtu and dns-size) you can make your dead connections alive again.
We also add new UDP dns servers beside the list we published before that may help.

After a few days of silence...
We're back with something massive.
Some fresh leaks coming...

After weeks of continuous internet shutdowns in Iran, we have decided to take action.
We have split our team into two parallel projects to expose the regime’s horrific tactics against the Iranian people:
Team 1 has extracted highly confidential government reports and internal orders. These documents reveal systematic strategies to:

Control and manipulate public opinion
Trick and trap citizens
Hunt down Starlink terminals
Target people selling VPN configurations
Seize control of news channels and proxy groups

Team 2 has focused on the mafia networks behind the “white internet” (filtered internet) business. They sell access to the poor at exorbitant prices while working hand-in-hand with the censorship infrastructure (TIC). They actively help block DNS and develop new filtering methods just to make their illegal business more profitable.
So far, we have extracted over 750 gigabytes of sensitive data, including:

Detailed logs and filtering strategies
User profiling systems
Internal orders to enforce nationwide censorship
And much more...

We are now carefully organizing and analyzing this massive archive. In the coming steps, we will publish key findings and develop effective strategies to bypass this digital oppression.

We also discovered concrete evidence in the leaked data that the regime has attempted to block public DNS servers on a large scale.
According to the extracted configurations and Cloudflare Radar data (see attached image), they deployed strict DNS blocking rules. However, the documents clearly show that they failed to fully block DNS requests to the outside world.
Most of their own servers collapsed during the first tests, forcing them to reroute traffic and rely on DNS forwarding instead. Meanwhile, several ISPs were unable to implement the blocking properly.
We have published the relevant files below. You can scan them yourself and discover the servers and configurations.