Coder Legion - Recent posts tagged fraud

There is no such thing as a digital arrest

Fri, 30 Oct 2026 19:55:59 +0000

Originally published on the Dunime blog.

How the video-call script works, why it keeps working, and the free government channels that report it.

“You are under digital arrest. Stay on video. Don't tell anyone.” Every line of that script is a tell, and none of it is how Indian law enforcement works.

How the script runs

It usually starts with a call about a parcel, a SIM card or a bank account linked to a crime. The caller transfers the victim to someone presenting as police, a central agency or customs, on a video call with a uniform, an office backdrop and official-looking documents.

The victim is told they are under “digital arrest”, must stay on camera, must not tell family, and must move money to a “verification” or “safe” account to clear their name. Calls can run for hours or days.

Why it keeps working

Authority �orrowed from real agencies, with real-looking names and seals.
Fear of arrest, of a case against a child, of public shame.
Isolation. “Don't tell anyone” is not procedure. It removes the second opinion that would end the fraud in a minute.
Time pressure that leaves no room to check anything.

The uniform is a prop. The isolation is the attack.

The official position

In October 2024 the Indian Cyber Crime Coordination Centre (I4C), under the Ministry of Home Affairs, issued a public advisory stating that the CBI, police, customs, ED and judges do not arrest anyone on a video call, and asked people to report such calls to 1930 or cybercrime.gov.in.

What to do during the call

Hang up. Do not stay on video, share your screen or install any app the caller asks for.
Verify independently. Call the agency on a number you look up yourself, never one the caller gives you.
Tell someone. One family member hearing the story usually ends it.
Never transfer money to “verify” an account or “clear your name”. No agency asks for this.

How to report it

If money has moved, call 1930 or file at cybercrime.gov.in at once and inform your bank; the sooner a report is made, the better the chance of the money being held.

Report the number even if you lost nothing. Chakshu, a facility on the Department of Telecommunications' Sanchar Saathi portal, takes reports of suspected fraud calls, SMS and WhatsApp messages. In February 2026 the government told the Rajya Sabha that 39.43 lakh mobile connections had been disconnected after analysis of citizen reports.

For organisations

Finance teams, senior staff and employees' families are all targets. A two-line rule in onboarding and awareness sessions, that no agency arrests anyone over video and no payment ever clears a case, does more than any tool.

Questions people ask

Is digital arrest legal in India? No. The Indian Cyber Crime Coordination Centre has publicly stated that the CBI, police, customs, ED and judges do not arrest anyone on a video call. A 'digital arrest' is a fraud.

Where do I report a digital arrest call? Call the national cybercrime helpline 1930 or file a complaint at cybercrime.gov.in. Suspected fraud calls and messages can also be reported through Chakshu on the Sanchar Saathi portal, even if no money was lost.

What is Chakshu? Chakshu is a facility on the Department of Telecommunications' Sanchar Saathi portal for reporting suspected fraud calls, SMS and WhatsApp messages. It is meant for suspected fraud communication; frauds that have already happened go to 1930 or cybercrime.gov.in.

Sources

This guide is part of Dunime's fraud-help hub — also in हिन्दी, বাংলা, मराठी, తెలుగు and தமிழ், each with a short video: dunime.com/protect.

Worried a phone was compromised during a scam call? Dunime's Yantrix checks Android and iPhone devices for spyware and remote-access implants.

Published by Dunime Technologies — custom software, automation and cybersecurity, Delhi NCR, India.

The Deepfake That Signed Off on $25 Million: A Teardown of the Arup CFO Video-Call Heist (Feb 2024)

Thu, 29 Oct 2026 07:45:39 +0000

Originally published at vibeagentmaking.com.

In January 2024 an Arup employee in Hong Kong made 15 transfers totalling HK$200 million after a video call on which every other participant was a pre-recorded deepfake. The rules of wire transfers decided in 1989 that recognizing a signature is not by itself a security procedure, and the one check that exposed the fraud came after the money had moved.

In January 2024, an employee in the finance department of Arup's Hong Kong office joined a video conference. The engineering firm's chief financial officer, who works from the United Kingdom, appeared on the call, and so did other colleagues the employee recognized. Over the following week the employee made 15 transfers totalling HK$200 million, about US$25.6 million, to five bank accounts.

"(In the) multi-person video conference, it turns out that everyone [he saw] was fake," Acting Senior Superintendent Baron Chan Shun-ching of the Hong Kong police told the public broadcaster RTHK when the force described the case. Every face and every voice on the call was synthetic except the victim's own.

The date in the headline is when the world heard about it. The money moved in January. The police made the case public at a briefing on Friday, February 2, without naming the company, and Arup confirmed it was the victim on May 17, after the Financial Times reported it. Arup is a large and sophisticated firm, with 18,500 employees in 34 offices, and it worked on the Sydney Opera House and designed Beijing's Bird's Nest stadium. That is part of why the case is worth taking apart slowly.

The artifact, in order

