A developer can pass a technical interview, deliver useful work, earn the trust of a team, and still become one of the organization’s biggest security risks later.
That is the challenge highlighted by recent U.S. prosecutions and security warnings involving alleged North Korean IT workers who obtained remote jobs at cryptocurrency and technology companies using false identities, facilitators, and remotely operated devices.
The danger is not limited to fake résumés or suspicious interviews.
Once hired, a developer may gradually gain access to source code, cloud infrastructure, deployment systems, payment services, smart contracts, and other systems capable of moving real money.
That makes the threat an employment-lifecycle problem, not just a recruitment problem.
FBI warns about North Korean IT worker schemes
The FBI’s October 13 warning described networks that allegedly help North Korean IT workers obtain remote employment while concealing their real identities and locations.
Facilitators may provide:
- Stolen or false identities
- Local mailing addresses
- Employer-issued device hosting
- Interview assistance
- Remote computer access
- Payment infrastructure
This means the person listed on an application may not always be the same person performing the work.
The applicant and the actual operator can be different
A normal recruitment process assumes one consistent person exists behind the résumé, video interview, laptop, and employee account.
The FBI warning suggests those elements can be divided among several people.
One person’s identity may appear on the application.
Another person may attend an interview.
A third person could ultimately perform the work.
The employer may see each part individually and fail to realize they do not belong to the same person.
A local laptop does not prove the worker is local
Companies often ship managed laptops to remote employees because they want more control over software, security, and access.
That does not necessarily establish who is operating the computer.
The FBI has described arrangements in which a laptop remains at a local address while someone elsewhere accesses it remotely.
That makes location-based checks less reliable if they only confirm where the physical device is sitting.
Remote work makes the model easier to hide
Remote employment creates legitimate reasons for workers to connect from different locations, use remote tools, and work through distributed infrastructure.
Attackers can exploit those normal practices.
A suspicious setup may look very similar to a genuine remote-work arrangement.
That means companies need to evaluate several signals together rather than relying on one indicator.
The worker can be technically competent
One of the most dangerous assumptions is that a fraudulent applicant must perform badly.
They may be capable developers.
They can ship useful code, solve technical problems, and earn strong internal reviews.
That useful work can actually increase risk because successful employees are often given more responsibility.
Trust becomes the route through which additional permissions are granted.
Prosecutors allege more than $900,000 was stolen
A June 2025 U.S. indictment described developers allegedly hired by an Atlanta blockchain research company and a Serbian token business.
According to prosecutors, the employers did not know the workers’ real identities.
The developers were later given projects that provided access to crypto assets.
Authorities alleged that more than $900,000 was eventually stolen.
The allegations remain subject to the court process.
One alleged theft involved smart-contract changes
According to the indictment, one of the alleged thefts involved modifications to two smart contracts.
That is an important example because it shows that attackers do not always need to steal a wallet seed phrase.
If a developer has enough authority over production code, they may be able to alter how the application itself handles money.
A small code change can have a very large financial effect.
Code access and money access can become closely connected
A crypto company may separate wallets from engineering systems.
But developers can still influence how transactions are created.
For example, code can determine:
- Payment destinations
- Withdrawal conditions
- Contract permissions
- Fee recipients
- Treasury workflows
- Administrative roles
A developer capable of changing those rules may influence funds without directly possessing a private key.
Trust reportedly developed before the theft
The timing of the alleged Georgia case is particularly important.
Prosecutors said the developers were hired in 2020 and 2021.
The alleged thefts occurred later, in 2022.
That suggests the opportunity developed over time rather than through one immediate intrusion.
The employees allegedly entered through a normal hiring process, completed work, and later gained access to more sensitive responsibilities.
Security should follow authority growth
A developer may begin with permission only to read a repository.
Later they may gain the ability to:
- Merge code
- Approve pull requests
- Deploy production releases
- Access cloud systems
- Manage secrets
- Operate financial services
Each step increases authority.
Companies should treat those changes as separate security decisions rather than assuming the original hiring check covers everything permanently.
Kraken caught a suspicious applicant before hiring
Kraken has described a recruitment attempt involving an applicant it linked to a suspected North Korean operation.
The exchange said it had already received warnings from industry partners about suspicious applicants.
During the hiring process, Kraken noticed inconsistencies and investigated further.
The applicant was stopped before receiving production access.
Industry intelligence can improve hiring defenses
Kraken’s example shows why shared security information can be useful.
A suspicious email address or identity detail may mean little by itself.
If the same identifier has appeared in another investigation, it becomes more meaningful.
However, companies still need to avoid treating one signal as definitive.
A fraudulent applicant may be using the identity of an innocent person.
FBI warns against relying on single indicators
The FBI has emphasized that individual warning signs can be unreliable.
Remote-access tools, unusual locations, or changing payment details can all have legitimate explanations.
Automatically rejecting applicants based on one characteristic could exclude qualified people while failing to catch sophisticated operations.
A layered assessment is more effective.
Technical interviews answer only one question
A technical interview can show whether someone understands programming.
It does not prove:
- Who they really are
- Who will operate the employer’s laptop
- Whether the identity documents belong to them
- Whether they will later misuse access
Technical ability and identity assurance are different problems.
Companies need to evaluate both.
Salary itself can be part of the objective
Not every operation needs to steal a company’s cryptocurrency.
Some schemes may simply aim to collect legitimate wages under false identities.
That can still create serious sanctions, compliance, and fraud exposure for the employer.
The U.S. Justice Department previously described millions of dollars in alleged employment income being moved through cryptocurrency as part of these schemes.
More than $7.74 million was targeted in a forfeiture action
A June 2025 forfeiture complaint involved more than $7.74 million allegedly connected to North Korean IT worker operations.
Authorities described income earned through employment arrangements and later transferred through crypto infrastructure.
That is a different financial path from stealing a company’s treasury.
Both can produce revenue for the same broader operation.
A company can lose money without noticing missing crypto
This is why treasury monitoring alone is not enough.
A company may check its wallets and find no missing assets.
Yet it could still have paid salaries to someone using a false identity.
It may also have legal exposure if payments ultimately benefited sanctioned entities.
Payroll, identity verification, and security need to be examined together.
Employee referrals can expand the threat
An insider who has earned trust may recommend another candidate.
In normal companies, employee referrals are common and useful.
In a coordinated fraudulent operation, that recommendation could help another person gain access.
The indictment reportedly included allegations involving a recommendation that led another company to hire someone using an alias.
Contractor relationships create similar risks
The same problem can arise through outsourcing.
A company may approve a contractor or consulting firm without meeting every developer assigned to its project.
The contractor’s own identity checks then become part of the customer’s security model.
If several clients share the same developer environment, one compromise can potentially affect multiple organizations.
A shared contractor account makes attribution harder
Project teams sometimes share service accounts or development environments.
That can save operational effort.
But it can make it difficult to determine which person performed a sensitive action.
Strong audit trails should link individual people to:
- Code changes
- Cloud access
- Deployments
- Administrative actions
Shared credentials weaken that accountability.
Repositories often contain more than code
Source repositories can expose valuable operational information even when no credentials are stored directly.
A developer may learn:
- Infrastructure architecture
- Deployment methods
- Wallet integration logic
- Environment naming
- Internal service addresses
- Authentication patterns
Poorly managed repositories may also contain actual secrets.
Read access can therefore be useful to an attacker even before they receive write privileges.
Deployment systems can be more dangerous than repositories
A repository may require multiple code reviews before changes are merged.
But the deployment pipeline can have its own credentials and permissions.
If someone can alter the build process or release configuration, they may affect what reaches production even when the main source code looks normal.
Security reviews need to cover the full software supply chain.
Internal financial systems matter too
Crypto firms may keep customer balances in internal databases.
An exchange, for example, may update customer balances internally without sending an onchain transaction for every trade.
Access to those systems can therefore have financial consequences.
A malicious user may not need direct wallet authority if they can manipulate the systems that determine which withdrawals get created.
Small malicious changes can have large effects
A malicious code change may be only a few lines long.
What matters is the function it controls.
Changing a destination address can redirect funds.
Changing a permission check can bypass authorization.
Changing a withdrawal condition can create an unauthorized payment path.
The percentage of the codebase modified tells little about the importance of the change.
Code review must focus on consequences
Reviewers need to understand what a change actually controls.
A test showing that the application still launches successfully may not catch a changed payment destination.
Likewise, normal tests may miss rarely used administrative paths.
Security review should focus particularly on code touching:
- Payments
- Permissions
- Withdrawals
- Authentication
- Contract upgrades
- Treasury functions
Familiarity can weaken review discipline
This threat becomes more difficult after the employee earns trust.
Reviewers may think:
“This person has worked with us for months.”
That familiarity can make people less skeptical.
Good security processes need to continue working even when the developer is considered a reliable colleague.
Emergency access deserves extra scrutiny
Incidents can create another opportunity.
During an outage or emergency, teams may give a skilled engineer temporary elevated access so they can solve the problem quickly.
That may be operationally necessary.
But it also creates a moment when one employee has more power than usual and everyone else is under pressure.
Temporary permissions should be logged and removed afterward.
Data theft may happen before financial theft
An employee does not need to move crypto immediately.
They may first copy:
- Source code
- Customer data
- Business plans
- API credentials
- Internal documents
That data can remain valuable long after the employee leaves.
This creates another risk beyond direct financial loss.
Google has warned about extortion involving company data
Google Threat Intelligence Group has reported that North Korean-linked IT worker activity expanded into Europe and included extortion involving information taken from former employers.
That broadens the threat.
A worker may earn salary first, collect valuable information, and later use the data for pressure or additional attacks.
Offboarding cannot recover copied information
Removing an employee’s account stops future access through that account.
It does not erase data already copied.
This is why companies need to determine what information the person could access while employed.
If sensitive credentials may have been viewed, those credentials may need to be rotated.
If sensitive data may have been copied, legal and incident-response teams may also need to become involved.
HR, finance, IT, and managers each see different clues
A sophisticated scheme can remain hidden because each department sees only part of it.
Human resources may see identity documents.
Finance sees payment details.
IT sees devices and connection logs.
Managers see work performance and access requests.
Each detail can appear reasonable by itself.
Cross-team analysis can reveal patterns
The FBI recommends looking at these observations together.
For example:
A worker changes their payment account.
The person appearing in video meetings changes unexpectedly.
The employer-issued laptop uses unusual remote access.
The employee requests broader cloud privileges.
Each event may have a harmless explanation.
Together, they may justify additional review.
Identity fraud can hurt innocent people
Companies also need to avoid assuming that the individual whose identity appears in fraudulent paperwork is responsible.
The identity may have been stolen.
That means investigations should focus on evidence about the actual operator.
Nationality, accent, or ethnicity are not reliable substitutes for technical and employment records.
The threat is behavior and concealed control
The core problem is not where someone comes from.
The problem is whether:
- Their identity is false
- Another person is operating their account
- Their device is being remotely controlled
- They misuse privileges
- Their payments are being diverted
Security decisions should be based on those facts.
Termination does not automatically remove every access route
Offboarding a suspicious employee requires more than disabling email and Slack.
The person may have created or received:
- Code-hosting tokens
- Cloud credentials
- API keys
- Vendor accounts
- Deployment certificates
- Wallet permissions
Every route needs to be reviewed.
Deployed smart-contract changes can outlive the employee
A company can disable an employee account immediately.
It cannot necessarily undo an already deployed contract change just as easily.
Blockchain changes may require:
- A new transaction
- A contract upgrade
- Governance approval
- A migration
This is another reason access control before deployment is critical.
Permission inventories help after an incident
Companies should be able to reconstruct what an employee could actually do.
That includes:
- Repository roles
- Production permissions
- Cloud access
- Secret access
- Financial system roles
- Deployment authority
Without that record, an incident investigation begins with uncertainty.
Good records can also limit unnecessary panic
An investigation may ultimately show that a suspicious employee only had access to a test environment.
They may have requested production access but never received it.
Those distinctions matter.
A false identity does not automatically prove that customer assets were compromised.
Incident reports should separate confirmed access from suspected intent.
A fake applicant is different from a fake recruiter
Crypto companies face another related attack route.
Instead of a fraudulent worker joining a company, attackers may approach legitimate developers with fake job offers.
They may ask the employee to run code or complete a technical assignment that installs malware.
That compromises an existing employee rather than placing a new one inside the business.
The resulting account can look legitimate in both cases
Whether the attacker was hired directly or compromised a real employee, the system may see an authorized developer account.
Logs identify the account.
They do not automatically identify the human controlling it.
Endpoint investigation, identity records, and access patterns are needed to determine what happened.
Employment security must continue after onboarding
Traditional hiring checks often end when the employee starts.
These cases show why security needs to continue throughout the relationship.
A worker may receive additional responsibilities months later.
Each major increase in authority should trigger appropriate review.
That is particularly important in crypto businesses where one permission change can place millions of dollars within reach.
Useful security controls include least privilege
Developers should receive only the permissions required for their current tasks.
A front-end engineer may not need production treasury access.
A contract developer may not need cloud billing permissions.
Keeping privileges narrow limits what one compromised or malicious account can reach.
Production deployment should require separation of duties
One person should not ideally be able to write sensitive code, approve it, and deploy it alone.
Separating those responsibilities makes abuse more difficult.
For high-risk smart-contract changes, teams can require:
- Independent code review
- Multiple approvals
- Automated security testing
- Reproducible builds
- Multisig deployment authority
The goal is to prevent one trusted account from becoming the only control.
Payment authority should be separated from development
A developer may need to create the logic that prepares payments.
They do not necessarily need the authority to approve the final transfer.
Keeping transaction creation and transaction signing separate reduces risk.
Hardware wallets and multisig can provide strong controls at the final stage.
But those controls work best when signers can clearly verify what the application is asking them to approve.
Security teams should monitor privilege growth
A developer who begins with low-level access may eventually accumulate many roles.
That is sometimes called permission creep.
Periodic access reviews can identify privileges that are no longer needed.
They can also highlight unusual combinations of authority.
The local-device relay problem needs specific controls
Managed laptops are useful but not sufficient.
Organizations may need to monitor:
- Remote-control software
- Unexpected peripherals
- Connection patterns
- Approved login locations
- Device posture
- Session behavior
The objective is not to ban normal remote work.
It is to confirm that the approved employee is actually the person controlling the device.
Payment changes deserve independent verification
Changes to salary or contractor payment instructions can be another useful signal.
A sudden request to send wages to a new bank account or crypto wallet may be legitimate.
But high-risk changes can be independently verified through an existing trusted channel.
This is useful for preventing both worker fraud and ordinary business-email compromise.
Industry reporting can stop later attacks
A company that detects a suspicious applicant before hiring may still have valuable information.
Kraken’s case illustrates how sharing indicators through appropriate security channels can help other firms recognize patterns.
An attempted intrusion is still useful intelligence even if the attacker never gained access.
Attempts and confirmed breaches should remain separate
Reporting should distinguish clearly between:
- Suspicious applicant
- Confirmed false identity
- Employee with production access
- Malicious code change
- Confirmed asset theft
Those are different stages.
Combining them can exaggerate the scope of an incident.
Following the money is another investigation
Identifying a suspicious worker does not automatically identify where wages or stolen funds went.
Payments can pass through:
- Bank accounts
- Crypto wallets
- Exchanges
- Other intermediaries
Blockchain tracing can help follow crypto movements.
But identifying the people controlling each step may require additional evidence.
Freezing funds and recovering funds are different
Authorities may identify and freeze assets.
That does not automatically mean the victim receives them immediately.
A forfeiture complaint, seizure order, and final return of funds are separate stages.
Companies should distinguish amounts sought by authorities from amounts actually recovered.
A company can face sanctions risk even without theft
If an employer unknowingly pays a sanctioned operation through a fraudulent employee arrangement, the company can face compliance concerns even when no treasury assets are stolen.
That is why hiring and payroll processes belong inside the security discussion.
The financial risk begins before a developer ever touches a production wallet.
The interview is only the beginning
A successful interview grants an opportunity.
Employment creates access.
Successful work creates trust.
Trust creates additional permissions.
The threat becomes dangerous when those permissions reach systems capable of changing code, infrastructure, or money.
That progression explains why recruitment screening alone cannot solve the problem.
What crypto companies should watch
Identity consistency:
The person in the documents, interviews, work sessions, and device activity should remain consistent.
Access expansion:
Repository, deployment, cloud, and payment permissions should be reviewed as responsibilities change.
Remote-control patterns:
A laptop at a local address may still be operated from somewhere else.
Code changes:
Financially sensitive changes deserve independent review and deployment controls.
Payment information:
Changes in payroll or contractor destinations can provide additional context.
Offboarding:
All credentials, service accounts, deployments, and copied information should be considered.
Final thoughts
The most difficult insider threat may not look like an attacker at all.
It may look like a successful employee.
A developer can pass the interview, complete projects, communicate normally with colleagues, and build the trust needed to receive progressively stronger access.
That is what makes the threat described by U.S. authorities particularly relevant to crypto companies.
The risk begins with identity deception, but it becomes financially dangerous through ordinary business processes.
Repository access becomes deployment access.
Deployment access can affect smart contracts.
Cloud credentials can reach financial systems.
A trusted developer can eventually sit close to the company’s assets.
The strongest defense is therefore not a single hiring check.
It is a security model that follows the employee throughout the full lifecycle, verifies identity and device control, limits privileges, separates critical duties, records changes, and makes sure that no single account becomes powerful enough to quietly turn legitimate development access into control over the company’s money.
