Forged Information Detection and Anti-Fraud: A Practical Guide for Enterprises

Recently, news that an AI model would be opened to a specific region spread quickly online, accompanied by polished promotional posters and fake screenshots. These materials were forwarded rapidly in group chats, and some developers briefly believed them to be genuine. Forged screenshots and fake pages are not new. More than two decades ago, someone forged a well-known technology media outlet’s page reporting an acquisition, complete with citations and notes, and published it half an hour before trading began. Investors had almost no time to verify it, and the relevant company’s stock rose sharply in a short period.

1. How to Identify Forged Screenshots and Fake Pages

The core method behind forged information has not changed: exploit information asymmetry and time gaps to create a highly credible illusion. Understanding several common techniques can help teams determine which points require stronger defenses.

1.1 Page Content Directly Rewritten

Attackers can modify text nodes on a real web page in the browser. The page address, layout, and buttons remain normal, so the screenshot looks authentic. This type of forgery targets human visual judgment. Looking only at the address bar and page appearance is not enough to confirm that the content is trustworthy.

1.2 Screenshots Generated or Composited by Tools

With image editing or generative models, attackers can place false text into templates based on real screenshots and imitate font rendering, shadows, and interface components. Output from generative models is increasingly close to real screenshots and is difficult to distinguish with the naked eye. Therefore, a screenshot itself cannot be used as evidence.

1.3 Using Time Gaps to Create a Faits Accompli

Forged content often appears at critical moments, such as before market open, on the eve of a launch event, or around holidays. People’s verification speed often cannot keep up with emotion-driven forwarding and trading. Teams should set a fixed verification window for major information and must not act immediately simply because the information appears urgent.

2. How to Design a Layered Verification Architecture

A single control is unlikely to stop forgery. A more reliable approach is to distribute verification across three layers—source, content, and network—with each layer taking on part of the risk.

2.1 Digitally Sign Critical Announcements

For important announcements, the publisher should use a private key to generate a digital signature over the content, and the recipient should verify it with a preconfigured public key. When implementing this, teams should note the following. The signing algorithm and hash algorithm should be standardized, and it should be clear whether the signed object is the original text, a file, or structured data. The private key should be stored in a hardware security module or key management service and must not be written into code or logs. The public key should be distributed through trusted channels, and the certificate chain should be verified. Each message should carry a timestamp and a unique identifier so that the recipient can reject expired and replayed messages. The signature verification logic is only an illustrative approach and cannot be deployed directly; key and certificate design must be completed before formal implementation.

2.2 Establish Content Review and Anomaly Monitoring Processes

Teams can use cloud services such as content moderation, log analysis, and threat intelligence to collect external news, screenshots, and posts involving the company, then perform entity recognition and sentiment analysis and compare the results with internal databases. When high-risk terms such as “acquisition” or “free access” appear together in content involving the company, an alert should be triggered and sent to the security team for review.

Image recognition can provide clues, such as detecting abnormal text edges or sudden local color changes. However, such results have false positives and false negatives and can only serve as supporting evidence. A determination must combine the original source, digital signatures, metadata, and manual review; image recognition results must not be treated as the sole basis.

2.3 Block Impersonation at the Domain and Network Layers

Impersonating domains often use similar-character substitutions, such as replacing the letter l with the number 1. Protection should be deployed in layers, because a single device cannot cover every point.

• DNS layer: Deploy DNS filtering and threat intelligence to block resolution requests for known impersonating domains. Configure secure DNS policies for employee devices and control DoH (DNS over HTTPS) egress to prevent employees from bypassing corporate DNS policies.
• Application layer (WAF): A WAF is deployed in front of the company’s own web applications to block impersonating access and malicious requests reaching those applications. It cannot block resolution requests on external sites used by employees; this boundary should be stated explicitly in the plan.
• Endpoints and browsers: For important news websites, check whether the certificate is valid and whether the issuer and domain match. Certificate validation can only confirm the identity of the connected party, not whether the page content is真实.

3. Enterprise Implementation Checklist

The following steps can help teams put the above approach into practice. Each item should have an assigned owner.

• Source verification: Confirm that major announcements carry valid signatures and that the certificate chain can be traced to a trusted root. Owner: security team.
• Timestamp and anti-replay: Check whether the message timestamp is within the valid window and whether the identifier is duplicated. Owner: system development team.
• DNS and certificate validation: Confirm that the domains and certificates of important websites accessed by employees match, and that DNS filtering policies are in effect. Owner: network operations team.
• Multi-source cross-validation: Confirm major information through the official app, trusted dedicated lines, or callback calls. Owner: business lead.
• Alert handling: Anomaly alerts must be assigned to manual reviewers within the agreed time limit, and conclusions must be recorded. Owner: security on-call staff.
• Post-incident review and archiving: For each confirmed forgery incident, record the propagation path, causes of misjudgment, and improvement measures. Owner: security lead.

4. What Developers and Employees Should Do

When integrating external information, developers should treat data sources as untrusted by default. External content that has not been signed or verified should not be written directly into core business databases. Input validation should be performed at interfaces, and external data should be marked as unverified until it passes the verification process.

Employee training is equally important. Training can help employees practice identifying page addresses, publication times, information sources, and evidence chains, and clarify which channels can be used for verification. When employees encounter screenshots involving major interests, they should first confirm through official channels before deciding whether to forward them or act on them.

5. The Rhythm of Long-Term Governance

Governance of forged information requires sustained investment. Technical controls are responsible for detecting anomalies, blocking propagation, and preserving evidence; organizational processes are responsible for clarifying who verifies, within what time limit, and how to improve after errors. Both are indispensable. Teams can start with signed announcements and multi-source verification, then gradually add review monitoring and network protection, and conduct regular reviews to steadily improve their ability to identify forged information.