The public record for this incident is thin, and nearly all of it comes from two places: the Hong Kong police, who described the case in February 2024, and Arup, which confirmed it in May 2024 and talked about it in 2025. Read in order, their accounts give a sequence of five steps.

First, a message. In mid-January the employee received what the South China Morning Post, citing police, called "a phishing message ... that appeared to be from the company's CFO based in the United Kingdom saying a secret transaction had to be carried out." The employee's first read of it was correct. According to Chan, the worker initially "suspected it was a phishing email, as it talked of the need for a secret transaction to be carried out."

Second, the meeting. The fraudsters answered that doubt with a video conference. Police told AFP that the employee received "video conference calls from someone posing as senior officers of the company requesting to transfer money to designated bank accounts." Chan said the call had several participants and that all of them except the victim were impersonated, and he said where the material came from: "Scammers found publicly available video and audio of the impersonation targets via YouTube, then used deepfake technology to emulate their voices." Then he added the detail that most later retellings drop. As AFP reported it, "the deepfake videos were pre-recorded and did not involve dialogue or interaction with the victim." The meeting was a playback. Nobody on it had to answer a question.

It worked anyway. Chan said the worker "put aside his early doubts after the video call because other people in attendance had looked and sounded just like colleagues he recognized." That sentence is the whole attack. A person's judgment had caught the phishing message. The meeting existed to overrule that judgment, and it did.

Third, the payments: "15 transfers totalling HK$200 million to five bank accounts over a week in January," as the Post summarized the police account in May.

Fourth, the discovery. CNN's February report gives it one line: "The scam involving the fake CFO was only discovered when the employee later checked with the corporation's head office." Police received the report on January 29, AFP said, "at which point some HK$200 million (US$26 million) had already been lost via 15 transfers."

Fifth, what was not touched. Arup's statement in May: "Our financial stability and business operations were not affected and none of our internal systems were compromised." Its global chief information officer, Rob Greig, later called the incident "technology-enhanced social engineering" and said: "It wasn't even a cyberattack in the purest sense. None of our systems were compromised and there was no data affected."

What the record does not say

None of these sources says anything about Arup's payment controls. It does not say who else, if anyone, approved the 15 transfers, what limits applied, whether payments to new accounts were held, or whether a callback rule existed and was skipped. Arup's spokesperson told CNN in May that the company could not "go into details at this stage as the incident is still the subject of an ongoing investigation." When police briefed AFP in February they said "no arrest has been made so far," and I found no later report of an arrest or of the money being recovered.

The retellings have filled the gap anyway. The AI Incident Database notes in its entry that the case "has become a recurring reference for reports on AI-powered scams," and that "its emergence as a shorthand in journalism is worthy of note in and of itself." Shorthand collects detail as it travels. A 2026 VentureBeat retrospective puts the call on Zoom, says the first wire transfer "took minutes," and states that there was "No second approver, no out-of-band confirmation, no system-enforced hold." None of those details appears in the police statements or in Arup's. The database's editors observe that it is cited "particularly when discussing the dangers of deepfake technology in real-time video conferencing," while the police described clips that were recorded in advance.

So a teardown has to work the way an engineer works an incident that left no logs: from the outcome back to the controls that would have stopped it, saying at each step which part is inference.

A rule written in 1989

Money movement stopped trusting recognition a long time ago, and the rule is written down. Article 4A of the Uniform Commercial Code, the American law of wire transfers, was approved in 1989. Its definition of a "security procedure" lists what can count as one: "algorithms or other codes, identifying words or numbers, encryption, callback procedures, or similar security devices." Then it adds a sentence that reads, thirty-five years on, as if it were written about Arup: "Comparison of a signature on a payment order or communication with an authorized specimen signature of the customer is not by itself a security procedure."

A signature check is recognition. You hold the thing in front of you against what you know the real one looks like. The drafters did not call that useless. They said it could not stand alone, and the reason is not hard to see: a good enough forgery passes a comparison by definition. A face on a video call is a signature that moves.

Article 4A is American law and did not govern transfers out of Hong Kong. I cite it for what the people who wrote the rules of wire transfers decided about recognition, and the same thinking runs through the checklists bank examiners work from. The examiner's guide of the National Credit Union Administration, the US regulator for credit unions, tells examiners to "ensure credit union controls address adequate separation of duties between initiators, approvers, and reconcilers," to check funds-transfer agreements for "telephone call-back requirements," and to look for "dual-control verification." The first of the FBI's prevention tips for business email compromise is one line: "Use secondary channels and/or two-factor authentication to verify requests for changes in account information."

That family is not small. The FBI's Internet Crime Complaint Center counted 305,033 business email compromise incidents, domestic and international, between October 2013 and December 2023, with $55,499,915,582 in exposed losses. In its 2023 data, "international banks located in the United Kingdom and Hong Kong often acted as an intermediary stop for funds." The Arup case is the video-call version of a fraud the payments world has been fighting for a decade, in one of the places where that fraud's money habitually passes through.

