The significant transition was not simply a convincing synthetic face. In the retained KZ-CERT account, passing the video-verification step enabled a change to a trusted account attribute. The attacker then used the newly trusted phone number to authenticate. The record therefore describes a chain from identity deception into durable account access. ## The…
Inspect the ClaimsCase · DiggingBeagle record
Deepfake-assisted bank video verification preceded trusted-number replacement
KZ-CERT described deepfake-assisted bank video verification followed by replacement of the customer’s trusted phone number and account access. The account describes a recovery takeover, but does not identify the bank or quantify the losses.
Public disclosure: May 16, 2024
Scope
The fraud sequence attributed to KZ-CERT in its 16 May 2024 advisory. The victim bank, incident dates, number of victims, implementation details and loss amount are not established by the retained record.
Assessment profile
Assessment method- Setting
- production
- Exploitation
- observed live
- Impact
- Band 2 of 4
- Evidence
- Grade B
- AI role
- WITH AI
Basis and provenance
Attributed official advisory retained in the corpus. Original source text could not be re-fetched in this pass, and no independent reproduction or present-day applicability was established.
Impact basis: The official account reports takeover of an account authentication path and subsequent transfers. Scale, loss and current exposure are unknown; the score is not a quantified financial-loss rating.
Assessed Oct 1, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-KZCERT-RECOVERY-PIVOT · CLM-KZCERT-TRUSTED-NUMBER · CLM-KZCERT-DEEPFAKE-VERIFY · CLM-KZCERT-DEEPFAKE-CONFIRMED · KZ-CERT advisory on DeepFake-assisted bank video verification
At a glance
## Comparison with agent failures The Comet demonstration and this fraud differ in attacker input and execution: one influenced an assistant handling authenticated sessions, while the other reportedly deceived a bank verification process. Their useful connection is the conversion of a lower-trust input into a higher-impact authority change, not a claim…
Read the implicationsThe affected bank, underlying incident dates, victim count and loss amount are not disclosed in the retained evidence. The exact capture/replay method, liveness checks and bank-side authorization conditions are not available. No current implementation was retested and no institution-specific remediation is established.
Limits and uncertaintyFull account
The significant transition was not simply a convincing synthetic face. In the retained KZ-CERT account, passing the video-verification step enabled a change to a trusted account attribute. The attacker then used the newly trusted phone number to authenticate. The record therefore describes a chain from identity deception into durable account access.
The sequence matters
The attacker first obtained facial video during a messenger call. The advisory then describes use of that material with DeepFake face substitution during bank video verification. Replacement of the trusted phone number followed verification; it was not an established prerequisite that the attacker had already taken over the original number. Subsequent authentication and transfers are reported in the same sequence. Reversing these steps would change the mechanism and the defensive lesson.
The only exact date supported here is the advisory’s publication on 16 May 2024. It should not be presented as the date of every underlying transaction, and DiggingBeagle’s later publication is not a new occurrence of the fraud.
What authority changed
The useful question for a recovery flow is what becomes possible immediately after a claimant passes a check. A phone number can be a contact detail, an authenticator destination or an account-recovery attribute; those roles should not be assumed equivalent. In the reported sequence, changing the trusted number affected later authentication. An isolated assessment of face-matching accuracy would therefore miss the downstream transition that made the deception consequential.
Impact and evidentiary limit
KZ-CERT’s account reports subsequent access and transfers, but the retained evidence does not quantify loss or identify the bank. It does not support extrapolation to all video-identification systems, all Kazakhstan banks, or current implementations. The original page could not be re-fetched in readable form during this enrichment; the incident reconstruction remains attributed to the existing canonical Claims and their source locators rather than being relabelled independently verified.
What a review should examine
A review of a comparable recovery design should trace identity proofing, authority to replace a trusted attribute, independent notification and permission to move funds as separate transitions. This is a proposed review method, not a claim that the unidentified institution lacked every such control. The critical test is whether control of a newly supplied channel becomes sufficient evidence of ownership before the legitimate customer has an independent opportunity to detect or challenge the change.
Mechanism and trust boundary
- 01
Acquire facial video
The retained advisory describes a messenger call used to record the customer’s face.
- 02
Pass bank video verification using substituted media
DeepFake-assisted identity verification is reported before trusted-number replacement.
- 03
Replace the trusted number
The attacker’s number becomes the trusted account attribute in the reported sequence.
- 04
Use the changed authentication path
KZ-CERT reports subsequent authentication and transfers; no amount is established here.
Timeline
- May 16, 2024Event type unspecified
KZ-CERT publishes DeepFake bank-fraud advisory
The advisory describes facial-video capture, DeepFake-assisted bank video verification, trusted-number replacement and subsequent authentication and transfer of funds.
- May 16, 2024disclosure
Public disclosure
Claims & evidence
CLM-KZCERT-RECOVERY-PIVOTThe reported sequence illustrates a high-impact recovery pivot: when successful video verification can authorize replacement of a trusted phone number, defeating that verification step can enable subsequent authentication through the newly trusted number.supported
Basis: inference
Scope: Inference from the specific KZ-CERT sequence; it is not evidence that every bank, every recovery flow or a current deepfake-aware implementation exposes the same transition.
- supportsKZ-CERT advisory on DeepFake-assisted bank video verificationgovernment record
Reported sequence from DeepFake-assisted video verification through trusted-number replacement and authentication using the changed number
CLM-KZCERT-TRUSTED-NUMBERIn the same KZ-CERT sequence, video verification was followed by changing the trusted phone number to the attacker's number, authenticating through the changed number and transferring funds to accounts controlled through third parties.supported
Basis: reported finding
- supportsKZ-CERT advisory on DeepFake-assisted bank video verificationgovernment record
Attack sequence bullets covering trusted-phone-number replacement, authorization through the changed number and subsequent transfer of funds to third-party accounts
CLM-KZCERT-DEEPFAKE-VERIFYKZ-CERT reported that an attacker recorded a bank customer's face during a messenger video call and then used the previously recorded material with DeepFake face substitution while confirming the customer's identity through bank video verification.supported
Basis: reported finding
- supportsKZ-CERT advisory on DeepFake-assisted bank video verificationgovernment record
Attack sequence beginning with the messenger video call and continuing through DeepFake face substitution, bank-application installation and customer identity confirmation by video verification
CLM-KZCERT-DEEPFAKE-CONFIRMEDKZ-CERT specialists explicitly stated that DeepFake technology was used in the fraud type described by the advisory.supported
Basis: reported finding
- supportsKZ-CERT advisory on DeepFake-assisted bank video verificationgovernment record
Paragraph following the attack-sequence bullets in which KZ-CERT specialists state that DeepFake technology was used in this type of fraud
Implications
Comparison with agent failures
The Comet demonstration and this fraud differ in attacker input and execution: one influenced an assistant handling authenticated sessions, while the other reportedly deceived a bank verification process. Their useful connection is the conversion of a lower-trust input into a higher-impact authority change, not a claim that they share the same exploit.
Standards context and conclusion
NIST’s recovery guidance is a design comparison, not retroactive evidence about what an unidentified bank was legally required to do in 2024. The available facts are insufficient for a legal finding. The lesson supported by this account is that recovery must be assessed as an end-to-end authorization flow: a successful check can be dangerous when it authorizes a durable replacement of the customer’s trusted channel.
Controls and mitigations
- DiggingBeagle design recommendation: treat trusted-number replacement as an authenticator/recovery change, not an ordinary profile edit; require assurance appropriate to the resulting authority.
- DiggingBeagle design recommendation: use an independent previously established notification channel and consider risk-based delays or additional review before high-impact actions. These controls were not tested against the reported bank.
- NIST comparison: SP 800-63B-4 treats recovery and binding of new authenticators explicitly and requires recovery notifications within its framework. This is comparative guidance, not an assertion of a binding Kazakhstan obligation.
Unknowns and contradictions
- The affected bank, underlying incident dates, victim count and loss amount are not disclosed in the retained evidence.
- The exact capture/replay method, liveness checks and bank-side authorization conditions are not available.
- No current implementation was retested and no institution-specific remediation is established.
Sources and citation
Material revision history
- Sep 29, 2026 · Published version · first publication · revision 54
- Oct 1, 2026 · Published version · material revision · revision 65Public fields changed: ai_roles, assessment_profile, attack_path, case_kind, implications, links, mitigations, narrative, references, scope, summary, unknowns