Network Flow Analysis in Telecom Fraud: Six Methods to Trace Hidden Infrastructure
This article details six network flow analysis methods—timeline reconstruction, DNS/IP/TLS profiling, app behavior reconstruction, multi-case correlation, and scoring-based warning models—to help investigators trace fraud infrastructure beyond traditional person-card-money leads, emphasizing evidence compliance and analytical rigor.
1. Correct Understanding: Network Flow Is Not 'Universal Evidence' but an Investigative Lever
The greatest value of network flow analysis lies in discovering direction, expanding leads, and assisting case correlation. For example, when a victim claims they downloaded an "investment app" and communicated with "customer service," traditional inquiry only yields the app name, chat screenshots, and receiving accounts. Network flow can further reveal: which domains and IPs the victim's phone accessed during key periods; whether the app frequently connected to overseas cloud servers after launch; whether there were fixed heartbeats, device info uploads, configuration pulls, or customer service interface calls; whether the same domain or server appears in other cases; and whether the fraudulent app, URLs, fund accounts, and phone numbers form a closed loop.
However, network flow alone usually cannot prove "a specific person committed fraud." An IP, domain, or certificate fingerprint only indicates a communication relationship or infrastructure association. To build case support, it must be combined with fund flow, communication flow, account flow, device flow, electronic forensics, and personnel investigation. In short: network flow finds direction; the evidence system establishes facts.
2. Start with the Incident Timeline
Many analyses fail not because of tools but because the timeline is poorly constructed. Upon receiving a telecom fraud report, the first step is not to query IPs immediately but to reconstruct the victim's key time points: first contact with fraud info; click/download/login times; first transfer time; times when the fraudster requested screen sharing, remote control installation, bank card unbinding, or additional deposits; and whether the victim uninstalled the app, deleted chats, changed phones, or reset the network before reporting.
With these time points, querying network flow for the corresponding windows greatly improves accuracy. In practice, three windows can be defined: Contact window (around first click, scan, download); Transaction window (around transfers, deposits, withdrawal failures, induced additional funds); Disposal window (around reporting, payment stop, app uninstall). Many fraud apps generate distinct outbound connections at launch, login, deposit, withdrawal, and customer service communication. Without a timeline, massive traffic is noise; with it, leads become clear.
3. Method 1: Domain Name and DNS Analysis
Fraudulent sites and apps rely on domain resolution. DNS logs are highly practical in network flow analysis. Key aspects:
Whether the domain matches the claimed behavior. E.g., a victim claims a "securities investment platform" but the domain is unrelated to legitimate institutions, with crude naming, spelling anomalies, missing registration, or mismatched entity — raise alert.
Whether the domain changes frequently. Fraud groups prepare multiple backup domains to evade blocking; the same app may push different access addresses via a config interface. Analyze not just one domain but associated domains, subdomains, CNAMEs, and historical resolution IPs from the same period.
Whether the domain repeats across multiple cases. A domain in a single case is a lead; repeated appearance across cases significantly increases value. Especially when the same batch of domains appears in different regions, with different victims, and different fraud scripts, it often indicates a shared technical platform or black/gray industry service provider.
DNS has limitations: some apps hardcode IPs, use public cloud, CDN, or encrypted DNS. In such cases, DNS cannot stand alone; combine with connection records, certificate info, app samples, and fund leads.
4. Method 2: IP, Port, and Cloud Resource Profiling
IP analysis is common but prone to misjudgment. An IP appearing in victim traffic does not equal a fraud den — it could be a cloud server, CDN, proxy node, third-party API, or a legitimate service being abused. Therefore, IP analysis cannot rely solely on "overseas"; more important is its position in the case chain. Valuable phenomena include:
Multiple victims accessing the same batch of servers.
The same server simultaneously hosting login, deposit, customer service, config push, and other interfaces.
Server IPs matching domains and interface paths found in fraudulent app samples.
Servers changing resolution or migrating to adjacent address ranges or similar cloud resources within a short time.
The same batch of IPs repeatedly associated with the same fund accounts, customer service accounts, and script types.
Ports also provide reference. Common web ports are not necessarily suspicious; unconventional ports are not necessarily illegal. The key is whether access behavior matches the business scenario. For instance, an "investment app" maintaining a long-lived fixed heartbeat to an unknown server, then accessing another batch of interfaces during deposit/withdrawal, warrants deeper dissection.
5. Method 3: TLS Certificates, SNI, and Connection Characteristics
Most traffic is now HTTPS, reducing plaintext content. This shifts focus to metadata. TLS handshakes may expose certificates, SNI, protocol versions, cipher suites — though not always present and affected by encryption changes, they retain reference value in many cases.
Examples: multiple domains using the same certificate; certificate subject, issuance time, validity period close to the fraud site's launch time; different apps showing similar TLS fingerprints; the same device accessing a fixed SNI or fixed certificate service before/after key operations.
These suit "correlation analysis," not standalone determination. TLS fingerprints, certificate reuse, missing SNI, etc., can be influenced by client, CDN, proxy, encryption policies. Officers should phrase conclusions as "exhibits correlation characteristics" or "has further verification value," avoiding absolute judgments.
6. Method 4: App Behavior Flow Analysis
In fraud cases, apps are critical carriers. Network flow analysis must not only see which sites the victim visited but also reconstruct what the app did. Common network behaviors of a fraudulent app include:
Requesting configuration on first launch.
Uploading device model, OS version, network environment.
Accessing account interfaces during registration/login.
Accessing order interfaces during deposit/withdrawal.
Accessing instant messaging interfaces for customer service chat/tickets.
Risk control or remote control components connecting to external services.
Re-fetching addresses after abnormal exit or network switch.
These behaviors help judge the app's functional structure without knowing chat content. The "config interface" is especially important. Many fraud apps hide real service addresses in configs to quickly swap domains, customer service, or payment channels. Finding the config interface often leads to a batch of backend domains, backup servers, and homologous apps.
Practical approach: combine app sample analysis, network flow retrospective, and victim phone forensics. Traffic alone shows connections; with app samples, you know which function each connection serves; with victim statements and transfer records, you know at which fraud stage these functions occurred.
7. Method 5: Multi-Case Correlation to Find Shared Infrastructure
Anti-fraud analysis fears being stuck in single cases. Network flow's real power is multi-case collision. Abstract each case into element types:
Domains visited by victims.
Destination IPs and ports.
DNS resolution records.
TLS certificates and SNI.
App package names, signatures, download links.
Customer service accounts, group numbers, QR codes.
Receiving accounts, crypto addresses, payment channels.
Phone numbers, SMS links, landing pages.
Then check which elements repeat across cases. The more repetitions, the more cross-regional, the closer to key fraud actions, the higher the analytical value. Example: victims in three regions encounter "order brushing," "fake investment," and "impersonated customer service" scripts, but their apps connect to the same batch of config domains and backend IPs overlap. This suggests a shared technical platform or batch black/gray industry service behind different scripts.
This method serves "cutting chains, pulling nails, stopping flows": from a single victim to the tech service provider; from a single domain to the entire infrastructure; from a single app to the mass production and distribution chain.
8. Method 6: Precision Over Volume in Warning Models
Network flow can be used for early warning, but must avoid "alert flooding." A good fraud warning model should not rely solely on blacklists. Blacklists help quick blocking but lag due to rapid resource changes. A more robust approach is multi-dimensional scoring:
Whether it appears in reported samples.
Whether it has interface association with known fraudulent apps.
Whether multiple victims accessed it during key periods.
Whether it is close to abnormal fund behavior.
Whether it exhibits short-term batch switching, batch resolution, batch access patterns.
Whether legitimate business, CDN, public services can be excluded to reduce false positives.
Whitelists and manual review are mandatory. In policing, false positives are serious: misjudging normal enterprises/users as fraudulent resources damages credibility and increases grassroots workload.
9. Basic Workflow for Network Flow Analysis
Officers can follow this process:
Fix incident information: record victim statements, transfer times, chat screenshots, download links, app names, phone models, carriers, network environment.
Determine time windows: around clicks, downloads, logins, transfers, withdrawal failures, reporting.
Extract network elements: domains, IPs, ports, protocols, connection duration, traffic volume, DNS, TLS, HTTP access records, NAT mappings.
Behavior reconstruction: judge which connections relate to fraud actions vs. system updates, ads, normal app traffic.
Correlation collision: cross-reference with local historical cases, higher-level leads, carrier data, internet company feedback, fund accounts, app samples.
Form layered conclusions: separate established facts, suspected associations, leads pending verification — do not mix.
Drive disposal closure: timely warning where possible, coordinate payment stop, legally push blocking to industry regulators or enterprises for verification, escalate leads to special task forces.
10. Common Pitfalls
Equating IP with suspect. IP only shows network access relationship, especially under NAT, proxy, cloud, CDN — must combine with logs, accounts, devices, funds.
Relying only on blacklists, ignoring context. Blacklists suit quick interception, not complete analysis. Whether a domain is fraudulent depends on its behavioral position in the case.
Ignoring time synchronization. Phone time, system log time, server time, carrier log time may differ. Wrong timeline leads to wrong correlation.
Overstating conclusions in reports. Technical analysis must keep boundaries: clearly state what can and cannot be proven. Otherwise, later forensics and prosecution stages face challenges.
Prioritizing technology over procedure. Network flow data involves personal info and electronic data; must be collected, extracted, stored, used lawfully. Unclear source, non-standard process, unprovable integrity — even the best technical lead may be inadmissible.
11. Compliance and Evidence Awareness Must Come First
The Anti-Telecom Fraud Law mandates comprehensive governance across telecom, finance, internet sectors. The Personal Information Protection Law, Data Security Law, Cybersecurity Law also impose requirements on data processing, security, and personal info protection.
For police work, special attention to electronic data authenticity, integrity, legality. Regulations require standardized collection, extraction, examination of electronic data. For network flow logs to enter the evidence system, at minimum ensure:
Legal data source.
Complete acquisition procedures.
Extraction scope relevant to the case.
Original logs retained.
Record of extraction time, personnel, tools, process.
Integrity verification.
Ability to explain field meanings and analysis methods.
Conclusions corroborated by other evidence.
This is why network flow analysis cannot pursue only "speed." Speed serves early warning and loss prevention; stability serves conviction. Both are needed.
Conclusion
Telecom fraud is not a single-point crime but an industrialized crime weaving information, technology, fund, and personnel chains. Network flow analysis does not replace police work; it helps officers see the invisible network chains clearly.
Reliable network flow analysis relies not on mysterious algorithms or a phrase "system determined." It relies on clear timelines, standardized data sources, solid correlation analysis, cautious conclusion expression, and cross-verification with fund, communication, account, device, and personnel leads.
For grassroots officers, mastering this methodology solves at least three problems: faster identification of fraudulent network entry points, more accurate discovery of cross-case associations, and more stable support for subsequent crackdown and governance.
Technology changes, fraud tactics change, but the basic principles of analysis remain: start from the incident, let data speak, close the loop with evidence.
References
Anti-Telecom Network Fraud Law of the PRC — https://www.npc.gov.cn/c2/c30834/202209/t20220902_319186.html
Cybersecurity Law of the PRC — https://www.cac.gov.cn/2025-12/29/c_1768735112911946.htm
Personal Information Protection Law of the PRC — https://www.npc.gov.cn/npc/c2/c30834/202108/t20210820_313088.html
Data Security Law of the PRC — https://www.npc.gov.cn/npc/c2/c30834/202106/t20210610_311888.html
SPP: Provisions on Several Issues Concerning the Collection, Extraction, and Examination of Electronic Data in Criminal Cases — https://www.spp.gov.cn/zdgz/201609/t20160921_167425.shtml
2025 Anti-Telecom Fraud Publicity Manual (MPS Criminal Investigation Bureau & National Anti-Fraud Center) — https://www.gov.cn/lianbo/bumen/202506/content_7028568.htm
MIIT: Information and Communication Industry Anti-Fraud Work Promotion Meeting — https://www.miit.gov.cn/xwfb/bldhd/art/2025/art_37e5ce0fe70845c68350f80b23268649.html
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Frontline Investigation
Daily curates a variety of tech resources, tools, tips, and news (5G, big data, cloud computing, AI), aiming to become a go-to popular science encyclopedia for everyone.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