What these controls share is that they do not care how convincing the request was. A callback goes to a number the firm already had on file, so it reaches the real chief financial officer however good the fake one looked. A second approver who has to confirm through a separate channel adds a person the fraudsters must also fool, on a line they do not control. The control's strength does not depend on the attack's weakness. That is the design principle, and it is why the quality of the deepfake, which is where most of the coverage looked, is the least important variable in the case.

The gates, reverse-engineered

With that template, the outcome narrows down which gates were missing or ineffective, even though the record never names them. What follows is inference, and I will say where.

An out-of-band confirmation before the first transfer. This is the gate we can be surest about, because the case contains its test. When the employee checked with head office, the fraud collapsed on contact. The confirmation that would have stopped all 15 transfers did take place. It took place after them. Either no rule required that check before money moved, or the rule could be satisfied through a channel the fraudsters controlled, such as a reply to their own message or another call they set up. The record does not say which.

An independent second approver. The record does not say whether anyone else signed off. If someone did, they signed off on the same evidence, the call, which means the second approval was not independent. What makes dual control work is the second channel as much as the second person. Two people who watched the same video are one control.

A hold on new payees and a limit on velocity. Five accounts received 15 transfers in about a week. The examiner's guide tells examiners to review "typical daily transaction volume," because "unusual transaction amounts or volumes may reflect fraudulent/erroneous activity or weak controls." Whether Arup's systems had holds or limits of that kind, and what they were set to, is not public.

And the one gate that clearly did fire was the human one. The employee spotted the first message as phishing. Everything after that was the attackers' answer to a control that worked.

Why the fake was cheap

The attackers did not need anything Arup protected. Chan said they built the participants from "publicly available video and audio of the impersonation targets via YouTube." A firm whose leaders speak at conferences and appear in the media has, without meaning to, published the training data for its own impersonation. The more visible its people are, the cheaper they are to copy, and that exposure grows with the communications budget, not the IT budget.

Nor did they need the newest technology. Pre-recorded clips were enough. Greig, interviewed by the World Economic Forum a year later, put it plainly: "It's freely available to someone with very little technical skill to copy a voice, image or even a video." Then he tried the harder version himself. "After the incident, I was curious so I attempted to make a deepfake video of myself in real time. It took me, with some open source software, about 45 minutes." He was candid about the result: "It wasn't particularly convincing." The attack on his firm never had to be convincing in real time. It only had to hold up through a meeting in which nobody asked it anything.

Recognition by machine had fared no better. At the same February briefing, police described a separate scheme from the previous July to September, in which eight stolen identity cards had been used for 90 loan applications and 54 bank account registrations, and in which, on at least 20 occasions, "AI deepfakes had been used to trick facial recognition programs by imitating the people pictured on the identity cards." Human eyes and automated face matching fell to the same trick in the same city, a few months apart.

Move the last line to the top

The February account turns on one late moment: the employee checks with head office, and the fraud falls apart. That check is the control. It costs almost nothing and depends on nobody's eyes, and when it was finally used it worked at once. In the Arup sequence it came last, once the message had been read, the meeting held and all 15 transfers made.

The practical version is short enough to fit on a card. Wherever a person can approve an irreversible action because they recognize who is asking, by face, by voice or by writing style, put a confirmation in front of it that runs through a channel set up before the request arrived. A number already on file will do. So will a second approver who must reach the requester independently, or a code agreed in advance. Then have the system enforce the order, so the check comes before the money moves. None of this requires detecting the deepfake. It is built so that it never has to.

In the sentence of CNN's February report that describes the fraud being caught, the word to change is "later."

Sources:

