Deteção de Criação Massiva de Contas em APIs de IA com Sinais de Dispositivo e Rede (PT-PT)

Uma conta é uma linha numa base de dados. Um dispositivo é um objeto físico pelo qual alguém pagou.

Essa assimetria é a base da deteção de abuso ao nível do dispositivo, e é por isso que uma operação de criação massiva que pode gerar 20.000 contas gratuitamente não consegue gerar 20.000 dispositivos gratuitamente. Em algum lugar, por baixo da camada de conta, existe um conjunto finito de hardware real, caminhos de rede reais e um conjunto de truques usados para fazer com que esse pequeno conjunto pareça grande.

Esses truques têm assinaturas. Esta publicação é um percurso pelos que a análise de dispositivo e rede da Didit emite, o que cada um realmente significa e como os ponderar — por 0,03€ por verificação, ou incluídos no pacote de verificação completa de 0,33€.

Principais conclusões

• As operações de criação massiva reutilizam um substrato físico pequeno por trás de uma grande superfície de contas. A reutilização é detetável.
• Três famílias de sinais são importantes: duplicação (mesmo dispositivo ou endereço, mais de uma vez), integridade (este não é um cliente normal) e rede (este caminho não é o que afirma ser).
• DEVICE_RECOVERED_HIGH_CONFIDENCE é o código único de maior valor para este problema — deteta um dispositivo a regressar após uma limpeza, que é o movimento padrão de regeneração.
• Os códigos de integridade como AUTOMATION_FRAMEWORK_DETECTED e DEVICE_EMULATOR_DETECTED são fortes por si só. Os códigos de duplicação são fracos por si só e precisam de corroboração.
• As ações de aviso são configuráveis por código — recusar, rever ou registar — para que a escada de escalonamento seja sua.
• 0,03€ por verificação autónoma; incluído no pacote de verificação de 0,33€.

As três famílias de sinais

Duplicação — já vi isto antes?

Código	Significado
DUPLICATED_DEVICE_FINGERPRINT	O mesmo dispositivo aparece em mais de uma verificação
DUPLICATED_IP_ADDRESS	O mesmo endereço aparece em mais de uma verificação
DEVICE_RECOVERED_HIGH_CONFIDENCE	Um dispositivo previamente visto a regressar após uma reposição ou reinstalação
EXPECTED_IP_ADDRESS_MISMATCH	O endereço difere do esperado para esta sessão

A Didit faz uma distinção explícita entre um dispositivo duplicado e um dispositivo recuperado, e a diferença é a parte interessante.

Um dispositivo duplicado são duas verificações do mesmo dispositivo — comum, muitas vezes inocente. Um tablet familiar. Uma estação de trabalho partilhada. Um agente de suporte a ajudar um utilizador num fluxo.

Um dispositivo recuperado é um dispositivo que foi limpo, reposto ou teve a aplicação reinstalada, e agora regressou. A Didit ainda o reconhece.

Para a criação massiva de contas, esse segundo caso é o sinal de ouro. O procedimento operacional padrão após um banimento é repor o dispositivo e registar-se novamente — é precisamente isso que faz uma rede “hidra” regenerar-se mais rapidamente do que é podada. DEVICE_RECOVERED_HIGH_CONFIDENCE numa conta nova diz: este hardware já esteve aqui antes, sob uma conta diferente, e alguém teve o trabalho de tentar apagar isso. Quase nada legítimo produz essa combinação numa primeira verificação.

Integridade — este é um cliente normal?

Código	Significado
AUTOMATION_FRAMEWORK_DETECTED	O cliente está a ser controlado por automação, não por uma pessoa
DEVICE_EMULATOR_DETECTED	Um dispositivo emulado em vez de hardware real
DEVICE_ROOTED_OR_JAILBROKEN	O modelo de segurança do sistema operativo foi removido
DEVICE_RUNTIME_HOOKING_DETECTED	Instrumentação em tempo de execução está anexada ao processo
DEVICE_APP_TAMPERED	O binário da aplicação foi modificado
DEVICE_DEBUGGER_ATTACHED	Um depurador está anexado
DEVICE_INTEGRITY_SIGNALS_MISSING	Sinais de integridade esperados estão ausentes

