Innovative Tunneling Techniques Leverage File Storage, IMAP, Meek, and NTP for Covert Connectivity
A fresh set of unconventional tunneling approaches has surfaced in the world of proxies and VPNs, expanding options for establishing covert network links through everyday services.
File Tunnel
The core idea is straightforward yet effective: when two hosts share access to the same file storage, ordinary files can serve as the medium for TCP connectivity. File-Tunnel listens on a local TCP port; incoming connections cause data to be appended to a file. The remote instance reads the same file, reconstructs the TCP stream, and forwards it to the intended destination. Return traffic flows through a second file. Files are periodically rotated to prevent unbounded growth.
Supported storage includes SMB or NFS shares, FTP servers, RDP or Citrix mounted disks, VirtualBox shared folders, WSL, Docker volumes, and Dropbox. Recent additions provide native S3 and WebDAV support. Because many providers offer inexpensive or free-tier S3-compatible buckets, the resulting tunnel traffic appears as routine object-storage requests. Example invocation on side A forwards RDP while side B acts as the remote endpoint:
- ft.exe --s3 --bucket mybucket --region ru-moscow-1 --access-key XXXXXXXX --secret-key XXXXXXXX -L 5000:192.168.1.20:3389
Environment variables FT_S3_ACCESS_KEY and FT_S3_SECRET_KEY keep credentials off the command line. WebDAV works with services such as Mail.ru Cloud using a simple URL and credentials.
True IMAP Tunnel (Secure)
Building on earlier serverless experiments, True IMAP Tunnel (Secure) uses an IMAP mailbox as the transport. Both tunnel endpoints authenticate to the same account and designate dedicated folders for each direction. Data frames are wrapped as draft messages via the APPEND command; they never traverse SMTP. The receiving side monitors via IDLE or polling, extracts frames, marks messages deleted, and issues EXPUNGE in batches. Optional AES-256-GCM encryption protects frames, and message appearance (subject, attachment filename) can be customized to reduce suspicion. Tested providers include Gmail, Outlook, Seznam, Mail.ru, Yandex, Timeweb, and Rambler. The single Go binary supports SOCKS5, VLESS, SSH, and can run as a Shadowsocks SIP003 plugin.
Meek
Meek, a legacy Tor pluggable transport, offers an alternative when XHTTP fails against certain CDNs. Clients issue HTTP POST requests (up to 64 KB) carrying an X-Session-Id header; the server maps sessions to TCP connections and returns responses in HTTP bodies. Empty POSTs maintain polling intervals that grow from 100 ms to 5 s. Because of its simplicity, Meek functions through shared hosting with small PHP or Python reflectors. Standalone operation is achieved by manually setting TOR_PT_* environment variables, bypassing Tor entirely. A Python wrapper converts the ephemeral SOCKS listener into a fixed TCP port for direct use with tools such as SSH.
ntptun
Extending the ICMP and DNS tunneling lineage, ntptun carries IP or UDP payloads inside NTP mode-3/4 packets using extension fields. The Linux TUN mode provides full IP-over-NTP connectivity; the Windows UDP mode maps multiple clients via port offsets. Recommended deployment places GOST with KCP between the application and ntptun, yielding an HTTP/SOCKS5 proxy whose traffic hides inside NTP. Downstream modes include honest poll (client-driven) and push (server-initiated) with keep-alives; active-probing resistance drops unexpected packets that do not match expected session behavior.
Related articles
Yandex Apps Leak Pre-Trigger Audio Buffers, Payment Data, and Contacts via Reverse Engineering
Reverse engineering of Yandex Search and Yandex Browser APKs reveals extensive data collection practices on Android devices. The apps maintain a server-controlled pre-trigger audio buffer that captures up to three seconds or more of microphone input before the wake word Alice is detected. WiFi fingerprinting, full contact book synchronization via ContentObserver, and transmission of PAN and CVV details to mobpayment.yandex.net occur before tokenization. Additional findings include 94 JavaScript Bridge methods, logcat exfiltration with AES encryption, hardcoded Yandex DNS servers, and a native surveillance library named libquarkenstein_daemons.so. The analysis also covers passive geolocation, cell tower data collection, and inventory of installed applications including competitors such as Chrome, Firefox, WhatsApp, and Telegram. These mechanisms operate under remote configuration flags and bypass several Android privacy restrictions through manifest queries.
TSPU Filtering Disrupts Timeweb Cloud Servers: Diagnosis, CDN Failures, and Reverse Proxy Bypass
Russian hosting provider Timeweb Cloud experienced widespread TSPU-based DPI filtering starting in early June that selectively blocked TLS handshakes on port 443 while leaving SSH, ICMP, and TCP connectivity intact. The issue affected multiple providers including Beget and Selectel, was publicly acknowledged by Timeweb on June 5, and proved highly variable by region, operator, and time of day. Attempts to mitigate via new IP addresses or Timeweb's own CDN failed due to poisoned caches and platform outages, while Yandex Cloud CDN blocked all POST requests required for WordPress functionality. A working solution involved deploying a minimal nginx reverse proxy on another Russian cloud VPS that preserves full HTTP methods, handles certificate synchronization, and routes ACME challenges correctly. Timeweb support later closed tickets without resolution after requesting ineffective mtr traces that cannot detect DPI behavior. The case highlights systemic challenges in diagnosing state-mandated filtering and the limitations of standard network diagnostics against selective TLS interference.
UnifiedPush and Public ntfy.sh: Why Push Notifications Fail on Android Without Google Services
Developers building a messenger without Google services adopted UnifiedPush with the public ntfy.sh instance as the default distributor and push server. Production logs revealed that four out of five delivery attempts failed from day one, with error codes 507, 429, and 400 dominating. The 507 errors occurred because ntfy from Google Play relies on Firebase for instant delivery, leaving no active subscriber visible to the server when FCM is unavailable. Rate-limit 429 responses were triggered against the recipient's IP rather than the sender, collapsing under carrier-grade NAT used by mobile users. WebPush endpoints additionally rejected requests missing the mandatory TTL header. The team ultimately deployed a self-hosted ntfy instance and an embedded distributor inside the app to bypass these constraints.
Six Bitrix24 Disk Migration Errors That Force Portal Redesign After Six Months
A detailed analysis reveals that copying a legacy file share structure directly into Bitrix24 Disk creates persistent access control, ownership and performance problems that surface only after several quarters of operation. The article examines six specific mistakes including one-to-one folder replication, overuse of personal My Disk storage, assignment of rights to individual users instead of departments, dumping unclear documents into the common drive, attaching file copies rather than links to CRM and tasks, and enabling full desktop synchronization. Each error is illustrated with real symptoms, root causes from rushed migrations, and concrete remediation steps using REST and D7 API calls. A Toyota T-Connect case from 2013-2023 demonstrates how unmonitored open permissions can remain undetected for a decade. The guidance stresses pre-migration inventory, pilot testing on one department, named owners for every top-level section, and quarterly rights audits. The piece is aimed at integrators and IT leads who handle large Bitrix24 deployments.