Heather Chen and Kathleen Magramo, "Finance worker pays out $25 million after video call with deepfake 'chief financial officer'," CNN, February 4, 2024. https://www.cnn.com/2024/02/04/asia/deepfake-cfo-scam-hong-kong-intl-hnk/index.html
AFP, "Multinational loses HK$200 million to deepfake video conference scam, Hong Kong police say," Hong Kong Free Press, February 5, 2024. https://hongkongfp.com/2024/02/05/multinational-loses-hk200-million-to-deepfake-video-conference-scam-hong-kong-police-say/
Harvey Kong, "'Everyone looked real': multinational firm's Hong Kong office loses HK$200 million after scammers stage deepfake video meeting," South China Morning Post, February 4, 2024. https://www.scmp.com/news/hong-kong/law-and-crime/article/3250851/everyone-looked-real-multinational-firms-hong-kong-office-loses-hk200-million-after-scammers-stage
Lo Hoi-ying, "UK multinational Arup confirmed as victim of HK$200 million deepfake scam that used digital version of CFO to dupe Hong Kong employee," South China Morning Post, May 17, 2024. https://www.scmp.com/news/hong-kong/law-and-crime/article/3263151/uk-multinational-arup-confirmed-victim-hk200-million-deepfake-scam-used-digital-version-cfo-dupe
Kathleen Magramo, "British engineering giant Arup revealed as $25 million deepfake scam victim," CNN, May 17, 2024. https://www.cnn.com/2024/05/16/tech/arup-deepfake-scam-loss-hong-kong-intl-hnk
"Arup victim of multimillion-dollar deepfake video scam in Hong Kong," Dezeen, May 17, 2024. https://www.dezeen.com/2024/05/17/arup-victim-deepfake-video-scam/
"'This happens more frequently than people realize': Arup chief on the lessons learned from a $25m deepfake crime," interview with Rob Greig, World Economic Forum, February 4, 2025. https://www.weforum.org/stories/2025/02/deepfake-ai-cybercrime-arup/
Uniform Commercial Code § 4A-201, "Security Procedure," as published by the Legal Information Institute, Cornell Law School, and in the Federal Reserve's Regulation J materials. https://www.law.cornell.edu/ucc/4A/4A-201 and https://www.federalreserve.gov/frrs/regulations/uniform-commercial-code-article-4a-funds-transfers.htm
Uniform Law Commission, "UCC Article 4A, Funds Transfers (1989)." https://www.uniformlaws.org/viewdocument/enactment-kit-54?CommunityKey=2985cf6d-9c22-4abe-abf1-1f36f8a27201&tab=librarydocuments
National Credit Union Administration, Examiner's Guide, "Wire Transfer Review Procedures." https://publishedguides.ncua.gov/examiner/Content/ExaminersGuide/ElectronicPaymentSystems/ExamProcedures/WireTransfer2-Review.htm
FBI Internet Crime Complaint Center, PSA I-091124-PSA, "Business Email Compromise: The $55 Billion Scam," September 11, 2024, "Statistical Data" and the prevention tips. https://www.ic3.gov/PSA/2024/PSA240911
AI Incident Database, Incident 634, editor's note. https://incidentdatabase.ai/cite/634/
Louis Columbus, "The $25.6 million deepfake that human review, MFA and liveness detection all missed," VentureBeat, May 21, 2026, cited here for how the case has been retold. https://venturebeat.com/security/25-million-deepfake-that-human-review-mfa-and-liveness-detection-all-missed

Confirm through a channel the request did not arrive on.

The control that would have stopped this fraud did not have to detect the deepfake. It only had to happen before

    the money moved, through a channel set up in advance. The same rule applies when software agents can initiate
    payments or other actions that cannot be undone: the order of request, confirmation and execution should be
    enforced, and afterwards it should be checkable. Chain of Consciousness keeps a tamper-evident record of an
    agent's actions, so that order can be verified later by someone who was not there.

pip install chain-of-consciousness
npm install chain-of-consciousness

Or start without installing anything: Hosted Chain of Consciousness.

Building Fraud-Resistant User Onboarding With KYC and Authentication

Tue, 21 Jul 2026 08:04:26 +0000

User onboarding is one of the easiest places for fraud to enter a business. It is fast, automated, and built to reduce friction, which also makes it attractive to bad actors. Fake identities, stolen credentials, bot signups, and account takeovers can all begin here if the system is too loose.

At the same time, heavy checks can push away legitimate users. The real goal is balance. Businesses need onboarding flows that feel smooth for real users and hard to exploit for fraudsters.

This balance comes from combining identity verification, authentication, risk scoring, and review processes in the right order. In this guide, you will learn practical ways to build fraud-resistant user onboarding with KYC and authentication.

1. Start with better identity data, not just more identity questions

Many onboarding flows fail because they treat verification as a form problem. They keep adding fields, extra screens, and manual reviews, yet still miss obvious risk.

Preventing fraud during onboarding depends on accurate user data and strong authentication systems. Using KYC Data marketing datasets can support better verification decisions, alongside secure login and identity management practices. Strong data helps teams spot mismatched identities, suspicious patterns, and incomplete records, which means the process becomes more precise instead of simply becoming longer for everyone.

2. Use risk-based onboarding instead of one fixed flow for every user

Not every applicant presents the same level of risk, so they should not face the same onboarding path. A low-risk user with consistent device, location, and identity signals may only need basic checks.

A higher-risk user should face stronger verification before account creation or access approval. Risk-based onboarding reduces friction where it is unnecessary and adds controls where they matter most. A solid risk model often considers:

Device reputation and browser behavior
IP quality, geolocation, and network anomalies
Identity mismatches across submitted data points

This approach makes fraud controls feel more targeted, and that usually improves both security and conversion.

3. Verify identity in layers

Fraud-resistant onboarding works best when identity is tested through multiple signals that support each other. A name and email address alone are not enough. Neither is a single document upload. Stronger onboarding compares user-submitted information against other signals, then looks for consistency across the full session. When these signals align, confidence rises. When they conflict, the system should slow down or escalate the case.

This layered approach may include document verification, selfie matching, phone validation, email reputation, and behavioral checks. It is about avoiding decisions based on one signal that can be spoofed.

4. Build authentication into onboarding

Authentication should begin during onboarding, not weeks later after fraud has already settled into the system. If the first login experience is weak, the account may pass KYC but remain vulnerable to account takeover, credential stuffing, or synthetic identity abuse. Secure onboarding connects identity proofing with login controls from the start.