Esta família é qualitativamente diferente da duplicação, e vale a pena ser claro sobre o porquê: estes códigos descrevem intenção.

DUPLICATED_IP_ADDRESS pode acontecer a qualquer pessoa numa universidade. AUTOMATION_FRAMEWORK_DETECTED num fluxo de verificação significa que alguém está a conduzir uma verificação de identidade com um script. DEVICE_EMULATOR_DETECTED significa que o “telefone” que completa a sua verificação é software a correr num servidor — a forma mais barata de fazer uma máquina parecer cem. DEVICE_APP_TAMPERED significa que o binário do cliente foi modificado, que é o que se faz quando se quer que ele reporte coisas que não são verdadeiras.

Farms de emuladores e frameworks de automação são as ferramentas industriais da criação massiva de contas. Quando aparecem numa verificação, a explicação inocente é frágil.

DEVICE_INTEGRITY_SIGNALS_MISSING é o mais subtil. Não diz que algo está errado — diz que os sinais que indicariam que nada está errado não chegaram. Trate a ausência como um negativo fraco em vez de um neutro, porque suprimir a telemetria é, por si só, uma técnica.

Rede — este caminho é o que afirma ser?

Código	Significado
PRIVATE_NETWORK_DETECTED	Um caminho de rede privado ou anónimo
COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP	A geografia do documento e da rede não coincidem
IP_LOCATION_NOT_ALLOWED	A localização está fora da sua política configurada
IP_ADDRESS_IN_BLOCKLIST / IP_ADDRESS_IN_ALLOWLIST	O endereço correspondeu a uma das suas listas
DEVICE_FINGERPRINT_IN_BLOCKLIST / DEVICE_FINGERPRINT_IN_ALLOWLIST	O dispositivo correspondeu a uma das suas listas
LOCATION / NO_ACTION	Informativo

Os sinais de rede são a família mais fraca e devem ser ponderados em conformidade. Desenvolvedores preocupados com a privacidade usam rotineiramente redes anónimas, e a população de uma API de IA é mais técnica do que a média — uma taxa de base mais alta de uso de rede privada é esperada, não suspeita.

COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP é mais útil do que a geografia bruta porque é uma contradição em vez de uma localização. As pessoas viajam e as pessoas mudam de local, por isso não é condenatório por si só, mas combinado com um sinal de duplicação, torna-se consideravelmente mais forte.

Os códigos de “blocklist” e “allowlist” são a parte da aplicação — abordados em profundidade na publicação sobre propagação de “blocklist”.

Ponderação: o que é forte, o que é fraco

O erro de implementação mais comum é tratar cada aviso como equivalente. Não são remotamente equivalentes.

Fortes por si só — base razoável para recusar ou rever rigorosamente:

DEVICE_EMULATOR_DETECTED · AUTOMATION_FRAMEWORK_DETECTED · DEVICE_APP_TAMPERED · DEVICE_RUNTIME_HOOKING_DETECTED · IP_ADDRESS_IN_BLOCKLIST · DEVICE_FINGERPRINT_IN_BLOCKLIST

Fortes em contexto — escalar quando combinados com qualquer outra coisa:

DEVICE_RECOVERED_HIGH_CONFIDENCE · DEVICE_ROOTED_OR_JAILBROKEN · COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP

Fracos sozinhos — corroborar antes de agir:

DUPLICATED_IP_ADDRESS · PRIVATE_NETWORK_DETECTED · DUPLICATED_DEVICE_FINGERPRINT · DEVICE_INTEGRITY_SIGNALS_MISSING

O padrão é consistente: os códigos que descrevem manipulação deliberada do cliente são fortes; os códigos que descrevem recursos partilhados são fracos. Os recursos partilhados têm milhares de explicações inocentes. Um binário modificado não.

Configurar a resposta

As ações de aviso são configuráveis por código, para que possa construir uma verdadeira escada de escalonamento em vez de uma única porta de passagem/falha.

Um padrão de funcionamento para uma API de IA:

• Recusar em DEVICE_APP_TAMPERED, DEVICE_EMULATOR_DETECTED, AUTOMATION_FRAMEWORK_DETECTED e qualquer ocorrência de “blocklist”. Uma correspondência de “blocklist” força uma recusa por design.
• Rever em DEVICE_RECOVERED_HIGH_CONFIDENCE e em DEVICE_ROOTED_OR_JAILBROKEN.
• Registar apenas em DUPLICATED_IP_ADDRESS, PRIVATE_NETWORK_DETECTED e LOCATION — capture-os para correlação, mas nunca aja sobre eles sozinhos.

Os códigos apenas registados não são desperdiçados. São eles que possibilitam uma investigação seis semanas depois, quando a sua camada de tráfego sinaliza uma conta e precisa de saber o que mais ela toca. Recolhê-los no nível mais barato, como descrito na arquitetura de acesso com base no risco, é o que permite que a correlação posterior funcione.

Leitura dos sinais numa sessão

Os resultados de dispositivo e rede chegam com a decisão da sessão:

curl -X GET 'https://verification.didit.me/v3/session/{sessionId}/decision/' \
  -H 'x-api-key: YOUR_API_KEY'

Direcione com base nos avisos, não apenas no estado de nível superior. Uma sessão aprovada que contenha DUPLICATED_DEVICE_FINGERPRINT e DEVICE_RECOVERED_HIGH_CONFIDENCE é aprovada e merece uma análise mais aprofundada — e se apenas ler o estado, nunca saberá.

A Didit também revela correspondências entre sessões, que é como se passa de um único aviso para o conjunto de outras sessões que partilham esse dispositivo ou endereço. Essa é a transição de uma conta para um cluster.

Casos de uso

Plataformas de API de IA a recolher sinais de dispositivo e rede no nível pago mais barato para que os dados de correlação existam antes de serem necessários.

Programas de teste gratuito e de crédito onde as “farms” de emuladores são o vetor de abuso dominante e DEVICE_EMULATOR_DETECTED sozinho remove a maior parte do volume.

Mercados e plataformas de serviços a detetar vendedores ou estafetas removidos que regressam em hardware limpo.

iGaming a aplicar regras de conta única e autoexclusão, onde a recuperação de dispositivos é a evasão padrão.

Perguntas frequentes

Isto funciona na web, ou apenas em aplicações móveis?

Ambos. A profundidade dos sinais de integridade é maior em dispositivos móveis nativos, onde o sistema operativo expõe mais — códigos como DEVICE_ROOTED_OR_JAILBROKEN e DEVICE_APP_TAMPERED são conceitos de aplicações nativas. As sessões web ainda produzem sinais de rede e correlação de dispositivos.

Um atacante determinado pode derrotar o “device fingerprinting”?

Sim, parcialmente — é por isso que é uma família entre várias e não a resposta completa. O objetivo não é uma identificação perfeita, é o custo. Cada camada de evasão que um operador adiciona custa-lhe dinheiro e tempo de engenharia, e as ferramentas de evasão por si só ativam códigos de integridade. Um atacante que tenha derrotado o “device fingerprinting” é geralmente visível numa das outras famílias de sinais.

O que é que 0,03€ realmente compra?

Uma verificação de IP e análise de dispositivo numa sessão, retornando o catálogo completo de avisos. É faturado por verificação bem-sucedida sem mínimo, e já está incluído quando executa o pacote de verificação completa de 0,33€.

Um sinal de rede privada é suficiente para recusar?

Não, e recusar com base nisso custar-lhe-á programadores reais. Para uma audiência técnica, as redes anónimas são comuns. Registe-o e use-o como corroboração.

Como é que isto se relaciona com a deteção de destilação no tráfego?

Não deteta destilação. Os sinais de dispositivo e rede informam-no sobre o cliente e a conta, nunca sobre o conteúdo do tráfego da sua API. A deteção semântica é uma camada separada que reside na sua própria pilha. Estes sinais informam-no sobre quantas contas um operador está a executar; a sua camada de tráfego informa-o sobre o que eles estão a fazer com elas.

Pronto para começar?

A análise de dispositivo e rede é uma única verificação em qualquer sessão de verificação.

• Leia a documentação — Visão geral da Análise de IP e Dispositivo e o catálogo completo de avisos.
• Veja o produto — Verificação de Utilizador.
• Verifique os preços — 0,03€ por verificação, incluído no pacote de 0,33€, sem mínimos.
• Comece gratuitamente — business.didit.me, 500 verificações KYC por mês sem custos.