This means setting password standards, checking breached credentials, enforcing secure session handling, and enabling multifactor authentication where it fits the risk level. A verified identity without protected access is incomplete. Businesses need both. When identity checks and authentication systems reinforce each other, fraud becomes much harder to scale.

5. Pay attention to behavior during the actual signup session

Fraud can show up in how a user moves through onboarding, not just in what they submit. Bots often move too quickly, and fraud rings repeat the same flow over and over. Synthetic identities may produce patterns that feel complete but behaviorally unnatural. This is why session behavior matters. It gives teams another way to separate real customers from automated abuse or coordinated attacks. Signs worth watching include:

Rushed completion times
Repeated correction loops
Copy-paste behavior in sensitive fields
Multiple attempts from the same environment.

These should not automatically cause rejection, but they should influence the risk score and trigger stronger verification when needed.

6. Reduce manual review by defining clear escalation rules

Manual review is expensive, slow, and often inconsistent when teams do not have clear decision rules. Fraud-resistant onboarding should reserve human review for cases that are genuinely unclear or high-impact. Everything else should move through a structured decision framework. This keeps the queue smaller and helps analysts focus on the cases where judgment matters most.

Good escalation rules define what triggers a pause, what allows automatic approval, and what creates an immediate decline. They should also explain how KYC results, authentication failures, device signals, and session behavior interact. A review team performs better when the system already organizes risk instead of dropping every uncertain case into one pile.

7. Protect the onboarding flow from abuse at the system level

Fraud is not only about fake identities. It is also about process abuse. Attackers test forms, automate retries, rotate IPs, and look for weak points in registration, password setup, or verification handoffs. This means the onboarding system itself needs protection, not just the applicant record. Strong defensive controls often include:

Rate limits on registration and verification attempts
Bot detection on forms and login steps
Alerting for unusual spikes in failed onboarding events

These controls help teams spot organized abuse earlier. They also prevent fraudsters from learning the system through repetition. When attackers cannot test the same path hundreds of times, their efficiency drops fast, and that creates room for real users to move through safely.

8. Review performance often, because fraud patterns keep changing

No fraud program stays effective forever without adjustment. Attack methods evolve, user behavior shifts, and traffic sources change. A process that worked six months ago may now be blocking too many good users or missing a pattern that has become common. This is why onboarding needs regular tuning, with fraud, security, and growth teams looking at the same signals.

Key questions include where legitimate users abandon the flow, which checks catch the most meaningful risk, and which controls create effort without improving outcomes. The best onboarding systems keep learning. They improve through review, measurement, and steady changes that strengthen protection without turning signup into a burden.

Endnote

The strongest onboarding systems do not rely on one tool, one document, or one login step. They combine accurate data, layered identity checks, secure authentication, and clear risk decisions into one process. This is what makes fraud harder to enter and easier to detect early. When businesses build onboarding this way, they do more than reduce fraud losses. They create a safer first experience for legitimate users as well.

Binary PDF Modification Detection: How It Works and Where It Fails

Wed, 27 May 2026 08:26:25 +0000

The question sounds simple: has this PDF been edited after it was originally created? The answer, it turns out, requires understanding how PDF files store their history at the byte level.

This article explains the technical approach behind binary PDF modification detection — what signals we look for, why they are reliable, and critically, where the method breaks down. If you want a quick answer without the technical detail, HTPBE.tech is an online tool that tells you whether a PDF has been edited (yes/no) in seconds. If you want to understand how that answer is produced, read on.

How a PDF File Is Structured

Before discussing detection, you need to understand the PDF file format at a structural level.

A PDF file consists of four components:

Header — declares the PDF version (%PDF-1.7)
Body — a collection of numbered objects (pages, fonts, images, metadata)
Cross-reference table (xref) — an index mapping object numbers to byte offsets
Trailer — points to the xref table and the document root object

A minimal trailer looks like this:

trailer
<<
  /Size 42
  /Root 1 0 R
  /Info 2 0 R
>>
startxref
9876
%%EOF

The /Info entry points to the document information dictionary — this is where metadata lives.

The Metadata Dictionary

The PDF Information Dictionary (/Info) contains fields that describe the document’s origin and history:

Field	Meaning
`/CreationDate`	When the document was originally created
`/ModDate`	When the document was last modified
`/Creator`	Application that created the source document (e.g., Microsoft Word)
`/Producer`	PDF library or printer that generated the PDF (e.g., macOS Quartz PDFContext)
`/Author`	Document author
`/Title`	Document title

Dates are encoded in a specific format:

D:20231015143022+03'00'

This means: 2023-10-15 at 14:30:22, UTC+3. The timezone offset is significant — we will come back to it.

The Creator/Producer distinction matters enormously. When someone writes a document in Microsoft Word and exports it to PDF:

Creator = Microsoft Word
Producer = Microsoft Word (or a Word-internal PDF engine)

When someone then opens that PDF in Adobe Acrobat and edits it:

Creator stays as Microsoft Word (preserved from original)
Producer changes to Adobe Acrobat 23.0 (the tool that wrote the new version)

This mismatch is a strong signal of modification.

The Incremental Save Mechanism

This is the core of PDF modification detection, and it is what makes PDFs fundamentally different from most other file formats.

When you edit a PDF and save it, most PDF editors do not rewrite the entire file. Instead, they append changes to the end:

The original file body is left intact
New or modified objects are appended after %%EOF
A new cross-reference table is appended, containing entries for the changed objects
A new trailer is appended with a /Prev field pointing to the byte offset of the previous xref table

[original body]
%%EOF
[new objects]
xref
[new xref entries]
trailer
<<
  /Size 55
  /Root 1 0 R
  /Prev 9876          ← points to original xref
>>
startxref
14523
%%EOF

This incremental update mechanism exists for good reasons: it enables fast partial saves, supports undo history, and is required for certain digital signature workflows. But it also leaves a clear paper trail.

A PDF with multiple %%EOF markers, multiple xref sections, or a trailer with /Prev has been saved more than once. This does not automatically mean fraud — legitimate workflows involve multiple saves. But it is a definitive indicator that the file was modified after initial creation.

What Automated Detection Actually Examines

A detection tool like HTPBE examines several independent signals and combines them into a confidence score.

1. Timestamp Consistency

The simplest check: is ModDate later than CreationDate? If yes, the file was modified. But there are subtleties:

ModDate == CreationDate does not mean the file was never edited. Some editors reset ModDate to match CreationDate to hide modifications.
ModDate earlier than CreationDate is impossible under normal conditions and indicates tampering with metadata.
Timezone changes between CreationDate and ModDate (e.g., creation in +03'00' but modification in Z) suggest the file was modified on a different machine or with a different tool.

2. Cross-Reference Table Analysis

Counting xref sections reveals the number of save operations:

1 xref section: the file was saved exactly once — typical for freshly exported PDFs
2+ xref sections: the file was modified at least once after initial creation
3+ xref sections: multiple rounds of editing

The content of the xref updates also matters. If the updated objects include the /Info dictionary (metadata), it suggests metadata was modified after the fact.

3. Creator/Producer Mismatch Analysis

We maintain a knowledge base of known PDF creation tool combinations. Some mismatches are routine:

Creator: Word + Producer: Adobe PDF Printer — normal, Word printed to PDF
Creator: Google Docs + Producer: Skia/PDF — normal Google Docs export

Some mismatches are suspicious:

Creator: Microsoft Excel + Producer: iLovePDF — the file was processed by an online editor
Creator: LibreOffice + Producer: Adobe Acrobat — the file was opened and re-saved in Acrobat
Creator: (empty) + Producer: FPDF — programmatically generated, may be a reconstructed document

The tool also looks for editors known to be used for document fraud: certain online PDF editors, specific versions of commercial tools with known history-stripping features.

4. Digital Signature Integrity

PDF supports cryptographic digital signatures (/Sig objects). When a signed PDF is modified:

The signature covers specific byte ranges of the file
If content outside those byte ranges is modified, the signature becomes invalid
If the signature object itself is removed and the document re-saved, the absence of a previously-present signature is detectable via the revision history

5. Object Stream Anomalies

PDF 1.5+ supports compressed object streams. Legitimate PDF generators produce consistent, well-formed object streams. Anomalies we check for:

Objects with inconsistent generation numbers
Orphaned objects not reachable from the document root
Objects that exist in the xref table but whose byte offsets point to different object types (indicates partial overwrite attempts)

Putting It Together: The Confidence Score

No single signal is conclusive. A document with ModDate > CreationDate might be completely legitimate. A document with matching timestamps might have been forged with a tool that resets them.

Detection tools combine multiple signals into a weighted confidence score:

Signal	Weight	Rationale
Multiple xref sections	High	Hard to fake without specialized knowledge
Creator/Producer mismatch with known editor	Medium-High	Common in legitimate workflows too
Timestamp anomaly (impossible date)	High	Never legitimate
Timestamp anomaly (reset to match)	Medium	Detectable but requires suspicion
Known fraud-associated producer	Medium	Context-dependent
Digital signature removed	High	Strong indicator of post-signing modification

A score above a threshold produces a “Modified” verdict. Below the threshold: “Original”. The threshold is calibrated to minimize false positives on legitimate documents.

False Positives: When Unmodified PDFs Look Modified

This is where the method has real limitations.

Legitimate workflows that trigger modification signals:

PDF/A conversion — archival format conversion modifies the file structure. ModDate will differ from CreationDate even if content is unchanged.
Digital signing — adding a digital signature is a modification. A signed-after-creation document will show multiple xref sections even if the content was never altered.
Optimization — tools like Ghostscript, qpdf, or Adobe Acrobat’s “Reduce File Size” rewrite the entire file, resetting the xref structure but potentially preserving old timestamps.
Printer workflows — some enterprise print systems re-process PDFs (adding watermarks, headers, or compliance stamps) as a routine step.
Email clients — some email clients modify PDF attachments (adding metadata, stripping features) during send or receive.
Merging or splitting — combining PDFs with tools like PDFtk or iLovePDF creates a new document with a new Producer and potentially inconsistent metadata from the source files.

In all these cases, the document content may be perfectly authentic, but the structural signals indicate modification. This is why results should always be interpreted in context.

False Negatives: When Modified PDFs Look Original

More dangerous is the opposite case: a forged document that passes detection.

Techniques that evade detection:

Full reconstruction — printing to PDF (or using print → save as PDF) creates a completely new file with a fresh xref, consistent timestamps, and a single clean structure. All modification traces are lost. The resulting PDF looks freshly created, even if it was forged.
Metadata scrubbing — tools like exiftool or custom scripts can overwrite all metadata fields, including timestamps and creator information, before the file is distributed. A sophisticated forger resets CreationDate = ModDate and sets Producer to match the expected original tool.
Re-export from source format — if the forger has access to the source document (a Word file, for example), they can modify the source and re-export to PDF. The resulting PDF has no modification traces because it was never “modified” — it was created fresh from a modified source.
PDF reconstruction tools — specialized tools can parse a modified PDF and reconstruct it as a clean single-revision file, stripping all incremental save history.

The fundamental limitation: binary detection works on file structure, not content. We can detect that a file’s structure shows signs of modification, but we cannot verify whether the visible text or numbers are correct. A forger skilled enough to reconstruct the PDF properly can evade structural detection entirely.

What This Means in Practice

Binary PDF modification detection is a fast, automated first-line check. It catches:

Naive modifications made with standard PDF editors (the vast majority of document fraud cases)
Metadata inconsistencies that reveal post-creation editing
Structural anomalies that indicate multiple save operations

It does not catch:

Sophisticated forgeries where the PDF was fully reconstructed
Source-level modifications (edit the Word doc, re-export)
Cases where the file was “legitimately” processed by a PDF workflow tool

For high-stakes verification (legal documents, financial instruments, regulated industries), automated detection should be combined with:

Human review of the document content for semantic consistency
Verification of the document’s origin through the issuing party
Cryptographic verification if the original was digitally signed
Chain-of-custody controls that prevent the question from arising

Technical Implementation Notes

For developers building similar tools, the key libraries:

pdf-lib (JavaScript/Node.js) — parse PDF structure, read xref tables, access object streams
PyMuPDF / fitz (Python) — comprehensive PDF analysis, supports most PDF versions
pdfminer.six (Python) — lower-level access to PDF internals
iTextSharp (.NET) — commercial-grade PDF analysis

The core algorithm:

Parse the xref table(s) — count revisions
Extract /Info dictionary — compare timestamps, analyze Creator/Producer
Walk the xref chain via /Prev pointers — identify which objects changed between revisions
Check for /Sig objects — verify digital signature presence and coverage
Score each signal — weight by reliability and combine

The implementation challenge is handling malformed PDFs. Real-world documents frequently deviate from the PDF specification. A robust tool must handle:

Missing or corrupted xref tables (PDF readers use recovery mode)
Linearized PDFs (a different structure used for web-optimized files)
Encrypted PDFs (metadata may be accessible even if content is not)
PDF 2.0 documents with new structural features

Conclusion

Binary PDF modification detection is a reliable heuristic, not a cryptographic proof. It answers the question “does this file’s structure suggest modification?” with high accuracy for everyday document fraud. Against a skilled adversary who understands PDF internals, structural detection alone is insufficient.

The honest answer to “has this PDF been edited?” is: we can tell you what the file’s structure reveals. For most fraud cases — edited invoices, tampered bank statements, modified contracts — that is enough.

HTPBE.tech implements the detection approach described in this article. The web tool is free, requires no registration, and processes PDFs in seconds. The API is available for integration into document verification workflows.

Hackers and scammers target blockchain developers and founders. How to protect yourself?

Mon, 24 Mar 2025 21:14:03 +0000

The new scam is gaining momentum in March 2025, and blockchain developers and project founders are especially at risk. With social engineering tactics becoming increasingly sophisticated, it's important to stay ahead of potential threats. This article outlines some of the most advanced and deceptive scams, particularly those targeting job seekers in Web3, and provides actionable steps to protect yourself.

1. Job Offer Scams and Fake Recruiters

Scammers impersonate recruiters or employees of well-known Web3 companies. They approach blockchain developers on LinkedIn or Telegram with flattering messages and high-paying job offers.
The victim is invited to an "interview," but the scammers claim they use a "secure, in-house video conferencing tool" instead of Zoom or Google Meet.
Once the victim installs the software and joins the interview, their system is compromised, leading to the theft of wallet funds. The attack works by detecting and sweeping funds from hot wallets like MetaMask or Phantom.

How to Protect Yourself:

Never install software from an unknown source, even if it appears to come from a reputable company.

Verify recruiters by checking mutual connections, their work history, and whether they have genuine endorsements.

Use a separate, clean device for work-related communications, especially if you're dealing with crypto assets.

Keep your development machine air-gapped from any wallets holding significant funds.

2. Fake GitHub Repositories and UI Scams

A scammer contacts you with a request to audit or test a GitHub repository. They send a Bitbucket or GitHub link, claiming it's a work-related test or a proof of concept. Sounds legit, and many will not notice anything suspicious. And that would be a fatal mistake.
The repository contains malicious code designed to extract private keys, inject malware, or execute wallet-draining scripts.
The victim runs the provided script or opens a compromised user interface (UI) that requests private key access.

How to Protect Yourself:

Always inspect repositories thoroughly before running any code, especially scripts requiring execution privileges.

Use a sandboxed virtual machine or an isolated environment (e.g., Tails OS) when testing unverified code.

Check commit history and contributors — if a repo has no meaningful history or appears AI-generated, it's a red flag.

Never enter your private key or seed phrase into any website or application outside of a trusted wallet provider.

3. Overpaid Job Offers with Unrealistic Salaries

Scammers offer extremely high salaries (e.g., $150+ per hour or $250K+ yearly) for simple blockchain-related work. Bu there is a “small nuance”. They ask for personal information, including GitHub, CV, and even direct access to test repositories.
Eventually, they request that you install their software, test a smart contract, or deploy a script — one that compromises your system.

How to Protect Yourself:
Be skeptical of job offers with excessive salaries that seem too good to be true.

Validate companies by researching them on official sites, checking real employees, and cross-referencing with known Web3 security experts.

Avoid sending personal data or connecting wallets to unknown platforms before verifying legitimacy.

4. Fake Zoom, Google Meet, and Chat Applications

Scammers claim that for "security reasons," they use a proprietary meeting tool instead of known platforms. They send a link that looks like Zoom, Google Meet, or Telegram but is actually a phishing site.
When opened, the malicious site installs a script that either extracts browser-stored private keys or deploys clipboard hijackers.

How to Protect Yourself:

Always check URLs carefully — phishing domains often contain small typos or extra characters.

Use browser security extensions that detect fake domains.

Run crypto-related communications in a separate, hardened browser profile (e.g., Brave with strict security settings).

Never download standalone meeting software unless it’s from a verified, official source.

Attackers build "legit-looking" LinkedIn profiles with fake endorsements and AI-generated backgrounds. They engage in friendly, long-term social engineering before making their move.
If a victim refuses one scam, they may attempt a different angle — fake token sales, job offers, or investment opportunities.

How to Protect Yourself:

Cross-check profiles using multiple sources. If someone’s work history lacks depth, it's likely fake.

Be cautious of unsolicited offers and overly eager recruiters.

Never let social pressure rush you into downloading files or clicking on unknown links.

Final Thoughts: Stay Vigilant, Stay Secure

As blockchain developers and founders, you're a prime target for scammers due to the nature of your work and access to valuable assets. Implementing strict security measures — such as hardware wallets, separate work environments, and in-depth verification processes — will drastically reduce your risk of falling victim to these scams.

Key Takeaways:
Always verify recruiters and job offers before engaging.
Use sandboxed environments for testing third-party code.
Never install unknown meeting software or click suspicious links.
Keep personal and professional crypto wallets separate.
Treat unsolicited, high-paying offers with extreme skepticism.

If you come across new scams or need further insights, share your experiences — awareness is our best defense.

Coder Legion - Recent posts tagged fraud

There is no such thing as a digital arrest

How the script runs

Why it keeps working

The official position

What to do during the call

How to report it

For organisations

Questions people ask

Sources

The Deepfake That Signed Off on $25 Million: A Teardown of the Arup CFO Video-Call Heist (Feb 2024)

The artifact, in order

What the record does not say

A rule written in 1989

The gates, reverse-engineered

Why the fake was cheap

Move the last line to the top

Confirm through a channel the request did not arrive on.

Building Fraud-Resistant User Onboarding With KYC and Authentication

1. Start with better identity data, not just more identity questions

2. Use risk-based onboarding instead of one fixed flow for every user

3. Verify identity in layers

4. Build authentication into onboarding

5. Pay attention to behavior during the actual signup session

6. Reduce manual review by defining clear escalation rules

7. Protect the onboarding flow from abuse at the system level

8. Review performance often, because fraud patterns keep changing

Endnote

Binary PDF Modification Detection: How It Works and Where It Fails

How a PDF File Is Structured

The Metadata Dictionary

The Incremental Save Mechanism

What Automated Detection Actually Examines

1. Timestamp Consistency

2. Cross-Reference Table Analysis

3. Creator/Producer Mismatch Analysis

4. Digital Signature Integrity

5. Object Stream Anomalies

Putting It Together: The Confidence Score

False Positives: When Unmodified PDFs Look Modified

False Negatives: When Modified PDFs Look Original

What This Means in Practice

Technical Implementation Notes

Conclusion

Hackers and scammers target blockchain developers and founders. How to protect yourself?

1. Job Offer Scams and Fake Recruiters

2. Fake GitHub Repositories and UI Scams

3. Overpaid Job Offers with Unrealistic Salaries

4. Fake Zoom, Google Meet, and Chat Applications

5. Social Engineering and Psychological Manipulation

Final Thoughts: Stay Vigilant, Stay Secure